EKS vs GKE：超大规模 Kubernetes 集群架构的性能深度对比（100K+ 节点）

AI 训练的爆发式增长，正在把 Kubernetes 集群推向前所未有的规模。当单个训练任务可能需要数万张 GPU 同时协作时，“一个集群究竟能撑多大”就不再是理论问题，而是实打实的基础设施决策。

到 2025 年底，Google Cloud 和 AWS 几乎同时给出了各自的答案：GKE 展示了一个 130,000 节点的集群演示¹，EKS 则正式提供了 100,000 节点超大规模集群支持²。两者都在为超大规模 AI 工作负载铺路，但它们的架构路线却截然不同：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>无需分片"]
        GS --> GS2["1M+ Objects<br>13,000 QPS"]
        GA --> GK["Kueue"]
        GK --> GK1["Gang Scheduling<br>93 秒抢占 39K Pods"]
        GA --> GN["节点管理"]
        GN --> GN1["Node Problem Detector<br>+ 自动修复"]
    end
    subgraph EKS["☁️ EKS — 100K Nodes"]
        direction TB
        EA["API Server"] --> ES["etcd（深度改造）"]
        ES --> ES1["Raft 共识卸载<br>BoltDB 放在 tmpfs 上"]
        ES --> ES2["Key-space 分区<br>10M+ Objects / 32 GB"]
        EA --> EK["Karpenter"]
        EK --> EK1["节点自动扩缩<br>2,000 nodes/min"]
        EA --> EM["节点管理"]
        EM --> EM1["自动修复<br>100 分钟滚动更新"]
    end

规模指标对比：130K vs 100K

根据 Google Cloud 和 AWS 公开披露的数据，下面整理出几个最关键的对比指标：

如果只看公开出来的核心数字，GKE 在调度速度和最大节点数上更占优势。更值得注意的是，GKE 在平台层做了更多深度集成：Kueue 的 gang scheduling、Spanner 控制面后端，以及内建的节点扩缩能力，都更像是平台“开箱即用”的能力，而不是交给用户自己拼装的方案。

相比之下，EKS 公开了更完整的大规模集群运维数据，但要达到这些结果，背后需要相当多的工程优化。这些优化大致可以分成两层：

• AWS 平台层改造：包括 etcd 的 key-space 分区、把 BoltDB 放到 tmpfs、把 Raft 共识卸载到 AWS 内部日志系统，以及修复 API Server informer cache 的锁竞争问题。这些都是 AWS 在控制面内部完成的改造，不需要用户自行配置。
• 用户层调优：包括 Karpenter 的 disruption budget 参数、把 SOCI Snapshotter 预装进节点 AMI、镜像拉取策略，以及工作负载层面的资源配置。这些仍然需要用户根据自己的场景去理解和优化。

换句话说，GKE 把更多复杂性收进了平台内部，而 EKS 则把更多调优自由度，以及相应责任，留给了用户。这种差异的根源，首先来自两者完全不同的存储架构。

存储架构：Spanner vs 深度改造后的 etcd

这是整个比较里最关键的架构差异，也很可能是决定两者扩展上限的核心因素。

GKE 的路线：直接用 Spanner 替换 etcd

GKE 选择了更激进的做法：直接把 Kubernetes 控制面的后端存储从 etcd 换成 Google 自家的 Spanner¹。Spanner 是为大规模一致性和水平扩展设计的分布式数据库，因此 GKE 不需要继续和 etcd 的传统瓶颈正面缠斗，而是从一个完全不同的架构起点出发。

从公开数据来看，GKE 在 130K 节点规模下实现了 13,000 QPS 的 lease 更新吞吐，并没有明显表现出逼近极限的迹象。控制面还处理了超过 100 万个对象，这对 Spanner 来说并不算激进负载。

这种设计的好处是，不需要围绕分片策略或内存优化做太多额外工程，因为 Spanner 本身已经解决了分布式一致性和扩展性问题。代价则是它离上游 Kubernetes 更远了：标准 Kubernetes 默认依赖 etcd，而 GKE 直接换成 Spanner，意味着控制面本身已经是高度定制化的实现。

