Kubernetes 1.37 : les nouveautés à connaître avant ta prochaine mise à jour

Kubernetes 1.37, nom de code « Garhwal », est sorti le 26 août 2026. Si tu gères des clusters en production, cette version mérite ton attention : elle fait passer en stable plusieurs fonctionnalités de sécurité qui traînaient en beta depuis des mois, et elle acte le début de la fin pour un composant que tu utilises peut-être encore sans le savoir. Dans cet article, tu retrouves les changements qui comptent vraiment pour l’exploitation quotidienne, sans passer par les 67 items de la release note officielle.

Ce qui passe en stable (GA) et que tu peux activer sans crainte

Une version stable, c’est une fonctionnalité que tu peux mettre en production sans attendre le prochain cycle. Sur les 67 améliorations de Kubernetes 1.37, 16 franchissent ce cap. Voici celles qui changent concrètement ta façon de gérer un cluster.

Montage de volumes SELinux accéléré

Si tes nœuds tournent avec SELinux en mode enforcing (RHEL, Fedora CoreOS…), tu as sûrement déjà vu un pod mettre de longues secondes, voire des minutes, à démarrer sur un volume contenant beaucoup de fichiers : c’est le relabeling SELinux fichier par fichier qui bloque. Kubernetes 1.37 généralise l’option de montage native -o context, qui applique le label au niveau du point de montage plutôt qu’à chaque fichier. Le gain de démarrage est immédiat, et ça ferme au passage certaines techniques d’exploitation basées sur les chemins hôte.

Certificats de pods (Pod Certificates) en GA

C’est la fonctionnalité qui va t’intéresser si tu cherches à sortir du tout-bearer-token pour l’authentification inter-services. Avec la source de volume projeté PodCertificate, chaque pod peut désormais recevoir automatiquement un certificat X.509 signé, avec rotation gérée par Kubernetes. Ça t’évite de déployer et maintenir cert-manager ou un sidecar dédié juste pour du mTLS basique entre services internes. À utiliser en complément d’un service mesh si tu en as un, ou en solution autonome si ton besoin est simple.

Ressources au niveau du pod

Pour les workloads composés de plusieurs conteneurs étroitement couplés (un conteneur principal + un sidecar de log shipping, par exemple), tu peux désormais définir un pool de ressources CPU/mémoire partagé au niveau du pod plutôt que de fixer des limites rigides conteneur par conteneur. Résultat : moins de sur-provisionnement « au cas où » sur chaque conteneur pris isolément.

DRA : les tolérances de dispositifs passent en GA

La Dynamic Resource Allocation (DRA), qui gère l’attribution de matériel spécialisé (GPU, TPU, cartes réseau dédiées), avait déjà atteint la GA en 1.34. En 1.37, les device taints/tolerations deviennent stables : un device défaillant ou en maintenance peut désormais être « tainté » exactement comme un nœud, et tes workloads peuvent choisir de tolérer ce taint ou non. Si tu opères des pools de GPU pour de l’inférence IA, c’est le genre de détail qui t’évite un incident silencieux le jour où une carte commence à dériver.

Ce qui arrive en beta : à tester avant la prochaine LTS

Les fonctionnalités en beta sont activées par défaut dans la plupart des cas, mais restent à valider en environnement de test avant une généralisation.

• ClusterTrustBundles : une API cluster-scoped pour distribuer des ancres de confiance X.509 à tes workloads, avec mise à jour automatique lors des rotations de certificats — le complément naturel des Pod Certificates ci-dessus.
• Préemption pour le redimensionnement de pods à chaud : le scheduler peut désormais préempter des pods de priorité plus basse pour libérer de la place quand une demande de resize « in-place » ne trouve pas de ressources disponibles sur un nœud saturé.
• Scoring de capacité de stockage : les nœuds peuvent être priorisés lors du provisionnement de volumes persistants selon leur capacité disponible, pour étaler la charge ou au contraire consolider selon ta stratégie.
• Autoscaling horizontal jusqu’à zéro réplique pour le HorizontalPodAutoscaler, utile pour des workloads événementiels qui n’ont pas besoin de tourner en continu.

