Kubernetes 官方發布遷移指南:從 Dashboard 走向多叢集工具 Headlamp
Kubernetes Blog · 2026-07-13
背景
Kubernetes 官方部落格於 2026-07-13 刊出由 Microsoft 工程師 Vincent T. 撰寫的遷移指南,說明如何將叢集管理介面從 Kubernetes Dashboard 換成 Headlamp。文章開宗明義指出兩者「都能顯示叢集內執行的內容,但運作方式不同」——Dashboard 是只能部署在叢集內、一個叢集對應一份的 Web 應用,透過 kubectl port-forward 或 ingress 存取,以 Bearer token 登入。相較之下,Headlamp 的定位更接近「帶 UI 的 kubectl」,可以裝在桌機上,也可以跑在叢集內,並且直接讀取本機的 kubeconfig,因此能在同一畫面同時管理多個叢集。這篇指南並未使用「淘汰」字眼,而是把 Headlamp 定位成因應多叢集維運需求而生的替代方案,延續了 6 月 1 日同一部落格另一篇《From Kubernetes Dashboard to Headlamp》的鋪陳。
遷移方式
指南把遷移拆成幾個明確步驟。第一步是盤點現況,包含目前用到哪些叢集(dev/staging/prod)、常碰的 namespace、最常做的操作(檢視、編輯、擴縮、刪除、除錯),以及現行的存取方式與登入憑證。第二步是驗證 kubeconfig 是否可用:
kubectl config current-context
kubectl get nodes
kubectl get pods -n <namespace>文章強調「如果這些指令能跑,Headlamp 就能用同一份身分與 RBAC」,不需要另外設定權限。第三步是選擇上線策略,官方建議兩種做法:
- 平行運行(建議做法):先安裝 Headlamp,讓團隊試用一段時間,Dashboard 暫時保留,等大家熟悉後再移除。
- 直接切換:安裝 Headlamp 後立刻更新文件與連結,隨後盡快移除 Dashboard。
文中特別註明「在共用叢集上,平行運行比較安全」。第四步則是決定 Headlamp 的部署位置:桌面版直接沿用本機 kubeconfig、不佔叢集資源、免 port-forward,多叢集開箱即用;叢集內版本則適合共用瀏覽器存取的場景,可比照其他叢集內應用一起維運,通常搭配 ingress 與 SSO 使用。
影響範圍
對使用者而言,最大的變化集中在三處:登入方式從貼上 token 改為使用 kubeconfig(有時搭配 SSO);建立資源從填表單改為「套用 YAML」;多叢集操作從特殊案例變成日常流程。導覽介面也從單純的表格清單,新增了視覺化地圖檢視。指南同時列出「不會改變」的部分——瀏覽工作負載與資源、依 namespace 篩選、檢視 YAML/事件/狀態、查看日誌、執行 RBAC 允許的操作——這些既有工作流程在 Headlamp 上維持一致,降低了團隊轉換的學習成本。當叢集內版本執行 Headlamp 時,權限一樣透過 Kubernetes ServiceAccount 走 RBAC 規則,並未引入新的授權模型。
Pod 還適合當 AI Agent 的部署單位嗎?CNCF 提出 Agent-Substrate 構想
CNCF Blog · 2026-07-14
原本的問題
CNCF 大使、Solo.io 工程師 Lin Sun 於 2026-07-14 發表文章,質疑 Pod 是否仍是部署 AI agent 的合適抽象層。文章指出,agent 的生命週期特性與傳統微服務截然不同:agent 往往是「陣發性」(bursty)且短暫的,只在需要處理特定任務時被喚醒,其餘時間閒置,而傳統服務假設的是持續在線。若替每一個潛在 agent 都配置專屬 Pod,「很快就會變得浪費」——Pod 原本是為長時間運行的工作負載設計,和 agent 的執行模式並不對齐。除了資源浪費,agent 的隔離、身分管理與多租戶問題也更複雜:agent 可能動態建立子 agent、暫停等待人工核准、或代表使用者執行動作,既有以 Pod 為中心的可觀測性與政策框架難以涵蓋這些行為。文章也點出 Pod 生命週期與 agent 生命週期在排程變動下常常對不上,計費、配額與跨團隊資源分配也缺乏對應的抽象層。
討論的替代方案
文章提出名為 agent-substrate 的構想,在 Kubernetes 之上疊加一層控制平面,引入四個新抽象:
- WorkerPool——對應 NodePool,是一組執行資源的集合。
- Worker——對應 Node,是由 Kubernetes 管理、長時間運行的 Pod。
- ActorTemplate——對應 PodTemplate,用宣告式方式描述 agent 規格。
- Actor——邏輯上的 AI agent 實體,依需求被排程到 Worker 上執行。
在這個模型裡,Pod 退居為執行層的 Worker,而不是部署單位本身;Actor 則是輕量、可動態排程到共用 Worker 上的邏輯實體,理論上能比逐一部署 Pod 支撐多得多的 agent 數量。文章同時提到兩個具體實作:kagent(kagent.dev)展示了這套 agent-substrate 概念的落地方式,agent-gateway(agentgateway.dev)則負責流量政策的仲裁,並提及可搭配 gVisor(runsc)做沙箱隔離。
目前的取捨
文章沒有給出定論,而是列出幾個尚待釐清的問題:agent 的身分應該掛在 ActorTemplate 還是 Pod/Service 上?安全政策要如何從 Pod 層級平移到 Actor 層級?分散式 agent 執行需要什麼樣的所有權與配額機制?可觀測性又該如何跨多個 Worker 追蹤同一個邏輯 agent?作者的立場相對保守:Kubernetes 對微服務與推論工作負載依然出色,但「AI agent 引入了更多獨特特性」。她的結論是,Pod 或許仍是合適的執行單位,卻未必該同時承擔 agent 的部署、身分與生命週期單位——agent-substrate 目前仍屬探索性質,而非成熟方案。
原始來源:CNCF Blog: Is a Pod the right deployment unit for an AI agent?
大規模維運 OpenTelemetry 收集器:OpAMP 協定如何統一代理管理
CNCF Blog · 2026-07-13
背景
CNCF 大使 Dotan Horovits 於 2026-07-13 發表文章,整理 OpAMP(Open Agent Management Protocol)協定維護者 Andy Keller 的觀點,說明為何大規模維運 OpenTelemetry Collector 車隊如此困難。Keller 提到許多組織「大概各自開發了三、四、甚至五種不同的代理管理協定」——這些收集器的部署型態差異極大,從龐大的 OpenTelemetry gateway,到嵌入式裝置如 POS 機、收集 Windows 事件的筆電都有,規模從幾十台到 IoT 場景下的數百萬台不等。再加上負責部署的團隊往往和負責可觀測性設定的團隊分屬不同組織,每次要調整設定就出現溝通斷層,長期下來各自為政、缺乏統一機制。
協定機制
OpAMP 的設計目標是讓中央後端能對代理車隊做標準化的遠端管理:自動下發設定、推送更新、監控健康狀態,並透過 WebSocket 或 HTTP 即時回報狀態,官方形容這是「監控你的監控系統本身」。協定架構分成兩塊:一是唯讀的 OpAMP Extension,回報目前設定與健康狀況;二是獨立行程的 OpAMP Supervisor,具備讀寫能力,介於管理平台與 collector 之間。整體規格刻意保持精簡,只用兩種 Protocol Buffers 訊息(server-to-agent 與 agent-to-server)溝通。當新設定送達時,Supervisor 會把設定寫入磁碟並重啟 collector,若啟動失敗則會自動「回復設定並沿用上一個已知可用的版本」,提供基本的容錯機制。設定內容採用通用的 name-value pair,因此 OpAMP 管理的不只是 Collector,還包含已支援遠端設定的 Java SDK、透過 OpAMP Bridge 與 OpenTelemetry Operator 溝通的 Kubernetes 部署,以及新近開源的 Fluent Bit 代理。
實際應用
文章提到 Nike 曾在 KubeCon North America 2025 分享企業級規模導入 OpAMP 的實務經驗;在 Kubernetes 場景中,OpAMP Bridge 作為中介,讓 OpAMP 平台與 OpenTelemetry Operator 等原生機制協同運作;在 SDK 層面,團隊可以即時調整微服務架構中的抽樣率、或啟用除錯紀錄,而不必重新部署應用程式。Fluent Bit 的車隊管理是較新的專案,Fluentd 的支援也已排入規劃。文章另外提到即將於 KubeCon Europe 2026 前後推出的 OpAMP Gateway Extension,目的是解決 WebSocket 連線的擴展瓶頸:與其讓十萬台 collector 全部直連管理平台,不如部署一百個 OpAMP gateway,每個承接一千台 collector 的連線,再由這一百個 gateway 統一連回管理平台,藉此降低連線負擔並支援網路分段。該擴充目前仍處於 Alpha 階段。整體規格目前仍是 Beta,各元件成熟度不一,規格文件收錄於 OpenTelemetry 專案下的 opamp-spec 儲存庫,參考實作則是 opamp-go。後續路線圖包含設定差異(diff)傳輸、真正無需重啟的熱重載,以及仍在草稿階段、走向意圖導向的 Telemetry Policy OTEP。
原始來源:CNCF Blog: Operating OpenTelemetry at scale with OpAMP、opamp-spec (GitHub)