Kubernetes 1.34 en fin de vie le 27 octobre

Kubernetes 1.34 atteindra sa fin de vie le 27 octobre 2026, selon le calendrier officiel du projet. Passé cette date, la branche ne recevra plus de correctifs de la communauté, y compris pour les failles de sécurité. Les clusters gérés chez les fournisseurs cloud disposent d'un sursis plus ou moins long, mais la mise à jour doit désormais entrer dans les plans des équipes d'exploitation.

Le calendrier upstream

Publiée en août 2025, la version 1.34 est entrée en mode maintenance le 27 août 2026. Dans cette phase, seules les corrections jugées critiques sont encore intégrées. La fin de vie, deux mois plus tard, marque l'arrêt complet des publications de correctifs pour cette branche.

Trois versions resteront alors maintenues par le projet :

• 1.35, jusqu'au 28 février 2027 ;
• 1.36, jusqu'au 28 juin 2027 ;
• 1.37, la plus récente, jusqu'au 28 octobre 2027.

Pour un cluster encore en 1.34, viser la 1.36 ou la 1.37 laisse davantage de marge avant le prochain chantier. Nous avions détaillé les nouveautés de cette dernière dans notre article sur Kubernetes 1.37.

Sur EKS : support standard jusqu'au 2 décembre

Amazon EKS applique son propre cycle : 14 mois de support standard à partir de la disponibilité sur sa plateforme, puis 12 mois de support étendu. Arrivée sur EKS le 2 octobre 2025, la version 1.34 y reste en support standard jusqu'au 2 décembre 2026, puis en support étendu jusqu'au 2 décembre 2027.

Ce support étendu est activé par défaut, mais il est facturé en supplément à l'heure de cluster. Les équipes qui le désactivent verront leur plan de contrôle mis à jour automatiquement à la fin du support standard. Et au terme du support étendu, AWS met à jour d'office le plan de contrôle, sans préavis précis. Les groupes de nœuds managés et les nœuds autogérés, eux, ne suivent pas automatiquement.

Sur AKS : fin de vie en novembre

Chez Microsoft, la fin de vie de la version 1.34 sur AKS est fixée à novembre 2026. Le cluster bascule ensuite dans un régime de « support plateforme » réduit, valable jusqu'à la disponibilité générale de la 1.38 : Microsoft n'y traite plus que les problèmes liés à la plateforme Azure, pas ceux de Kubernetes lui-même. Les clients du support à long terme (LTS) peuvent prolonger jusqu'en novembre 2027.

Microsoft annonce aussi qu'à partir du 1er juin 2027, AKS mettra automatiquement à jour les clusters restés sur une version non prise en charge. Ces mises à jour imposées ne respectent ni les fenêtres de maintenance ni les blocages liés aux API dépréciées.

Préparer la migration

Une mise à jour de Kubernetes se fait une version mineure à la fois : passer de la 1.34 à la 1.36 suppose de transiter par la 1.35. Quelques étapes permettent de limiter les surprises :

• inventorier les clusters et leurs versions, plan de contrôle comme nœuds ;
• repérer les API dépréciées ou supprimées dans les versions cibles, à l'aide des notes de version ;
• vérifier la compatibilité des modules complémentaires (CNI, contrôleurs d'entrée, opérateurs) ;
• tester la montée de version sur un environnement de préproduction avant la production.

La politique d'écart de versions tolère des nœuds jusqu'à trois versions mineures derrière le plan de contrôle, mais AWS déconseille de rester durablement dans cette configuration. Mieux vaut aligner les deux au fil des mises à jour.