首页/AI 提示词库/编程开发/Kubernetes 排障

Kubernetes 排障

⌨ 编程开发 适配:Claude / GPT / DeepSeek难度:进阶 4 个变量一键复制
使用说明

Pod 起不来、服务不通、资源吃紧时按排查树走:把 kubectl 输出贴进来,得到按概率排序的原因和修复命令。

部署后 Pod 反复重启、CrashLoopBackOff、镜像拉取失败、服务间访问不通。

提示词模板未填写变量以红色标出
我的 K8s 集群出问题了,帮我按排查树定位。

【环境】{{集群环境}}
【现象】{{故障现象}}
【命令输出】{{已有输出}}
【最近改动】{{最近变更}}

请输出:
一、原因假设排序:结合现象和最近的变更,列出 3 个最可能的原因(按概率排序),每个说明「如何证实/证伪」——用具体的 kubectl 命令,比如 kubectl get events --sort-by=.lastTimestamp。
二、快速止血:如果业务在受影响中,先执行的应急命令(回滚 rollout undo 或扩副本),并说明每种止血的副作用。
三、根因修复方向:针对第一嫌疑原因给出修复方案(改 YAML 的具体字段、调整资源值怎么算基准)。
四、验证清单:修完后按什么顺序验证(Pod 状态 → readiness → 探针 → 服务连通 → 日志无异常),每步给命令。
五、预防建议:基于这次故障,给我 2 条落地配置改进(比如加 startupProbe、发布前用 dry-run 校验)。

要求:所有命令可复制执行;不确定的信息别假设,直接告诉我还缺哪个命令的输出、让它贴回来。
填变量变量会自动替换进上方模板,可随时复制
已填 0 / 4
使用步骤
  1. 先止血再查因,别在生产上边猜边试。
  2. 贴日志给 AI 时带上 describe 事件段。
  3. 每次变更记录回滚命令,出事 30 秒内能执行。
CrashLoopBackOff 先看 logs 不看事件
Events 只告诉你容器死了,logs 里通常直接写着死因。
资源 limits 改动是常见元凶
突然 OOMKilled 或 CPU 节流,先对最近一次资源变更做回滚对照。
常见问题
日志已经滚动丢了怎么办?

加 --previous 看上一次容器的日志;再配合把日志侧挂到持久化(Loki/ELK)避免下次丢失。

要不要直接让 AI 生成修复 YAML?

可以,但让它先复述当前 YAML 再改,逐字段说明改了什么、为什么,防止整段重写引入新问题。