Kubernetes Megacluster 技術全景：各家大規模叢集如何突破萬節點天花板

Kubernetes 上游 SIG Scalability 定義了 5,000 nodes 的「建議上限」，但各大雲端廠商和科技公司早已在挑戰這個天花板。GKE 用 Spanner 替換 etcd 跑出 130K nodes、EKS 靠 etcd consensus offload 做到 100K nodes、ByteDance 用自建的 KubeBrain 管理 20K+ nodes、OpenAI 從 2,500 一路擴展到 7,500 nodes。每家都走了截然不同的技術路線，但目標一致：讓 Kubernetes 承載更大規模的工作負載。

這篇文章將全面梳理各家的突破策略、比較不同擴展哲學的優劣，並探討 Kubernetes 大規模叢集的未來方向。

mindmap
  root((K8s Megacluster<br>技術全景))
    瓶頸分析
      etcd - Raft/BoltDB
      kube-scheduler - 序列化
      API Server - lock contention
      網路/DNS
    各家突破策略
      GKE - Spanner 130K
      EKS - etcd offload 100K
      AKS - Fleet Manager 5K
      ByteDance - KubeWharf 20K+
      OpenAI - 2.5K to 7.5K
      阿里雲 - 萬級叢集管理
    三種擴展哲學
      單叢集垂直擴展
      Multi-Cluster 橫向擴展
      全自建控制面
    未來方向
      etcd 替代方案標準化
      MultiKueue
      DRA
      Gang scheduling

Kubernetes 擴展性天花板在哪？

在深入各家解決方案之前，先理解為什麼有 5,000 nodes 這個建議上限。

Kubernetes Scalability SIG 定義了一套 SLI/SLO 框架¹來衡量叢集在大規模下的健康狀態：

• API request latency (mutating)：對單一資源的變更操作（Create、Update、Delete），p99 ≤ 1 秒
• API request latency (read-only)：讀取單一資源 ≤ 1 秒；跨 namespace/cluster 的 List 請求 ≤ 30 秒
• Pod startup latency：從 Pod 建立到容器回報啟動（不含 image pull 和 init containers），p99 ≤ 5 秒

這些 SLO 在 5,000 nodes 以下都能穩定達標。一旦超過這個規模，etcd 寫入延遲飆升、scheduler 排程速度跟不上、API Server 的 informer cache 出現鎖競爭。官方文件也明確指出²，超過 5,000 個節點後，叢集可能會出現明顯的效能下降。

接下來，讓我們逐一拆解這些瓶頸，看看它們為什麼會在大規模下爆發。

瓶頸全解析

flowchart TD
    A["Client Request"] --> B["kube-apiserver"]
    B --> C["etcd (BoltDB)"]
    B --> D["Informer Cache"]
    B --> E["kube-scheduler"]
    E --> F["Node Assignment"]
    F --> G["kubelet"]
    G --> H["Pod Running"]

    C -.- C1["❌ Raft consensus overhead"]
    C -.- C2["❌ Disk I/O bottleneck"]
    C -.- C3["❌ 2GB default size limit"]
    D -.- D1["❌ RW lock contention<br>PR #132132, #130767"]
    E -.- E1["❌ Serial processing<br>~100-500 pods/sec"]
    G -.- G1["❌ Network/DNS issues<br>at 5K+ nodes"]

    style C fill:#ff6b6b,color:#fff
    style E fill:#ffa94d,color:#fff
    style D fill:#ffa94d,color:#fff
    style G fill:#ffe066,color:#333

etcd：最直接的效能瓶頸

etcd 使用 BoltDB 作為底層儲存引擎，該引擎為一個基於磁碟的嵌入式 key-value 數據庫。etcd 透過 Raft 共識協議在多個節點間同步資料，確保任何一個節點掛掉，資料都不會遺失。但這個機制在超大規模叢集中會帶來幾個核心問題：

• Raft consensus 開銷：每次寫入都需要多數節點確認，延遲隨叢集規模線性增加
• 磁碟 I/O 瓶頸：頻繁的 WAL 寫入和 snapshot 操作，在高併發下直接卡住
• 資料量上限：預設 2GB 的 database size limit，大型叢集很快就會碰到天花板

這就是為什麼 GKE、EKS 和 ByteDance 都不約而同地選擇優化 etcd 作為突破口。

kube-scheduler：序列化處理的天花板

