Kubernetes Pod 崩溃循环分析器

要解决什么问题

Pod 陷入 CrashLoopBackOff 时，kubectl logs 往往只留下最后一次崩溃的尾部输出。真正的原因可能在更早的容器退出记录里，也可能混在 kubectl describe 的事件流中：是配置写错、依赖不可达，还是容器被内核杀掉？靠肉眼翻退出码、对时间线、查内存曲线，既慢又容易漏掉 OOMKilled 这类"看起来是应用报错，实际是内存超限"的信号。

它如何工作

这个技能把诊断拆成三条互相印证的证据链：

• 事件与状态：读取 kubectl describe pod 输出，提取容器的 Last State、Reason 与 Exit Code，而不是只信当前的 Running 假象。
• 退出码分析：针对 126/127、137、143 等常见退出码区分"命令不存在""被 SIGKILL""优雅退出"等不同成因。
• 事件时间线：通过 Kubernetes Events API 拉取 Scheduled、Started、Killing、BackOff 等事件，按发生顺序重建崩溃节奏，判断是启动即退、运行一段时间后才退，还是反复重启。
• 内存交叉验证：当出现 OOMKilled 信号时，用 Prometheus 的 container_memory_rss 指标和 cAdvisor 统计做比对，确认内存是否真的触顶，避免把资源问题误判为应用缺陷。

适用边界与注意点

• 需要在环境中有可用的 Docker 环境，上游明确把它列为前置条件。
• 诊断依赖集群内可访问的 kubectl 上下文与 Prometheus/cAdvisor 数据；指标缺失时，内存维度只能作为参考。
• 它给出的是根因分析结果，不包含自动修复、回滚或重启操作，后续处置仍需人工确认。