技能介绍

复杂的 Pod 故障排查

当 Kubernetes 中的 Pod 陷入 CrashLoopBackOff 或被 OOMKilled 终止时，初学者和运维工程师往往需要手动执行多条命令。逐一翻找 History 事件与日志往往费时费力，且容易忽略关键的资源配置问题。我们需要一种更结构化的方式来快速定位根因。

诊断流程与核心能力

该技能将常见的排障经验固化为标准流程，直接调用底层 API 和 kubectl 子命令来还原现场：

多维状态收集：自动执行 kubectl describe pod 检查底层状态与 Events，同时配合 kubectl logs --previous 获取崩溃前的日志输出。
Events API 分析：直接请求 /api/v1/namespaces/{ns}/events 端点，过滤出与当前 Pod 强相关的调度和生命周期事件。
根因定位与修复：

- CrashLoopBackOff：深度分析应用输出的 Stderr 和 Stdout，对比历史版本，找出导致启动失败的异常行为。
- OOMKilled：解析内存资源（requests/limits）与实际用量曲线，确认是否因超过 memory.limit 被内核杀掉。

适用边界与注意点

该技能的诊断逻辑基于 Kubernetes 原生状态机制，非常适合处理常见的调度失败、探针超时以及内存溢出问题。不过请注意，它无法替代对业务代码内部逻辑的深度调试；若应用卡在外部依赖（如数据库连接超时），仍需结合具体业务上下文分析。此外，运行环境要求具备正常的 kubectl 上下文，并满足上游仓库声明的 Docker 依赖条件。