Agent Skills
返回列表
🔒

Kubernetes CrashLoop 诊断器

IT 运维与安全 更新于 2026.08.30

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，安装 @user_3c6cb52e/kubernetes-crashloop-diagnostician。

技能介绍

要解决什么问题

CrashLoopBackOff 是 Kubernetes 里最常见的故障形态之一：Pod 反复重启，kubectl logs 往往只留下最后一段输出，真正有用的线索散落在 kubelet 状态、事件记录和容器退出码之间。人工排查时通常要反复回答几个问题：

  • 容器到底为什么退出：应用 panic、启动配置错误，还是被驱逐？
  • 是 OOMKill 造成的，还是存活探针失败后 kubelet 主动重启了容器？
  • 重启有没有规律，比如总是在启动后某个时间点？

把这些线索手工拼起来，既慢又容易漏。

核心能力与工作流程

这个技能通过两条路径收集证据：

  • Kubernetes client-go API：直接读取集群状态，不用人工粘贴 kubectl 输出
  • kubectl debug：在出问题的容器上临时挂载调试入口，抓取运行时现场

诊断大致按以下步骤推进：

  1. 定位处于 CrashLoopBackOff 状态的 Pod 及其容器
  2. 解析容器退出码和重启次数，区分应用自身退出与外部干预
  3. 检查事件流里的 OOMKill 记录，并核对内存限制配置
  4. 分析存活探针（liveness probe）的失败模式与时间线
  5. 汇总结论，输出自动化修复建议

适用边界

  • 需要可用的 Docker 环境，调试阶段依赖容器运行时
  • 需要足够的集群权限，至少能读取目标 Pod 的详情与事件
  • 修复建议是提示性质，不会自动执行变更，落地前仍需人工确认
  • 上游文档提取自 Kubernetes 官方仓库，具体行为可能随版本演进

使用场景

  • 集群中某个 Deployment 的 Pod 反复重启，需要快速定位容器退出码与重启原因。
  • 怀疑容器被 OOMKill，要结合事件记录和内存限制判断是内存不足还是探针误杀。
  • 存活探针配置不当导致无故障的容器被反复重启，需要区分探针失败与应用崩溃。
  • 需要在出问题的容器内临时挂载调试入口抓取运行时信息，而不是手动复制 kubectl 输出。

适合人员

  • 负责 Kubernetes 集群稳定性的 SRE，需要缩短 CrashLoop 类故障的平均定位时间。
  • 正在排障的后端工程师，想确认容器退出是应用 panic、配置错误还是被驱逐。
  • 编写集群监控与自动修复策略的平台工程师，需要结构化的诊断结论与修复建议。
  • 维护生产集群的 DevOps 负责人，要在变更上线后快速评估 Pod 重启是否属于异常。