Kubernetes Megacluster 技術全景：不同平台如何突破 10K 节点门槛

Kubernetes Megacluster 技術全景：不同平台如何突破 10K 节点门槛

在上游 Kubernetes 社区里，SIG Scalability 长期将 5,000 节点视为一个有明确可扩展性目标和运维指导支撑的“大集群”量级12。但各大云厂商和基础设施能力很强的公司，早已持续挑战这个范围。GKE 通过用 Spanner 替换 etcd，展示了 130K 节点；EKS 通过对 etcd 做深度重构，实现了 100K 节点；ByteDance 通过自建控制面体系支撑 20K+ 节点；OpenAI 也公开总结了从 2,500 到 7,500 节点的扩展经验。

这些路线的技术实现完全不同，但目标一致：让 Kubernetes 继续承载更大规模的 AI 和平台工作负载。

本文会系统比较这些策略，解释它们分别在解决哪些瓶颈，以及超大规模 Kubernetes 接下来可能往哪里演进。

mindmap
  root((K8s 超大集群<br>技术全景))
    核心瓶颈
      etcd - Raft/BoltDB
      kube-scheduler - 串行路径
      API Server - 锁竞争
      网络与 DNS
    主要路线
      GKE - Spanner 130K
      EKS - etcd offload 100K
      AKS - Fleet Manager 5K
      ByteDance - KubeWharf 20K+
      OpenAI - 2.5K 到 7.5K
      阿里云 - 超大规模集群舰队管理
    扩展哲学
      单集群纵向扩展
      多集群横向扩展
      全自研控制面
    未来方向
      etcd 替代方案标准化
      MultiKueue
      DRA
      组调度

Kubernetes 的扩展上限到底在哪里？

在比较各家方案之前，先要理解为什么 5,000 节点会反复出现在 Kubernetes 的扩展性讨论里。

SIG Scalability 定义了一组面向大规模集群的 SLI 和 SLO1，包括：

  • 变更类 API 延迟：单对象的创建、更新、删除请求，p99 控制在 1 秒内
  • 只读 API 延迟：单对象读取在 1 秒内，大规模跨 namespace 或跨集群的 List 请求在 30 秒内
  • Pod 启动延迟：从 Pod 创建到容器报告启动完成，不含镜像拉取和 init container，p99 控制在 5 秒内

这些目标对应的是上游明确测试和文档覆盖的大集群范围。一旦显著超过这个规模，常见瓶颈就会被放大出来：etcd 写入延迟上升，调度器吞吐越来越难跟上，API Server 的 informer cache 也更容易在共享锁上发生争用。Kubernetes 的大集群文档同样明确提醒，超过这个文档化的大集群目标后，性能可能会明显下降2。

接下来拆开看这些瓶颈，就更容易理解各家为什么会走向不同的架构路线。

瓶颈拆解

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 共识开销"]
    C -.- C2["❌ 磁盘 I/O 瓶颈"]
    C -.- C3["❌ 默认容量限制"]
    D -.- D1["❌ RW 锁竞争<br>PR #132132, #130767"]
    E -.- E1["❌ 调度路径偏串行<br>~100-500 pods/sec"]
    G -.- G1["❌ 5K+ 节点下的网络与 DNS 问题"]

    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 保存 Kubernetes 控制面状态，底层依赖 BoltDB 存储，并通过 Raft 做复制。这个组合能很好地保证一致性和持久性，但到了超大规模时，也会集中暴露出几个老问题：

  • Raft 协调开销：每次写入都要经过共识路径，直接拉高延迟、限制吞吐
  • 磁盘 I/O 压力：WAL 写入和 snapshot 在高频状态变化下会越来越贵
  • 数据库体量限制：随着对象数量持续增长，默认 etcd 容量限制和运维复杂度都会迅速变得棘手

这也是为什么 GKE、EKS 和 ByteDance 都把存储层作为第一突破口，只是各自选了完全不同的做法。

kube-scheduler：偏串行的调度路径会撞上天花板

默认调度器并不是为极端并发的 Pod 放置场景设计的。当一个工作负载需要在很短时间内快速落下几千个 Pod，尤其是大规模分布式 AI 训练时，调度器吞吐本身就会成为瓶颈。ByteDance 的 Gödel scheduler 公开宣称可达到 5,000 pods/sec3，明显高于多数人对上游默认调度路径的量级认知。

API Server：informer cache 的锁竞争

