打造 Kubernetes 自訂指標匯出器:補上 CPU/記憶體之外的擴縮依據
Kubernetes Blog · 2026-07-14
背景:內建指標的侷限
Kubernetes 官方部落格於 2026 年 7 月 14 日刊出教學文章,示範如何以 Go 撰寫自訂 Prometheus exporter,讓水平自動擴縮(HorizontalPodAutoscaler)能依據佇列深度、批次作業耗時等應用層訊號運作,而不只是 kubelet 回報的 CPU 與記憶體用量。內建資源感知僅涵蓋 CPU 與記憶體,訊息佇列待處理筆數、批次工作耗時、WebSocket 連線數等訊號都無法透過 metrics-server 取得。文章將 exporter 定義為只做一件事的 HTTP 服務:在 /metrics 路徑上以純文字格式輸出指標,供 Prometheus 定期抓取。當資料來源位於應用程式之外,或不想更動既有程式碼時,獨立 exporter 會比在應用內嵌入客戶端函式庫更合適。
三種指標型態與命名慣例
文章以 Prometheus 官方函式庫 github.com/prometheus/client_golang 示範三種資料型態:只增不減的 Counter(如 worker_jobs_processed_total)、可升可降的 Gauge(如 worker_queue_depth),以及能算出 p50/p99 分位數的 Histogram(如 worker_job_duration_seconds)。命名一律遵循 <namespace>_<name>_<unit> 的 snake_case 慣例,讓不同 exporter 產出的指標格式一致,方便跨團隊共用查詢與告警規則。
jobsProcessed = prometheus.NewCounterVec(
prometheus.CounterOpts{
Name: "worker_jobs_processed_total",
Help: "Total number of jobs processed, partitioned by status.",
},
[]string{"status"},
)
queueDepth = prometheus.NewGauge(prometheus.GaugeOpts{
Name: "worker_queue_depth",
})接上 HorizontalPodAutoscaler
寫完 exporter 後,文章接續說明如何將其封裝成容器、部署進叢集讓 Prometheus 能抓到資料,最終把自訂指標接進 HorizontalPodAutoscaler,使擴縮策略跳脫 CPU/記憶體框架,改以佇列深度或作業耗時作為依據。這個流程呼應官方 HPA 搭配自訂指標的走查文件,也是多數即時系統導入應用層擴縮的常見起手式。
GPU 共享中介軟體 HAMi 通過 CNCF 表決,晉升 Incubating 專案
CNCF Blog · 2026-07-15
核心機制:五大元件
CNCF 技術監督委員會(TOC)於 2026 年 7 月 15 日投票通過,將 GPU 虛擬化中介軟體 HAMi 從 Sandbox 提升為 Incubating 專案,目前版本為 v2.9.0,由 dynamia.ai、NVIDIA 員工與獨立貢獻者共同維護。HAMi 讓平台團隊能把實體 GPU 及 NPU、DCU、MLU 等加速器切分成細粒度單位跨工作負載排程,且不需修改應用程式碼。整體架構由攔截 Pod 提交並改寫排程欄位的 Mutating Webhook、負責過濾與綁定的 Scheduler Extender、向 Kubernetes 註冊裝置的 Device Plugin,以及在容器內攔截原生 CUDA driver、強制執行記憶體與算力上限的 HAMi-Core 虛擬化層組成,另有提供視覺化管理的 HAMi-WebUI。
- Mutating Webhook:改寫 Pod 排程欄位與資源請求
- Scheduler Extender:binpack / spread / 拓撲感知排程策略
- Device Plugin:向 K8s 註冊各廠牌加速器
- HAMi-Core:攔截 CUDA driver、限制記憶體與算力
- HAMi-WebUI:叢集與裝置視覺化管理介面
採用現況與生態整合
專案自 2024 年 8 月 21 日進入 Sandbox 至今,貢獻者數成長至 2,687 位(年增 43%),GitHub star 數約 3,500、fork 超過 550、參與組織逾 550 家,累積 16 次正式釋出。HAMi 也提供相容 Prometheus 的觀測層與 Grafana 儀表板範例,並與 Volcano、Koordinator 等批次排程/GPU 共享專案整合;路線圖列有與 KAI-scheduler、Kueue、llm-d 的協作項目。
2026 地端 DBaaS 調查:CRD 取代 Open Service Broker API,但統一標準仍缺席
CNCF Blog · 2026-07-15
從 OSBAPI 到 CRD 的轉向
CNCF 部落格於 2026 年 7 月 15 日發布地端(on-prem)資料庫即服務(DBaaS)現況調查,檢視企業在自管基礎設施上重建雲端資料庫自助體驗時採用的技術路徑。文章回顧 Cloud Foundry 時代的 Open Service Broker API(OSBAPI)曾是描述服務目錄、佈建、綁定的標準介面,但隨著 Kubernetes 成為地端平台主流基礎,越來越多團隊改以 CustomResourceDefinition(CRD)搭配 Operator 模式重建類似能力,例如以 Patroni 為基礎的 PostgreSQL 高可用方案。這種模式天生具備 GitOps 相容性,卻也讓實作方式分散在各家 Operator 手中,缺乏共通介面。
案例與尚待解的缺口
文章舉出 Klutch.io 作為開源案例,嘗試在 Kubernetes 上重建服務代理(service broker)體驗,把「開發者請求什麼」與「平台團隊如何實作」兩件事分離開來。文章明言目前仍沒有一套廣泛採用的框架能做到這種分離,即便 Operator 模式已能自動化大部分維運工作,將其作為橫跨多環境的集中式平台層,仍是一個尚待解答的問題。
| 面向 | 現況 | 缺口 |
|---|---|---|
| 介面標準 | CRD + Operator 各自定義 | 無廣泛採納的統一標準 |
| 服務代理 | Klutch.io 等專案摸索中 | 缺乏專為 K8s 設計的現代 service broker |
| 維運責任 | 由多個團隊分攤 | 即便有 Operator,責任仍分散 |
| 跨環境治理 | 各叢集各自為政 | 能否作為多環境集中治理層仍未有答案 |