Kubernetes 1.37 déprécie IPVS, active SELinuxMount et retire les secrets des pods statiques

26 août 2026. Kubernetes 1.37 atteint la disponibilité générale. Neuf ans. C’est le temps que l’API de métriques metrics.k8s.io a passé en bêta avant d’être promue stable dans cette version. Trois. C’est le nombre de changements cassants qu’un opérateur de cluster doit auditer avant de lancer la mise à niveau, et aucun ne touche l’API applicative : tous se jouent au niveau des nœuds.

Le cycle a livré environ 86 améliorations suivies, dont 16 promotions en stable et 22 fonctionnalités alpha inédites, selon la couverture pré-livraison de Cloudsmith et des trackers indépendants. Le point release paraît ennuyeux sur le papier ; il ne l’est pas, parce que la CNCF chiffre désormais l’adoption de Kubernetes en production à 82 % des organisations qui utilisent des conteneurs, contre 66 % deux ans plus tôt. Quand quatre ateliers de conteneurs sur cinq tournent sur le logiciel, une dépréciation réseau n’est pas une note de bas de page : c’est une fenêtre de maintenance pour des milliers d’équipes plateforme.

Ce qui passe en stable

La promotion la plus symbolique est celle de metrics.k8s.io, l’API de métriques sur laquelle reposent kubectl top et le Horizontal Pod Autoscaler. Elle sort de bêta après presque une décennie, un record de longévité qui dit la prudence du projet à verrouiller une API dont des millions de clusters dépendent de fait.

SELinuxMount passe lui aussi en GA, et surtout, il est activé par défaut. Au lieu de réétiqueter un volume fichier par fichier à chaque montage, le kubelet monte désormais avec une option context=<label> et applique l’étiquette SELinux en une seule opération. Le gain est réel sur les gros volumes, mais le comportement change au runtime sur tout cluster où SELinux est en mode enforcing. Plusieurs analyses pré-livraison signalent explicitement que la fonctionnalité « peut casser des charges existantes ».

Le reste des graduations est moins spectaculaire mais cohérent : la sortie KYAML de kubectl devient un format stable, les requêtes de ressources au niveau du pod (et non plus seulement par conteneur) passent stable, et les taints/tolérations par périphérique de la Dynamic Resource Allocation font de la planification GPU un citoyen de première classe plutôt qu’un greffon.

Trois changements cassants à traiter

Premier : kubectl run perd son drapeau --filename. La commande est conçue pour générer un pod depuis des arguments de ligne de commande, pas depuis un manifeste, et le projet impose enfin cette séparation. Tout script qui passait kubectl run -f doit basculer sur kubectl apply ou kubectl create.

Deuxième : les pods statiques ne peuvent plus référencer de secrets ni de config maps. La porte PreventStaticPodAPIReferences, qui permettait de désactiver la restriction, est supprimée purement et simplement : le comportement devient inconditionnel. Tout manifeste de pod statique qui tirait ses identifiants d’un secretRef ou d’un configMapRef ne démarrera plus après la mise à niveau, point final.

Troisième, et le plus long à traîner : le mode IPVS de kube-proxy est officiellement déprécié sous KEP-5495, et nftables devient le backend par défaut des nouvelles installations. IPVS était un mode recommandé depuis son introduction en alternative à iptables dans Kubernetes 1.11, en raison de son coût CPU plus bas à grande échelle. La suppression n’est pas prévue avant v1.43, plusieurs releases plus loin, mais le compteur tourne : un cluster standardisé sur IPVS doit préparer sa migration vers nftables.

Le durcissement silencieux du runtime

Sous ces trois changements visibles, deux contraintes durcissent les nœuds sans faire de bruit. cgroup v2 devient effectivement obligatoire : depuis 1.37, le kubelet refuse de s’initialiser sur un nœud cgroup v1 par défaut, sauf dérogation explicite. Et la sortie de containerd 1.x du support signifie que 1.37 exige containerd 2.0 ou plus récent, la version 1.35 ayant été la dernière à tolérer la branche 1.x.

