场景Pod 一直 CrashLoopBackOffkubectl logs 看不到崩溃前的错误日志路径坐标 → 分层 → 路径 → 定位 → 标点以下排查基于 K8s v1.25容器运行时为 containerd v1.6。crictl 命令在 containerd v1.6 支持-a参数查看所有容器。坐标上篇我们讲了 Init Container 耗时导致 Pod 启动慢——串行执行的 Init Container 把启动时间从 15 秒拉到了 3 分 20 秒。这次换个场景Pod 不是启动慢是一直重启——CrashLoopBackOff 状态而且kubectl logs看不到日志。一个 Pod 上线后状态在 CrashLoopBackOff 和 Running 之间反复切换。kubectl get po -w 看到的节奏Running → CrashLoopBackOff → Running → CrashLoopBackOff——每次 Running 只维持几秒。团队的第一反应看日志。kubectl logs 一看——空的。或者说只有 JVM 启动的几行日志崩溃前的错误栈完全看不到。“应用是不是没打日志”——排查方向一开始就歪了。日志不是消失了——是容器每重启一次上一个容器的 stdout/stderr 就被新容器覆盖了。kubectl logs读的是当前 running 容器实例的 stdout不是持久化存储。理解这点需要先看 K8s 的日志链路kubectl logs → kubelet每个 Node 上的节点代理管理 Pod 生命周期→ CRIContainer Runtime InterfaceK8s 与容器运行时之间的通信接口→ 容器的 stdout/stderr。kubelet 收到 logs 请求后调用 CRI 的ContainerStatus()获取当前容器 ID再调用ContainerLogs()拉取这个实例的 stdout。上一个实例退出了它的容器 ID 就从当前变成了前一个。如果不告诉 kubelet 你要看上一个人的日志它默认只给你看当前这个人。分层CrashLoopBackOff 日志拿不到的问题核心涉及 Pod 层和 CRI 层。Node 层和集群层与容器 stdout/stderr 获取无关跳过。第一层Podkubectl logs 的边界kubectl logs 默认读取当前正在运行的容器实例的 stdout/stderr。容器崩溃→kubelet 重启→新容器实例产生新容器 ID——这时 kubectl logs 指向的是新实例它的 stdout 只有启动日志。kubectl logs --previous可以拿到上一个实例的日志。kubelet 在容器重启时会记录前一个容器 ID--previous参数让 kubelet 用这个 ID 发起 CRI 的ContainerLogs()请求。但 --previous 也不是万能的。如果容器启动后还没来得及写数据到 stdout 就崩溃——比如 JVM 在类加载阶段因为配置冲突直接 abort——上一个人的 stdout 也几乎没有内容。第二层CRIcrictl logs 的兜底当 kubectl logs 和 --previous 都拿不到时排查要下沉到 CRI 层。容器运行时containerd不只在容器运行时管理 stdout/stderr——每个容器的日志会被写入宿主机文件系统即使容器退出这个文件也不会被立即删除。# 查看所有容器包括已退出的crictlps-a# 查看已退出容器的日志crictl logscontainer-idcontainerd 把每个容器的 stdout/stderr 写入/var/log/pods/namespace_pod_uid/container/0.log。容器退出后这个文件仍然存在直到 Pod 被删除。所以即使容器已经 restart 了三次crictl logs 拿到的是第一次启动时的 stdout——包括那个导致崩溃的异常堆栈。kubectl logs 和 crictl logs 的差别在于一个经过 kubelet 的当前容器语义层一个直接拿容器的日志文件。前者有实例概念当前 vs 前一个后者没有——只要 Pod 没删CRI 层的日志文件就在。分层排查顺序总览层级排查目标关键命令适用场景Pod 层当前容器日志kubectl logs pod -n ns容器还在 runningPod 层上一个实例日志kubectl logs pod -n ns --previous容器已重启 1 次CRI 层已退出容器日志crictl logs container-id容器重启多次–previous 拿不到CRI 层日志文件直读ls /var/log/pods/ns_pod_uid/c/0.logcrictl 不可用时路径下次遇到 Pod CrashLoopBackOff 但日志拿不到按这个三层兜底策略来第一层kubectl logs --previouskubectl logs -n production pod— 当前容器日志kubectl logs -n production pod --previous— 上一个实例日志第二层crictl logsCRI 层兜底crictl ps -a | grep image— 查看已退出容器crictl logs container-id— 读退出容器日志第三层容器日志文件直接读取ls /var/log/pods/ns_pod_uid/c/0.log— 直接访问日志文件journalctl -u containerd --since 10 min ago | grep -i error\|exception— journalctl 兜底异常判断标准命令正常异常kubectl logs pod返回应用日志空或只有启动日志 → 容器已重启kubectl logs --previous返回崩溃前日志空 → 容器在写 stdout 之前就崩了crictl ps -a显示 exited 容器容器全部清除 → Pod 已重新调度crictl logs id返回完整日志空 → 日志驱动未配置或文件轮转丢失定位CrashLoopBackOff 日志丢失的问题牵涉两个常见误判从表及里。❌ 误判 A“应用没打日志”第一直觉kubectl logs 拿不到日志 → 应用 stdout 没配置 → 加日志配置再部署。加配置、重建、重启——还是空的。这个问题不在应用侧在 K8s 的容器实例隔离机制上。kubectl logs 读的是当前 running 容器的 stdout/stderr。容器只要重启过之前的 stdout 就被新实例覆盖了。不是应用没打日志是日志打在了上一个实例的 stdout 上。❌ 误判 B“那直接用 crictl logs”第二层直觉kubectl logs 不行就用 crictl logs。crictl logs 确实能拿到已退出容器的日志——前提是这个容器实例还没被 GC 清理。kubelet 的容器 GC 由--maximum-dead-containers-per-container控制默认只保留 1 个前一个实例。容器重启超过 2 次后最早的那个实例已经被 kubelet 清理它的日志文件也随之删除。如果排查时 Pod 已经重启了多次或者 Pod 已被重新调度crictl logs 也会返回空。此外如果容器在打印任何 stdout 之前就崩溃了——比如 JVM 因配置错误在类加载阶段直接 abort——即使 crictl logs 也只能读到一个空的 stdout。这种场景需要另一个机制terminationMessagePath。✅ 正确的排查路径按层兜底kubectl logs → kubectl logs--previous→ crictl logs → container logfile先配兜底为所有 Pod 加上 terminationMessagePath FallbackToLogsOnError分层排查的顺序不能跳第一刀Pod 层kubectl logs 和 --previous。大多数场景下 --previous 就够了——90% 的 CrashLoopBackOff 在第一个 restart 后日志就在前一个实例里第二刀CRI 层crictl ps -a crictl logs。容器重启多次后用到。crictl 的日志文件在 Pod 删除前永久保留第三刀Node 层terminationMessagePath 配置。这是兜底的兜底——在容器不写 stdout 就崩溃时从容器内部捕获最后的输出排查 K8s 日志不是在查 kubectl logs——是在查容器实例的 stdout/stderr。每个容器实例都有自己的 stdout重启即丢失。标点修复方案分两步配置兜底机制 建立 CrashLoopBackOff 排查 check-list。配置 terminationMessagePathkubelet 在容器退出时会检查容器内的terminationMessagePath文件默认为/dev/termination-log。如果该文件存在kubelet 读取其内容作为 Pod 状态的理由。结合terminationMessagePolicy: FallbackToLogsOnError当该文件为空或不存在时kubelet 会回退到容器最后一段 stdout/stderr 日志。apiVersion:v1kind:Podmetadata:name:payment-servicespec:containers:-name:payment-serviceimage:registry:5000/payment-service:3.2terminationMessagePath:/dev/termination-logterminationMessagePolicy:FallbackToLogsOnError# ← 崩溃时回退到最后 4KB 日志resources:limits:memory:1Gi配置后kubelet 在容器退出exit code ! 0时的行为检查terminationMessagePath文件内容如果文件为空或不存在 → 读取容器最后 4KB 的 stdout/stderr将结果写入 Pod 的status.containerStatuses.lastState.terminated.messagekubectl describe pod的 Last State 段即可看到崩溃原因kubectl describe pod payment-service-7d4f8b9c6x-abc12|grep-A5Last Statekubectl describe pod的输出就会显示类似Last State: Terminated Reason: Error Exit Code:1Message: Exceptioninthreadmainjava.lang.IllegalStateException: Database connection pool exhausted at initialization at com.example.App.main(App.java:15)这段 message 就是从崩溃容器的最后 4KB stdout 截取的。即使容器在写 stdout 后瞬间崩溃、kubectl logs 还没来及读这段内容也已经被 kubelet 捕获了。CrashLoopBackOff 排查 Check-list每条对应一个命令kubectl get pods -n ns -o wide | grep CrashLoopBackOff— 确认哪些 Pod 处于 CrashLoopBackOffkubectl logs -n ns pod— 读当前容器 stdoutkubectl logs -n ns pod --previous— 读上一个容器实例 stdoutkubectl describe pod -n ns pod— 看 Last State Message如配了 terminationMessagePathkubectl get events -n ns --sort-by.lastTimestamp -o wide | grep pod— 看 Events 中的 BackOff 信息crictl ps -a | grep image— 找到所有已退出容器crictl logs container-id— 读退出容器的日志ls /var/log/pods/ns_pod_uid/c/0.log— 直接从文件系统读取日志kubectl get pod -n ns pod -o yaml | grep terminationMessage— 验证 terminationMessage 配置故障排查的终点不是修好了——是把排查路径写成 check-list。下篇我们聊 Pod 调度不均衡——nodeAffinity/podAntiAffinity 配置错误导致 Pod 堆积在部分节点上一个节点挂了影响面比预想的大很多。