預設的 kube-scheduler 採用序列化處理，一次只排程一個 Pod。當你需要每秒排程數千個 Pod 時（例如大規模 AI training job 一次啟動上千個 worker），scheduler 會成為嚴重瓶頸。ByteDance 的 Gödel scheduler 透過並行排程達到 5,000 pods/sec³，是上游 scheduler 的數倍以上。

API Server：informer cache lock contention

在超大規模叢集中，API Server 的 informer cache 會出現讀寫鎖競爭。EKS 團隊在 100K nodes 測試中發現了這個瓶頸，並回饋上游修復了兩個關鍵 PR：

• PR #132132⁴：Controller Manager 中 informer cache 的 RW lock 競爭導致事件處理延遲，寫入時阻塞讀取，影響資源狀態的即時反映
• PR #130767⁵：API Server 和 Kube Controller Manager（KCM）的 informer cache RW Lock contention，影響 KCM 性能和叢集穩定性

這兩個修復對整個 Kubernetes 生態都有貢獻，不只是 EKS 受益。此外，v1.31 引入的 strongly-consistent reads from cache 讓 API Server 可以直接從本地 cache 讀取一致性資料，而不需要每次都回 etcd 查詢，大幅降低 etcd 的讀取壓力，在超大規模叢集中，這直接減少了數以萬計的 etcd 讀取請求。

網路與 DNS

OpenAI 在從 2,500 擴展到 7,500 nodes 的過程中，踩了不少網路相關的坑⁶⁷：

• Flannel 性能瓶頸：Pod 間只能跑到 ~2Gbit/s（原生可達 10-15Gbit/s），最終在 7,500 nodes 階段遷移到 Azure 原生 CNI
• KubeDNS 熱點問題：排程策略導致 KubeDNS pod 集中在少數節點，超過 Azure 每台 VM ~200 QPS 的外部 DNS 查詢限制
• ARP cache 溢出：每個 Pod 都有獨立 IP，大規模下 ARP table 空間耗盡（neighbor table overflow!），導致節點間通訊異常

這些看似「小問題」，在萬級節點下都會被放大成叢集級別的故障。

各家怎麼突破？

GKE：用 Spanner 取代 etcd，天生分散式

Google 直接用 Cloud Spanner 替換 etcd 作為 Kubernetes 的後端儲存。

Spanner 基於 atomic clocks 實現全球一致性，天生就是分散式系統，完全不存在 etcd 的 Raft consensus 瓶頸。根據公開的測試成果⁸，總體達到：

• 130,000 nodes（v1.31+ 正式支援 65K nodes）
• 1,000 pods/sec 的調度吞吐量
• 1M+ Kubernetes objects

架構上這是一個優雅的解決方案，Spanner 天生水平擴展，不需要在 etcd 上做各種 workaround。但代價是深度綁定 Google Cloud 基礎建設。

生產環境中，GKE 客戶已經在運行 20K–65K nodes 的叢集，主要用於 TPU + GPU 的大規模 AI 訓練。

EKS：etcd consensus offload，保持 conformance

AWS 的策略是在保持 Kubernetes conformance（通過 CNCF 一致性測試，確保標準 kubectl 和 API 都能照常使用）的前提下，對 etcd 做深度改造⁹：

• Consensus offload：將 etcd 的 Raft 共識層卸載到專用的 journal 服務（類似 WAL，負責持久化和資料同步），讓 etcd 不再需要自己處理 Raft 協議，大幅降低寫入延遲
• 分區策略：支援 10M+ objects，database size 上限提高到 20GB
• BoltDB in-memory 化：etcd 內部使用 BoltDB 作為 MVCC（多版本並行控制）後端，負責處理多個 client 同時讀寫的情況。EKS 將 BoltDB 從 EBS 磁碟搬到 tmpfs（記憶體），因為 journal 已接管 durability，BoltDB 不再需要寫磁碟，讀寫吞吐量獲得數量級提升

EKS 達到了 100K nodes GA¹⁰ 的里程碑，支援 1.6M Trainium chips / 800K GPUs 的超大規模 AI 工作負載，Anthropic 是其主要客戶之一。

在實際的擴展性測試中，EKS 以每分鐘約 2,000 個節點的速率加入叢集，50 分鐘內完成全部 100K 節點的部署。工作負載分配上，約 70K 節點執行 fine-tuning 任務，另外 30K 節點透過 LeaderWorkerSet 運行大型推理工作負載。硬體方面，節點採用 Trn2 和 P5e/P6 系列 EC2 實例，EBS 提供超過 260K IOPS 和 10 GB/s 的吞吐量，而節點 AMI 預裝的 SOCI Snapshotter 則透過延遲載入容器鏡像來降低啟動時的頻寬壓力。