Le kubelet rootless progresse lui aussi en bêta : l’agent de nœud tourne sans privilèges root, ce qui réduit la surface d’attaque d’un composant qui touche à tout sur la machine. Combiné au basculement par défaut de SELinuxMount, une part notable du risque de cette mise à niveau se situe dans le comportement runtime des nœuds, pas dans la surface d’API que les équipes ont l’habitude d’auditer.

Pourquoi ce point release compte

Le calendrier de 1.37 suit le rythme tri-annuel que le projet a adopté pour rendre chaque cycle moins pressé : première alpha le 10 juin 2026, gel des améliorations le 17 juin, gel du code les 22 et 23 juillet, gel de la documentation les 5 et 6 août, rc.0 le 6 août, rc.1 le 19 août. Aucun glissement : le projet fonctionne comme il a été repensé.

La coïncidence avec le boom de l’infrastructure IA n’est pas fortuite. L’enquête annuelle de la CNCF publiée en janvier 2026 encadre Kubernetes comme le système d’exploitation de fait des charges d’IA : deux tiers des organisations qui font tourner des modèles génératifs déclarent l’utiliser pour l’inférence. Un pod d’inférence réunit souvent un serveur de modèle et des side-cars de batching ou de télémétrie : pouvoir fixer les limites de ressources au niveau du pod, au lieu d’additionner des estimations par conteneur, rend la planification de capacité sur les nœuds GPU nettement moins sujette à l’erreur.

Le précédent le plus parlant reste dockershim, le shim qui laissait le kubelet parler directement à Docker Engine : supprimé dans Kubernetes 1.24 en 2022 après plus d’un an de préavis, il a pourtant surpris des équipes dont les pipelines CI supposaient Docker toujours présent sous le capot. PodSecurityPolicy a suivi la même pente, déprécié plusieurs releases avant d’être retiré dans 1.25 au profit de Pod Security Admission. La dépréciation d’IPVS emprunte exactement ce chemin : avis formel, piste de plusieurs releases jusqu’à v1.43, et migration documentée vers nftables. Les suppressions plus abruptes, celles des secrets des pods statiques et du basculement SELinuxMount, ressemblent davantage au retrait de PodSecurityPolicy : elles imposent de corriger les manifests sans délai.

La checklist avant mise à niveau

# 1. Auditer les manifests de pods statiques pour les références secret/configMap
grep -R "secretRef\|configMapRef" /etc/kubernetes/manifests/ 2>/dev/null

# 2. Vérifier que tous les nœuds sont bien en cgroup v2
stat -fc %T /sys/fs/cgroup/        # doit afficher cgroup2fs

# 3. Identifier le mode de kube-proxy avant de planifier la migration IPVS -> nftables
kubectl get configmap kube-proxy -n kube-system -o yaml | grep -i mode

# 4. Si SELinux est en enforcing, tester SELinuxMount sur un nœud de staging d'abord
getenforce                          # Enforcing ou Permissive ?

Ces quatre commandes couvrent l’essentiel du risque. Le piège classique de cette release n’est pas dans les manifests applicatifs, il est dans le nœud lui-même.

Verdict

Si votre cluster tourne sur IPVS à grande échelle pour des raisons de coût CPU, vous avez du temps : la suppression n’est pas prévue avant v1.43. Mais ouvrez dès maintenant le chantier de migration vers nftables et testez-le sur un cluster de staging, plutôt que d’attendre qu’une dépréciation devienne une urgence.

Si vos nœuds sont en RHEL, Fedora CoreOS ou toute distribution en SELinux enforcing, le basculement par défaut de SELinuxMount est le premier risque à mesurer : testez-le sur un nœud isolé avant de le subir en production. Et si vous exploitez des pods statiques pour le plan de contrôle, relisez chaque manifeste à la recherche de secretRef ou configMapRef : cette release ne tolère plus le motif, sans exception.

La règle simple reste : auditez le nœud avant d’auditer l’API. Les trois changements cassants de Kubernetes 1.37 se corrigent tous en amont, à condition de les chercher au bon endroit.

Références

• Kubernetes Blog — v1.37 Sneak Peek, 31 juillet 2026
• Kubernetes Contributors — v1.37 Release Information
• shattered.io — Kubernetes 1.37 Release: 3 Breaking Changes to Fix, 25 août 2026
• CNCF Annual Cloud Native Survey, janvier 2026