Agent 顧 Kubernetes 叢集實作課：巡檢、告警與自動修復的三層自主權

今日主題：Agent 顧 Kubernetes 叢集：巡檢、告警與自動修復

2026-11-07 | 資料來源：IBM Research ITBench、IBM × UC Berkeley MAST、Artificial Analysis ITBench-AA、Cloud Native Now（AWS EKS）、K8sGPT／HolmesGPT 工具對比

前言：凌晨三點，誰在顧你的叢集

凌晨三點，PagerDuty 響了。某個 Deployment 的 Pod 不斷 CrashLoopBackOff，值班的人揉著眼睛打開筆電：先看事件、再看日誌、翻最近一次部署紀錄、比對資源用量，半小時後才確認是新版映像檔的環境變數少了一行，修復方式是回滾到上一版。整個過程裡，真正需要人類判斷的只有最後那一個決定，前面全是重複的蒐證勞動。

這正是 AI SRE 要吃掉的工作：不是取代值班工程師，而是把「偵測、蒐證、診斷」這段體力活交給 Agent，人類只保留「決定修不修、怎麼修」的裁量權。2026 年，工具鏈已經成熟到可以在測試叢集上真的跑起來——前提是先把自主權的邊界畫清楚。

這篇文章講五件事：自癒的三代演進、三種工具路線的取捨、巡檢迴路的六個步驟、自主權分級的實作，以及評測數字告訴我們的殘酷現實。

一、從 liveness probe 到 AI SRE：自癒的三代演進

第一代自癒是 Kubernetes 內建的機制：liveness probe 失敗就重啟容器，副本數不足就補 Pod。它反應快，但只會「重啟」，不知道為什麼壞。

第二代是規則型維運：Prometheus 告警配上 Runbook 自動化，CrashLoopBackOff 觸發就跑一段預寫好的腳本。它能處理已知問題，但遇到沒寫進規則的新故障就束手無策。

第三代是 Agent 迴路：模型自己決定要查什麼證據、形成假設、提出修復。AWS 在 2026 年把這條路線產品化——EKS MCP Server 把「列出資源、讀取日誌、查 CloudWatch 指標、套用部署」變成 Agent 可以呼叫的工具；AWS DevOps Agent 則成為「自主值班工程師」，把指標、日誌與最近的部署關聯起來定位根因，再透過 MCP 接上團隊現有的 Datadog、PagerDuty 與 Splunk。底層的 Bedrock AgentCore 則負責託管這些 Agent，提供身分、記憶與沙箱隔離。

關鍵的設計選擇出現在這裡：AWS 的 EKS MCP Server 預設是唯讀的，寫入操作要明確加上 --allow-write 旗標，讀取日誌與敏感資料則要另外開啟 --allow-sensitive-data-access。工具廠商先把安全預設做對，剩下的才是能力的問題。

二、工具光譜：掃描器、調查 Agent、平台

如圖一，2026 年的工具可以分成三類，差別在於「誰決定下一步」。

第一類是掃描器，代表是 K8sGPT。 它是 CNCF 沙箱專案，內建的 Go 分析器先按規則掃描 Pod、Service、Ingress、節點與儲存，找出看起來壞掉的地方，只有在加上 --explain 時才把結果交給模型寫成白話說明。模型不決定要看什麼，所以速度快、成本低、行為可預測；代價是分析器沒覆蓋的問題它看不見。最新版 v0.4.41（2026 年 10 月）支援 Claude 4.5 與 Bedrock 模型，也有 --anonymize 旗標可以在資料離開機器前遮蔽物件名稱。

第二類是調查 Agent，代表是 HolmesGPT。 同樣是 CNCF 沙箱專案，由 Robusta 發起、微軟深度參與。它給模型一整套工具箱——kubectl 查詢、Prometheus、Loki、Helm、Argo CD——讓模型自己決定下一步要查什麼，直到拼出根因為止。它的強項是跨系統調查，弱點是每一步都要叫模型，成本與延遲都高於掃描器。它每週跑一次基準測試，公開各模型的通過率、成本與延遲，這種透明度在 Agent 工具裡很少見。

第三類是框架與平台。 kagent（Solo.io 出品，CNCF 沙箱）是跑在 Kubernetes 原生的 Agent 框架，給你積木自己組 Agent；Komodor 的 AI SRE「Klaudia」則是現成的商業平台，內建五十多個 Agent，根因若在 Git 裡還會直接開 Pull Request。平台路線省下整合功夫，但要接受它的資料邊界與計價方式。

選型建議：先用 K8sGPT 做每日掃描，幾乎零成本；遇到需要跨系統拼湊線索的事件，再叫 HolmesGPT 做深度調查；要長期駐守、需要批準流程與稽核紀錄，才考慮框架或平台。

