Le cluster Kubernetes à 130 000 nœuds de Google : ce que l’orchestration hyperscale change pour les charges IA en 2026

Le plus grand cluster Kubernetes publiquement divulgué

Dans un article d’ingénierie du Google Cloud Blog, Google décrit un cluster GKE de 130 000 nœuds construit et exploité en mode expérimental — le double du plafond précédemment supporté de 65 000 nœuds et le plus grand cluster Kubernetes publiquement divulgué à ce jour. La démonstration, détaillée autour de KubeCon 2025, prouve que Kubernetes standard peut désormais opérer à l’échelle requise par les entraînements IA frontières, sans pousser les opérateurs vers des ordonnanceurs sur mesure.

Le cluster a orchestré environ 1,3 million de vTPU tout en soutenant 90 % d’utilisation en AllReduce collectifs — le motif qui compte pour l’entraînement de grands modèles. Il a aussi atteint des chiffres de benchmark qui redéfinissent « l’orchestration hyperscale » :

• QPS de l’API server à 500k au pic, écritures etcd à 100k/sec.
• Débit soutenu de 1 000 démarrages de pods par seconde avec un démarrage de pod sous 5 secondes à l’échelle du cluster.
• Kueue a préempté 39 000 pods en 93 secondes pour laisser place à des charges prioritaires.

Comment Kubernetes a brisé son propre plafond

Trois évolutions architecturales ont rendu 130K nœuds atteignables :

1. Remplacer etcd par un stockage basé sur Spanner. Des comptes d’objets dépassant 1,3 milliard saturent la mémoire et les chemins d’écriture d’etcd. Google a substitué le magasin clé-valeur par défaut par un système custom basé sur Spanner qui scale horizontalement sans les limites historiques d’etcd. C’est le plus grand changement du plan de contrôle de Kubernetes depuis 10 ans.
2. Watch cache et sharding de l’API server. Un watch cache fortement cohérent combiné à un modèle de sharding plus fin garde l’API server réactif à 500k QPS, au lieu de s’effondrer aux dizaines de milliers que plafonnent habituellement les clusters de production.
3. Ordonnancement par job avec Kueue et JobSet. L’ordonnanceur Pod par défaut est la mauvaise primitive pour l’IA. Kueue ajoute le gang-scheduling, l’admission tout-ou-rien, le fair-share, les priorités et les quotas — le vocabulaire batch qui manquait à l’entraînement ML. JobSet orchestre les runs multi-jobs par-dessus.

Pourquoi cela compte pour les charges IA

Le contexte concurrentiel mérite d’être nommé. AWS EKS plafonne à 10 000 nœuds par cluster et Azure AKS à 5 000, ce qui force des architectures multi-clusters et la dette opérationnelle qui vient avec. La marge de 13x à 26x de Google sur les concurrents managés signifie qu’un entraînement IA frontière peut s’exprimer comme un seul job Kubernetes au lieu d’une fédération de clusters collée par du glue code.

Pour les équipes IA d’entreprise, trois déplacements pratiques s’imposent :

• L’ordonnancement par job devient une primitive Kubernetes de première classe. Si votre pile d’entraînement a des ordonnanceurs custom boulonnés hors de Kubernetes (Ray, Slurm, opérateurs maison), Kueue et JobSet sont désormais le chemin de référence. Les équipes devraient évaluer la migration plutôt qu’accumuler plus de code custom.
• La prime multi-clusters / fédération se réduit. Les équipes qui ont architecturé autour de l’hypothèse « un seul cluster ne tiendra pas » construite il y a 12 mois doivent revisiter. Des topologies mono-cluster plus simples peuvent redevenir viables pour beaucoup de charges d’entraînement d’entreprise.
• L’outillage d’observabilité doit suivre. Même quelques milliers de nœuds pèsent déjà sur Prometheus, les pipelines de logs et les dashboards. Un monde à 130K nœuds implique de réarchitecturer la pile d’observabilité avec du streaming et de l’échantillonnage intégrés.

Le goulot passe des puces à l’énergie

L’aveu le plus franc dans les divulgations concerne la vraie contrainte. L’industrie est en train de passer d’un monde contraint par l’offre de puces à un monde contraint par l’énergie électrique. Un seul NVIDIA GB200 consomme 2 700 W, et l’empreinte énergétique d’un cluster de 100K GPU peut atteindre plusieurs centaines de mégawatts — un profil de charge que la plupart des data centers et des raccordements utility ne savent pas livrer vite.

C’est pourquoi l’histoire de scalabilité de GKE se conjugue avec celle des data centers alimentés par piles à combustible — les deux sont des réponses à la même réalité sous-jacente. Kubernetes scale désormais au niveau du job ; la pile énergétique du data center doit scaler au niveau du cluster Kubernetes. Les entreprises qui résolvent les deux bouts de la pile posséderont la décennie de l’infrastructure IA.

Ce que les architectes d’entreprise devraient faire

Trois mouvements pratiques pour la planification 2026 :

• Auditer la surface d’ordonnanceurs custom. Chaque ordonnanceur custom, opérateur custom ou système batch non-Kubernetes devient de la dette technique potentielle maintenant que Kueue existe. Tout ne doit pas migrer, mais tout doit être revu.
• Piloter Kueue sur les empreintes GKE existantes. Les primitives qui ont rendu 130K nœuds possibles — files d’attente de jobs, gang scheduling, quotas fair-share — règlent de vrais problèmes même sur des clusters de 500 nœuds. La technologie est disponible aujourd’hui.
• Reconstruire les plans de capacité autour de l’énergie, pas seulement des cœurs. La ressource rare n’est plus la disponibilité des puces pour la plupart des cas d’usage d’entreprise — ce sont les kilowatts qu’il faut pour les alimenter. La planification de capacité doit modéliser explicitement les régions contraintes en énergie et les options de génération sur site.

Google n’a pas seulement brisé une limite Kubernetes. Il a changé la forme de la conversation sur la façon dont l’entraînement IA devrait être orchestré — et, par extension, sur la conception de la prochaine génération de data centers IA.

Sources et lectures complémentaires

• How We Built a 130,000-Node GKE Cluster — Google Cloud Blog
• Google Cloud Demonstrates Massive Kubernetes Scale with 130,000-Node GKE Cluster — InfoQ
• Benchmarking a 65,000-Node GKE Cluster with AI Workloads — Google Cloud Blog
• Google’s 130,000-Node GKE Cluster: Scaling AI, Confronting Power Limits — Austin Osuide
• GCP: Building the Largest Known Kubernetes Cluster — CloudSteak
• Google Breaks Kubernetes Limits Again — FAUN Kaptain
• Google’s 130,000-Node Kubernetes Colossus — WebProNews