在极端规模下，API Server 和控制器链路里的 informer cache 也会因为锁竞争产生明显开销。EKS 团队在超大规模测试期间识别并推动了两个关键修复：

  • PR #1321324：减少控制器路径里的 informer cache RW 锁竞争，降低事件处理延迟
  • PR #1307675：修复影响 API Server 与 controller-manager 行为的 informer cache 锁竞争问题

这些修复并不只对 EKS 有价值，而是让整个 Kubernetes 生态都受益。除此之外，Kubernetes v1.31 引入的缓存强一致读取（strongly consistent reads from cache），也进一步减少了直连 etcd 的读取压力。

网络与 DNS

OpenAI 从 2,500 扩展到 7,500 节点的公开经验说明，很多时候先出问题的未必是控制面，而是网络67：

  • Flannel 吞吐不足：OpenAI 曾报告 Pod 间吞吐只有 ~2 Gbit/s，后来迁移到 Azure 原生 CNI
  • KubeDNS 热点问题：调度集中和上游 DNS 限制叠加后，热点会非常明显
  • ARP 缓存溢出：超大规模 Pod IP 数量会撑爆邻居表，进而影响节点间通信

到了这个量级，很多平时看起来只是“小问题”的网络细节，都会直接升级为集群级故障模式。

不同平台是怎么突破的？

GKE：直接用 Spanner 替换 etcd

Google 的方案是和上游默认假设差异最大、但架构上也最干净的一条路线：用 Spanner 取代 etcd。

Spanner 为 GKE 提供了一个天然面向横向扩展、支持外部一致性事务的分布式存储后端。这样一来，GKE 不需要继续和 etcd 的经典单系统瓶颈硬碰硬，而是从一个完全不同的起点出发。根据 Google 的公开数据8，GKE 达到了：

  • 演示环境中的 130,000 节点
  • GKE v1.31+ 正式支持 65K 节点
  • 大约 1,000 pods/sec 的调度吞吐
  • 1M+ Kubernetes 对象

从架构角度看，这是一种非常优雅的解法。但代价也很明确：它高度绑定 Google Cloud 基础设施，与上游 Kubernetes 默认基于 etcd 的控制面假设相比，定制程度要高得多。

Google 同时也表示，生产环境客户已经在运行 20K 到 65K 节点规模的 TPU 和 GPU 训练集群8。

EKS：保留 etcd，但把最难的部分重做一遍

AWS 走的是反方向。它没有替换 etcd，而是在保留 etcd 的前提下，对周边实现做了大规模底层重构，同时尽量保持 Kubernetes 一致性兼容预期9：

  • 共识卸载：把 Raft 协调逻辑卸载到 AWS 内部日志（journal）层，减轻 etcd 自身的共识负担
  • key-space 分区：通过分区提升规模上限，把支持的对象数量推到 10M+
  • BoltDB 放进 tmpfs：既然持久性由其他层接管，就可以把 BoltDB 从 EBS 挪到内存后端，显著降低延迟

EKS 已经正式提供 100K 节点 GA10，AWS 也把它定位为超大规模 AI 环境的基础设施，公开提到过单集群设计点可面向 160 万颗 Trainium 或 80 万张 GPU 的量级。

AWS 还给出了相对少见的详细运维数据。在其测试环境中：

  • 节点加入速率大约是 每分钟 2,000 个节点
  • 整个 100K 节点集群大约 50 分钟完成拉起
  • 约 70K 节点承载微调（fine-tuning）工作负载
  • 约 30K 节点通过 LeaderWorkerSet 承载大型推理负载

对应的硬件和环境也经过了高度调优，包括 Trn2 与 P 系列实例、高吞吐 EBS，以及预装在 AMI 中的 SOCI Snapshotter，用于降低镜像拉取压力。

不过，这组结果仍需要谨慎解读：

  1. 测试环境条件很好，经过高度挑选和调优，并不是一般生产环境的自然基线。
  2. 对长期混合工作负载下的 Ingress、可观测性组件，以及大量监视/列出（Watch/List）消费者带来的控制面压力，并不是这次测试的主要重点。
  3. 无论控制面是否撑得住，几万到十万级加速器节点的成本本身都非常惊人。

AKS：接受单集群上限，转向多集群横向扩展

Microsoft 在 AKS 上的路线明显更务实。官方文档把 5,000 节点 / 200,000 Pods 作为 AKS 单集群的大规模上限参考11，然后通过 Fleet Manager 去做跨集群扩展，而不是继续把一个集群无限拉大12。