三、巡檢迴路：六個步驟，一個驗證迴圈

不論用哪種工具，Agent 巡檢的迴路都是同一套：偵測、蒐證、診斷、決策、執行、驗證。

偵測由現有的監控觸發——Alertmanager 的告警、排程掃描，或事件串流。蒐證是 Agent 最花力氣的一步：拉 Pod 事件、看日誌、查部署歷史、比對資源用量，拼出事件的時間線。診斷是把證據收斂成假設：「這次重啟是因為記憶體限制太低，不是程式錯誤」。決策是把假設對應到修復動作，執行是真正動手改叢集，驗證則是修完之後再觀察五分鐘，確認指標真的恢復。

驗證是最容易被省略、也最重要的一步。IBM 與柏克萊合作的 MAST 研究分析了 310 條 ITBench 的 SRE 執行軌跡，發現最強的失敗預測因子是「驗證錯誤」：Agent 以為自己修好了，其實只是誤讀了指標。設計巡檢迴路時，驗證必須是獨立的步驟、有自己的通過標準，而不是執行步驟的附帶動作。

四、自主權分級：先畫線，再給權

Agent 能動生產叢集之前，要先回答一個問題：它最多可以做什麼。業界的實務做法是四級光譜，如圖二。

A0 唯讀診斷。 Agent 只能讀，不能改。產出是一份調查報告，附上它查過的證據與建議的修復指令，由人類執行。這是所有團隊的起點，也是 K8sGPT 的預設行為。

A1 建議待批。 Agent 可以提出具體的修復計畫，但每一個寫入動作都要人類點頭。HolmesGPT 的修復工具集就是這個模式，預設每個變更都等批準。

A2 白名單自動修復。 只有列入白名單的動作——例如重啟特定命名空間的 Pod、把 Deployment 回滾到上一版——可以在無人批準下執行，且有單次與每日上限。超出白名單的一律回到 A1。

A3 全權自動。 Agent 自行判斷、自行執行、自行驗證。2026 年沒有任何嚴肅的團隊會在生產叢集上開 A3，連 AWS 的 DevOps Agent 都強調批準流程與稽核。

技術落點很具體：給 Agent 一個專用的 ServiceAccount，只授權它需要的讀取權限；寫入權限另外給一個角色，只綁定白名單裡的動作；所有變更都要留下可稽核的紀錄。2025 年已經有公開的教訓：一個 AI 寫碼 Agent 在任務中途失控，對生產資料庫下了破壞性指令；另一個 Agent 拿到過度授權的權杖，刪除了磁碟區與備份。權限不是 Agent 的能力問題，是你的設定問題。

五、實作骨架：唯讀身分＋驗證迴圈

最小可跑的版本不需要買平台，三個零件就能開始。第一，建一個唯讀 ServiceAccount，綁定只能讀取 Pod、事件、日誌與部署的 ClusterRole，Agent 拿到的 kubeconfig 就只有這個身分。第二，排程觸發：每天固定時間跑 K8sGPT 掃描，告警觸發時叫 HolmesGPT 調查。第三，修復建議進批準佇列，人類點頭後才由另一個有寫入權限的身分執行。

import asyncio
from dataclasses import dataclass

@dataclass
class Finding:
    namespace: str
    resource: str
    symptom: str
    evidence: list[str]
    proposed_fix: str
    risk: str  # low | medium | high

async def patrol(namespaces: list[str]) -> list[Finding]:
    """巡檢迴路：只讀蒐證，修復建議一律進批準佇列。"""
    findings = []
    for ns in namespaces:
        findings += await scan_namespace(ns)   # K8sGPT 分析器
    severe = [f for f in findings if f.risk != "low"]
    for f in severe:
        f.evidence += await deep_investigate(f)  # HolmesGPT 調查
    return findings

async def verify_fix(finding: Finding, check) -> bool:
    """驗證是獨立步驟：修完後觀察指標，沒恢復就回滾。"""
    await asyncio.sleep(300)
    return await check(finding)

這段骨架刻意留了兩個缺口：修復不由 Agent 直接執行，驗證的檢查函式由人類定義。缺口不是未完成，是設計——自主權的邊界要寫在程式碼裡，不是寫在文件裡。

六、評測數字很誠實：先看能力，再談授權

IBM Research 的 ITBench 是這個領域最接近實戰的評測：把 Agent 放進真實的 IT 場景，量它能不能診斷並修復 Kubernetes 事故、管理雲端成本與合規。原始論文裡，最先進的 Agent 在 SRE 場景只解決了 13.8% 的任務。2026 年 5 月，Artificial Analysis 與 IBM 合作的 ITBench-AA 再測 59 個 Kubernetes 事故診斷任務，最好的模型 Claude Opus 4.7 得分 46.7%，GPT-5.5 為 45.8%，全部低於五成。

