Le projet Kubernetes publie la version 1.37, composée de 67 évolutions : 16 deviennent stables, 23 passent en bêta, 27 arrivent en alpha et une concerne une dépréciation ou un retrait. Ce volume justifie une lecture ciblée plutôt qu'une activation générale des nouveautés.

La réponse rapide

NiveauNombreDécision conseillée
Stable16Vérifier l'impact et adopter selon le besoin.
Bêta23Tester sur un environnement représentatif.
Alpha27Réserver aux laboratoires et aux essais réversibles.
Dépréciation ou retrait1Rechercher immédiatement les dépendances concernées.

Une version Kubernetes ne se résume pas au serveur d'API. Les nœuds, pilotes CSI et CNI, contrôleurs d'ingress, opérateurs et outils de sauvegarde doivent être compatibles.

Commencer par l'inventaire réel

Exportez les versions du control plane, des kubelets et des extensions. Recherchez les API dépréciées dans les manifestes Git, mais aussi dans les ressources créées dynamiquement par les opérateurs. Un dépôt propre ne garantit pas qu'un ancien objet n'existe plus dans le cluster.

Contrôlez ensuite les matrices de support du fournisseur managé. EKS, AKS et GKE ne proposent pas toujours la version immédiatement et peuvent appliquer leurs propres restrictions.

Les fonctions alpha ne sont pas des raccourcis

Une fonction alpha peut changer de schéma, être désactivée par défaut ou disparaître. L'activer sur le control plane peut compliquer la restauration et la prochaine mise à niveau. Elle convient à un cluster de test isolé avec des critères de sortie, pas à un besoin urgent de production.

Pour les fonctions bêta, documentez les feature gates et vérifiez leur valeur par défaut. Le passage d'une étape à l'autre peut modifier le comportement sans changement apparent dans vos manifestes.

Une montée de version progressive

Testez d'abord les admissions, politiques réseau, volumes persistants, autoscaling et interruptions planifiées. Mettez à niveau un environnement hors production, puis un petit pool de nœuds. Observez les erreurs API, redémarrages, latences DNS et temps d'attachement des volumes.

Conservez un plan de retour réaliste. Un snapshot etcd aide pour un cluster autogéré, mais ne restaure pas automatiquement les bases et volumes des applications.

Ne pas attendre la fin de support

Reporter plusieurs versions augmente le nombre d'API et de composants à migrer simultanément. Un rythme régulier, avec une fenêtre et des tests reproductibles, réduit davantage le risque qu'une grande opération annuelle.

Kubernetes 1.37 apporte beaucoup, mais la priorité reste la compatibilité de l'écosystème. Les équipes efficaces traiteront d'abord les retraits, valideront les extensions critiques et n'activeront les fonctions expérimentales qu'avec une hypothèse mesurable.