Google Kubernetes Engine（GKE）のチームは、130,000ノードのKubernetesクラスターを成功裏に構築・運用したことを明らかにした。これにより、現在までに公表された中で最大のKubernetesクラスターとなった。このマイルストーンは、クラウドネイティブインフラストラクチャがどれほど進化したか、またAIやデータの時代における大規模で計算集約的なワークロードに対する準備が整っていることを示している。
この偉業は、Kubernetesのコントロールプレーンとストレージバックエンドの主要コンポーネントを再設計することで達成された。従来のetcdデータストアを、大規模なスケールをサポートできるカスタムのSpannerベースのシステムに置き換え、クラスターのAPIやスケジューリングロジックを最適化して、ノードやポッドの更新による負荷を軽減した。また、エンジニアリングチームは、自動化された並列ノードプールのプロビジョニングや迅速なリサイズのための新しいツールを導入し、このような大規模な環境での応答性を妨げる典型的なボトルネックを克服する手助けをした。
AIのトレーニングや推論のワークロードが増加する中で、しばしば数百または数千のGPUや高スループットのCPUクラスターを必要とするため、大規模で統一されたKubernetesクラスターを運用する能力は重要な要素となる。130,000ノードのクラスターを用いることで、大規模なモデルのトレーニング、分散データ処理、またはグローバルなマイクロサービス群といったワークロードを単一のコントロールプレーンの下で管理でき、オーケストレーションやリソースの共有が簡素化される。
スケールの突破口となったのは、Googleがコントロールプレーンの主要データストアとしてのetcdを、カスタムのSpannerバックのストレージレイヤーに置き換えたことである。従来のKubernetesは、強い整合性のある状態管理のためにetcdに依存しているが、etcdは書き込みの増幅、ウォッチのファンアウト、リーダー選出のオーバーヘッドにより、非常に高いノードやポッドの数においてスケーリングのボトルネックとなる。クラスターの状態をSpannerにオフロードすることで、Googleは水平スケーラビリティ、グローバルな整合性、ノード、ポッド、リソースリースなどのAPIオブジェクトの自動シャーディングを実現した。これにより、APIサーバーへの負荷が大幅に軽減され、通常Kubernetesクラスターを数万ノードで制限する合意のボトルネックが排除された。また、APIサーバーは、ノードのハートビートやポッドの状態更新によるコントロールプレーンの飽和を防ぐために、ウォッチトラフィックをバッチ処理し圧縮するように再設計された。
インフラストラクチャリソースに関して、Googleは、数万のノードが同時にクラスターに参加する際に発生するサンダリングハード問題を回避するために、高度に並列化されたノードのプロビジョニングとスケジューリングの最適化を導入した。ノードプールは、積極的な並列処理を用いて作成され、kube-schedulerは、ポッドごとのスケジューリング遅延を減少させ、グローバルロックを最小限に抑えるように調整された。また、ネットワーキングとIPアドレス管理も見直され、極端なスケールでのCIDR枯渇やルートテーブルの制限を回避するように改良された。重要なことに、エンジニアたちは「クラスターのスケール」を、リソースの割り当てを単に増やすのではなく、APIの効率、データベースアーキテクチャ、スケジューリングアルゴリズム、ネットワークコントロールプレーンにわたるフルスタックシステムの問題として捉えた。このアーキテクチャの変化が、Kubernetesが数万ノードから真のハイパースケール領域へと移行することを可能にした。
このマイルストーンは、過去のGKEの限界を大きく超えるものである。数年前、GKEは最大65,000ノードのクラスターのサポートを文書化していた。これらの限界はすでに大規模なワークロードをサポートしていたが、130,000ノードはその容量の2倍以上であり、Google Cloudが「AIギガワット時代」と呼ぶものをサポートするという強い意欲を示すものである。
それでも、Googleは、このクラスターが主にスケーラビリティを検証するための概念実証として「実験モード」で構築されたことに注意を促している。ほとんどの実際の展開においては、オートスケーリング、ネットワークポリシー、リソースの割り当て、スケジューリングの制約といった制限により、より保守的な構成が必要となる場合がある。
大規模なAIやデータワークロードを追求する組織にとって、この発表は、かつては小規模から中規模のサービスにのみ適していると考えられていたクラウドネイティブインフラストラクチャが、今や数十万ノードまでスケールできることを示している。また、適切に最適化されたKubernetesは、もっとも要求の厳しい計算ニーズに対しても依然として有効なバックボーンであることを示している。
しかし、このようなクラスターのスケーリングはGoogleに特有のものではない。2025年7月、AWSはEKSが最大100,000のワーカーノードをサポートするクラスターを発表し、従来の限界を大幅に超えることとなった。この強化は、超大規模なAI/MLワークロードをターゲットにしており、AWSによれば、このスケールの単一のEKSクラスターは最大160万のTrainiumチップまたは80万のNVIDIA GPUをサポートでき、「最先端のモデルのトレーニング、ファインチューニング、エージェント推論」といった超大規模なAI/MLワークロードを可能にする。
AWSは、このスケールを達成するために、内部で広範な再設計をしたことを文書化している。彼らは、Kubernetes APIサーバーの調整、コントロールプレーンのキャパシティのスケーリング、ネットワークおよびイメージ配信パイプラインの改善を通じて、データプレーンを最適化し、極端な負荷に対応できるようにした。テスト中、クラスターは数百万のKubernetesオブジェクト（ノード、ポッド、サービス）を処理し、激しいノード／ポッドの入れ替わりや重いスケジューリング負荷の下でも応答性のあるAPI遅延を維持した。
最近のEKSの発表は、GKEが示したスケーラビリティの野心が特定のクラウドベンダーに限られないことを示している。主要なクラウドプロバイダーが、100,000ノードのKubernetesクラスターを本番環境で提供することを約束したことは、Kubernetesが「AIギガワット時代」に対応する準備が整っているという主張を強化するものである。また、企業がGKEの130,000ノード構築のようなカスタムの大規模エンジニアリングに投資するか、EKSを通じて管理された高スケールサービスを採用するかを評価する際の選択肢を提供する。