Kubernetes Pod 诊断运行器

要解决的具体问题

• Pod 异常时证据分散：kubectl logs、kubectl exec 和 /api/v1/pods 分别给出不同片段，人工拼装耗时且容易漏掉关键线索。
• 常见异常定位慢：OOMKilled 与 CrashLoopBackOff 的原因可能藏在事件、退出码、日志和资源指标里，需要多步排查。
• 观测依赖不统一：资源使用是否异常通常要结合 metrics-server 的指标判断，缺少统一入口时容易得到片面结论。

核心能力与关键步骤

• 自动执行诊断序列：使用 kubectl exec 进入 Pod 采集运行时信息，用 kubectl logs 拉取应用日志，并通过 /api/v1/pods 获取对象与事件。
• 异常归因：从事件中识别 OOMKilled，结合日志与退出行为分析 CrashLoopBackOff 的触发条件。
• 资源观测：通过 metrics-server 获取 CPU/内存等利用率，辅助判断是配额、限制还是实际负载导致的异常。
• 输出诊断路径：将日志片段、事件信息和资源指标按时间顺序组织，便于进一步复盘与修复。

适用边界与注意点

• 需要可用的 Kubernetes 上下文与足够权限；否则 kubectl 与 API 访问会失败。
• metrics-server 不可用时，只能得到有限的资源侧证据，结论应保留不确定性。
• kubectl exec 依赖镜像内可用的工具链，且可能在受限环境中被安全策略禁止。