L’essentiel
Kubernetes v1.37 « Garhwal » (26 août 2026) contient trois changements cassants qui imposent une revue immédiate de l’infrastructure : (1) les nœuds en cgroup v1 refusent de démarrer le kubelet – un blocage, pas un avertissement ; (2) kube-dns est retiré, avec une échéance de migration à la v1.40 ; (3) IPVS dans kube-proxy entre dans son cycle de dépréciation jusqu’à sa suppression en v1.43. Côté positif, l’API metrics.k8s.io, qui alimente le HorizontalPodAutoscaler et kubectl top, passe de bêta à stable (v1) après neuf ans en production. Les équipes sur Kubernetes managé avec des images de nœuds à jour sont peu concernées. Les clusters autogérés sur des images anciennes doivent traiter cette mise à niveau comme un projet de modernisation, pas comme une simple montée de version.
67 améliorations : ce qui est livré
Le cycle de la v1.37 a duré 15 semaines, du 18 mai au 26 août 2026, avec les contributions de 1 754 personnes issues de 212 entreprises. Bilan : 67 améliorations, dont 16 passées en stable, 23 en bêta, 27 entrées en alpha et une dépréciation ou suppression. Baptisée « Garhwal », du nom d’une région himalayenne de l’Uttarakhand, en Inde, la version arbore un logo de sommets enneigés et de rivière sinueuse, pour montrer que « chaque couche, chaque route et chaque contribution sont liées ».
Parmi les autres passages en stable, les plus utiles en exploitation sont la sortie KYAML de kubectl, la définition des ressources au niveau du pod et les taints et tolérances au niveau des périphériques pour la Dynamic Resource Allocation (DRA). Ce dernier point compte pour les équipes qui exploitent des charges GPU ou des accélérateurs : la DRA devient le mécanisme de base de l’ordonnancement de matériel hétérogène dans les pipelines d’IA et de ML. Pour les équipes qui exploitent des clusters Kubernetes en production, la décision de mise à niveau dépend toutefois des changements cassants plus que des nouveautés – et cette version en compte trois.
Fin de cgroup v1 : le blocage au démarrage
Depuis Kubernetes v1.35, les nœuds en cgroup v1 génèrent des avertissements au démarrage. En v1.37, le comportement se durcit : si le kubelet détecte cgroup v1, le nœud ne s’initialise pas. Aucune dégradation progressive : mettre à niveau un cluster concerné met immédiatement ces nœuds hors service.
Pour vérifier un nœud, exécutez stat -fc %T /sys/fs/cgroup/. La sortie tmpfs signifie cgroup v1 ; cgroup2fs signifie cgroup v2 et le nœud est sûr. CentOS 7, RHEL 7 (noyau EL7 3.10) et Ubuntu 18.04 utilisent cgroup v1 par défaut. La plupart des images de nœuds managées sur EKS, GKE et AKS sont passées à cgroup v2 entre 2022 et 2023 : les équipes sur des pools de nœuds à jour gérés par le fournisseur cloud sont en général épargnées.
Le champ failCgroupV1: false de la KubeletConfiguration permet de lever le blocage. Le projet Kubernetes le juge dangereux : le nœud perd la QoS mémoire, les métriques Pressure Stall Information (PSI) et certaines configurations de swap qui exigent cgroup v2, et le champ disparaîtra dans une version future. C’est une assurance de migration, pas une configuration durable.
La voie pragmatique : mettre à jour l’image des nœuds avant de toucher à la version de Kubernetes. En on-premise, passez à RHEL 8+, Rocky Linux, AlmaLinux 8+ ou Ubuntu 20.04+ ; dans le cloud, mettez à jour l’AMI ou l’image de VM des groupes de nœuds autogérés. L’effort d’ingénierie cloud et DevOps est réel mais bien circonscrit : cgroup v2 est stable depuis des années et la migration est bien documentée.
Calendrier de kube-dns et d’IPVS
kube-dns est retiré en v1.37. CoreDNS, solution par défaut depuis Kubernetes 1.13 (2018), le remplace entièrement. Les clusters encore sous kube-dns ont jusqu’à Kubernetes 1.40 pour migrer ; au-delà, le DNS du cluster cessera de fonctionner. La migration consiste à remplacer kube-dns par un Deployment CoreDNS et à convertir les ConfigMaps en syntaxe Corefile. La plupart des services Kubernetes managés l’ont automatisée depuis longtemps. Si vous voyez des pods kube-dns dans kube-system, planifiez la migration ce trimestre.
IPVS dans kube-proxy entre officiellement en dépréciation en v1.37, avec une suppression prévue en v1.43. Son successeur, nftables, offre de meilleures performances, des règles plus expressives et une maintenance active en amont. Si votre équipe réseau a bâti supervision, alertes ou outils maison autour des compteurs IPVS, planifiez le passage à nftables avant la v1.43, soit environ quatre cycles de version, ou 12 à 18 mois au rythme actuel.
L’API de métriques passe en stable
L’API metrics.k8s.io, qui fournit la consommation CPU et mémoire des pods et des nœuds, passe de bêta à stable (v1) en v1.37. Le release lead Dipesh Rawat relève lui-même l’ironie : malgré son étiquette bêta, l’API est largement utilisée en production depuis des années. C’est elle qui fait fonctionner kubectl top nodes, kubectl top pods, le HorizontalPodAutoscaler (HPA) et le VerticalPodAutoscaler (VPA).
Conséquence pratique : l’interface v1 relève désormais de la garantie de compatibilité de Kubernetes et ne changera pas de façon incompatible dans un avenir prévisible. La mise en garde des runbooks selon laquelle le HPA repose sur une API bêta peut être supprimée.
Ce que cela implique pour les équipes logicielles aux États-Unis et dans l’UE
La fin de cgroup v1 est le point le plus urgent de cette version. Contrairement à la plupart des changements cassants, qui touchent des versions d’API ou des schémas de manifestes, celui-ci vise l’infrastructure des nœuds. Il exige une coordination entre l’équipe plateforme et les responsables des images de nœuds – infrastructure cloud, exploitation on-premise ou équipe qui fournit les images de VM. Les responsables techniques devraient lancer la vérification stat sur tous les nœuds cette semaine et classer les résultats avant la prochaine fenêtre de mise à niveau.
Les clusters on-premise et hybrides sont les plus exposés. Les entreprises qui font tourner Kubernetes sur des distributions d’entreprise anciennes, notamment de l’ère RHEL 7, risquent une double migration : système d’exploitation et Kubernetes en même temps. Dans les secteurs régulés (FinTech, santé, assurance, secteur public), une montée de version majeure de l’OS exige généralement le feu vert de la sécurité, des scans de vulnérabilités propres et parfois un comité des changements. Intégrez ce délai dès maintenant.
Les échéances de kube-dns et d’IPVS sont plus souples, mais pas infinies. La v1.40 et la v1.43 laissent plusieurs cycles de marge, mais ces sujets doivent entrer dans le backlog dès ce cycle de planification. Le rythme des versions de Kubernetes s’accélère : l’écart entre marge confortable et échéance ferme se réduit plus vite qu’avant.
Qu’est-ce que cela change pour les entreprises en France ?
En France, l’impact se concentre sur les clusters on-premise et les clouds de confiance. Banques, assureurs, opérateurs publics et industriels hébergent souvent Kubernetes dans leurs propres datacenters ou chez des fournisseurs français comme OVHcloud ou Scaleway, notamment pour des raisons de souveraineté des données. Dans les environnements autogérés subsistent des nœuds sous CentOS 7 ou RHEL 7, dont le support éditeur standard a pris fin en juin 2024. Pour ces DSI, la 1.37 est d’abord un chantier système, pas une simple montée de version Kubernetes.
Le cadre réglementaire pousse dans le même sens. Les entités financières sont soumises à DORA depuis janvier 2025, sous la supervision de l’ACPR et de l’AMF, et la directive NIS2 étend les exigences de gestion des vulnérabilités et des correctifs à de nombreuses entités. Les hébergeurs visant la qualification SecNumCloud de l’ANSSI doivent eux aussi justifier de systèmes maintenus. Regrouper la migration vers cgroup v2 avec la modernisation de l’OS, et la documenter dans la gestion des changements, permet de traiter la mise à niveau et la preuve d’audit en une seule fois.
Vous préparez une mise à niveau Kubernetes ou une migration des nœuds vers cgroup v2 ?
Nos ingénieurs cadrent et réalisent des mises à niveau de clusters Kubernetes, des migrations de nœuds vers cgroup v2 et des transitions vers CoreDNS pour des équipes produit aux États-Unis et dans l’UE, y compris dans les secteurs régulés où une montée de version de l’OS exige une validation conformité. Nous identifions les changements cassants propres à votre configuration avant de toucher au moindre nœud.
Parler à un ingénieurCe que les responsables techniques doivent faire maintenant
| Action | Échéance | Remarques |
|---|---|---|
Exécuter stat -fc %T /sys/fs/cgroup/ sur tous les nœuds du cluster | Cette semaine | Sortie tmpfs = cgroup v1 : le kubelet ne démarrera pas après la mise à niveau. À auditer avant toute tentative de passage en v1.37. |
| Mettre à jour l’image des nœuds en cgroup v1 avant Kubernetes | Avant la prochaine fenêtre | Cible : RHEL 8+, Rocky Linux 8+, AlmaLinux 8+, Ubuntu 20.04+ ou image cloud à jour. cgroup v2 doit être actif dans l’OS avant la mise à niveau du kubelet. |
| Vérifier le DNS : CoreDNS et non kube-dns | Ce sprint | Exécuter kubectl get pods -n kube-system | grep dns. kube-dns doit être migré avant la v1.40, sinon le DNS du cluster tombe. |
| Contrôler le mode IPVS de kube-proxy | Ce sprint | Chercher mode: ipvs dans kubectl get configmap kube-proxy -n kube-system -o yaml. Si présent, planifier nftables avant la v1.43. |
| Documenter la migration OS dans la gestion des changements (DORA/NIS2) | Ce cycle de planification | Pour les entités régulées : conserver plan de mise à niveau, validations et scénario de retour arrière comme preuve d’audit. |
| Évaluer les fonctions alpha de la DRA pour les charges GPU ou accélérateurs | Ce cycle de planification | Les taints et tolérances au niveau des périphériques sont stables. Les ajouts alpha de la DRA peuvent réduire l’ordonnancement maison dans les pipelines d’IA/ML. |
| Mettre à jour les runbooks HPA (API de métriques stable) | Prochain cycle | Supprimer les réserves liées à la bêta. L’API metrics.k8s.io v1 relève de la garantie de compatibilité de Kubernetes. |
Sources: Kubernetes v1.37: Garhwal — Official release blog (kubernetes.io, August 26, 2026); Kubernetes cleans house, bins legacy kube-dns, IPVS, and cgroup v1 (The Register, August 26, 2026).
FAQ
Qu’est-ce que cgroup v1 et pourquoi Kubernetes 1.37 le supprime-t-il ?
cgroup v1 est le mécanisme Linux d’origine (control groups) qui permet à Kubernetes de regrouper et de limiter les ressources CPU, mémoire et E/S des conteneurs. Depuis la v1.35, Kubernetes émet des avertissements au démarrage des nœuds encore en cgroup v1. En v1.37, cela devient un blocage : si le kubelet détecte cgroup v1, le nœud ne s’initialise pas. cgroup v2, disponible depuis le noyau Linux 4.5 et activé par défaut dans la plupart des distributions récentes depuis 2021, offre une hiérarchie unifiée, une meilleure QoS mémoire, les métriques PSI et une gestion du swap plus efficace.
Comment vérifier si mes nœuds utilisent cgroup v1 ?
Exécutez stat -fc %T /sys/fs/cgroup/ sur chaque nœud. La sortie tmpfs signifie cgroup v1 ; cgroup2fs signifie cgroup v2 et la mise à niveau est sans risque. CentOS 7, RHEL 7 et Ubuntu 18.04 utilisent cgroup v1 par défaut. La plupart des images de nœuds managées sur EKS, GKE et AKS sont passées à cgroup v2 entre 2022 et 2023.
Qu’est-ce que le contournement failCgroupV1 et faut-il l’utiliser ?
La KubeletConfiguration comporte un champ failCgroupV1 qui, positionné à false, lève le blocage au démarrage. Le projet Kubernetes le qualifie explicitement de dangereux : le nœud perd la QoS mémoire, les métriques PSI et les configurations de swap qui exigent cgroup v2, et le champ sera supprimé dans une version future. À réserver à une assurance temporaire pendant la migration.
Que deviennent kube-dns et IPVS dans Kubernetes 1.37 ?
kube-dns est retiré en v1.37 au profit de CoreDNS, la solution par défaut depuis Kubernetes 1.13 (2018). Les clusters encore sous kube-dns doivent migrer avant Kubernetes 1.40, faute de quoi le DNS du cluster cessera de fonctionner. IPVS dans kube-proxy est déprécié en v1.37 et sera supprimé en v1.43, remplacé par nftables.
Que change le passage en stable de metrics.k8s.io pour le HPA ?
L’API metrics.k8s.io, qui alimente kubectl top, le HorizontalPodAutoscaler (HPA) et le VerticalPodAutoscaler (VPA), passe de bêta à stable (v1) dans Kubernetes 1.37 après neuf ans en production. Elle relève désormais de la garantie de compatibilité de Kubernetes et ne changera plus de manière incompatible.
Qu’est-ce que cela change pour les entreprises en France ?
En France, une part importante des clusters Kubernetes tourne on-premise ou chez des clouds de confiance, souvent sur des images Linux d’entreprise anciennes. Pour ces environnements, la 1.37 est d’abord un chantier système. Les entités financières soumises à DORA et celles concernées par NIS2 doivent de toute façon démontrer une gestion des correctifs et des systèmes maintenus : la migration vers cgroup v2 gagne à être intégrée au plan de gestion des changements et des risques.