Kubernetes 1.37 « Garhwal » : l’ordonnancement GPU des workloads IA repensé

YuSMP Group Editorial Team Rédaction, YuSMP Group

L’essentiel

Ce qu’apporte Kubernetes 1.37

Kubernetes publie une version environ tous les quatre mois ; la 1.37 « Garhwal » (du nom de la région himalayenne de l’Uttarakhand) est arrivée le 26 août 2026. Les 67 améliorations se répartissent en 16 stables, 23 bêta et 27 alpha, plus une annonce de dépréciation. Le projet suit de près la maturité de chaque fonctionnalité : « stable » signifie que l’API est figée et sûre en production, « bêta » qu’elle peut encore évoluer à la marge mais qu’elle est prête pour des tests à grande échelle.

Le fil conducteur de la version est l’efficacité des workloads GPU et accélérateurs. Les deux fonctionnalités phares — taints de périphériques DRA et gang scheduling — répondent à des pannes que les équipes rencontrent sans cesse en entraînement ou en inférence de grands modèles de langage : un nœud GPU défaillant qui bloque silencieusement un job, et un placement partiel des Pods qui consomme le budget accélérateurs. La communauté de l’ingénierie Kubernetes traite ces problèmes comme prioritaires depuis la vague du calcul IA ; la 1.37 est la version où les réponses du control plane sortent de l’alpha.

Taints de périphériques DRA : contourner les GPU défaillants à grande échelle

Dynamic Resource Allocation (DRA) est le cadre de Kubernetes pour gérer les accélérateurs et le matériel spécialisé. En 1.37, DRA obtient les taints de périphériques en stable : le même mécanisme taint/toleration que les exploitants utilisent déjà pour les contraintes d’ordonnancement au niveau des nœuds, appliqué directement à chaque GPU ou accélérateur.

Concrètement, un device plugin (ou le driver DRA) peut marquer un GPU précis en NoSchedule ou NoExecute dès qu’il détecte des erreurs matérielles, des défaillances de mémoire ECC ou un bridage thermique. L’ordonnanceur refuse alors de placer de nouveaux Pods demandant ce périphérique sur le nœud concerné, et les Pods existants sans toleration correspondante peuvent être évincés. Le GPU défaillant est contourné automatiquement : personne n’a besoin de vider le nœud ni de le cordonner à la main.

Pourquoi est-ce important à grande échelle ? Dans les grands clusters d’entraînement — de 64 à 256 nœuds H100 ou B200 — un seul GPU dégradé peut bloquer un job multi-nœuds entier ou produire silencieusement des résultats faux. Avant les taints DRA, il fallait surveiller la santé des GPU hors du cluster, intervenir manuellement et relancer les jobs. Avec les taints DRA en stable, le control plane s’en charge : le périphérique fautif est signalé, le travail est redirigé et le job continue sur du matériel sain. À 2 à 3 dollars l’heure de GPU, cette automatisation se traduit directement en budget de calcul récupéré.

Gang scheduling : un placement des Pods en tout ou rien

Le gang scheduling — ou préemption consciente du workload — règle le problème du placement partiel : un job d’entraînement distribué demande N Pods workers GPU, mais seuls N-2 peuvent être placés parce que deux nœuds sont occupés. Sans gang scheduling, ces N-2 workers démarrent, réservent leur mémoire GPU et attendent, inactifs, les retardataires. Avec le gang scheduling, l’ordonnanceur place les N Pods en même temps ou aucun, et met le job en file d’attente jusqu’à ce que la capacité soit disponible.

En Kubernetes 1.37, le gang scheduling via la préemption consciente du workload passe en bêta sur scheduling.k8s.io/v1beta1. L’API PodGroup permet de déclarer un ensemble de Pods comme une unité logique ; l’ordonnanceur traite leur placement de façon atomique. Si un job plus prioritaire a besoin des ressources du cluster, le PodGroup en attente est préempté d’un bloc, au lieu de voir ses Pods dispersés dans la file d’éviction.

Le bénéfice opérationnel est net : les jobs d’entraînement ne laissent plus de GPU inactifs en attendant des retardataires, et l’utilisation globale des accélérateurs progresse, puisque des jobs à moitié placés ne monopolisent plus de ressources. Jusqu’ici, il fallait pour cela déployer des ordonnanceurs externes comme Volcano ou YuniKorn. En 1.37, c’est disponible dans le cœur : aucun composant de control plane supplémentaire à versionner, surveiller ou mettre à jour avec le cluster.

Des dépréciations avec des échéances fermes

Kubernetes 1.37 comporte deux dépréciations assorties d’un calendrier de retrait ferme — pas un « pourra être retiré un jour », mais des versions cibles précises.

kube-dns déprécié ; retrait en Kubernetes 1.40. CoreDNS est l’implémentation DNS par défaut depuis Kubernetes 1.13 (2019). kube-dns avait survécu comme option pour les clusters antérieurs à cette bascule. Avec la 1.37, le projet le déprécie officiellement et fixe son retrait à la 1.40. Pour les équipes sur des services managés — EKS, GKE, AKS — ce n’est probablement pas un sujet : ces services utilisent CoreDNS par défaut depuis des années. Les clusters auto-hébergés installés à l’époque de la 1.12 avec kube-dns doivent auditer leur déploiement DNS avant de dépasser la 1.39.

