以 Kubernetes 為骨幹打造多代理人資安平台：Cloud Native 與 Agentic AI 的實戰整合
CNCF Blog · 2026-06-17
法國電信巨頭 Orange Innovation 的首席資安架構師 Willem Berroubache 於 2026 年 6 月 17 日在 CNCF 部落格發表文章，記錄其團隊在受監管的生產環境中，以 Kubernetes 為基礎建構即時多代理人資安作業平台的架構決策與實戰心得。這套系統融合了大型語言模型、傳統機器學習，以及十餘項 CNCF 專案，已進入主動部署階段。文章脫胎自 KubeCon Europe 2026 的實際演講內容。
系統架構：四個專責代理人與一個協調器
平台的核心是一個以 LangGraph 實作的協調器代理人（Coordinator Agent），透過 A2A（Agent-to-Agent）協定管理四個功能獨立的子代理人。A2A 協定於 2025 年開源，現由 Linux Foundation 治理，以標準化信封格式在代理人間傳遞請求與回應。
- Detect Agent：搭載 Falco 與 eBPF，在 syscall 層攔截可疑行為
- Threat Analyst Agent：對照 MITRE ATT&CK 框架分類威脅升級事件
- Remediate Agent：執行已核准的資安回應動作
- Notify Agent：透過 Mattermost 通知 SOC 分析師
事件先流入 Kafka，再經由 scikit-learn 的 Isolation Forest 異常檢測模型進行前置篩選，僅將真正異常的事件送往 LLM 代理人處理，藉此同時控制 token 成本與推論延遲。
五項關鍵技術決策
第一，每個代理人以獨立的 Kubernetes Deployment 部署，擁有各自的資源限制、身份識別與重啟策略，避免了單體式設計的效能瓶頸。第二，代理人之間的通訊安全並非依賴服務網格，而是由 cert-manager 為每個代理人發放專屬憑證，在傳輸層直接實現 mTLS；配合 Cilium 與 CiliumNetworkPolicy 限制橫向流量。
第三，安全約束不內嵌於 LLM 提示詞中，而是以 OPA 策略與 Kyverno Admission Rule 實作，並納入 Git 版本控制與 CI 測試流程，讓治理規則具備可審計性。第四，A2A 信封攜帶 Trace ID 貫穿所有操作，搭配結構化 JSON 日誌、Prometheus 指標及 Cilium Hubble 流量可視化，實現完整的跨代理人追蹤。第五，前置的 Isolation Forest 模型替 LLM 過濾大多數正常事件，將 LLM 呼叫量集中在真正需要判斷的新型威脅場景，避免無差別地消耗推論資源。
人機協作的三種決策路徑
對於高風險的矯正動作，系統設計了三種終態：自動執行、自動拒絕、或升級至人工 SOC 分析師。升級時，Mattermost 訊息會附上完整的推理鏈與內嵌 ChatOps 指令，讓分析師可直接批准或否決。關鍵在於，升級的觸發條件是確定性的政策判決，而非模型的臨時反應，因此行為具備可預測性。
整套代理人設定以 Kubernetes Custom Resource 形式存放於 Git，透過 Argo CD 進行 GitOps 式管理。若代理人行為異常，回滾操作與處理一般微服務退化完全相同，不需要額外的 AI 專屬運維程序。Berroubache 的核心論點是：Cloud Native 的宣告式設定、身份管理與可觀測性工具鏈，天然適合承載多代理人 AI 系統的複雜度，而不是為此另起爐灶。
原始來源：CNCF Blog — Why Cloud Native Belongs at the Heart of Agentic AI
Oracle 捐贈 300 萬美元 Arm64 算力，CNCF 專案全面強化多架構 CI/CD 支援
CNCF Blog · 2026-06-15
2026 年 6 月 15 日，CNCF 開發者關係總監 Dave Neary 在官方部落格宣布，Oracle Cloud 自 2023 年底起捐贈 300 萬美元的 Arm64 運算資源給 CNCF 旗下專案，協助各專案在 x86 之外同步建立完整的 Arm64 建置、測試與發布流程。截至 2025 年底，AWS 超過 50%、Azure 超過 33% 的新執行個體已採用 Arm64 架構，多架構支援從「錦上添花」正式演變為雲端原生專案的基本門檻。這篇文章詳細說明 CNCF 如何透過 OCI 算力點數，幫助成員專案克服 Arm64 CI 長期資源不足的問題。
Arm64 的快速崛起與 CI 資源瓶頸
Arm64 在公有雲的佔比在近兩年出現顯著躍升。儘管 GitHub Actions 已陸續推出 hosted Arm64 runner，但其可用的 CPU 核心數與記憶體容量相對有限，對需要大型建置矩陣、多架構容器映像或效能驗證的專案而言，往往力不從心。CNCF Infra 團隊因此利用 OCI 點數，為專案動態配置任意規格的 Arm64 自託管 runner，彌補 GitHub hosted runner 的空缺。
過去，許多開源專案在遭遇 Arm64 CI 異常時，傾向先跳過而非修復，形成惡性循環。containerd 維護者 Phil Estes 曾表示：「這個 Arm64 CI 問題解決之前，我們不會合併這個 PR。」這種態度的轉變，代表 Arm64 已從可選架構升格為正式支援目標。
OCI 點數的申請流程與使用限制
專案維護者只需向 CNCF Service Desk 提交工單，說明預期用途、所需的 OCI 服務項目，以及每月預估消耗量，即可開始使用。CNCF Infra 建議初始月費控制在 5,000 美元以內，以確保社群資源的公平分配與長期可持續性；若有明確需求，也可申請例外。獲批之後，專案會收到現有 OCI hosted runner 的存取設定，以及 GitHub Actions workflow 整合指引，全程由 CNCF Infra 及社群志工提供支援。
在使用量方面，成長速度相當驚人。OCI 點數消耗在 2025 年上半年兩個月內，就已超越 2024 年全年的總量，顯示 Arm64 建置需求正在快速爆發。
受益專案與實際成效
目前已有超過十個 CNCF 專案透過此計畫提升 Arm64 支援，包括 OpenTelemetry、Longhorn、Crossplane、Jaeger、Falco 和 containerd。OpenTelemetry 維護者 Antoine Toulmé 表示，Arm64 上的效能表現遠優於舊有的 x86 伺服器，令團隊相當滿意。Falco 維護者 Federico Di Pierro 則指出，Arm64 GitHub runner 是 Falco 提升該架構支援層級的關鍵所在。
在實務層面，對於需要交叉編譯或原生建置多架構容器映像的專案，以下是一個簡化的 GitHub Actions 配置範例：
jobs:
build-arm64:
runs-on: [self-hosted, linux, arm64] # OCI 自託管 runner
steps:
- uses: actions/checkout@v4
- name: Build multi-arch image
run: |
docker buildx build \
--platform linux/arm64 \
--tag my-project:arm64-${{ github.sha }} \
--push .對 CNCF 生態系的長遠意義
這項計畫揭示了一個重要的基礎設施治理模式：透過共享的雲端點數池，降低個別開源專案引入新架構的門檻，而非讓每個專案各自向雲端供應商洽談資源。CNCF Infra 團隊在此扮演的角色，已從單純的 CI 維運演進為多架構策略的推動者。
隨著 Arm64 在邊緣運算與 AI 推論節點的佔比持續提升，CI/CD 管線的多架構支援將成為雲端原生專案的標配。CNCF 透過 OCI 點數計畫提前布局，有助於確保整個生態系在架構多元化的浪潮中維持競爭力，避免日後因技術債積累而被迫大幅重構建置流程。
原始來源：Improving Arm64 support in CNCF projects with OCI credits | CNCF
Grafana Assistant Investigations：從自動根因分析到跨系統矯正的 AI 調查工作流
Grafana Blog · 2026-06-17
Grafana Labs 於 2026 年 6 月 17 日發布文章，介紹 Grafana Cloud 的 Assistant Investigations 功能的最新演進。這項功能以背景代理人（background agent）的形式持續監控指標、日誌、追蹤與效能剖析，在使用者回報問題之前主動偵測異常，並自動啟動根因調查流程。作者 Maurice Rochau 描述其設計目標為「高度敏感且調校過的調查代理人」，而不是讓工程師手動翻查儀表板的傳統工具。
多來源資料整合與 MCP 擴充
Assistant Investigations 可同時分析來自多個資料來源的訊號，包括 Grafana 原生的四類可觀測性資料（metrics、logs、traces、profiles）、服務設定與標籤，以及 GitHub/GitLab 程式碼儲存庫。透過 Model Context Protocol（MCP）伺服器整合，可進一步接入 Snowflake、Salesforce、LaunchDarkly 等外部商業系統，將技術異常與業務指標（如用戶流失率）關聯起來，讓根因分析得以跨越純技術可觀測性的邊界。
「Skills」機制讓團隊可以封裝標準化的調查邏輯：將企業內部常見的故障排查步驟定義為可重用的技能模組，不同的調查任務按需組合，形成一致且可稽核的 runbook 流程。這種設計避免了每次調查都依賴個別工程師的經驗判斷。
從調查到矯正的自動化閉環
系統不僅分析問題，還可執行矯正動作：自動建立 Pull Request 或工單，將發現的根因直接轉化為程式碼修正提案或追蹤任務，讓調查結果不再只是一份報告，而是觸發下游工程工作流的起點。新版本加入了工作空間（Workspace）協作功能，允許多位團隊成員同時查看進行中的調查並介入引導方向。
排程功能可設定每日自動執行的定期調查，並將摘要透過 Slack 發送。自訂規則（Custom Rules）讓平台工程師定義在特定條件觸發時自動啟動哪種調查模式，與 Grafana Alerting 及 Incident Response Management（IRM）直接整合，使警報升級後能無縫轉入 AI 調查流程，省去人工交接的延遲。
工程層面的基礎能力改進
Grafana 工程團隊在文章中點出幾個持續投入的方向：上下文壓縮（context compaction）以處理長時間跨度的觀測資料；基準測試框架用來評估代理人在各類故障模式下的準確率；以及「保持代理人存活」的可靠性工程，確保背景調查代理人在長時間運行時不中斷。這些能力直接影響調查的深度與成本，解決了 AI agent 在複雜生產環境中維持長時間執行狀態的工程難題。Grafana Assistant 可從 Grafana Cloud 的 Alerting & IRM 區塊中啟用，並透過 TypeScript SDK 供開發者整合至外部應用程式。