Kubernetes 1.37 : ce qui casse le 26 août et comment préparer votre montée de version

Kubernetes v1.37 doit sortir le mercredi 26 août 2026. Le Sneak Peek publié par la Release Team et le thread « Release Highlights » sur kubernetes/sig-release donnent déjà une image assez nette du cycle : environ 86 enhancements suivis, dont une petite trentaine en phase de graduation. Rien de spectaculaire côté fonctionnalités « vitrine », mais plusieurs durcissements de comportements historiques qui, eux, peuvent casser des clusters en production s’ils ne sont pas anticipés.

Cet article se concentre sur ce qui demande une action de votre part avant la montée de version. Comme toujours avant une GA, le contenu exact reste susceptible d’évoluer jusqu’à la publication des release notes définitives : traitez ce qui suit comme une feuille de route d’audit, pas comme un changelog gravé dans le marbre.

Calendrier : pourquoi commencer maintenant

Le rythme de Kubernetes est de trois versions mineures par an, avec une fenêtre de support d’environ quatorze mois par version (douze mois de correctifs, deux mois de maintenance). Concrètement, une équipe plateforme qui saute un cycle se retrouve mécaniquement en fin de support avant la fin de l’année suivante.

L’intérêt de travailler avant la GA est double. D’abord, les release candidates sont disponibles plusieurs semaines à l’avance et permettent de valider un cluster de staging sur du code quasi final. Ensuite, les ruptures listées ci-dessous se détectent avec des outils que vous avez déjà — grep, PromQL sur vos métriques apiserver, un kubectl récent — et se corrigent sur des versions antérieures. Autrement dit : la quasi-totalité du travail de remédiation peut être faite sur vos clusters 1.35 ou 1.36 actuels, sans attendre.

Les ruptures à auditer dès aujourd’hui

Static pods : fin des références aux Secrets et ConfigMaps

C’est le changement le plus susceptible de faire tomber un control plane. Les static pods — ceux que le kubelet lit directement depuis staticPodPath, typiquement /etc/kubernetes/manifests — n’ont jamais eu de support fiable pour les objets de l’API : le kubelet les démarre avant, et indépendamment de, toute connectivité avec le kube-apiserver. Une référence à un Secret ou un ConfigMap dans un static pod produisait au mieux un comportement non déterministe, au pire un pod bloqué au démarrage.

En 1.37, ces références deviennent un motif de rejet explicite par le kubelet plutôt qu’une source de bugs silencieux. L’impact concerne surtout les control planes auto-hébergés (kubeadm et dérivés) et les manifests maison qui auraient dérivé au fil des ans.

# Sur chaque nœud du control plane
grep -rnE 'secretKeyRef|configMapKeyRef|envFrom|^\s+secret:|^\s+configMap:' \
  /etc/kubernetes/manifests/

Les remplacements sont connus : hostPath pour les fichiers de configuration et les certificats, variables d’environnement littérales, ou fichiers déposés par votre outil de provisioning (Ansible, Ignition, cloud-init). Le point de vigilance est ailleurs : dans les couches d’automatisation qui génèrent ces manifests. Auditez vos rôles Ansible et vos templates avant les fichiers eux-mêmes.

kubectl run --filename déprécié

Le flag --filename (et son alias -f) de kubectl run est déprécié. Il fait doublon avec kubectl apply -f / kubectl create -f et n’a jamais eu de sémantique très claire. La dépréciation ne casse rien immédiatement — le flag émet un avertissement — mais elle signale une suppression future, et les avertissements sur stderr ont l’art de faire échouer les jobs CI configurés en mode strict.

# Dans vos dépôts d'infra, scripts et manifests CI
grep -rnE 'kubectl[[:space:]]+run[^|;&]*(-f|--filename)[[:space:]=]' . \
  --include='*.sh' --include='*.yml' --include='*.yaml' --include='Makefile'

La migration est triviale : kubectl create -f manifest.yaml ou kubectl apply -f manifest.yaml selon que vous voulez de la création stricte ou de l’idempotence.

Mode ipvs de kube-proxy : dépréciation multi-versions

Le mode ipvs de kube-proxy poursuit son cycle de dépréciation, engagé sur plusieurs versions. Il reste fonctionnel en 1.37, mais l’orientation du projet est claire : nftables devient le backend de référence pour les clusters modernes, iptables conserve son rôle de mode de compatibilité, et ipvs sort progressivement du périmètre maintenu.

kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep -iE '^\s*mode:'

Si vous êtes en ipvs, planifiez la bascule vers nftables — mais pas dans la même fenêtre que la montée de version. Un changement de backend de proxying modifie le chemin de données réseau de chaque nœud : c’est un chantier à part entière, avec ses propres tests de conformance et sa propre fenêtre de rollback. Vérifiez également que votre noyau et votre distribution supportent correctement nftables, et que vos éventuelles règles firewall maison ne présupposent pas des chaînes iptables spécifiques.

cgroup v1 : la trajectoire de sortie se confirme

Le support de cgroup v1 est en mode maintenance depuis plusieurs versions : plus de nouvelles fonctionnalités, corrections limitées aux régressions critiques. Les distributions Linux modernes sont en cgroup v2 par défaut depuis longtemps ; le risque se concentre sur les nœuds anciens ou les images de base figées.

# cgroup2fs = v2 ; tmpfs = v1 (hybride ou legacy)
stat -fc %T /sys/fs/cgroup/

Les fonctionnalités qui dépendent structurellement de cgroup v2 — MemoryQoS, le redimensionnement in-place des ressources de pod, la gestion fine de la pression mémoire — ne fonctionneront jamais sur v1. Traitez la migration comme un prérequis de renouvellement de flotte, pas comme une option.

Les nouveautés qui changent l’exploitation

Metrics API en GA. La metrics.k8s.io sort enfin de v1beta1. Pour la plupart des utilisateurs, c’est transparent : le HPA, le VPA et kubectl top consomment l’API via des clients qui gèrent la négociation de version. En revanche, tout tooling maison qui tape en dur sur /apis/metrics.k8s.io/v1beta1/..., ainsi que les manifests APIService déclarés manuellement, doivent être revus.

kubectl get --raw /apis/metrics.k8s.io | jq '.versions[].groupVersion'
kubectl get apiservices | grep metrics

DRA : device taints and tolerations. La Dynamic Resource Allocation gagne un mécanisme de taints et tolerations appliqué aux devices eux-mêmes, et non plus seulement aux nœuds. Concrètement, cela permet de marquer un GPU individuel comme dégradé ou en maintenance — par exemple depuis un agent de santé matérielle — et de faire évacuer ou éviter ce seul accélérateur, sans cordonner un nœud entier qui en héberge huit. Pour les plateformes d’entraînement et d’inférence, c’est un gain d’exploitation direct.

ulimits par conteneur. La possibilité de définir des ulimits au niveau du conteneur répond à un besoin ancien : jusqu’ici, ces limites étaient héritées de la configuration du runtime sur le nœud, donc uniformes pour toutes les charges. Les workloads sensibles au nombre de descripteurs de fichiers — proxies, brokers, bases de données — devaient passer par des DaemonSets privilégiés ou de la configuration de nœud. Cette fonctionnalité arrive derrière un feature gate : lisez sa maturité dans les release notes avant de l’inscrire dans une politique de plateforme.

Native Histograms Prometheus. L’exposition des métriques des composants Kubernetes au format native histograms de Prometheus arrive également derrière un feature gate. L’intérêt est réel : résolution bien supérieure sur les latences pour un coût de cardinalité nettement plus faible que les buckets classiques. Le prérequis est en revanche côté ingestion — Prometheus (ou votre backend compatible) doit être configuré pour les accepter, et vos règles d’alerting basées sur histogram_quantile doivent être revalidées.

Sécurité des nœuds : le kubelet en user namespace passe en bêta

L’exécution du kubelet lui-même dans un user namespace — le « mode rootless » — franchit une étape de maturité. L’idée est de faire tourner le kubelet et le runtime sans privilèges root sur l’hôte : une compromission du kubelet n’accorde alors que des capacités mappées dans le namespace, pas un accès root réel au nœud. C’est une réduction de surface d’attaque substantielle sur des clusters multi-tenants ou exposés.

À ne pas confondre avec les user namespaces pour les pods (le champ hostUsers: false), qui répondent à un problème voisin mais distinct : isoler les UID des conteneurs de ceux de l’hôte.