这条路线有很明确的优点：

  • 不需要重写 Kubernetes 核心组件
  • 每个集群都保持在更可控、更成熟的运行区间
  • 多集群之间的故障隔离更强

但它也有明显限制。一些分布式 AI 训练工作负载希望所有节点处于一个统一、扁平、可直接互通的网络里，方便做 all-reduce（全量归约）之类的集体通信。这也是为什么 GKE 和 EKS 仍然持续推动单集群极限。

ByteDance：自建控制面

ByteDance 走的是定制化程度最高的一条路，通过 KubeWharf 生态13 自建整套控制面能力：

  • KubeBrain 替代 etcd，底层基于 TiKV 或 byteKV，据称支持 20K+ 节点
  • Gödel scheduler 提供并行调度，公开宣称可达 5,000 pods/sec3
  • Katalyst 聚焦资源管理与利用率优化
  • KubeAdmiral 提供多集群编排，面向超大规模服务和 Pod 舰队14

这条路线意味着最大的控制权，也意味着最高的维护成本。对 TikTok 这种规模的公司来说是合理的，但前提是你必须愿意长期投入强平台团队，并接受自己离上游越来越远。

OpenAI：在 Azure 上循序渐进地扩容

如果你既不打算替换控制面，也不准备自研调度器，那么 OpenAI 的经验可能最有参考价值。

它公开的扩展过程大致分成两个阶段：

  1. 2,500 节点6：控制面和网络层面的薄弱点开始明显暴露。
  2. 7,500 节点7：重点逐步转向网络，包括从 Flannel 迁移到 Azure 原生 CNI，以获得更高吞吐和更大的 Pod IP 路由规模。

OpenAI 还详细写到了集群级 WATCH 模式对 API Server 的成本，尤其是巨大的 Endpoints 对象。改用 EndpointSlices 之后，这部分负担显著下降。团队同时也处理了 Prometheus 在大规模下的内存压力问题。

核心结论很直接：在你真正冲向 10K 节点之前，最先拖垮你的，往往是网络、DNS 和可观测性，而不只是 etcd。

阿里云：更强调超大规模集群舰队运维

阿里云展示的是另一种“规模”15：不是只追求一个单集群有多大，而是强调如何运维数量极多的 Kubernetes 集群舰队。这对应的是另一类业务需求，即多租户、多集群的大规模平台运维，而不一定是少数几个巨型 AI 集群。

超大集群路线对比

维度 GKE EKS AKS
公开讨论的最大规模 130,000 节点（演示） 100,000 节点（GA） 5,000 节点（单集群文档上限）
公开提到的生产规模 20K-65K 客户集群 客户环境已到数万节点量级 主要通过 Fleet 横向扩展，而不是单集群超过 5K
etcd 处理方式 ✅ 用 Spanner 替代 ✅ 保留 etcd，但做深度重构 ❌ 继续使用 etcd
Pod 调度吞吐 ~1,000 pods/sec ~500 pods/sec 官方未突出披露
超大规模策略 单集群纵向扩展 单集群纵向扩展 多集群横向扩展
主要 AI 加速器方向 TPU + GPU Trainium + GPU Azure 基础设施上的 GPU

三种扩展哲学

mindmap
  root((突破 5K 节点<br>三种策略))
    1. 单集群纵向扩展
      GKE
        用 Spanner 替代 etcd
        展示 130K 节点
        ~1,000 Pods/sec
      EKS
        卸载 etcd 共识层
        100K 节点 GA
        单集群支持超大规模加速器
    2. 多集群联合管理
      Azure AKS Fleet Manager
        单集群目标 5K 节点
        跨集群工作负载放置
        故障隔离更强
      阿里云
        集群舰队级运维
        多租户架构
    3. 全自研控制面
      ByteDance KubeWharf
        KubeBrain 替代 etcd
        Gödel 达到 5,000 pods/sec
        KubeAdmiral 管理超大规模舰队

综合来看，市场上的方案大致可以归纳为三种扩展哲学：

1. 单集群纵向扩展：GKE 与 EKS

这条路线会主动改造控制面，让一个集群可以承载远超上游默认范围的节点数。它很适合需要统一调度域和统一网络域的大规模分布式 AI 训练，但代价是控制面会越来越专用，单个集群的故障爆炸半径也会变大。

2. 多集群横向扩展：AKS Fleet 这类方案