不過，從測試結果中，有幾點值得注意：

1. 測試環境偏理想：預先配置良好的硬體和精選工作負載，僅停用 1,000 節點模擬故障，未必反映生產環境多變且不可控的實際情況
2. 未探討長期運行挑戰：監控服務、Ingress、混合負載長期執行的 Watch/List API 壓力未被涵蓋
3. 成本驚人：以 trn1.2xlarge 每小時 ~$1.34 計算，50K 節點月費約 $4,900 萬美元，100K 節點直接翻倍

AKS：承認上限，走 Multi-Cluster 橫向擴展

Microsoft Azure 則選了截然不同的路線，承認¹¹單叢集 5,000 nodes / 200,000 pods 的上限，轉而用 Fleet Manager¹² 做 Multi-Cluster 橫向擴展。

Fleet Manager 讓你統一管理多個 AKS 叢集，透過跨叢集的負載分配來突破單叢集限制。這個策略的優勢是：

• 不需要改動 Kubernetes 核心元件
• 單叢集保持在 upstream 建議的安全範圍內
• 故障隔離更好，一個叢集掛了不影響其他叢集

但缺點也很明顯，例如跨叢集通訊會帶來額外開銷，資料一致性也更具挑戰。更關鍵的是，大型 AI 訓練（例如訓練 ChatGPT 級別的模型）需要所有節點在同一個網路內進行 all-reduce 的梯度同步與運算，這在跨叢集架構下難以實現。因此，GKE 和 EKS 才會選擇在單一叢集內做到極限。

ByteDance：全自建控制面，追求極致吞吐

ByteDance 走了最「硬核」的路線，完全自建控制面元件（KubeWharf¹³ 生態系）：

• KubeBrain：替代 etcd，基於 TiKV/byteKV，支援 20K+ nodes
• Gödel scheduler：並行排程器，達到 5,000 pods/sec³（上游約 100 - 500 pods/sec）
• Katalyst：資源管理框架，達到 60% 資源利用率
• KubeAdmiral¹⁴：Multi-Cluster 橫向擴展編排引擎，管理 100K+ microservices、10M+ pods

這套自建體系支撐了 TikTok 等超大規模產品。但代價是極高的維護成本，需要一個專門的平台團隊來維護這些元件，而且無法直接受益於 Kubernetes 上游的改進。

OpenAI：從 2,500 到 7,500 的實戰之路

OpenAI 的經驗可能是最接近「一般企業」的擴展路徑。他們沒有自建控制面，也沒有替換 etcd，而是在 Azure 上一步步踩坑、一步步解決。他們的擴展歷程分為兩個階段：

1. 2,500 nodes 階段⁶：遇到 etcd 和網路層面的基礎瓶頸，開始意識到 Kubernetes 預設配置在大規模下的不足。
2. 7,500 nodes 階段⁷：從 Flannel（overlay 網路，Pod 封包在虛擬網路中傳輸）遷移到 Azure 原生 CNI（alias-based IP addressing，Pod 直接取得 Azure VNet IP，不需要額外封裝），網路吞吐量從 ∼2Gbit/s 跳到接近原生的 10–15Gbit/s，同時應對約 200K pod IP 的路由規模需求。

此外，OpenAI 團隊還處理了 API Server WATCH 的 N² 擴展問題，傳統的 Endpoints object 包含所有 Pod IP，每個節點都會 WATCH 這個巨大的 object，節點數 × object 大小形成 N² 放大效應。改用 EndpointSlices 將資料切分成小块後，負載降低了 1000x。同時也解決了 Prometheus 在大叢集下的 OOM 問題。

OpenAI 的經驗告訴我們：在邁向萬級節點之前，網路、DNS 和監控往往會率先出問題，而不只是 etcd。

阿里雲 ACK：管理萬級叢集

阿里雲的 ACK 走的是另一個維度¹⁵：不是單叢集擴展到萬級節點，而是管理萬級數量的叢集。這反映了不同市場的需求差異：大量中小型叢集的多租戶管理，而非少數超大型叢集。

Megacluster 比較總覽

三種擴展哲學

