EKS vs GKE：大規模 Kubernetes 叢集架構的效能深度比較 (100K+ 節點)

AI 訓練的爆發式成長，正在把 Kubernetes 叢集推向前所未有的規模。當單一訓練任務可能需要數萬張 GPU 同時協作，「一個叢集能撐多大」就不再是理論問題，而是真金白銀的基礎建設決策。

2025 年底，Google Cloud 和 AWS 幾乎同時端出了各自的答案：GKE 展示了130,000 節點的叢集 demo¹，EKS 則正式 GA 了 100,000 節點的 Ultra Scale 支援²，無非是為了運行日漸重要的超大規模 AI workload 提供必要的解決方案。但兩者在架構上卻走了截然不同的路線：GKE 直接用 Spanner 取代 etcd，EKS 則在 etcd 上做深度改造³。

本文將從規模數據、儲存架構、調度能力、節點管理等多個面向進行分析，並探討兩大平台在超大規模 Kubernetes 叢集上的設計取捨。

架構總覽：GKE vs EKS

flowchart TD
    subgraph GKE["☁️ GKE — 130K Nodes"]
        direction TB
        GA["API Server"] --> GS["Spanner"]
        GS --> GS1["天生分散式<br>無 sharding 需求"]
        GS --> GS2["1M+ Objects<br>13,000 QPS"]
        GA --> GK["Kueue"]
        GK --> GK1["Gang Scheduling<br>93s preempt 39K Pods"]
        GA --> GN["Node Management"]
        GN --> GN1["Node Problem Detector<br>+ Auto-repair"]
    end
    subgraph EKS["☁️ EKS — 100K Nodes"]
        direction TB
        EA["API Server"] --> ES["etcd（深度改造）"]
        ES --> ES1["Raft consensus 卸載<br>BoltDB on tmpfs"]
        ES --> ES2["Key-space 分區<br>10M+ Objects / 32GB"]
        EA --> EK["Karpenter"]
        EK --> EK1["Node Autoscaling<br>2,000 nodes/min"]
        EA --> EM["Node Management"]
        EM --> EM1["Auto-repair<br>100 min rolling update"]
    end

規模數據對比：130K vs 100K

根據 Google Cloud 和 AWS 所公開的相關數據，下表整理了相關的關鍵指標：

從純數字來看，GKE 在「調度速度」和「最大節點數」上佔了上風，而且值得注意的是，GKE 在平台整合層面做了大量設計工作：Kueue gang scheduling、Spanner 後端、節點自動擴展等能力都是開箱即用，使用者不需要手動調整參數就能在超大規模下獲得良好的效能表現。

相比之下，EKS 雖然提供了更完整的 Day-2 operations 測試數據，但要達到這些效能數字，背後需要大量的調校工作。這些調校可以分為兩個層面：

• AWS 平台層的改造（使用者無需介入）：etcd 的 key-space 分區、將 BoltDB 搬到 tmpfs、Raft consensus 卸載到 AWS 內部 journal 系統、以及 API Server informer cache 的鎖競爭修復。這些是 AWS 在控制面底層所做的工程改造，使用者享受成果但無法也不需要自行調整。
• 使用者層的調校（需要自行設定與優化）：Karpenter 的 disruption budgets 設定、SOCI Snapshotter 預裝到節點 AMI、容器鏡像拉取策略、以及各種 workload 層級的資源配置。這些需要使用者根據自身場景深入理解底層機制並精心調校，才能在超大規模下達到最佳效能。

換句話說，GKE 把複雜度藏在平台裡，EKS 則把調校的自由度（和責任）交給了使用者。這背後的差異，很大程度來自兩者在儲存架構上的根本性不同。

儲存架構：Spanner vs etcd 深度改造

這是整個比較中最核心的差異，也是影響 scalability ceiling 最關鍵的因素。

GKE 的做法：用 Spanner 直接取代 etcd

GKE 採取了最大膽的路線，把 Kubernetes 控制面的儲存後端從 etcd 換成 Google 自家的 Spanner¹。Spanner 是一個天生分散式的全球級資料庫，擴展性幾乎沒有上限。這意味著 GKE 不需要跟 etcd 的單點瓶頸搏鬥，直接站在一個更高的起點。

從測試數據來看，GKE 在 130K 節點規模下達到了 13,000 QPS 的 lease 更新量，而且沒有觀察到明顯的瓶頸跡象。資料庫物件數超過 100 萬，這對 Spanner 來說只是輕鬆的日常。

