K8s CrashLoopBackOff 解决器

问题：Pod 反复重启，终端里只有一串看不懂的状态

凌晨三点，告警群里弹出一条消息：某个 Deployment 的副本状态是 CrashLoopBackOff。打开终端执行 kubectl get pods，看到的是 Error、ImagePullBackOff，或者是完全没有有效输出的日志。此时最直接的困惑是：容器到底死在哪个环节？是配置缺失导致进程启动即退？是内存超限被内核杀掉？还是镜像层拉不下来？

传统排查方式需要运维人员交替执行 kubectl logs、kubectl describe pod、kubectl events，再根据情况深入到运行时层面用 crictl 检查容器状态。每一步都会暴露新的线索，也意味着更多的命令行操作和上下文切换。

工作方式：围绕三条证据链做诊断

该技能将排查过程拆解为三个数据源，按优先级依次采集和分析：

• Kubernetes API 元数据：通过 /api/v1/pods 端点获取 Pod 的当前状态、重启次数、事件记录。这一层能快速锁定容器是否处于 Waiting、Terminated 状态，以及退出码。
• 容器历史日志：使用 kubectl logs --previous 读取上一次崩溃时的输出。很多情况下，进程退出前的 panic、配置加载失败或缺少依赖的报错都会保留在这里。
• 容器运行时检查：通过 crictl 直接与 CRI 交互，查看容器的详细运行时状态。当怀疑是 OOMKilled 事件或运行时层面的问题（比如挂载路径异常）时，这一步能补充 API 和 kubectl 无法覆盖的信息。

核心判断逻辑围绕三类高频故障展开：

• OOMKilled：对比容器的 limits.memory 与实际内存峰值，确认是资源上限过低还是内存泄漏。
• ConfigMap/Secret 缺失：检查 Pod 引用的配置对象是否存在，以及对应的卷或环境变量是否正确挂载。
• 镜像拉取失败：核对镜像地址、标签是否存在、私有仓库的认证是否过期。

适用边界与注意点

该技能工作在诊断层面，不负责修复。它给出的是定位结论，修复动作仍需要人工执行，比如调整资源配额、补齐配置对象、更新镜像引用。

运行环境需要具备完整的 Kubernetes 访问权限，包括 /api/v1/pods 的读权限和 crictl 的可用性。如果集群使用了非标准 CRI 或受限的运行时插件，crictl 的结果可能需要交叉验证。

另一个限制是：它不能替代完整的可观测性体系。对于偶发性崩溃、网络策略阻断、存储卷挂载超时等更复杂的场景，仍然需要结合 Prometheus、kube-state-metrics 等工具做更长时间的数据采样。