mindmap
  root((K8s 5K Nodes<br>三種突破策略))
    1. 單叢集擴展
      GKE
        用 Spanner 換掉 etcd
        已驗證 130K 節點
        每秒排程 1,000 Pods
      EKS
        把 etcd 共識層卸載
        已 GA 100K 節點
        單叢集支援 800K GPUs
    2. 多叢集聯合管理
      Azure AKS Fleet Manager
        單叢集上限 5K 節點
        跨叢集自動分配工作負載
        一個叢集掙了不影響其他
      阿里雲 ACK
        統一管理上萬個叢集
        多租戶共用架構
    3. 全自建控制面
      ByteDance KubeWharf
        KubeBrain 取代 etcd
        Gödel 並行排程 5,000 pods/sec
        Katalyst 資源利用率達 60%
        KubeAdmiral 管理 10M+ pods

從各家策略中，可以歸納出三種擴展哲學：

1. 單叢集垂直擴展（GKE、EKS）

改造 Kubernetes 底層元件，讓單一叢集承載更多節點。適合大型分散式 AI 訓練，例如 all-reduce（所有節點互相交換模型梯度的通訊模式，需要每個節點都能直接通訊）和需要統一資源視圖的場景。代價是深度改造意味著與上游漸行漸遠，控制面的單點風險也隨規模增大。

2. Multi-Cluster 橫向擴展（AKS Fleet、阿里雲）

保持單叢集在安全範圍內，透過上層的多叢集管理平台（如 AKS Fleet Manager）統一調度和管理。適合微服務架構、多區域部署和故障隔離要求高的場景。代價是跨叢集通訊開銷，以及無法支援需要全節點互通的分散式訓練任務。

3. 全自建控制面（ByteDance）

完全替換所有控制面元件，不受上游限制。只適合超大規模且有專業平台團隊的科技公司。代價是極高的維護成本，以及無法直接受益於上游改進。

共同模式與未來方向

儘管各家走了截然不同的技術路線，但仔細觀察後仍然可以歸納出幾個共同趨勢：

etcd 替代方案成為標配：GKE 用 Spanner、EKS 做 consensus offload、ByteDance 用 KubeBrain⁸⁹¹³。幾乎所有突破萬級節點的方案都需要「動 etcd」，這已經從各家的個別嘗試演變成大規模叢集的共同前提。

MultiKueue 跨叢集調度：讓 AI 訓練任務可以分配到多個叢集執行，兼顧多叢集的故障隔離和大規模運算需求。對 AKS Fleet 這類多叢集架構特別有意義。

DRA（Dynamic Resource Allocation）：當叢集規模超過萬級節點，GPU/TPU 的數量也隨之爆炸性增長（EKS 單叢集就有 800K GPUs）。傳統的 device plugin 只能做簡單的數量分配，無法處理「我需要同一台機器上的 4 張 GPU 且它們透過 NVLink 互連」這類拓撲感知的需求。DRA 提供更精細的硬體資源分配機制，是大規模 AI 叢集的必要基礎。

Gang scheduling：大型 AI 訓練通常需要「全部或不調度」的語義，所有 worker 全部就緒才啟動，否則整個任務不調度。在萬級節點的叢集中，一個訓練任務可能需要同時佔用數千個 GPU，如果只排到一半就開始運行，剩下的資源全部浪費。Gang scheduling 確保資源全到位才啟動，正在成為大規模 AI 叢集的標配。

結語

回顧全文，各家的技術路線清楚反映了不同的產品定位和工程取捨：

• GKE 用 Spanner 做最乾淨的架構重構，適合深度使用 Google Cloud 的用戶
• EKS 在 etcd 上做深度改造保持 conformance，適合需要最大規模單叢集的 AI 公司
• AKS 務實地走 Multi-Cluster 橫向擴展，適合多區域部署和故障隔離要求高的企業
• ByteDance 完全自建控制面追求極致吞吐，適合有強大平台團隊的科技公司

對大多數企業來說，「分而治之」仍是最穩健的策略。但隨著 AI 訓練規模持續成長，大語言模型需要數千乃至數萬個加速器協同運算，單叢集的極限也在不斷被推高。

未來的關鍵趨勢將圍繞 etcd 替代方案的標準化、MultiKueue 跨叢集調度、DRA 和 gang scheduling 展開。Kubernetes 能否在這場超大規模的軍備競賽中持續演進，值得持續關注。

參考資料