這個設計的優點是工程複雜度較低，Spanner 本身的設計就能解決分散式一致性和擴展性問題，不需要額外的 sharding 策略或記憶體優化。但代價是與上游 Kubernetes 的距離變遠了：標準 Kubernetes 依賴 etcd，換成 Spanner 意味著 GKE 的控制面已經是高度客製化的實作。

EKS 的做法：在 etcd 上做深度魔改

EKS 選擇了另一條路，保留 etcd 作為儲存後端，但在其上進行大量底層改造：

• Raft consensus 卸載：把 etcd 的 Raft 共識機制卸載到 AWS 內部的 journal 系統，降低 consensus 延遲
• BoltDB 搬到記憶體：將 etcd 底層的 BoltDB 儲存引擎從磁碟搬到 tmpfs（RAM-backed 檔案系統），大幅降低 I/O 延遲
• Key-space 分區：對 etcd 的 key-space 進行分區（partitioning），最多帶來 5 倍的寫入吞吐量提升

透過這些改造，EKS 的 etcd 總大小達到 32 GB（跨分區），資料庫物件數超過 1,000 萬³；但由於兩份測試的條件與統計口徑未必完全一致，這裡更適合解讀為「EKS 公開測試揭露了更高的物件量級」，而不是直接推論其儲存能力一定比 GKE 強 10 倍。

沿用 etcd 的好處是：比較不容易踩到 Kubernetes conformance（規範相容性）的坑，EKS 的控制面仍然符合上游的介面約定。但代價是工程複雜度極高，每一層 etcd 的改造都需要大量的測試和驗證來確保穩定性。

調度能力：Kueue Gang Scheduling vs 標準 Scheduler

在超大規模叢集中，儲存架構決定了控制面「能不能撐住」，但對於 AI 訓練工作負載而言，調度器的行為才是直接影響 GPU 利用率和訓練效率的關鍵。傳統的 Kubernetes 調度器採用逐一調度（one-pod-at-a-time）的模式，這在一般微服務場景下運作良好，但在大規模分散式訓練中卻可能造成嚴重的資源浪費與死鎖風險。想像一個需要 1,000 張 GPU 的分散式訓練任務：如果調度器只排到 800 張 GPU，其餘資源又被其他任務搶走，這 800 張 GPU 就會陷入閒置等待，既無法開始訓練，也無法釋放給其他工作使用。在叢集規模達到數萬甚至十萬節點時，這類資源碎片化問題會被急劇放大。

這正是為什麼 gang scheduling 在大規模 AI 訓練中至關重要：一組 Pod 必須同時啟動，缺一不可。如果一個需要 1,000 張 GPU 的訓練任務只拿到了 999 張，那 999 張就全部浪費了。

GKE 在這方面展示了明顯的優勢。透過整合 Kueue（Kubernetes 原生的佇列管理框架），GKE 在測試表現中能夠在 93 秒內 preempt 39,000 個 Pods，為高優先級的訓練任務騰出資源¹。這個數字在大規模 AI 訓練的場景中非常有意義。當你需要快速回收資源給一個緊急的訓練任務時，93 秒比等待數分鐘甚至數十分鐘的差距是巨大的。

相比之下，EKS 的公開資料中並未提及 gang scheduling 的具體方案或數據。這不代表 EKS 不能做 gang scheduling（畢竟 Kueue 也可以跑在 EKS 上），但 GKE 在這個維度上提供了開箱即用的深度整合和經過大規模驗證的數據。

EKS 的節點生命週期管理數據更完整

如果說調度是 GKE 的強項，那麼 Day-2 節點管理就是 EKS 展現優勢的地方。EKS 的測試報告提供了非常完整的節點生命週期數據：

• 節點加入速率：每分鐘 2,000 個節點，50 分鐘完成 100K 節點的叢集建置
• 節點自動修復：自動偵測故障節點並觸發修復流程
• 100K 節點滾動更新：透過 Karpenter 的 disruption budgets，在約 100 分鐘內完成全叢集的滾動更新

此外，測試環境中的節點 AMI 預裝了 SOCI Snapshotter 來延遲載入容器鏡像，避免短時間大量拉取鏡像造成的頻寬壓力。在 API Server 層面，EKS 團隊也受惠於 v1.31 引進的 strongly-consistent reads from cache，並且回饋上游修復了 informer cache 的鎖競爭問題（PR #132132、#130767），提升了事件處理效率³。

