Présentation de la version 1.37
La release de Kubernetes prévue le 26 août 2026 porte le numéro de version 1.37. Elle introduit plusieurs changements de comportement qui impactent directement la configuration du plan de contrôle et des nœuds. Parmi les nouveautés, l’API metrics.k8s.io passe du statut beta à stable après près de neuf ans, et le mode User Namespace (Rootless) du kubelet atteint la bêta, ouvrant la voie à des composants exécutés sans privilèges root sur le système hôte.
Dépréciations majeures
Le mode ipvs de kube-proxy est désormais marqué comme obsolète. Tout cluster qui conserve cette option génère un avertissement au démarrage, par exemple :
W0826 12:34:56.789012 1 kubeproxy.go:123] "ipvs mode is deprecated and will be removed in a future release"
Les administrateurs doivent migrer vers le mode iptables ou un équilibreur externe, ce qui implique la re‑validation des règles de NAT et la mise à jour des scripts d’automatisation. En parallèle, les pods statiques ne peuvent plus référencer des Secret ou ConfigMap via les champs d’API, corrigeant un bug qui permettait des montages indirects non contrôlés. Enfin, le drapeau --filename de kubectl run est retiré, simplifiant l’interface mais obligeant les utilisateurs à recourir à kubectl create -f ou à des manifestes explicites.
Évolutions de la sécurité et du monitoring
Le passage du metrics.k8s.io à la version stable garantit une API de métriques compatible avec les outils de monitoring natifs (Prometheus, Grafana) sans dépendre de versions beta. Cela réduit les risques de rupture de contrat d’API lors de futures mises à jour. Le support bêta du kubelet en mode User Namespace permet d’exécuter le processus kubelet dans un espace de noms utilisateur distinct, limitant les privilèges sur le nœud. Cette isolation nécessite toutefois que le runtime de conteneur supporte les namespaces non privilégiés et que les plugins CNI soient compatibles, sinon le plan de contrôle peut rencontrer des erreurs de montage de volume.
Conséquences pour les opérateurs
Les équipes DevOps devront auditer leurs clusters pour détecter l’usage d’ipvs et planifier une migration avant la suppression définitive, afin d’éviter une interruption de service. La suppression de la référence aux secrets dans les pods statiques impose de ré‑architecturer les modèles de déploiement qui s’appuyaient sur cette fonctionnalité, typiquement en passant par des InitContainers ou des ProjectedVolumes. Le retrait du drapeau --filename pousse à adopter des pipelines CI/CD basés sur des fichiers manifestes versionnés, renforçant la traçabilité. Enfin, la combinaison du kubelet rootless et du retrait progressif du support cgroup v1 signifie que les clusters anciens, encore sur cgroup v1, devront être mis à jour ou migrés vers cgroup v2 pour conserver la compatibilité avec les futures versions de Kubernetes.
