Kubernetes 的發源地：Google Kubernetes Engine（GKE）與 GKE Autopilot 深度解析

很多人學 Kubernetes 的時候，會把它當成一個從天而降的新技術。但如果回頭看它的血緣，會發現這其實是一段已經跑了二十年的老故事，主角是 Google 內部一套叫做 Borg 的系統。

這篇想把兩件事講清楚：Kubernetes 跟 Borg 之間的關係到底是什麼，以及 Google Cloud 對外提供的 GKE，標準模式跟 Autopilot 模式該怎麼選，才不會選錯之後在維運上吃虧。

理解 GKE 最快的方式，不是先背名詞，而是先搞懂 Google 為什麼會做出 Kubernetes，以及它想解決的問題原本長什麼樣子。

血緣：從 Borg 到 Kubernetes

在 Kubernetes 出現之前很多年，Google 內部就已經在用一套叫做 Borg 的系統，管理跨越好幾千台機器的容器化工作負載。官方在 2015 年正式對外發表了描述 Borg 設計的論文。

Kubernetes 在 2014 年由幾位工程師發起，後續加入的開發者裡有不少來自 Borg 團隊。Google 官方多次公開說明，Kubernetes 的設計深受 Borg 與另一個內部實驗性系統 Omega 的影響。

這段歷史的實際意義是：Kubernetes 處理的很多「棘手問題」，例如排程、健康檢查、滾動更新，Google 內部其實已經用真實流量驗證了十幾年，不是憑空設計出來的理論。

GKE：Google 把這套經驗包裝成對外服務

Google Kubernetes Engine 是 Google Cloud 對外提供的 Kubernetes 託管服務，官方在 2015 年推出。它把建立、升級、修補、監控叢集這些原本要自己動手的工作，變成一個受管理的服務。

GKE 有兩種操作模式，這是這篇文章要花最多篇幅講清楚的部分：標準模式與 Autopilot 模式。兩者共用同一套 Kubernetes API，差別在於「節點層由誰管理」。

GKE 標準模式：你決定節點，你負責節點

標準模式下，你要自己決定節點池用什麼機型、開幾台、怎麼設定自動擴縮的上下限。好處是控制權完整，你可以針對特殊硬體需求或成本模型做精細調整。

代價也很直接：節點層的容量規劃、資源使用率、部分資安設定，都要自己負責。如果團隊裡沒有人熟悉 Kubernetes 節點層的維運細節，這件事很容易被忽略，直到出問題才發現。

GKE Autopilot：把節點層整個交出去

Autopilot 模式的核心承諾是：你只需要描述工作負載要多少資源，Google 負責把對應的節點生出來、擴縮、打安全性補丁、依發行版本管道自動升級。

計費邏輯也跟著改變。一般工作負載走的是依 Pod 實際請求資源計費，需要特定硬體（例如 GPU 或特定機型）的工作負載，則是按底層基礎設施加上管理費計費。

多叢集與跨區域負載平衡：不是只有單一叢集這回事

實務上很少有團隊只跑一個叢集打天下。多個地區各自跑一個叢集，再靠跨區域的負載平衡機制把流量分配過去，是常見的高可用架構。

GKE 支援跨叢集的服務發現與流量路由，讓你可以把同一個服務部署到多個地區的叢集，依延遲、健康狀態或容量把使用者導向最合適的一個。這一層跟前面談的節點管理模式是分開的，標準模式與 Autopilot 叢集都能參與同一套多叢集架構。

選擇多叢集架構的常見理由，是想在單一地區發生問題時，讓其他地區的叢集接手流量，而不是把所有雞蛋放進同一個地區的同一個叢集裡。

怎麼選：判斷標準不是新舊，是團隊的維運容量

1. 先問團隊有沒有精力顧節點層。 沒有專職維運人力的團隊，Autopilot 通常能省下大量瑣碎的維運工作。
2. 再看工作負載形狀特不特殊。 需要極度客製化的節點排程邏輯，或依賴特殊硬體驅動的工作負載，標準模式會更彈性。
3. 用實際流量試算成本。 兩種計費模式在不同用量模式下的結果差很多，紙上談兵沒有意義，拿真實的資源使用量試算才準。
4. 不用急著一次選死。 ComputeClass 這類機制讓「整個叢集二選一」不再是唯一選項，可以先從局部工作負載開始嘗試。