Kubernetes 1.37 : ce qui change pour les clusters

Publiée le 26 août 2026 sous le nom de code « Garhwal », Kubernetes 1.37 arrive progressivement chez les fournisseurs cloud et dans les distributions. Avec 67 améliorations, dont 16 passées en version stable, 23 en bêta et 27 en alpha, cette version renforce la sécurité des Pods, la planification des charges d'IA et prépare plusieurs abandons à surveiller dès maintenant.

Les nouveautés stables à retenir

La fonctionnalité la plus attendue concerne l'identité des workloads : les certificats de Pods et les ClusterTrustBundles passent en stable. Ils permettent de distribuer aux Pods des clés privées, des certificats X.509 et des ancres de confiance, sans passer par un outil tiers.

Autre graduation notable, KYAML : un sous-ensemble plus sûr de YAML, qui reste du YAML valide. Les manifestes existants n'ont donc pas à être modifiés. L'API metrics.k8s.io, utilisée par l'autoscaler horizontal (HPA) et kubectl top, passe quant à elle en v1.

Côté exploitation, l'API StorageVersionMigration devient stable et activée par défaut. Elle migre les ressources stockées, natives comme personnalisées, vers une nouvelle version de stockage après une mise à jour d'API. L'initialisation du cache de watch de l'API server est également rendue plus résiliente, pour éviter les pics de requêtes vers etcd.

L'allocation dynamique de ressources (DRA), pensée notamment pour les GPU, gagne plusieurs briques stables : requêtes de ressources étendues sans device plugin, taints et tolerations sur les périphériques, attribut NUMA standardisé.

En bêta : HPA à zéro et gang scheduling

Plusieurs fonctions bêta changent la donne pour les équipes plateforme. L'HPA peut désormais réduire une charge à zéro Pod lorsqu'elle est inactive (spec.minReplicas: 0), pour les HPA basés sur des métriques d'objet ou externes ; la fonction est activée par défaut. Le gang scheduling, qui planifie un groupe de Pods en tout ou rien via les API Workload et PodGroup, passe aussi en bêta, tout comme la préemption tenant compte de l'ensemble d'un groupe : des briques clés pour l'entraînement distribué de modèles.

La qualité de service mémoire fondée sur cgroups v2 est activée par défaut, et le contrôle d'admission peut désormais être chargé depuis des fichiers sur disque, actif dès le démarrage de l'API server.

Les abandons à planifier

C'est la partie à lire avant toute mise à jour :

• kube-dns est déprécié. CoreDNS est le DNS par défaut depuis la 1.13 ; le projet indique qu'aucun nouveau paquet kube-dns n'est attendu après la 1.40.
• Le mode ipvs de kube-proxy est déprécié. Il devrait être désactivé par défaut en 1.40 et supprimé en 1.43. Les clusters concernés affichent désormais un avertissement au démarrage.
• Les Pods statiques ne peuvent plus référencer de Secrets ou ConfigMaps, un comportement qui relevait d'un bug, et la feature gate permettant de contourner la restriction est supprimée.
• cgroup v1 reste en sursis. Depuis la 1.35, le kubelet refuse par défaut de démarrer sur un nœud en cgroup v1, sauf configuration explicite. Le projet invite à migrer vers cgroups v2, son support étant appelé à disparaître.

Comment préparer la montée de version

Avant de migrer, vérifiez le mode de kube-proxy, le DNS utilisé et la version de cgroups de vos nœuds. Les manifestes de Pods statiques méritent aussi une relecture. Pour ceux qui débutent avec l'écosystème, notre guide Conteneurs Docker : par où commencer pose les bases, et l'automatisation des renouvellements reste un chantier connexe, comme le montre le passage aux certificats TLS à 47 jours.