La dépréciation à anticiper : la fin programmée d’IPVS

C’est le point qui mérite une ligne dans ton backlog d’infra dès maintenant. Le backend kube-proxy IPVS est officiellement déprécié à partir de la 1.37, avec une suppression prévue en 1.43. En parallèle, le nouveau backend NFTables (alpha en 1.37, avec un support de l’accès NodePort en localhost via proxy userspace) est sur une trajectoire pour devenir le backend par défaut dès la version 1.40, en remplacement progressif d’iptables.

Concrètement, si ton cluster tourne encore avec IPVS, tu as jusqu’à la 1.43 pour basculer, mais autant commencer à planifier la migration vers iptables (le mode le plus courant aujourd’hui) ou NFTables plutôt que d’attendre le dernier moment. Vérifie la configuration de ton kube-proxy avec kubectl get configmap kube-proxy -n kube-system -o yaml si tu as un doute sur le backend actuellement utilisé.

Comment préparer ta mise à jour vers Kubernetes 1.37

Avant de lancer la migration sur un cluster de production, quelques réflexes qui t’évitent les mauvaises surprises :

• Consulte la note de version officielle pour la liste complète des 67 changements, y compris ceux spécifiques à ta distribution (EKS, AKS, GKE ont chacune leur propre calendrier de disponibilité).
• Teste d’abord sur un cluster de non-production, en particulier si tu utilises SELinux en mode enforcing ou si tu as des CRD volumineuses (le décodage concurrent des watchs, en beta, cible justement ce cas).
• Si tu es sur IPVS, planifie ta bascule de backend kube-proxy indépendamment de la montée de version elle-même, pour isoler les deux changements.
• Documente-toi sur les guides de dépréciation officiels pour vérifier qu’aucune API que tu utilises n’arrive en fin de vie dans cette version.

Si tu veux revoir les fondamentaux du hardening d’un cluster avant de monter en version, notre guide complet pour sécuriser un cluster Kubernetes reste une bonne base, indépendamment de la version installée.

FAQ

Faut-il migrer vers Kubernetes 1.37 tout de suite ?

Pas dans l’urgence. Comme pour toute montée de version majeure, teste d’abord en environnement de non-production. Les fonctionnalités GA de cette version (SELinux, Pod Certificates, DRA taints) sont solides, mais rien n’oblige à migrer avant ta fenêtre de maintenance habituelle — sauf si tu es concerné par la dépréciation d’IPVS.

IPVS va-t-il disparaître immédiatement ?

Non. La dépréciation en 1.37 signifie que le composant est marqué pour suppression, prévue en 1.43 — tu as donc plusieurs cycles de release devant toi (généralement plusieurs mois par version) pour planifier la migration.

Les Pod Certificates remplacent-ils un service mesh ?

Pas forcément. Ils couvrent le besoin de base (certificat X.509 par pod, rotation automatique) mais un service mesh comme Istio ou Linkerd ajoute des couches supplémentaires (observabilité, retry, politiques de trafic). Pour un besoin de mTLS simple entre quelques services, les Pod Certificates peuvent suffire seuls.

En résumé

Kubernetes 1.37 consolide surtout des fondations de sécurité posées lors des versions précédentes : SELinux et certificats de pods passent enfin en stable, la DRA continue sa maturation pour les workloads GPU, et le compte à rebours démarre officiellement pour IPVS. Rien qui impose une migration en urgence, mais de quoi mettre à jour ta feuille de route infra pour les prochains mois. Si un point de cet article te concerne directement — bascule IPVS, adoption des Pod Certificates —, c’est le bon moment pour ouvrir le ticket avant que ça devienne urgent.