问题背景
Kubernetes 集群中的故障排查通常涉及多个维度：指标异常、Pod 状态异常、网络不通、存储挂载失败、配置错误等。单一脚本或单一 Agent 很难覆盖所有场景。多 Agent 协同架构通过将不同能力拆分为独立角色，可以更高效、更可靠地完成复杂故障的自动诊断与修复。
多 Agent 系统架构
一个完整的 K8s 故障自动修复系统可划分为以下 Agent：
+-------------+ +-------------+ +-------------+ +-------------+
| 观测 Agent | -> | 诊断 Agent | -> | 执行 Agent | -> | 审计 Agent |
+-------------+ +-------------+ +-------------+ +-------------+
^ |
+---------------------------------------------------+
| Agent 角色 | 职责 |
|---|---|
| 观测 Agent | 采集指标、日志、事件、链路数据 |
| 诊断 Agent | 基于 LLM 和知识库推理故障根因 |
| 执行 Agent | 调用 K8s API 或运维工具执行修复 |
| 审计 Agent | 记录操作日志，支持回滚与复盘 |
| 协调 Agent | 分配任务、管理状态、协调多 Agent 协作 |
观测 Agent
观测 Agent 负责从多个数据源收集信息：
- Prometheus：CPU、内存、QPS、P99 延迟等指标。
- Loki / ELK：容器日志、应用日志、系统日志。
- Jaeger / Tempo：分布式链路追踪。
- Kubernetes Events：Pod 调度、镜像拉取、健康检查等事件。
func collect(ctx context.Context, alert Alert) (Observation, error) {
obs := Observation{Alert: alert}
obs.Metrics = prometheus.Query(alert.MetricQuery)
obs.Logs = loki.Query(alert.PodName, alert.Namespace, time.Now().Add(-10*time.Minute))
obs.Events = k8s.ListEvents(alert.Namespace, alert.PodName)
return obs, nil
}
诊断 Agent
诊断 Agent 接收观测数据，结合 LLM 与 RAG 知识库进行根因分析。诊断过程可采用 ReAct 模式：
思考1：Pod 处于 CrashLoopBackOff，首先检查最近日志。
行动1：请求日志摘要。
观察1：日志显示 "connection refused to redis:6379"。
思考2：可能是 Redis 服务不可用或配置错误，需要检查 Redis Service 和 Endpoint。
行动2：请求 Redis 状态。
观察2：Redis Endpoint 为空，说明没有 Redis Pod 被选中。
结论：Redis Deployment 副本数为 0，需要扩容。
诊断 Agent 可以维护一个故障模式库，将历史故障案例向量化存储，遇到新告警时先进行相似案例检索。
执行 Agent
执行 Agent 根据诊断结果执行修复动作。执行前需要校验：
- 动作是否在白名单中。
- 是否超过当日执行次数限制。
- 是否需要人工审批。
常见修复动作包括：
| 故障场景 | 修复动作 |
|---|---|
| Pod 崩溃 | 重启 Pod、回滚镜像版本 |
| CPU 饱和 | 扩容 Deployment |
| 内存泄漏 | 滚动重启、调整资源限制 |
| 配置错误 | 更新 ConfigMap/Secret 并滚动更新 |
| 网络不通 | 检查 Service/Endpoint/NetworkPolicy |
func execute(action Action) error {
switch action.Type {
case "scale":
return k8s.ScaleDeployment(action.Namespace, action.Target, action.Replicas)
case "restart":
return k8s.DeletePod(action.Namespace, action.PodName)
case "rollback":
return k8s.RolloutUndo(action.Namespace, action.Target)
default:
return fmt.Errorf("unsupported action: %s", action.Type)
}
}
审计 Agent
审计 Agent 记录每次故障处理的完整上下文：
- 原始告警信息
- 各 Agent 的输入输出
- 最终执行的修复动作
- 执行前后的指标对比
- 人工介入记录
这些数据不仅用于合规审计，也是持续优化诊断模型和修复策略的重要素材。
协调 Agent 与状态机
协调 Agent 负责管理一次故障修复的完整生命周期。可以使用状态机模型：
Detected -> Observing -> Diagnosing -> PendingApproval -> Executing -> Verifying -> Resolved/Failed
状态转换通过消息总线或工作流引擎驱动。各 Agent 之间通过定义良好的消息协议通信，避免紧耦合。
关键技术挑战
- 幻觉与误判：LLM 可能给出错误诊断，需要设置置信度阈值，并在关键操作前要求人工确认。
- 权限控制：执行 Agent 需要最小权限原则，避免越权操作。
- 并发与竞态：多个告警同时触发时，需要避免冲突操作。
- 可解释性：每次自动修复都应能解释"为什么做"和"做了什么"。
总结
多 Agent 协同是实现复杂 K8s 故障自动修复的有效架构。通过观测、诊断、执行、审计等角色的分工协作，系统可以在保证安全可控的前提下，大幅提升故障响应速度和恢复效率。这也是云原生 AIOps 平台的核心能力之一。