K8s Crashloop 诊断运行手册

要解决什么问题

Pod 陷入 CrashLoopBackOff 时，现象往往比原因更有欺骗性：重启次数在涨，但 kubectl describe 里可能只有一句含糊的 "back-off restarting failed container"。真正的根因通常藏在四个方向里——内存超限被杀（OOMKilled）、ConfigMap 缺失导致配置加载失败、存活探针误判、镜像拉取失败——每一个都指向完全不同的修复动作。人工排查时容易在事件和日志之间来回跳转、凭经验猜测，漏掉一个信号就得多花半小时。

它如何工作

这个运行手册把诊断固化为一条可重复的取证链路：

• 采集现场证据：通过 Kubernetes API 拉取 Pod 事件，并直接调用 /api/v1/namespaces/{ns}/pods/{name}/log 端点获取容器日志，同时检查资源限制配置。
• 结构化归因：不是罗列日志，而是按预设的根因类别逐项排除或确认：

- OOMKilled：比对退出码与资源 limit，判断是否被内存压垮；
- ConfigMap 缺失：检查事件是否显示引用了不存在的配置对象；
- 存活探针失败：区分探针误配与应用启动过慢；
- 镜像拉取错误：定位 ErrImagePull / ImagePullBackOff 类事件。

• 证据对齐结论：把观察到的信号和归因绑定，避免"看到报错就改配置"式的盲目修复。

适用边界与注意点

• 前提是能正常访问集群的 Kubernetes API，且执行环境满足上游对 Docker 环境的要求。
• 诊断质量取决于可观测信号：如果镜像自身的启动脚本有缺陷，或应用崩溃前没有任何日志输出，手册只能指出排查方向，无法替代对业务代码的理解。
• 资源限制类问题需要结合工作负载的真实流量判断，手册提供的是判定入口，而不是容量规划方案。