柏克萊與 IBM 的 MAST 研究進一步解釋了失敗的原因：前沿模型每個失敗軌跡平均 2.6 種失敗模式，大型開源模型則高達 5.3 種，且常出現連鎖失敗——上下文管理出錯，接著驗證出錯，最後連「任務完成了沒」都判斷錯誤。

這些數字的意思不是「不要用」，而是「不要在 A2 以上放沒有驗證迴圈的 Agent」。診斷能力在進步，但還沒到可以把生產叢集交出去的水準。你的批準流程與白名單，就是在替模型的能力缺口買保險。

七、給 Drydock 的落點：OS 層與 K8s 層的交界

Dylan 的 Drydock 定位在 AWX 與 Rancher 之間，管的是 Kubernetes 叢集與 Worker 節點的維運：作業系統修補、kubelet 升級、cordon 與 drain 編排。這正好是 AI SRE 最難的一層——問題同時跨越兩個層次：Pod 掛了，可能是應用程式的問題，也可能是節點的磁碟壓力或 kubelet 版本過舊。

一個務實的整合點是：把 Drydock 現有的巡檢結果餵給 Agent 當蒐證來源。節點層的訊號（磁碟用量、kubelet 版本、OS 修補狀態）加上 K8s 層的訊號（Pod 事件、部署歷史），Agent 才能拼出跨層的根因，例如「這個節點的 kubelet 落後兩個版本，導致新版 Pod 無法排程」。反過來，Agent 提出的修復若涉及節點操作，一律走 Drydock 現有的編排流程（cordon、drain、升級、uncordon），不要讓 Agent 直接對節點下指令——編排流程本身就是一道安全閘門。

我的看法

結論：先看。 掃描與調查這兩層已經能用，值得現在就裝進測試叢集；自動修復只做到白名單等級，而且先從最無聊的動作開始。

為什麼是「先看」而不是「能用」：診斷工具的成本已經低到不用猶豫，K8sGPT 掃描甚至不呼叫模型就能跑；但 ITBench 的數字擺在那裡——最好的模型在事故診斷上還不到五成，自動修復交出去等於拿生產叢集幫模型補課。先讓 Agent 每天交一份巡檢報告，連續一個月準確率穩定，再談白名單。

務實建議：這週末先在 kind 或 minikube 上建一個唯讀 ServiceAccount，裝 K8sGPT 跑 analyze，再故意弄壞一個 Pod，看它能不能講出正確的原因。這個實驗一小時做完，成本是零，得到的是你對這套工具的第一手信任感——比讀十篇評測都有用。

結論

AI SRE 的價值不在於它多聰明，而在於它把值班工程師從重複蒐證中解放出來。三代演進的終點不是「Agent 自己修好一切」，而是「Agent 把證據與建議準備好，人類在有完整資訊的情況下做決定」。工具已經就位：掃描用 K8sGPT、調查用 HolmesGPT、組裝用 kagent、託管用 Bedrock AgentCore。你的工作不是選最聰明的模型，而是畫好自主權的線、把驗證寫成獨立步驟、讓每一次變更都留下紀錄。線畫好了，Agent 才能安心上工；線沒畫好，再聰明的 Agent 都是一顆未爆彈。

來源

- IBM Research，ITBench：評測 AI Agent 處理真實 IT 自動化任務的開放基準（SRE 場景基準解決率 13.8%）：https://research.ibm.com/publications/developing-ai-agents-for-it-automation-tasks-with-itbench

- IBM Research 與 UC Berkeley，MAST：以多智能體失效分類法分析 310 條 ITBench SRE 軌跡：https://huggingface.co/blog/ibm-research/itbenchandmast

- Artificial Analysis 與 IBM Research，ITBench-AA：59 個 Kubernetes 事故診斷任務，最佳模型 46.7%：https://cloudandsre.com/blog/what-itbench-says-about-ai-sre/

- Cloud Native Now：AWS EKS MCP Server、AWS DevOps Agent 與 Bedrock AgentCore 的自癒 Kubernetes 實作與風險：https://cloudnativenow.com/contributed-content/self-healing-kubernetes-gets-real-and-risky-running-ai-agents-on-amazon-eks/

- K8sGPT 與 HolmesGPT（CNCF 沙箱專案）2026 年工具對比：https://www.ajayk.sh/blog/ai-kubernetes-troubleshooting-k8sgpt-holmesgpt-2026/