以 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 供開發者整合至外部應用程式。
用生產環境遙測資料驅動 k6 負載測試：告別憑感覺設定壓力
Grafana Labs Blog · 2026-06
負載測試最大的謊言，是拍腦袋決定壓力數字。 Grafana Labs 近期在官方部落格示範了一套完整流程，說明如何從 Grafana Cloud 的生產監控儀表板直接提取真實流量特徵，再以此驅動 Grafana Cloud k6 壓力測試腳本，讓測試場景真正重現線上負載，而非憑空假設。這個方法的核心概念是「先觀測、再施壓」，把可觀測性（Observability）與效能測試的回饋迴圈閉合起來。
原本的問題：假設式負載測試的盲點
開發團隊長期依賴「估計值」來設定測試負載，例如「大概會有 100 個並發使用者」或「每秒約 50 個請求」，這些數字往往來自直覺或舊有經驗，並不反映實際生產行為。當真實的流量突破這個假設上限，系統就會在毫無預警的情況下崩潰。更大的問題是，即便測試通過，工程師也無法確認通過的標準是否與真實世界相符，測試結果與生產指標之間存在一道難以跨越的鴻溝。
Prometheus/Mimir 等指標後端已經忠實記錄了所有需要的資訊，包括請求速率、延遲分佈、流量高峰時段等，只是過去這些資料幾乎不會被拿來回饋給壓力測試設定。這篇文章提出的方法，正是要打破這道牆。
採用的方法：從四個生產指標建構測試場景
整個流程從 Grafana 儀表板查詢四個關鍵維度開始。 首先是實際請求速率，以下列 PromQL 查詢取得基線與峰值吞吐量：
sum(rate(http_server_requests_total{app="leaderboard-api"}[$__rate_interval]))範例結果顯示基線為每秒 120 個請求，尖峰為每秒 340 個請求。第二個維度是延遲基線，透過以下查詢取得 p95 與 p99 延遲，做為後續測試的 SLO 閾值：
histogram_quantile(
0.95,
sum(rate(http_server_request_duration_seconds_bucket{app="leaderboard-api"}[5m])) by (le)
)第三個維度是流量形狀（Traffic Shape）：觀察儀表板判斷系統是平穩負載、週期性高峰還是突發型流量，以此決定使用常數負載、壓力測試還是尖峰測試。第四個維度是正常狀態下的錯誤率，用來設定測試的失敗閾值。
k6 腳本的組裝：executor 選擇與 threshold 設定
k6 的 executor 選擇直接影響測試的真實性。 對於需要模擬真實到達率（arrival rate）的場景，應優先選用 ramping-arrival-rate 而非以虛擬使用者（VU）為單位的 executor，因為生產流量的特徵是「每秒請求數」，而非「有多少人同時在線」。以下是根據上述生產資料組裝的完整腳本片段：
export const options = {
scenarios: {
realistic_load: {
executor: "ramping-arrival-rate",
preAllocatedVUs: 50,
maxVUs: 200,
stages: [
{ target: 120, duration: "5m" }, // 基線
{ target: 340, duration: "10m" }, // 尖峰
{ target: 120, duration: "5m" }, // 回落
],
},
},
thresholds: {
http_req_duration: ["p(95)<280"],
http_req_failed: ["rate<0.01"],
},
};preAllocatedVUs 設定預先配置的虛擬使用者數量，maxVUs 則是允許系統動態擴充的上限；thresholds 中的 p(95)<280 直接對應從 Prometheus 查詢出的 280ms p95 延遲基線，讓測試標準與生產 SLO 保持一致。若系統是穩定吞吐量場景，則可改用 constant-arrival-rate executor，以固定的每秒迭代次數取代分階段的速率變化。
閉合可觀測性回饋迴圈
測試執行後，應在同一套 Grafana 儀表板上加入測試時間點的標注（Annotation），讓工程師能直接對比測試期間的指標走勢與生產基線。這個步驟讓「壓測結果」與「生產表現」在同一個視角下比較，而不是在兩個獨立系統之間來回切換。這種做法實現了真正的 Shift-Left 測試：在部署之前就以接近生產的條件驗證系統行為。
Grafana 也提供 AI 輔助的 Grafana Assistant k6 腳本產生功能，工程師可透過 k6 Script Authoring Mode 以自然語言描述需求，讓 AI 自動分析生產指標並產生腳本，大幅降低手動組裝的門檻。無論手動或 AI 輔助，核心原則不變：壓力測試的設定值必須來自真實生產資料，而非工程師的直覺。
原始來源：Grafana Labs Blog — How to generate real-world load tests using Grafana Cloud k6 and production telemetry、k6 Docs — Scenarios Executors、k6 Script Authoring Mode