Kubernetes Pod 诊断运行手册

要解决的问题

当 Pod 长时间停在 CrashLoopBackOff、被标记为 OOMKilled，或反复报 ImagePullBackOff 时，手动排障往往要在 kubectl describe、日志、Events、节点状态之间来回切换。信息分散会让判断变慢，也容易漏掉早期关键线索。

技能如何工作

这个运行手册把排障拆成可重复的流程：

• 识别故障状态：围绕三类常见异常建立判断入口，先确认 Pod 当前处于哪种失败模式。
• 分层采集上下文：收集 Pod 日志、集群 Events、节点条件和资源配额，而不是只盯着单个容器输出。
• 收敛根因线索：把 OOMKilled 指向内存压力或 limit 配置，把 ImagePullBackOff 引向镜像、Registry 与拉取凭据，把 CrashLoopBackOff 引向启动命令、依赖和配置问题。

适用边界与注意点

它更适合作为标准排查路径：能减少遗漏，但不能替代集群权限和网络环境。若 ServiceAccount 权限不足，或节点与 Registry 之间存在连接问题，采集结果仍会受限。涉及生产环境时，应结合 RBAC、网络策略和变更记录复核结论。