Kubernetes 1.37 fait passer le gang scheduling en bêta et ajoute CompositePodGroup
La version 1.37 de Kubernetes (Garhwal) fait passer en bêta les API Workload et PodGroup, le gang scheduling et la préemption workload-aware, et introduit l’API CompositePodGroup pour planifier des groupes hiérarchiques de Pods destinés à l’IA/ML et au calcul distribué. Les équipes qui font tourner des charges par lots peuvent commencer à évaluer cette base native.
8 septembre 2026. L’équipe Kubernetes publie le billet qui détaille la prochaine étape du Workload-Aware Scheduling (WAS) dans la version 1.37, nom de code Garhwal. Les API Workload et PodGroup — qui portent le gang scheduling — passent en bêta, tout comme la préemption workload-aware et le partage des DRA ResourceClaims entre PodGroups. La version introduit surtout une nouvelle brique, l’API CompositePodGroup, pour exprimer des hiérarchies de groupes de Pods. Pourquoi c’est important : Kubernetes mise ouvertement sur les charges IA/ML et de calcul distribué, et fournit enfin une base native là où il fallait jusque-là un scheduler tiers.
Le gang scheduling passe en bêta
Le gang scheduling répond à un besoin précis des charges distribuées : un groupe de Pods doit se planifier ensemble ou pas du tout. Pour un job d’entraînement distribué, démarrer la moitié des workers sans le coordinateur ne sert à rien — il faut la garantie du « tout ou rien ». Les API Workload et PodGroup, qui encodent cette sémantique, passent donc en bêta en 1.37.
Le passage de cap s’accompagne de changements d’API à connaître :
- Versionnement. Les API Workload et PodGroup sont promues en v1beta1, à un cran de la disponibilité générale. Pour les pionniers qui testaient l’alpha, v1alpha2 est entièrement remplacé par v1alpha3 — une transition qui introduit des changements cassants destinés à nettoyer la structure autour du champ
disruptionMode. - File d’attente native. Jusqu’ici, chaque Pod membre d’un PodGroup était mis en file individuellement. En 1.37, seul l’objet PodGroup de tête est mis en file : tous ses Pods partagent ainsi le même comportement de file, ce qui prépare des stratégies de file avancées.
minCountmutable. Le champminCount, qui fixe le nombre minimal de Pods requis pour planifier un groupe, était strictement immuable. Il devient mutable : un contrôleur peut ajuster la taille minimale d’un gang à chaud, et les charges élastiques peuvent dégrader ou étendre leur périmètre sans interrompre les Pods déjà planifiés.
C’est ce dernier point qui raconte le mieux l’intention : Kubernetes ne vise pas seulement le HPC rigide, mais aussi les charges d’IA qui montent et descendent en puissance selon la demande.
La préemption workload-aware mûrit
La préemption workload-aware (WAP) décide quels Pods évincer quand un nouveau groupe ne tient pas dans le cluster. En 1.37, son feature gate distinct est fusionné dans le gate générique GenericWorkload, signe que la fonctionnalité est considérée comme un socle du gang scheduling et non plus une expérience isolée.
Deux évolutions changent le comportement réel :
- Une seule exécution de l’algorithme. En 1.36, le scheduler simulait la suppression des victimes puis réexécutait l’algorithme à chaque tentative de « repêchage » d’une victime, pour vérifier que le préempteur tenait encore. En 1.37, l’algorithme ne tourne qu’une fois : les Pods du préempteur sont supposés placés à partir de cette sortie, puis le repêchage vérifie si une victime peut rester en place. C’est un gain de performance direct sur les gros clusters.
- Le PodGroup devient une victime protégée. En 1.36, la préemption par défaut des Pods isolés ignorait les PodGroups et ne respectait pas leur
disruptionMode: un Pod pouvait être évincé seul, même quand son groupe exigeait le « tout ou rien ». 1.37 corrige cela : la préemption par défaut respecte désormais ledisruptionModedu PodGroup.
Le champ disruptionMode est d’ailleurs renommé pour être découplé de l’objet PodGroup : le mode PodGroup devient all, et le mode Pod devient single. Un nouveau champ preemptionPolicy apparaît sur le PodGroup (derrière le gate PodGroupPreemptionPolicy) pour décider, de façon autoritaire, si un groupe peut déclencher une préemption.
CompositePodGroup : la hiérarchie arrive
En 1.36, le WAS établissait une séparation nette entre le gabarit statique (Workload) et l’état d’exécution du groupe (PodGroup), mais les politiques de planification restaient limitées à un seul groupe plat. L’API CompositePodGroup, introduite en 1.37, étend ce modèle aux exigences hiérarchiques.
Concrètement, une charge peut désormais s’organiser en arbre de CompositePodGroup et de PodGroup, chaque nœud portant des politiques et des contraintes qui s’appliquent aux groupes qu’il chapeaute — un peu comme un PodGroup gouverne un groupe plat de Pods, mais sur plusieurs niveaux. Le scheduler traite cette hiérarchie comme une seule unité de planification et cherche à satisfaire les exigences de chaque groupe de l’arbre.
L’enjeu est l’ouverture à des structures de charge aujourd’hui gérées par des API d’extension comme JobSet et LeaderWorkerSet (LWS) : des grappes hétérogènes où des rôles différents (leader, workers, auxiliaires) ont des contraintes de topologie distinctes mais doivent démarrer et s’arrêter ensemble. Pour accompagner l’adoption, 1.37 livre un jeu d’API d’intégration pour les contrôleurs et la bibliothèque Go workloadbuilder, des briques standardisées qui simplifient l’intégration des contrôleurs hors-arbre. Le contrôleur natif Job a d’ailleurs été mis à niveau pour consommer pleinement ces API étendues.
Pourquoi Kubernetes mise sur le batch
Cette séquence de billets — gang scheduling, HPA à zéro, DRA, planification workload-aware — dessine une stratégie : Kubernetes veut devenir la plateforme par défaut des charges IA/ML et de calcul haute performance, pas seulement du web sans état. Le gang scheduling natif, la préemption consciente des groupes et les hiérarchies de CompositePodGroup attaquent directement le territoire occupé par des solutions comme Volcano ou Kueue.
La différence est la standardisation. Un scheduler tiers apporte sa propre API, ses propres objets et son propre cycle de vie. La voie native promet la même sémantique « tout ou rien », mais portée par les API Workload/PodGroup que l’écosystème commence à adopter comme dénominateur commun.
Ce qu’il faut mettre en place
Le tout est encore en bêta : à déployer sur des clusters de test, pas en production critique. Trois actions :
- Activez les feature gates. Gang scheduling, préemption workload-aware et CompositePodGroup passent par des gates (dont GenericWorkload et PodGroupPreemptionPolicy). Vérifiez la matrice exacte de la version 1.37 avant d’activer.
- Préparez la migration v1alpha2 → v1alpha3. Si vous avez des objets Workload/PodGroup en alpha, le remplacement de v1alpha2 par v1alpha3 est cassant autour de
disruptionMode. Reprenez vos manifestes avant la montée de version. - Évaluez contre votre scheduler actuel. Si vous utilisez Volcano ou Kueue, comparez sur vos charges réelles : le natif couvre-t-il le gang scheduling, l’élasticité (
minCountmutable) et la hiérarchie dont vous avez besoin ? Migrer trop tôt vers une bêta, c’est accepter des changements d’API futurs.
Verdict
Si vous faites tourner des charges de type IA/ML, HPC ou batch distribué sur Kubernetes, la 1.37 est le bon moment pour commencer l’évaluation sérieuse du WAS natif : le gang scheduling en bêta, la préemption consciente des groupes et l’API CompositePodGroup couvrent la majorité des cas pour lesquels vous payez un scheduler tiers. Si votre parc est du web sans état ou du microservice classique, le WAS natif ne vous apporte rien d’urgent — restez sur le scheduler standard et laissez la bêta mûrir. Dans les deux cas, notez que la promesse du natif est la standardisation, pas la performance brute : le critère de bascule doit être la simplification de votre pile, pas un gain de latence de planification que vous n’avez pas mesuré.