EKS 的路线：保留 etcd，但对其做大规模底层重构

EKS 则走了相反的路线。它保留 etcd 作为控制面存储，但围绕 etcd 做了大量底层优化：

• Raft consensus 卸载：把 etcd 的 Raft 协调逻辑卸载到 AWS 内部 journal 系统，以降低共识延迟
• BoltDB 放到内存后端：把底层 BoltDB 引擎从磁盘迁移到 tmpfs，大幅降低 I/O 延迟
• Key-space 分区：对 etcd 的 key space 做分区，据称最多可带来 5 倍写入吞吐提升

通过这些改造，EKS 对外披露的 etcd 总体量达到 32 GB（跨分区），数据库对象数超过 1,000 万³。不过，由于这两份测试报告的测试条件和统计口径并不完全一致，更稳妥的解读方式是：EKS 公开展示了更高数量级的对象规模，而不是直接得出“它的存储能力一定比 GKE 强 10 倍”这样的结论。

继续沿用 etcd 的好处是：EKS 在接口层面更接近上游 Kubernetes，不太容易踩到规范兼容性的坑。代价同样很明显：工程复杂度极高，每一层 etcd 深度改造都需要大量验证来保证稳定性。

调度能力：Kueue Gang Scheduling vs 默认调度器模型

在超大规模集群中，存储架构决定的是控制面“能不能撑住”，但对 AI 训练工作负载来说，调度器的行为更直接决定了 GPU 利用率和整体训练效率。传统 Kubernetes 调度本质上是一种“一次调度一个 Pod”的模式，这对很多微服务场景没有问题，但对于大规模分布式训练，部分调度成功往往会直接导致昂贵算力被浪费。

想象一个需要 1,000 张 GPU 的分布式训练任务，如果调度器只成功放置了 800 张，剩余资源又被其他作业抢走，那么这 800 张 GPU 很可能只能空转等待，既无法开始训练，也没法释放出来给别的任务使用。在十万级节点规模下，这种资源碎片化问题会被进一步放大。

这就是为什么 gang scheduling 在 AI 训练场景里如此关键：一组 Pods 要么同时启动，要么就不该启动。如果一个需要 1,000 张 GPU 的训练任务只分配到 999 张，那么这 999 张也可能全部被浪费。

GKE 在这一点上展示了明显优势。通过集成 Kueue 这个 Kubernetes 原生排队框架，GKE 展示了在 93 秒内抢占 39,000 个 Pods，从而为高优先级训练任务腾出资源的能力¹。这个数字在真实 AI 环境里非常有价值。需要紧急回收资源时，93 秒和几分钟甚至更久，差别是非常大的。

相比之下，EKS 的公开材料并没有给出 gang scheduling 方案或相应测试数据。这并不意味着 EKS 不能做 gang scheduling，因为 Kueue 同样可以部署在 EKS 上。但至少从当前公开材料来看，GKE 在这一维度上给出了更强的开箱即用集成，以及经过大规模验证的数据点。

EKS 公开了更完整的节点生命周期数据

如果说调度是 GKE 的强项，那么大规模节点运维则是 EKS 更突出的地方。EKS 公开了更完整的节点生命周期数据：

• 节点加入速率：每分钟 2,000 个节点，50 分钟完成 100K 节点集群构建
• 节点自动修复：自动检测故障节点并触发修复
• 100K 节点滚动更新：依靠 Karpenter disruption budgets，在大约 100 分钟内完成整个集群的滚动更新

测试环境还把 SOCI Snapshotter 预装进节点 AMI，以延迟容器镜像加载，降低大规模启动时镜像拉取带来的瞬时带宽压力。在 API Server 层面，EKS 团队也受益于 v1.31 引入的缓存强一致读取，同时还向上游贡献了 informer cache 锁竞争修复（PR #132132 和 #130767）³。

GKE 在 130K 节点测试中公开的大规模运维细节相对较少，但这并不应该被解读为 GKE 在节点修复或自动化方面较弱。更合理的解释是，这次公开材料的叙事重点主要放在控制面吞吐和扩展天花板，而不是完整生产生命周期流程。