Backend IPVS de kube-proxy déprécié ; retrait en Kubernetes 1.43. IPVS s’était imposé comme alternative performante à iptables pour kube-proxy sur les grands clusters. Le backend nftables, stable depuis Kubernetes 1.33, est désormais le successeur recommandé. nftables exige Linux 5.13 ou plus récent : vérifiez la version du noyau avant de migrer. L’échéance 1.43 laisse plusieurs cycles de version, mais la migration impose un redémarrage de kube-proxy sur chaque nœud — planifiez-la plutôt que de la subir.

Ce que cela change pour les équipes logicielles aux États-Unis et en Europe

Pour les équipes qui développent des produits IA/ML sur une infrastructure cloud, les améliorations GPU de la 1.37 tombent à point nommé. Les dépenses en infrastructure d’inférence et d’entraînement sur Kubernetes ont fortement augmenté en 2026, et le goulot d’étranglement s’est déplacé de la qualité des modèles vers l’efficacité opérationnelle : comment garder des GPU coûteux occupés, gérer les pannes matérielles sans intervention manuelle et réduire l’inactivité dans les files d’entraînement.

Taints de périphériques DRA et gang scheduling suppriment ensemble deux des causes les plus fréquentes de gaspillage GPU. L’un automatise la réponse aux pannes (périphérique signalé, workload redirigé), l’autre élimine la fragmentation qui laisse des jobs à moitié placés tourner à vide. Les équipes qui font de l’entraînement distribué en production profiteront des deux sans écrire de nouveau code d’infrastructure : mettre à jour le cluster, configurer le driver DRA pour émettre les taints et définir des PodGroups pour les entraînements batch.

Les dépréciations relèvent davantage de l’hygiène opérationnelle que de l’urgence. Un cluster encore sous kube-dns dispose de deux cycles avant la 1.40 ; la bonne réponse consiste à inscrire la migration au prochain sprint d’infrastructure. La migration nftables des utilisateurs d’IPVS est encore plus lointaine (1.43), mais l’exigence de noyau (Linux 5.13+) impose à certaines VM ou hôtes bare metal anciens une mise à niveau de l’OS au préalable — lancez cette vérification dès maintenant.

Qu’est-ce que cela change pour le marché français ?

En France, une bonne partie des capacités GPU se loue chez des clouds européens comme OVHcloud ou Scaleway, qui proposent des instances H100, ou s’exploite sur l’infrastructure propre des entreprises pour des raisons de souveraineté. Beaucoup d’équipes data et de laboratoires viennent par ailleurs du monde HPC, habitué aux ordonnanceurs de type Slurm qui allouent tous les nœuds d’un job d’un coup : le gang scheduling natif rapproche Kubernetes de ce modèle et rend la migration de ces workloads plus naturelle. Pour les offres managées, demandez explicitement quand la 1.37 sera disponible et avec quels drivers GPU.

Côté banques, assurances et secteur public, le cadre de changement est strict : le règlement européen DORA, applicable depuis janvier 2025, exige une gestion documentée des changements TIC, et les environnements qualifiés SecNumCloud par l’ANSSI imposent leurs propres procédures. Une montée de version qui touche le DNS et le backend réseau doit y passer comme un changement planifié, avec preuve de test en préproduction, plan de retour arrière et validation. La 1.37 laisse assez de marge pour traiter proprement les migrations kube-dns et IPVS dans ce processus.

Trois actions avant la 1.38

1. Auditer votre pile DNS. Lancez kubectl get pods -n kube-system -l k8s-app=kube-dns. Si des Pods kube-dns apparaissent, planifiez la migration vers CoreDNS avant de dépasser la 1.39. Le guide de migration de la documentation Kubernetes est simple pour la plupart des clusters ; le risque se situe dans les clusters avec des stub zones personnalisées à reporter.
2. Activer les taints de périphériques DRA dans vos pools de nœuds GPU. Vérifiez que la version de votre device plugin NVIDIA, AMD ou Google sait émettre des taints DRA. NVIDIA GPU Operator 24.x et suivants prennent en charge l’API DRA stable. Mettez le device plugin à jour avant de passer en 1.37 pour que les taints soient émis dès le premier jour.
3. Tester le gang scheduling sur vos plus gros entraînements. Déployez un cluster de préproduction en 1.37 et annotez vos jobs multi-workers avec scheduling.k8s.io/pod-group. Mesurez l’utilisation des GPU avant et après activation : la baisse d’inactivité est généralement mesurable dès le premier cycle complet.

Questions fréquentes

Sources

Kubernetes Project — Kubernetes v1.37 Release, 26 August 2026 (primary source)
The Register — Kubernetes cleans house, bins legacy kube-dns, IPVS and cgroup v1, 26 August 2026
Cloud Native Now — Kubernetes v1.37 Enhances Dynamic Resource Allocation, 2026