GKE 在這些維度的公開 Day-2 operations 數據相對較少，但並不代表它在節點修復/自動化能力上落後；更可能是這次 130K demo 的敘事重點放在「控制面吞吐量與擴展天花板」，而非完整的生產運維流程。

就節點生命週期與自動修復而言，GKE 本身其實有相當多「平台內建」的能力，能在很大程度上覆蓋 EKS 報告中強調的 auto-repair 類場景，例如：

• Node Problem Detector + 自動汰換：GKE 預設開啟 Node Problem Detector，會在節點上偵測常見的 OS/Kubelet/Runtime 異常並上報狀態；當節點健康狀態異常或長時間無法恢復時，搭配 managed node pool 的策略，GKE 可以自動將節點 drain 後重建，讓 workload 回到健康節點上。
• Managed Instance Group（MIG）和 Node pool 的自動控管：在多數 GKE node pool（特別是 VM-based）中，節點實際上由底層的受管節點群組維持期望狀態；節點失聯、硬體故障、或系統層異常時，平台可自動補齊節點數量。
• 自動升級和修補（auto-upgrade, auto-repair）與受控的滾動替換：GKE 透過既有的節點滾動升級機制，配合 cordon、drain 與 PDB、優雅終止預設參數，能在大規模下持續替換節點；只是 Google 在這次公開材料中沒有像 EKS 一樣，把「100K nodes rolling update 花多久」當作主打指標。

因此在文章表述上，這裡可以更精準地說：EKS 公開了更完整、可對照的「大規模 Day-2 流程數字」，而 GKE 這次公開資料偏少，但其平台本身並不缺少節點偵測與自動修復的 primitives；差異更多在於公開 benchmark 的敘事選擇與報告指標是否可直接對齊比較。

測試結果分析

根據現有的評測數據，本文仍需先釐清一個重要前提：這兩份測試報告的條件並不完全對等。

GKE 的 130K 節點測試更像是一個實驗結果分享，用於展示控制面在理想條件下的極限效能。重點在 Pod 調度吞吐量、Spanner 後端表現，以及 Kueue 的 gang scheduling 能力¹。

EKS 的 100K 節點測試則偏向生產情境的模擬，包含了節點加入、滾動更新、故障修復等 Day-2 操作的數據²。不過，EKS 的測試中僅停用 1,000 個節點用於模擬故障情境，這個比例（1%）在真正的大規模生產環境中可能偏低。

兩份報告都來自各自雲端廠商的官方發布，自然都會把最有利的數據放在最顯眼的位置。在比較時，我們需要同時重視「有公布的數據」與「未公布的數據」。GKE 沒提到滾動更新，不代表它做不好；EKS 沒提到 gang scheduling，也不代表無法使用開源方案達到相同目標。

結語

回顧整篇分析，GKE 和 EKS 在超大規模叢集上各自走了不同的路線，但它們要解決的核心目標皆是讓 Kubernetes 控制面在十萬節點規模下不崩潰，並且能有效地調度與管理 AI 訓練工作負載。

綜整上述各面向的優勢如下：

值得補充的是，節點自動修復並非 EKS 的獨佔優勢。GKE 預設就開啟了 Node Problem Detector 與 auto-repair 機制，能偵測 OS/Kubelet/Runtime 層級的異常並自動汰換故障節點⁴；而 EKS 近期也推出了 node monitoring agent 與 auto-repair 功能⁵，兩家在這個面向上的能力正在趨同。真正的差異在於：EKS 這次公開了完整的大規模 Day-2 benchmark 數字，而 GKE 的 130K demo 把敘事重心放在控制面吞吐量與調度天花板¹²。

所以，怎麼選？

• 如果你的場景是 burst AI training，需要快速調度數萬個 Pod 並搭配 gang scheduling 確保 GPU 不閒置，GKE 用 Spanner + Kueue 提供了目前公開數據中最高的天花板。
• 如果你更在意 Kubernetes conformance 和 Day-2 operations 的可預測性（滾動更新要多久、故障修復流程如何運作），EKS 提供了更完整且可複現的生產驗證數據⁶。

如果兩者你都在意，那真正的挑戰不在「單一叢集能撐多大」，而在「你的團隊有沒有能力運維這麼大的叢集」。在這個規模下，分而治之（Divide and conquer）仍然是目前最務實的策略。根據實際的 workload 特性、團隊能力和故障域需求，適當拆分為多個叢集，往往比把所有雞蛋放在一個超大叢集裡更穩健、更容易排錯、也更容易演進。畢竟，能跑 130K 節點是一回事，能穩定運維 130K 節點又是另一回事。

參考資料