GKE 系統指標開始看見 TPU 與 HPA

Google Cloud 把 GKE 系統指標接進 Cloud Monitoring，讓 TPU、加速器和 HPA 的狀態能直接查。

說真的，這次更新很實用。Cloud Monitoring 和 Google Kubernetes Engine 的系統指標，現在把 TPU 分區、slice 形成時間、加速器使用率，還有 HPA 推薦延遲都攤開來看。文件頁面最後生成時間是 2026-06-18 17:12:37 UTC，很多指標採樣間隔是 60 秒。

這種資料不是拿來看爽的。它直接影響你怎麼抓瓶頸，怎麼設告警，怎麼判斷是 pod 爆了，還是 TPU slice 卡住了。講白了，就是把原本藏在底層的東西，變成你能查、能畫圖、能告警的資料。

Google 這次到底露出了什麼

GKE system metrics 參考頁列出的是啟用後才會出現的系統指標。它們被放在 Kubernetes 指標家族裡，並標示成 GA 或 BETA。這代表 Google 不是只給你一個總覽，而是把更細的內部狀態也端出來。

這件事對雲端維運很重要。以前你常常只能看 CPU、memory、pod 數量。現在你還能看 partition、slice、accelerator duty cycle、memory bandwidth 和記憶體總量。對 GPU 或 TPU-heavy 工作負載來說，這些資料比單純的 node health 有用太多。

文件也把幾個實作細節講得很直白。像是 GAUGE、CUMULATIVE、DISTRIBUTION 這些型別行為不同。字串型指標要先用 MQL 轉換，才能拿去畫圖。單位則要看 MetricDescriptor 的定義。

• 預設是寫到 project 層級。
• 字串型指標要先用 MQL。
• 有些指標最多晚 240 秒才看得到。
• 型別字串都用 kubernetes.io/ 前綴。

TPU 指標把硬體狀態攤開了

最有意思的是 TPU 這塊。Google 把 accelerator partition、slice、metadata 都列出來，代表你不只知道 TPU 有沒有在跑，還能知道它是健康、異常，還是已經失敗。這種粒度很少見，至少在一般雲端監控裡不常看到。

對訓練模型的團隊來說，這差很多。TPU 排程很吃拓樸，slice 形成也很吃時間。你如果只看 pod 層級，很容易誤判成應用慢。實際上可能是硬體 slice 還沒組好，或 partition 狀態已經不對了。

這裡可以直接看出 Google 想讓你觀察什麼。它不是只想告訴你「有沒有資源」。它想告訴你「資源怎麼組起來」、「組多久」、「拆多久」、「哪個 slice 出事」。

“The AI industry is at an inflection point, and the next wave of progress will be driven by systems that can reason, plan and act.” — Thomas Kurian, Google Cloud Next 2024 keynote

Kurian 講的是 AI 系統，但放到這裡也通。模型越大，底層基礎設施就越不能只看表面數字。你需要更細的觀測資料，才知道問題卡在哪一層。

幾個 TPU 相關指標很值得記一下：

• accelerator/partition/state 用 1 或 0 表示分區健康。
• accelerator/slice/formation_durations 看 slice 組裝花多久。
• accelerator/slice/deformation_durations 看拆解和釋放資源花多久。
• accelerator/slice/metadata 會吐出 slice 和 partition 的組合資訊。

HPA 和 autoscaler 才是多數團隊會先用到的

如果你跑的是一般應用，不是 TPU 訓練，autoscaler 指標反而更直接。Google 這次放出推薦 CPU request、推薦 memory bytes，還有 HPA recommendation latency。這些數字能直接看出你的 scaling 邏輯有沒有跟上負載變化。

其中最實用的是 latency。文件定義得很清楚，它是從 metrics 產生，到 recommendation 套用到 apiserver 的時間差。這不是模糊的 proxy，而是 autoscaling 延遲本身。對要壓縮反應時間的團隊來說，這種資料很值錢。

如果把幾個指標放一起看，差異就更明顯了。快的指標適合即時判斷，慢的指標適合做趨勢分析。你可以把它們分成兩種用途，不要混著用。

