KubeHealer 开发实录 (2)：从状态展示到深度根因分析

1. 诊断维度的多层扩展

在完成了基础的 Pod 状态获取后，单一的 Status 字段已不足以描述复杂的故障现场。为了提供更立体的诊断视图，KubeHealer 在维度上进行了三项重要扩展：

1. 时间维度：引入了 Events API 分析。这能帮助排查“故障发生前后的上下文”，例如调度失败或镜像拉取超时的具体报错。
2. 数值维度：实现了对 Exit Code 的解析。不仅显示数字（如 137），更将其翻译为可读含义（如 SIGKILL/OOM）。
3. 配置维度：增加了对容器资源配额的检查，直接读取 Pod.Spec 中的配置。

2. 复盘：被掩盖的 OOM Killed 根因

在开发内存溢出（OOM）诊断功能时，遇到了一个典型且隐蔽的逻辑漏洞。

现象描述： 当一个 Pod 因 OOM 被杀（OOMKilled）后尝试重启，如果此时恰好遇到网络波动导致镜像拉取失败，Kubernetes 会将当前状态标记为 ImagePullBackOff。 初版代码采用了“短路”逻辑：一旦检测到镜像错误，立即返回结果。

问题：这导致了**ImagePullBackOff状态掩盖了实际的 OOMKilled 错误**。

解决方案： 重构了 GetContainerStatus 的逻辑流。即使当前处于镜像故障或等待状态，程序也必须强制检查 LastTerminationState。 只有通过关联分析该字段，才能发现容器虽然当前卡在网络上，但其根本死因是内存溢出。

3. 退出码差异：Exit Code 1 vs 137

在实际测试中发现，虽然 Linux 内核标准的 OOM 信号是 SIGKILL (9)，对应的退出码应为 137（128+9），但部分应用（如 stress 工具）在内存不足时可能被运行时捕获并抛出 Exit Code 1。

这表明，在诊断逻辑中，不能仅依赖退出码数字来判断故障类型。KubeHealer 确立了 Reason 字段优先 的判断原则：只要 Kubernetes 判定 Reason 为 OOMKilled，无论退出码是多少，都应发出内存溢出告警。

4. 资源配置与“noise neighbor”

Kubernetes 最佳实践要求必须为 Pod 设置资源限制。未设置 Limits 的容器可能会消耗节点上的所有可用内存，导致 “noise neighbor”现象，即某个容器过度使用资源，影响同节点上其他容器的稳定性和性能。

KubeHealer 新增了资源分析功能，能够提取并展示：

• Requests (请求值)：调度依据。
• Limits (限制值)：硬性封顶。

当检测到 OOM 时，工具会自动对比当前的 Limits 配置，如果发现 Limits 过小或未设置，将直接给出“建议增加资源限制”的修复指引。

5. 总结

至此，KubeHealer 完成了从“被动展示”到“主动关联分析”的转变。这种不再局限于单一状态字段，而是综合历史状态、事件和配置的分析方法，极大地提高了故障排查的准确率。