Kubernetes Pod 故障诊断

Pod 反复重启时，你缺的不是命令，而是线索

CrashLoopBackOff 和 OOMKilled 是 Kubernetes 里最“会说话”的两类故障——Pod 不会静默死亡，它会留下一串证据：退出码、事件、上一次容器的日志。但人工排查时，这些证据散落在三四个命令的输出里，很容易被忽略。真正棘手的往往是那些“看起来像镜像问题”却实际是探针配置错误的场景：镜像启动需要 20 秒，而 liveness probe 的 initialDelaySeconds 只给了 5 秒，容器被反复杀死重启，日志里却只写着探针超时。

这个技能要解决的就是“证据收集 + 根因定位”这一段机械但容易遗漏的工作。

它如何工作

核心流程分三步：

• kubectl describe pod：拉取 Pod 当前状态、重启次数、各容器退出码以及 Events 段，识别 OOMKilled、ImagePullBackOff、Unhealthy 等关键信号
• kubectl logs --previous：读取崩溃前容器的上一份日志，而不是当前（可能已退出）容器的输出
• kubectl get events：补充 Pod 级事件之外的集群视角信息

拿到输出后，它会解析几类关键信息：

• 退出码：如 137（SIGKILL，常由 OOM 或探针杀死）、1 或 2（应用自身启动失败）、127（入口命令不存在）
• 资源限制：对照 resources.limits.memory 与实际用量，确认是否被 cgroup OOM killer 终止
• 探针配置：检查 liveness/readiness probe 的 initialDelaySeconds、timeoutSeconds 是否与应用启动耗时匹配

适用边界与注意点

• 它诊断的是“已经发生”的崩溃，不负责预测或容量规划
• 日志输出依赖容器写 stdout/stderr；只写日志文件、不输出到标准输出的应用，能拿到的信息有限
• Events 有默认 TTL，刚发生几分钟内的故障才有完整记录
• 需要集群访问权限，且 kubectl 上下文必须指向正确的命名空间
• 只能基于已有证据推理，无法访问源码或 CI 产物，复杂场景仍需人工结合部署流水线排查