Kubernetes故障自动诊断、审批与修复

原文要点

原模板接收Alertmanager经webhook发来的K8s故障告警，归一化集群、命名空间、资源信息后调用kubectl封装API收集事件、日志、资源用量与工作负载状态；Anthropic Claude基于快照给出根因假设和唯一修复动作并标记Safe或NeedsApproval；Safe且在白名单内直接经动作API执行，否则发到Slack等待approved=true/false恢复等待节点。执行后等待稳定期再诊断一次让Claude验证症状是否消失，恢复则写事故日志API关闭，未恢复带完整上下文升级到Slack频道。

这次做成什么

在没有生产集群的前提下，用三个假HTTP服务（Mock）替代kubectl封装API、动作API、事故日志API，在n8n里搭通“告警→诊断→Claude判断→审批分支→验证→关闭或升级”的完整链路，理解每个分支的字段流转，再决定是否接入真实集群。

准备什么

• n8n可运行实例，能创建webhook与HTTP Request节点
• Anthropic凭据（Claude），模型可按账号可用版本调整
• Slack工作区凭据及两个频道：审批频道与升级频道
• 三个Mock API端点（可用webhook.site或本地json-server），先不接真实kubectl

具体怎么做

1. 准备三个Mock API

   建三个固定返回的假端点：诊断API返回下方示例诊断JSON；动作API返回{"executed":true}；事故日志API返回{"logged":true}。在n8n的HTTP Header Auth凭据里各配一个假token，隔离于任何真实集群凭据。

2. 导入模板并改配置

   导入模板后，把三个API base URL替换为Mock端点，Slack节点填你的审批频道与升级频道名，Claude节点确认模型。

3. 用合成告警手动触发

   复制webhook URL，POST下方示例Alertmanager合成payload。预期流程先调诊断Mock拿到快照，再把快照发给Claude，Claude按下方提示词返回一个动作与risk字段。

4. 走两条执行分支

   第一次让Claude返回restart-deployment且risk=Safe，白名单包含该动作，预期直接调动作Mock；第二次把提示词里的动作改成delete-node（不在白名单），预期流程发到Slack审批频道并挂起，手动向等待节点恢复地址POST {"approved":true} 才继续，POST {"approved":false} 则中止。

5. 演练验证与升级

   稳定等待期后流程会第二次调诊断Mock。第一次让Mock返回健康快照（restartCount不再增长），预期写事故日志Mock关闭；再把Mock改成仍有CrashLoopBackOff的快照，预期完整上下文被POST到升级频道。

可直接复制的材料

你是Kubernetes运维工程师。根据下面的诊断快照（JSON），输出且只输出一个JSON对象，不要Markdown、不要解释。字段：root_cause（一句话根因假设，中文）；action（唯一一个修复动作，只能是 restart-deployment、scale-deployment、rollback-deployment、delete-node 之一）；risk（若动作可逆且不删数据填Safe，否则填NeedsApproval）；reason（一行依据，引用快照中的字段值）。诊断快照：{{diagnostics_json}}

{"alerts":[{"status":"firing","labels":{"alertname":"KubePodCrashLooping","cluster":"test-cluster","namespace":"payments","pod":"checkout-7d9f4b6c5-x2v1a","severity":"critical"}}]}

{"events":[{"reason":"BackOff","message":"Back-off restarting failed container","count":14}],"logs":["Error: connect to redis:6379 connection refused"],"usage":{"cpu":"92%","mem":"310Mi"},"workload":{"restartCount":14,"readyReplicas":"0/1"}}

{"allowlist":["restart-deployment","scale-deployment","rollback-deployment"],"approval_resume_payload":{"approved":true}}

输入与输出示例

本站虚构演示，未运行原模板；真实恢复与否以Claude对第二次快照的判断为准。

输入

POST合成告警：cluster=test-cluster, namespace=payments, pod=checkout-7d9f4b6c5-x2v1a，Mock诊断返回restartCount=14、CrashLoopBackOff

对应输出

Claude按提示词返回{"root_cause":"容器依赖的redis连接失败导致反复重启","action":"restart-deployment","risk":"Safe","reason":"restartCount=14且日志含connection refused"}；因restart-deployment在白名单，动作Mock收到{"action":"restart-deployment","namespace":"payments"}；稳定期后第二次诊断readyReplicas=1/1，事故日志Mock收到{"incident":"KubePodCrashLooping","status":"resolved"}。

做完检查这些

• 告警webhook触发后，诊断Mock在Claude调用之前被请求，且Claude收到的快照字段与Mock返回一致
• Claude返回Safe且动作在白名单时，动作Mock直接收到执行请求，不经过Slack
• 动作不在白名单时流程在Slack等待，POST approved=true后继续，approved=false后不执行动作
• 第二次诊断显示症状消失时写事故日志关闭；仍有BackOff事件时升级频道收到含根因与动作的完整上下文

容易卡住的地方

• 模板依赖三个外部封装API（诊断、动作、日志），原文未给出其具体接口实现，接口路径需自行核对，不能假设kubectl可直接调用
• 白名单外的动作永远走人工审批，练习时别用delete-node之类高危动作连真实集群
• Claude输出若带Markdown代码块或非枚举动作会导致分支解析失败，提示词里必须要求只输出JSON
• approved恢复地址由n8n等待节点生成，重启实例或超时后旧地址可能失效
• Safe判定来自模型，本站不保证其对真实集群安全，生产启用前必须由运维复核白名单与提示词