Google Kubernetes Engine (GKE) 团队近日披露，他们成功构建并运维了一个包含13万个节点的Kubernetes集群，这也是迄今为止公开披露的最大规模的Kubernetes集群。这一里程碑标志着云原生基础设施已经发展到能够胜任AI与数据时代所要求的大规模、高密度计算工作负载。
为实现这一目标，团队对Kubernetes控制平面的关键组件和存储后端进行了重构。他们放弃了传统的etcd数据存储，转而采用基于Spanner的自定义存储系统，该系统能够支撑超大规模集群的稳定运行。同时，团队还优化了集群API和调度逻辑，以减少频繁的节点与Pod状态更新带来的负载压力。工程团队还引入了新的工具集，实现了自动化、并行化的节点池供应和快速扩容，从而突破了传统架构下制约集群响应能力的瓶颈。
随着AI训练与推理工作负载的增长，往往需要数百甚至数千个GPU或高吞吐量CPU集群来支持。运行超大规模的统一Kubernetes集群因此成为一项关键能力。一个拥有13万个节点的集群，意味着大规模模型训练、分布式数据处理或全球微服务舰队等任务可以在单一控制平面下进行管理，极大地简化了编排与资源共享的复杂度。
此次规模突破的核心在于，谷歌使用自定义的、基于Spanner的存储层替代了etcd作为主控制平面数据存储。传统的Kubernetes依赖etd来实现强一致性的状态管理，但在极高的节点和Pod数量下，etcd会因写入放大、监控分发开销和领导者选举等问题成为扩展瓶颈。通过将集群状态卸载到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所展示的可扩展性雄心并非某一家云供应商所独有。主要云服务提供商承诺在生产环境中提供10万个节点的Kubernetes集群，这一事实强化了Kubernetes已为“AI千兆瓦时代”做好准备的论点。这也为那些正在评估是投资于自定义的大规模工程（如GKE的13万节点构建），还是通过EKS采用托管式高规模服务的公司提供了一个选择。 | 
发表于 5 天前
|
查看: 10|
回复: 0
