Cluster Google 130K nœuds : K8s à l'échelle IA

Publié le avril 18, 2026 · par ALGERIATECH Editorial

⚡ Points Clés

Google a fait tourner un cluster GKE de 130 000 nœuds orchestrant 1,3 million de vTPU avec 90 % d’utilisation en AllReduce — le double de l’ancienne limite Kubernetes de 65 000 nœuds et le plus grand cluster publiquement divulgué à ce jour. Clés : un stockage Spanner en remplacement d’etcd, un cache de watch fortement cohérent shardé, et Kueue plus JobSet pour l’ordonnancement par job. AWS EKS plafonne à 10 000 nœuds et Azure AKS à 5 000, ce qui donne à Google une marge de 13x à 26x.

En résumé : Les équipes plateformes IA en entreprise devraient auditer leurs ordonnanceurs customs et piloter Kueue et JobSet sur leurs empreintes Kubernetes existantes avant d’ajouter davantage de code d’orchestration sur mesure.

Lire l’analyse complète ↓

🧭 Radar de Décision

Pertinence pour l’AlgérieMoyen▾

Peu de charges algériennes ont besoin de 130K nœuds aujourd’hui, mais les primitives Kueue + JobSet deviennent pertinentes dès quelques dizaines de nœuds — elles améliorent l’efficacité d’entraînement et le coût pour toute charge GPU.

Infrastructure prête ?Partiel▾

Les entreprises algériennes peuvent accéder à GKE et Kueue via les régions Google Cloud. La capacité locale en data centers pour héberger des clusters d’entraînement IA à grande échelle est en croissance.

Compétences disponibles ?Limité▾

Les opérateurs Kubernetes existent, mais l’expertise Kueue/JobSet à l’échelle IA est rare — les universités et bootcamps devraient l’ajouter aux cursus.

Calendrier d’action6-12 mois▾

Les équipes d’entreprise qui font tourner une charge sérieuse d’entraînement IA devraient évaluer Kueue/JobSet dans leur prochain cycle de planification.

Parties prenantes clésÉquipes plateformes IA/ML, DSI, responsables data engineering, universités

Type de décisionTactique▾

C’est une mise à niveau actionnable des piles Kubernetes existantes, et non un pivot stratégique pluriannuel.

En bref : Les équipes IA d’entreprise en Algérie devraient piloter Kueue sur leurs empreintes GKE ou Kubernetes auto-gérées existantes avant d’ajouter plus d’ordonnanceurs custom. Les DSI devraient auditer si leur pile d’entraînement IA repose sur des primitives batch non-Kubernetes qui peuvent être remplacées par le nouveau chemin de référence. La planification de capacité doit commencer à modéliser la disponibilité énergétique, pas seulement les cœurs GPU et CPU.

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 :

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.
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.
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.

Suivez AlgeriaTech sur LinkedIn pour des analyses tech professionnelles Suivre sur LinkedIn

Suivez @AlgeriaTechNews sur X pour des analyses tech quotidiennes Suivre sur X

Questions Fréquemment Posées

Quelle est la taille du cluster de 130 000 nœuds de Google comparée aux autres offres Kubernetes managées ?

Le cluster GKE de 130 000 nœuds est environ 13 fois plus grand que le plafond actuel d’AWS EKS de 10 000 nœuds par cluster et 26 fois plus grand que la limite d’Azure AKS de 5 000 nœuds. C’est le plus grand cluster Kubernetes publiquement divulgué à ce jour ; il a orchestré environ 1,3 million de vTPU avec 90 % d’utilisation en AllReduce collectifs.

Qu’est-ce que Kueue et JobSet, et pourquoi importent-ils ?

Kueue est un contrôleur de mise en file de jobs qui apporte les capacités d’un système batch — gang scheduling, admission tout-ou-rien, priorités, quotas, fair-share — à Kubernetes. JobSet est un compagnon qui orchestre les runs d’entraînement multi-jobs. Ensemble, ils transforment Kubernetes d’un ordonnanceur de pods en orchestrateur conscient de l’entraînement IA, supprimant le besoin de systèmes externes comme Slurm ou d’opérateurs custom pour beaucoup de charges.

Qu’est-ce que cette annonce signifie pour l’énergie et la planification des data centers ?

Google a explicitement signalé le basculement d’un monde contraint par les puces à un monde contraint par l’énergie. Un cluster de 100K GPU peut consommer plusieurs centaines de mégawatts. Les entreprises qui planifient leurs capacités IA devraient modéliser la disponibilité énergétique et du raccordement au même titre que la disponibilité GPU, et évaluer des options de génération sur site (piles à combustible, renouvelables co-localisés) dans les régions où les files utility sont longues.