这条路线让每个集群停留在相对安全的运行区间，再通过更上层的舰队平台做调度与管理。它更适合微服务、跨区域部署，以及强调故障域隔离的场景。缺点是，对于要求全节点直接互通的强耦合训练任务，适配并不如单集群方案自然。

3. 全自研控制面：ByteDance

这条路线通过重建整套控制面，尽可能摆脱上游限制。它只适合拥有超强平台团队、并且有足够业务规模支撑这笔长期工程成本的公司。

共同模式与未来方向

尽管实现细节不同，但有几个趋势已经越来越明显。

到了极端规模，几乎都要“动 etcd”。 GKE 直接用 Spanner 替代，EKS 保留 etcd 但把共识和存储路径大改，ByteDance 则通过 KubeBrain 自建替代方案8913。当集群规模明显超过上游测试范围后，控制面存储层几乎总会成为第一个被重构的部分。

MultiKueue 对跨集群 AI 调度越来越重要。 它提供了一种在多集群隔离能力之上，继续做作业级排队和跨集群放置的方式，对 Fleet 这类架构尤其关键。

DRA（Dynamic Resource Allocation，动态资源分配）会随着加速器数量暴涨而变得更重要。 到了这个规模，传统设备插件（device plugin）的表达能力往往太粗糙。AI 工作负载越来越需要拓扑感知的资源分配，比如同机多卡、NVLink 拓扑、PCIe 关系等。

组调度（Gang Scheduling）正在从“可选项”变成大规模 AI 集群的基本能力。 如果一个训练任务需要成千上万张加速器一起启动，部分调度成功只会浪费资源。因此，组调度会越来越成为集群设计的核心能力之一。

结语

这些平台的技术选择，本质上反映的是不同的产品定位和工程取舍：

  • GKE 通过用 Spanner 替代 etcd，走出了最彻底、也最干净的架构重构路线，目前公开的单集群上限最高。
  • EKS 在尽量贴近上游假设的同时，围绕 etcd 做了非常深的底层重构，适合既想要超大规模，又看重 Kubernetes 一致性兼容对齐的团队。
  • AKS 选择了更务实的多集群路线，通常也是运维上更保守、更稳妥的方案。
  • ByteDance 则证明了，只要愿意承担平台工程成本，全自研控制面确实可以把规模继续往上推。

对于大多数团队来说，分而治之仍然是更安全的默认策略。但随着 AI 训练持续需要更大规模、更加紧密协同的加速器资源，单个 Kubernetes 集群的实际天花板还会继续上移。

下一阶段的关键进展，很可能集中在更标准化的 etcd 替代路线、更成熟的 MultiKueue 跨集群调度、更丰富的 DRA 加速器感知能力，以及更完善的 gang scheduling 语义上。

参考资料

  1. Kubernetes SIG Scalability SLOs/SLIs ↩ ↩2

  2. Considerations for large clusters (Kubernetes) ↩ ↩2

  3. 5,000 pods/second and 60% utilization with Godel and Katalyst (KubeFM) ↩ ↩2

  4. Kubernetes PR #132132 ↩

  5. Kubernetes PR #130767 ↩

  6. Scaling Kubernetes to 2,500 nodes (OpenAI) ↩ ↩2

  7. Scaling Kubernetes to 7,500 nodes (OpenAI) ↩ ↩2

  8. How we built a 130,000-node GKE cluster (Google Cloud Blog) ↩ ↩2 ↩3

  9. Under the hood: Amazon EKS ultra scale clusters (AWS) ↩ ↩2

  10. Amazon EKS enables ultra scale AI/ML workloads with support for 100K nodes per cluster ↩

  11. Performance and scaling best practices for large workloads in AKS ↩

  12. Limitless Kubernetes Scaling for AI and Data-intensive Workloads: The AKS Fleet Strategy ↩

  13. KubeWharf community: how ByteDance is using Kubernetes ↩ ↩2

  14. KubeAdmiral: next-generation multi-cluster orchestration engine (CNCF) ↩

  15. Demystifying Kubernetes as a service (CNCF) ↩

« EKS vs GKE：超大规模 Kubernetes 集群架构的性能深度对比（100K+ 节点）
Eason Cao
Eason Cao Eason is an engineer working at FANNG and living in Europe. He was accredited as AWS Professional Solution Architect, AWS Professional DevOps Engineer and CNCF Certified Kubernetes Administrator. He started his Kubernetes journey in 2017 and enjoys solving real-world business problems.
comments powered by Disqus
Table of Content
Newsletter

訂閱並取得更新