实际上，GKE 本身已经具备不少平台内建能力，可以覆盖 EKS 报告里强调的大部分类自动修复场景：

• Node Problem Detector + 自动替换：GKE 默认启用 Node Problem Detector，节点可以上报常见 OS、kubelet 和容器运行时异常；当健康状态持续异常时，托管节点池可以自动 drain 并重建节点。
• Managed Instance Group（MIG）和节点池控制回路：对于很多基于 VM 的 GKE 节点池，真正负责维持期望节点数和替换异常节点的，是底层的 managed instance group。
• 结合自动升级与自动修复的受控滚动替换：GKE 已经具备围绕 cordon、drain、PodDisruptionBudget 和优雅终止默认策略的节点升级与替换机制。只是 Google 这次没有把“100K 节点滚动更新需要多久”作为主打测试指标⁴。

因此，更准确的表述应该是：EKS 公开了更完整、可直接对照的大规模运维数字，而 GKE 在这方面公开细节较少。但这并不代表 GKE 缺少节点健康探测或自动修复能力。差异既来自平台设计，也来自测试报告的叙事方式和指标选择。

如何解读这些测试结果

在下结论之前，需要先明确一个前提：这两份测试报告并不是完全等条件的对比。

GKE 的 130K 节点结果更像是一场工程能力展示，重点在于说明控制面在理想条件下的扩展上限。它强调的是 Pod 调度吞吐、Spanner 后端表现，以及 Kueue 的 gang scheduling 能力¹。

EKS 的 100K 节点结果则更接近生产导向的运维模拟，覆盖了节点加入、滚动更新和故障恢复等 Day-2 运维数据²。不过，EKS 的故障模拟只停用了 1,000 个节点，也就是整个集群的 1%，相较于真实世界里更苛刻的故障域，可能仍偏保守。

两份报告都来自各自云厂商的官方发布，因此都会优先展示最有利的数据点。真正比较时，既要看“公开了什么”，也要看“没有公开什么”。GKE 没公布滚动更新数据，不代表它做不好；EKS 没公布 gang scheduling 数据，也不代表它无法通过开源方案实现类似能力。

结语

回头来看，GKE 和 EKS 在超大规模集群上走的是两条不同的路线，但它们要解决的核心问题是一致的：如何在 100K 节点规模下保持 Kubernetes 控制面稳定，同时有效调度并运营大规模 AI 训练工作负载。

可以把两者的高层差异总结如下：

还需要强调一点：节点自动修复并不是 EKS 独有的能力。GKE 早已具备 Node Problem Detector 和自动修复机制，可以检测 OS、kubelet 和容器运行时层面的异常并自动替换故障节点⁵；而 EKS 也已经补上了节点监控代理和自动修复功能⁶。两者在这方面的能力正在逐渐趋同。更大的差异在于：EKS 公开了更完整的大规模 Day-2 运维故事，而 GKE 的 130K 节点文章更聚焦于控制面吞吐和调度上限¹²。

那么，该怎么选？

• 如果你的核心场景是 突发式 AI 训练，需要快速调度数万个 Pods，并依赖 gang scheduling 避免 GPU 空转，那么目前公开数据里，GKE 基于 Spanner + Kueue 的路线给出了更高的上限。
• 如果你更关注 Kubernetes 规范兼容性，以及 大规模运维流程的可预测性，例如滚动更新要多久、故障恢复流程如何落地，那么 EKS 给出了更完整、也更容易复现的公开运维数据⁷。

如果你两者都在意，那么最难的问题其实不再是“单个集群能不能撑到这个规模”，而是“你的团队能不能长期稳定地运维这么大的集群”。在这个规模下，分而治之依然是最务实的策略。基于工作负载特性、团队边界和故障域，把工作负载拆分到多个集群里，通常会比把所有东西都塞进一个超级大集群更稳健、更容易排障，也更容易演进。能跑到 130K 节点是一回事，能长期稳定地运维 130K 节点，是另一回事。

参考资料