AKS : Kubernetes 1.37 disponible et en LTS jusqu'en 2028

Kubernetes 1.37 est désormais en disponibilité générale sur Azure Kubernetes Service (AKS), et Microsoft l'a désignée version à support long terme (LTS). Annoncée dans les notes de version AKS datées du 25 octobre 2026, cette étape s'accompagne d'un changement de version par défaut et de plusieurs évolutions de comportement que les équipes d'exploitation ont intérêt à lire avant de planifier leurs mises à niveau.

Un calendrier de support étendu

Selon le calendrier publié par Microsoft, Kubernetes 1.37 est généralement disponible sur AKS depuis octobre 2026. Sa fin de vie en support communautaire est prévue en octobre 2027, et son support LTS court jusqu'en octobre 2028. AKS propose en effet un an de support communautaire, suivi d'un an de LTS avec rétroportage des correctifs de sécurité.

Le LTS n'est jamais automatique : il faut l'activer explicitement sur le cluster. Sans cette démarche, un cluster en 1.37 suit le cycle standard.

Dans le même temps, Kubernetes 1.36 devient la version par défaut pour les nouveaux clusters. Les correctifs 1.37.1, 1.36.5, 1.35.9 et 1.34.12 sont également publiés. Microsoft rappelle que le support communautaire de 1.34 et le support LTS de 1.31 se terminent en novembre 2026. Côté projet, la branche 1.34 est déjà arrivée en fin de vie, comme nous l'expliquions dans notre article sur Kubernetes 1.34.

Ce qui change avec 1.37 sur AKS

Pour les nouveaux clusters en 1.37 et au-delà, le chiffrement d'etcd avec des clés gérées par la plateforme est activé par défaut, sauf si le chiffrement d'infrastructure est configuré.

La documentation signale aussi un changement cassant pour ceux qui utilisent le service managé Prometheus d'Azure Monitor : à partir de 1.37, l'agent ama-metrics accède aux secrets Kubernetes au niveau de l'espace de noms pour les configurations PodMonitor et ServiceMonitor. Si l'une d'elles utilise basicAuth, il faut configurer cet accès avant la mise à niveau.

Pour un tour d'horizon des nouveautés du côté du projet lui-même, voir ce qui change avec Kubernetes 1.37.

Mises à niveau automatiques à partir de juin 2027

L'annonce la plus structurante concerne les clusters laissés sur une version non supportée. À partir du 1er juin 2027, AKS mettra automatiquement à niveau tout cluster qui reste sur une version obsolète à l'issue d'un délai de grâce de 60 jours après la fin de vie.

Microsoft prévient que cette mise à niveau imposée ne respecte pas la fenêtre de maintenance, ne s'arrête pas en cas d'API dépréciées et peut passer outre un Pod Disruption Budget qui bloquerait le drainage d'un nœud. Les charges de travail peuvent donc être perturbées. Les clusters en LTS sont, eux, migrés vers la version LTS applicable.

Autres évolutions de la version

Les notes de version annoncent aussi :

• un changement à venir : à partir de Kubernetes 1.38, les pools de nœuds Ubuntu passeront par défaut à Ubuntu 26.04 ; pour rester en 24.04, il faudra préciser la référence Ubuntu2404 ;
• de nouvelles fonctions en disponibilité générale pour Node Auto Provisioning, dont la prise en charge d'Azure Container Linux comme système des nœuds et des GPU managés ;
• la migration automatique des pools de nœuds en groupes à haute disponibilité (VMAS) vers des pools de machines virtuelles dans 23 régions, pendant les fenêtres de maintenance.

Que faire maintenant

Pour les équipes qui exploitent AKS, trois vérifications s'imposent : inventorier les clusters encore en 1.34 ou en 1.31 LTS, décider lesquels méritent l'activation du LTS, et contrôler les configurations Prometheus avant tout passage en 1.37. Mieux vaut planifier ces mises à niveau soi-même que de les subir à partir de juin 2027.