Kubernetes Pod 捕获诊断工具

什么时候需要它：Pod 崩溃循环排查成本高

Kubernetes 里 Pod 反复重启、状态卡在 CrashLoopBackOff 是最常见的棘手问题之一。这类问题往往不是单点故障：可能是内存配额不足触发 OOMKilled、configMap 缺失导致启动失败、探针配置错误导致反复重启，也可能是运行时依赖超时。传统排查需要手动执行 kubectl get events、kubectl logs、kubectl describe，再对比 resource quota 配置和监控数据，步骤分散且容易遗漏关键线索。

它怎么工作：三条线索交叉定位根因

这个技能直接对接 Kubernetes API 和 kubectl debug 能力，用自动化流程完成交叉验证：

1. 拉取运行时线索：通过 API 获取 Pod 关联的 Events、容器 Logs 和命名空间的 ResourceQuota，先排除明显的配置缺失或资源超限。
2. 深入容器排查：借助 kubectl debug 在运行失败的容器里注入诊断工具，检查文件缺失、依赖连接失败这类日志里看不到的内部异常。
3. 关联内存指标：如果日志出现 OOMKill 信号，自动匹配 Prometheus 的容器内存查询结果，确认是突发流量导致的内存超限，还是内存长期占用过高的配置问题。

适用边界：先看前置条件

它的能力聚焦在崩溃循环场景，无法处理集群节点故障、网络策略阻断这类跨层问题。使用前需要确保环境有可用的 Docker 环境，且 kubectl 拥有目标命名空间的查看和 debug 权限。如果集群未配置 Prometheus，内存关联分析这部分会跳过，仅保留事件和日志的基础诊断。