
谷歌 Kubernetes 引擎(Google Kubernetes Engine,GKE)背后的团队透露,他们成功构建并运行了一个拥有 13 万个节点的Kubernetes集群,使其成为迄今为止最大的公开披露的 Kubernetes 集群。这一里程碑突显了云原生基础设施的进步程度以及其对于 AI 和数据时代大规模、计算密集型工作负载的准备情况。
这一壮举是通过重构 Kubernetes 控制平面和存储后端的关键组件来实现的,用一个基于自定义Spanner的系统取代传统的 etcd 数据存储,以支持大规模,并优化集群 API 和调度逻辑,以减少恒定节点和 Pod 更新带来的负载。工程团队还引入了新的工具,用于自动化、并行化的节点池配置和更快的调整大小,帮助克服了在这种规模下通常会阻碍响应性的典型瓶颈。
随着 AI 训练和推理工作负载的增加,通常需要数百或数千个 GPU 或高吞吐量 CPU 集群,运行庞大、统一的Kubernetes集群的能力成为一个关键的推动因素。通过 13 万个节点的集群,大规模模型训练、分布式数据处理或全局微服务集群等工作负载可以在单个控制平面下进行管理,简化了编排和资源共享。
规模突破的核心是 Google 用定制的、基于Spanner的存储层取代了etcd作为主要的控制平面数据存储。。传统的 Kubernetes 依赖 etcd 来进行强一致性状态管理,但由于写扩增、监控扇出和领导者选举开销,etcd 在非常高的节点和 Pod 数量下成为扩展瓶颈。通过将集群状态卸载到 Spanner 中,谷歌获得了水平可扩展性、全局一致性以及节点、Pod、资源租赁等 API 对象的自动分片。这极大地降低了 API 服务器的压力,并消除了通常将 Kubernetes 集群限制在数万个节点的共识瓶颈。对 API 服务器进行重构,以批量处理和压缩监控流量,防止因节点心跳和 Pod 状态更新而导致控制平面饱和。
对于基础设施资源,谷歌引入了高度并行化的节点配置和调度优化,以避免当数万个节点同时加入集群时发生的踩踏问题。节点池的创建使用了激进的并行性,而 kube-scheduler 则被调优以减少每个 Pod 的调度延迟并最小化全局锁定。网络和 IP 地址管理也被重新设计,以避免CIDR耗尽和极端规模的路由表限制。至关重要的是,工程师将“集群规模”视为一个全栈系统问题,涵盖了 API 效率、数据库架构、调度算法和网络控制平面,而仅仅不是简单地增加资源配额。这种架构转变是 Kubernetes 能够从数万个节点进入真正的超大规模领域的原因。
这一里程碑也代表了对 GKE 限制的巨大飞跃。就在几年前,GKE还支持多达 65,000 个节点的集群。虽然这些限制已经支持了大规模的工作负载,但 13 万个节点是该容量的两倍多,这强烈表明谷歌云支持其所谓的“AI 吉瓦时代”的雄心壮志。
尽管如此,谷歌警告说,这个集群是在“实验模式”下构建的,主要是作为验证可扩展性的概念验证。在大多数实际部署中,像自动扩展、网络策略、资源配额和调度限制这样的限制可能需要更保守的配置。
对于追求大规模 AI 或数据工作负载的组织来说,这一公告表明,曾经被认为只适用于中小型服务的云原生基础设施现在可以扩展到数十万个节点。它表明,Kubernetes 在适当优化后,即使是最苛刻的计算需求下,仍然是一个可行的支柱。
然而,这种集群扩展并不是谷歌所独有的。在 2025 年 7 月,AWS宣布EKS 现在支持多达 10 万个工作节点的集群,这比通常的限制有了显著的增长。这种增强是针对超大型 AI/ML 工作负载的:根据 AWS 的说法,这种规模的单个 EKS 集群可以支持多达 160 万个 Trainium 芯片或 80 万个 NVIDIA GPU,从而实现“超大规模的 AI/ML 工作负载,如最先进的模型训练、微调和智能推理。”
AWS 记录了他们如何通过在底层进行广泛的再工程来实现这种规模。他们通过调整 Kubernetes API 服务器、扩展控制平面容量、改进网络和镜像分发管道来优化数据平面以处理极端负载。在测试期间,集群处理了数百万个 Kubernetes 对象(节点、Pod、服务),即使在高扰动和高调度负载下,也能保持响应式的 API 延迟。
最近的 EKS 声明表明,GKE 所展示的可扩展性雄心并不是一家云供应商所独有的。一家主要的云提供商承诺提供具有 100K 节点的 Kubernetes 集群,这一事实加强了 Kubernetes 已经为“AI 吉瓦时代”做好了准备的论点。它还为公司提供了一个选择,以评估是否投资于定制的大规模工程(如 GKE 的 130K 节点构建)或通过 EKS 采用托管的大规模服务。
原文链接:







评论