Kubernetes 故障一来，运维同学最怕两件事：一是排查慢，二是「自动化修复」把集群修坏。近年各类 AI SRE / ChatOps Agent 演示很炫——模型读日志、改 YAML、直接 kubectl apply——但少有人认真回答：谁来证明模型说的「修好了」是真的？一旦写错，回滚成本谁担？
对跑 Spring / Java 微服务、依赖 GitOps 发布的团队来说，这条边界尤其敏感：生产变更本就该走 PR + 评审 + 同步，而不是让一个 LLM 握着一把能改集群的钥匙。本文将基于项目仓库的一手说明（README、ARCHITECTURE、threat-model），介绍开源项目 Kubemend 如何用「只诊断、只开 PR、从不直接改集群」的安全模型，把修复 Agent 嵌进现有 GitOps 流程。
仓库地址：https://github.com/m-stepkowski/kubemend
Kubemend 是什么、解决什么问题
Kubemend 是一个用 Python 手写的 LLM Agent 运行时（不依赖 LangChain / CrewAI / AutoGen 等框架），面向 Kubernetes 事故处置。它刻意把交付物拆成三块同等重要的部分：harness 本体、hermetic 故障注入实验室，以及按场景重复跑、给出 pass-rate / 成本 / 迭代次数的评测器——评测不是附属测试脚手架，而是产品的一半。
一次典型运行大致是：
- 输入：任务描述 + 声明范围（namespace / app / 时间窗）；
- 诊断：从可观测性数据（默认 Prometheus 指标 + Loki 日志，也可接 Datadog / Grafana Cloud；链路追踪默认关闭、可选开启）以及只读集群状态里定位问题；
- 提案：只通过向 GitOps 仓库开 draft PR 提出变更；
- 验证：在请求人工合并之前，由 独立于模型的验证门禁 重新跑一遍检查——模型自称「搞定了」不被采信。
项目自述里写得很直白：它的唯一执行器是 Git 分支和草稿 PR；人类仍然负责 merge。集群侧真正写入的，只有在 PR 合并后由 Argo CD 这类 GitOps 控制器同步——Agent 进程本身不持有可写集群凭证。
当前可通过 PyPI（pip install kubemend）或 ghcr.io/m-stepkowski/kubemend 镜像安装；实验室可用 task lab:up + task demo 一键体验。最新公开发行版可见仓库 Releases（例如 v0.11.0）。项目仍标注 非生产就绪（例如工具执行尚未沙箱化等），适合作为架构参考与实验室验证，而非开箱即用的生产黑盒。
核心安全模型：诊断 + 开 PR，永不 kubectl apply
Kubemend 把信任边界写进结构，而不是写进「请模型遵守」的提示词。威胁模型文档强调：每一项控制都应对应测试或明确代码路径。
- 模型输出不可信（I1）。模型只能选择调用哪些工具、起草哪些文件内容；不能决定运行是否成功、能否扩大变更范围。终止成功的唯一路径是 harness 侧
gate.verify。 - 工具执行器才是安全边界。超时、截断、脱敏、路径白名单都在执行器层完成，再进入模型上下文；工具输出被当作数据，不当作指令。
- 对集群只有只读访问。使用只读 ServiceAccount；资源 kind 白名单（Pod / Deployment / Event / Quota 等）；从不拉取 Secret 值（连「先读再打码」都不做）。
- 唯一写路径是 Git（I5）。具备外部副作用的工具实质上是
propose_git_change：可建/改分支并开 draft PR，不能推到受保护的 base 分支，没有任何工具能直接变更集群。 - 变更形态刻意收窄。默认只允许改
apps/**/values*.yaml这类 Helm values，不直接改 chart templates，让 diff 小、可评审；修不了 values 表达不了的问题时，走结构化 handoff（交接报告），而不是硬开一个看起来像样的错误 PR。
告警驱动的 operator（可选，默认关闭）也值得单独说一句：它只是根据 Alertmanager webhook 创建同款 Job 来启动一次运行，并带 bearer token 与按 (namespace, app) 冷却；Job 一旦启动，仍走同一套「不可信模型循环 + 验证门禁」，并没有给模型新的集群写能力。触发决策与模型可达工具集是两条分离的路径。
验证门禁：helm render / 策略 / diff / 范围 / 配额
当模型不再发工具调用、宣称「完成」时，harness 独立重跑验证管线（即使模型中途自己调过 validate_change 也不复用其结果）：
- Render：对触及的应用执行
helm template，渲染失败则整关失败； - Policy：用项目自带 Kyverno 策略包做
kyverno apply（与实验室准入策略同源，如禁止特权、要求 limits、禁止:latest、要求标签、限制镜像仓库等）；策略「零命中」按失败处理（fail-closed），避免静默放行； - Diff：优先
argocd app diff，回退kubectl diff --server-side；空 diff 判失败（防止「改成原样」冒充修复）； - Scope check：解析 diff 触及的
(kind, ns, name)，必须落在任务声明的 namespace + app 范围内；越界会点名违规资源； - Live quota headroom：对照命名空间实时 ResourceQuota（当前重点覆盖 pods 等配额维度），避免「渲染与策略都过、上线后却因配额 Pending」的假验证通过。
任一门禁失败，会把结构化失败信息喂回循环让模型重试；触达迭代/成本/墙钟预算或循环检测上限则优雅 handoff。成功路径才会开 draft PR。仓库公布的 v0.1 评测基线（claude-sonnet-5，每场景 n=5）在常规故障场景约 29/30（97%） 通过；另有「必须改 template」「根因在声明范围外」「日志/状态里植入 prompt injection」等对抗场景，用来检验是否会胡开 PR。
与传统运维 Agent / ChatOps 的边界对比
| 维度 | 传统「直接改集群」Agent / ChatOps | Kubemend |
|---|---|---|
| 最终写动作 | kubectl apply / 补丁 API / 重启 Pod 等 |
仅 Git 分支 + draft PR |
| 成功判据 | 常依赖模型自述或简单探针 | harness 独立验证门禁通过 |
| 凭证形态 | 往往需要写权限甚至较宽 RBAC | 只读 SA + Git 写权限分离 |
| 变更评审 | 事后审计困难 | 变更天然落在 GitOps PR 流 |
| 失败形态 | 可能已改坏现场 | 验证不过则不开 PR / handoff |
边界可以概括成一句话：Kubemend 把「AI 修 K8s」从运维执行问题，收束成「帮你写一份可评审的 GitOps 变更提案」。它不替代 Argo CD、不替代你们的变更窗口与审批；它前置在「人点 merge」之前。对已经把发布纪律建在 Git 上的团队，这种形状往往比「再给 bot 一把 kubectl」更容易被安全与变更管理接受。
适用场景与局限
较契合：
- 已有 Helm values + Argo CD（或同类）GitOps，希望事故修复与日常发布同一条变更路径；
- 需要可复现评测与威胁模型文档，而不是 demo 录像；
- 希望 Agent 可读可观测性与集群状态，但写权限严格落在 Git 侧。
需要清醒认识的局限（以仓库自述为准）：
- 项目明确写了 not production-ready；工具执行尚未沙箱化等项仍在威胁模型讨论中；
- 修复表达力受 values-only 约束：根因在 template / 非 values 可表达处时，期望结果是 handoff，不是强行 PR；
- 单次运行无跨 run 持久记忆；范围外根因依赖 handoff 或「仅范围内 PR」策略；
- 脱敏依赖结构禁止读 Secret + 模式匹配，无法保证捕获「形态未知」的泄露；
- 实验室默认 Git 后端为 Local / Gitea；GitHub 后端在架构文档中列为后续扩展方向。较新版本已支持 chart/values 分仓等 GitOps 形态，但接入前仍需按
docs/getting-started.md核对仓库布局与 Argo 多源 diff 要求。
接入真实集群前，文档建议先 --read-only 跑通诊断与交接，再打开写路径。
小结
Kubemend 的价值不在于「AI 会不会修 CrashLoop」，而在于它把修复 Agent 的能力边界钉死在 GitOps PR 上，并用 helm render → Kyverno → live diff → scope → quota 这条独立门禁，拒绝信任模型的自我汇报。对已经把变更纪律建在 Git 上的架构与运维团队，这比再写一个「能 apply 的 ChatOps bot」更贴近生产现实。
如果你正在评估「运维 Agent 能不能碰生产」，不妨先读它的 ARCHITECTURE.md 与 docs/threat-model.md，再在仓库提供的 kind 实验里跑一遍 task demo——用可复现的失败与通过表，而不是一段成功录像，来判断这类设计是否值得引入你们的流水线。
- 项目仓库：https://github.com/m-stepkowski/kubemend
- 许可证：Apache 2.0