Kubernetes 崩溃循环终结者

当工程师排查Kubernetes集群中Pod异常时，常遇到CrashLoopBackOff状态——容器反复重启却找不到明确原因，日志里可能只有零散的错误片段，难以快速关联容器退出码、OOM终止事件或探针失败等核心线索。

要解决的具体问题

• 直接查看Pod日志容易被干扰，无法区分是配置错误、资源不足还是健康检查配置问题；
• 手动对比多个容器的退出码和事件记录效率低，难以快速定位根因；
• 缺乏工具关联容器终止的底层逻辑，导致排查周期延长。

核心能力与关键步骤

该技能通过kubectl与/api/v1/namespaces/{ns}/pods/{pod}/log API端点结合，核心能力是关联容器退出码与三类常见异常：OOM kills、readiness探针失败、配置错误。具体步骤如下：

1. 获取目标Pod的容器状态与重启次数，初步锁定异常容器；
2. 拉取每个容器的完整日志，筛选Exit Code、OOMKilled等关键标识；
3. 交叉分析探针失败日志（如Readiness probe failed）与配置错误提示（如Invalid YAML）；
4. 输出根因定位建议，例如“退出码137+OOMKilled→容器内存超限”或“探针失败→端口配置错误”。

适用边界与注意点

• 依赖可用的kubectl环境与集群API访问权限，需提前完成认证；
• 无法处理因节点故障、网络策略（NetworkPolicy）导致的Pod异常，此类问题需结合集群监控排查；
• 不能替代对业务配置的深度理解，复杂业务场景的根因仍需人工二次确认。