• autoscaler/latencies/per_hpa_recommendation_scale_latency_seconds 是 GA，最多 20 秒延遲。
• autoscaler/container/cpu/per_replica_recommended_request_cores 是 GA，最多 240 秒延遲。
• autoscaler/container/memory/per_replica_recommended_request_bytes 是 GA，也可能晚 240 秒。
• container/accelerator/duty_cycle 是 GA，60 秒採樣，適合看穩態使用率。

這種差異會直接影響告警設計。20 秒內出現的資料，適合做比較快的回饋迴路。240 秒才出現的資料，就比較像是容量規劃工具。拿錯用途，告警就會變得很吵。

另外，文件把 label 欄位也列得很細。像 partition_id、slice_topology、accelerator_type、block_id，都能拿來縮小查詢範圍。這對排障很重要，因為你不會想在整個叢集裡大海撈針。

跟其他雲端監控比，Google 走得更細

如果拿這次更新去比 AWS 和 Azure 的常見做法，差別很明顯。多數平台先給你節點、pod、磁碟、網路這幾層。Google 這次直接把硬體分區和 autoscaler 內部流程也放進來，觀測層次更深。

這不代表別家做得差。只是 Google 很明顯在押一個方向：把 Kubernetes 的系統層資料，和加速器硬體資料綁在一起。對跑 AI 訓練、推論，或混合工作負載的團隊，這會比單純看 node CPU 更有用。

你可以把這次更新理解成一個實際比較。不是誰比較炫，而是誰給的訊號更接近故障現場。

• 傳統雲端監控：偏 node、pod、磁碟、網路。
• GKE 系統指標：再加上 TPU partition、slice、autoscaler latency。
• 對 AI 工作負載：後者更接近真實瓶頸。
• 對一般 Web 服務：HPA 和 CPU 指標就已經很有用。

這也解釋了為什麼 Cloud Monitoring 要把資料做成 60 秒粒度。它不是要取代你的應用日誌，而是補上系統層的節奏。當延遲、形成時間、推薦時間都能量化，維運團隊就比較不會只能靠猜。

這背後其實是 GKE 觀測模型在變

這次文件更新還有一個背景意義。GKE 不再只是一個跑容器的地方。它慢慢變成一個能理解硬體拓樸、加速器狀態、以及 autoscaling 內部決策的系統。這對雲端原生團隊來說，算是很務實的變化。

以前很多團隊會把監控拆成三套。基礎設施看一套，應用看一套，AI 平台再看一套。問題是三套資料常常對不起來。現在如果 GKE 系統指標能直接進 Cloud Monitoring，至少你少了一層拼接成本。

我覺得真正有價值的地方，不是多了幾個圖表，而是你能更快回答這三個問題：資源有沒有健康、autoscaler 有沒有慢、TPU slice 有沒有卡住。這三題答不出來，很多故障都只能靠猜。

如果你手上有 GKE 叢集，特別是有 TPUs 或高頻 autoscaling，下一步很簡單：先確認這些 system metrics 有沒有啟用，再把 latency、partition state、duty cycle 拉進 dashboard。沒有這些資料，你的監控還是有點半套。

結論：先把這些指標接進告警

講白了，這次更新最值得做的事，不是先去背所有 metric 名稱，而是先挑三個。第一個看 HPA latency。第二個看 accelerator partition state。第三個看 duty cycle。這三個一起上，通常就能抓到大半問題。

如果你是平台工程師，我會建議先把這些指標接到現有 dashboard。接著再補一條告警：當 slice 形成時間拉長，或 HPA latency 超過平常值時，就先通知。這種做法比等使用者報 bug 實際多了。

接下來幾個月，我會觀察兩件事。第一，Google 會不會把更多 TPU 和 autoscaler 細節放進來。第二，團隊會不會真的把這些指標用在告警和容量規劃，而不是只放著好看。你如果現在就在跑 GKE，最好先把這頁文件打開，直接看自己的監控缺了什麼。