Kubernetes CrashLoopBackOff 诊断工具

要解决什么问题

Pod 长时间卡在 CrashLoopBackOff 时，kubectl describe 只告诉你容器在反复重启，却不说清原因。真正的线索藏在四处：容器日志里的报错、退出码的语义、节点事件中的 OOMKilled，以及存活探针配置是否合理。工程师排查这类问题，往往要在 kubectl logs、describe pod、事件流和探针配置之间来回切换，拼凑信息。

技能如何工作

该技能通过 kubectl 与 Kubernetes API 采集诊断所需信息：

• 容器日志与退出码：读取退出码判断失败类型，区分应用自身 panic、依赖不可用与被系统终止。
• OOMKilled 事件：检查事件流中的内存驱逐信号，区分内存泄漏与探针超时引发的级联重启。
• 存活探针配置：审查 liveness probe 参数，识别探针阈值过严导致的无谓重启。
• 生成修复步骤：汇总以上线索，输出可直接执行的修复建议。

一个容易混淆的点：Status 是 kubectl 的展示字段，用于给用户直观判断，并非 pod 的 phase；诊断时应以 pod phase 为准。

适用边界与注意点

• 需要可用的 kubectl 与 Kubernetes API 访问权限，且目标集群配置正确。
• 节点层面的问题需单独验证：节点初始化是否正确、节点特有的 Volume Limits，以及节点压力驱逐（node-pressure eviction）。
• 参考官方 pod 生命周期文档时，注意区分学习环境与生产环境的行为差异，并留意不同容器运行时的差异。
• 技能输出的是诊断建议，最终修复仍需在具体环境中验证。