技能介绍

它解决什么问题

CrashLoopBackOff 和 OOMKilled 是 Pod 故障里最常见的两类，但它们的直接现象都很模糊：容器反复重启、退出码被重置、kubectl describe 里只有一段循环报错。靠人肉轮询 kubectl logs、切到监控面板翻图表、再对着 Event 流猜原因，往往要花掉大半个下午，而这段时间里服务一直处于不可用状态。

这个技能把这条排查链路压缩成一次自动化分析：你给出目标 Pod，它负责把分散在多个数据源里的证据拼起来，输出根因判断，而不是再给你一份需要自己读的原始日志。

核心能力与工作方式

多源证据关联：同时读取容器日志、集群事件流（Event stream），以及来自 metrics-server 的资源指标，把这三者按时间轴对齐，避免只看日志导致的误判。
基于 kubectl 与 Kubernetes API：不依赖额外的 agent 或旁路采集组件，直接通过现有集群访问路径工作，只要有正常的集群权限就能跑起来。
自动定位根因：针对 CrashLoopBackOff 与 OOMKilled 两类失败做定向归因，区分是应用自身报错、启动探针不通过，还是内存请求/限制设置不合理导致的 OOM 被杀。

典型流程是：先确认 Pod 当前的失败状态与重启次数，再拉取最近一次崩溃前后的日志尾部和相关 Event，最后结合 CPU、内存的历史曲线判断资源是否触顶，从而给出「改配置」「改代码」还是「调资源请求」的结论。

适用边界与注意点

集群前置条件：目标集群需要已部署 metrics-server，否则拿不到资源指标，只能做日志与 Event 层面的分析。
权限要求：运行账号需要具备读取目标命名空间日志、Event 以及 Pod 指标的权限；跨命名空间排查时要确认 RBAC 覆盖范围。
只覆盖两类典型故障：设计目标是 CrashLoopBackOff 与 OOMKilled，其他原因（如节点污点、网络策略阻断、镜像拉取失败）不在它的归因范围内，需要另行排查。
依赖本地环境：上游说明里明确要求可用的 Docker 环境，实际使用前先确认这一条件是否满足。
结论仍需复核：自动归因给出的是高概率原因，涉及生产环境变更前，建议在测试命名空间先验证一次。