Malgré la bêta, ce n’est pas encore un choix de production généraliste. Les limitations sont structurelles : certaines opérations privilégiées deviennent impossibles ou nécessitent des contournements, l’accès aux périphériques (GPU, cartes réseau spécialisées) est contraint, les plugins CNI et CSI ne sont pas tous compatibles, et l’écosystème d’agents nœud — collecteurs de logs, outils de sécurité runtime eBPF — présuppose largement un kubelet root. Considérez-le comme une piste sérieuse pour des pools de nœuds dédiés à des charges non privilégiées, pas comme une bascule globale.

Méthode d’upgrade

1. Audit automatisé des API dépréciées. Vos apiservers exposent déjà l’information :

sum by (resource, version, removed_release) (
  increase(apiserver_requested_deprecated_apis[7d])
)

Complétez avec un scan statique de vos manifests et charts via pluto ou kubent. Attention : ces outils analysent ce qui est appliqué, pas ce qui dort dans un dépôt Git non déployé. Passez-les aussi sur vos sources.

2. Inventaire des feature gates. Une version mineure promeut, active par défaut ou retire des gates. Tout gate positionné explicitement dans votre configuration doit être revu :

kubectl get --raw /metrics | grep '^kubernetes_feature_enabled' | sort

Un gate promu en GA finit par être verrouillé puis supprimé : conserver --feature-gates=XYZ=true sur un composant après suppression du gate empêche son démarrage. C’est un mode de panne classique et parfaitement évitable.

3. Respecter le version skew. Le control plane monte en premier, une version mineure à la fois. Les kubelets peuvent être en retard de trois versions mineures sur le kube-apiserver, jamais en avance. kubectl est supporté à ±1 version mineure du control plane — vérifiez la version embarquée dans vos images de CI, c’est souvent l’oubli.

4. Rollout par environnement. Staging complet avec exécution de votre suite de tests d’intégration et un run de conformance ; puis un canari de production sur un pool de nœuds non critique ; puis la généralisation. Entre chaque étape, laissez le temps de voir remonter les problèmes lents — fuites mémoire, comportements dégradés sous charge de pointe, incompatibilités d’agents.

5. Distributions managées et k3s. EKS, GKE et AKS n’exposent pas une version mineure le jour de sa sortie amont : comptez plusieurs mois selon le fournisseur et le canal de release. Cela vous laisse du temps, mais ne vous dispense pas de l’audit : les ruptures ci-dessus s’appliqueront à l’identique le jour venu. Sur les distributions managées, l’accès aux nœuds étant restreint, les points bloquants seront plutôt les DaemonSets tiers et les webhooks d’admission. k3s et les distributions edge suivent généralement l’amont avec quelques semaines de décalage, avec un point d’attention particulier sur les backends de proxying et le support cgroup des images de base minimalistes.

Ce qu’il faut laisser en staging

La discipline de maturité reste la meilleure protection contre la dette technique :

• GA : utilisable en production, avec garantie de compatibilité. C’est le cas de la Metrics API en 1.37.
• Bêta : activé par défaut dans certains cas, mais l’API peut encore évoluer et la migration n’est pas toujours automatique. À réserver aux environnements où vous acceptez de refactorer sur un cycle. Le kubelet rootless entre dans cette catégorie.
• Alpha : désactivé par défaut, sans garantie de compatibilité ni de migration. Un cluster de test, jamais un cluster qui porte du trafic.

La règle pratique : pour toute fonctionnalité que vous inscrivez dans une API interne de plateforme — un CRD maison, un template Helm partagé, une abstraction exposée aux équipes produit — exigez la GA. Une abstraction construite sur une bêta engage vos utilisateurs sur un contrat que vous ne contrôlez pas.

Le vrai coût d’une montée de version Kubernetes n’est presque jamais dans la commande d’upgrade elle-même : il est dans l’inventaire de ce qui, dans votre plateforme, dépend d’un comportement jamais formellement supporté. Les static pods référençant des Secrets en sont l’illustration parfaite — ça fonctionnait par accident, ça cesse de fonctionner par décision. Les trois grep et la requête PromQL de cet article se lancent en une heure sur un cluster existant ; ce sont eux, et non les release notes, qui vous diront si le 26 août est une non-événement ou une astreinte.