KnoAI 技术站

主题

03. AI 值班 Agent 路线图 ​

当前已建成"发现 → AI 诊断 → 通知"链路（见 01/02 篇）。 本篇规划下一步：从"诊断通知"演进到真正能值班的 Agent。原则不变：自动修复必须经人工确认。

阶段一：已完成 ✅ ​

  • K8sGPT 10 分钟巡检 + AI 中文诊断 + 飞书卡片通知
  • Alertmanager 阈值告警 + 卡片通知（触发/恢复）
  • 适配器管道：解析容错、兜底翻译、日志可查

阶段二：告警上下文聚合 ✅（2026-08-01 已落地） ​

痛点：一条告警来了，值班人还要手动 kubectl get/describe/events 收集现场。

已实现：alertmanager-feishu-adapter 收到 firing + critical 告警后，异步（不阻塞 webhook 响应） 用只读 RBAC 自动收集上下文（Pod phase/容器状态/最近 5 条 Warning 事件），连同告警内容发给 qwen-plus 生成初步分析，在告警卡片后补推一张「🤖 AI 值班初判」卡片（青绿头）。

实现要点：

  • 适配器新增 SA + ClusterRole（只读 pods/nodes/events，不含 pods/log——日志原文待切内网模型后再开）
  • ThreadingHTTPServer + 后台线程分析；同一告警 2h 冷却（AI_ANALYZE_COOLDOWN），失败不留冷却自动重试
  • 只对 critical 触发 AI 初判（AI_ANALYZE_SEV 可配），warning 仅告警卡片，成本可控
  • Key 存 Secret alertmanager-ai（deploy.sh 从 .secrets.env 创建），optional 引用——无 Key 自动降级为仅告警卡片
  • 实测：合成 critical（真实 mysql/mysql-primary-0 对象）→ 双卡片推送成功；端到端走真实 Alertmanager 路由同样生效

阶段三：Runbook 半自动执行（中期） ​

方案：把高频处置固化成 Runbook（如"磁盘清理""Pod 重启""扩容"）， AI 诊断命中 Runbook 时，卡片上挂飞书交互按钮（互动卡片支持 callback）：

🛠 建议执行：重启 mysql-primary-0
[ ✅ 确认执行 ]  [ ❌ 忽略 ]  [ 📋 查看影响范围 ]
  • 点击「确认执行」→ callback 到执行器服务 → 校验白名单（只允许预定义动作 + 目标资源匹配）→ 执行 → 回执卡片更新结果
  • 白名单外动作一律只出建议不出按钮
  • 全部操作落审计日志（配合集群 apiserver 审计）

阶段四：值班 Agent 长期记忆（远期） ​

  • 告警/处置历史入向量库，AI 初判时检索"上次同类问题怎么修的"
  • 周报自动生成：本周告警分布、Top 问题、容量趋势、SLO 达成

技术选型备忘 ​

项候选倾向
AI 后端DashScope qwen-plus（现用）/ 内网 vLLM敏感阶段（含日志上下文）切内网 vLLM 更合适，需解决网段可达
上下文收集client-go controller / kubectl proxy适配器内嵌只读 client 即可
交互按钮飞书互动卡片 callback需公网回调地址或飞书网关，ai-ear.cn 可承担
执行器独立 Deployment + 白名单不复用 K8sGPT autoRemediation（保持关闭）

红线（任何阶段不放松） ​

  1. AI 无集群写权限；执行器白名单制，AI 输出只作为"建议选择"
  2. 送公网 API 的数据必须脱敏（anonymize）；含日志原文的阶段切内网模型
  3. 每一次自动动作都有审计记录 + 通知回执