技能介绍

要解决的排查痛点

Kubernetes 里 Pod 处于 CrashLoopBackOff、OOMKilled 或 ImagePullBackOff 状态时，表面症状高度相似，根因却完全不同：镜像拉取失败、内存超限被杀、应用启动即崩溃，各自的取证路径并不一样。人工排查往往要在 kubectl describe pod、kubectl logs、kubectl get events 的输出之间来回切换，再逐行筛出有用信息。这个技能针对的就是这段重复劳动：把常见 Pod 故障的归因流程固化下来，直接向 API Server 的日志与事件接口取证，而不是依赖人工翻命令行输出。

核心能力与工作步骤

技能覆盖三类典型故障状态：

CrashLoopBackOff：容器反复重启，重点看应用日志与退出码；
OOMKilled：容器因超出内存限制被杀，重点核对 resources.limits.memory 与实际用量；
ImagePullBackOff：镜像拉取失败，重点检查镜像地址、标签与拉取凭证。

取证方式是直接查询 API Server 的两类资源：

/api/v1/namespaces/{ns}/pods/{pod}/log：拉取容器日志；
/api/v1/events：获取命名空间内与该 Pod 相关的事件记录。

在此基础上，技能会对事件做聚合分析，定位最近的调度、拉取或启动失败点，再结合日志内容判断故障属于哪一类，从而给出可执行的修复方向，比如调高内存限额、修正镜像 tag 或修复启动参数。

适用边界与注意点

这个技能是诊断辅助，不是集群管理工具：它只做故障定位，不会自动重启 Pod、修改资源限额或回滚 Deployment。取证依赖 API Server 的日志接口与事件资源，而事件有留存窗口，Pod 早已被重建的旧故障可能取证不全。此外，上游要求环境中有可用的 Docker 环境，接入前需确认这一点。