Le 31 octobre 2026, AKS supprime les images de nœuds Azure Linux 2.0. Si un de tes node pools tourne encore dessus, il ne pourra plus scaler. Rien ne casse le jour J : pas de nœud qui tombe, pas d’alerte rouge. Le problème apparaît le jour où l’autoscaler veut ajouter des nœuds pendant un pic de charge et n’y arrive pas.
Il te reste un peu plus de trois semaines. Cet article te donne deux requêtes pour repérer les pools concernés, le chemin de migration le moins risqué, et un rappel sur Kubernetes 1.34, qui arrive en fin de vie upstream quatre jours plus tôt, le 27 octobre.
Ce qui se passe exactement le 31 octobre
Azure Linux 2.0 n’est plus supporté sur AKS depuis le 30 novembre 2025. Depuis cette date, l’image de nœud est figée sur la release 202512.06.0 : aucun correctif de sécurité n’a été publié depuis bientôt un an. Le 31 octobre 2026, Microsoft retire ces images, et la documentation AKS est claire sur la conséquence : tu ne pourras plus scaler tes node pools. Toute opération qui doit provisionner un nœud neuf à partir de cette image est donc exposée, autoscaler compris.
Pourquoi des clusters tournent encore dessus ? Parce que l’OS SKU AzureLinux pointait par défaut sur Azure Linux 2.0 pour les versions Kubernetes 1.27 à 1.31. Un cluster créé en 2024 et jamais monté au-delà de 1.31 est presque toujours dans ce cas.
Le piège du LTS
Si ton cluster est en support long terme (LTS) sur 1.30 ou 1.31, tu te crois peut-être couvert. Tu ne l’es pas. Microsoft le précise dans le calendrier des versions AKS : Azure Linux 2.0 atteint sa fin de vie pendant la période LTS des versions 1.28 à 1.31. Le LTS prolonge Kubernetes, pas l’OS des nœuds.
Repérer les node pools concernés
Sur un cluster
az aks nodepool list \
--resource-group rg-prod-aks \
--cluster-name aks-prod-01 \
--query "[].{pool:name, k8s:orchestratorVersion, osSku:osSku, image:nodeImageVersion}" \
-o tableUn pool avec l’OS SKU AzureLinux (ou l’ancien nom CBLMariner), une version Kubernetes inférieure ou égale à 1.31 et une image encore en 202512.06.0 est quasi certainement en Azure Linux 2.0.
Sur tout ton parc
Si tu gères plus de deux ou trois clusters, passe par Azure Resource Graph plutôt que de boucler sur chaque abonnement :
az graph query -q "
resources
| where type =~ 'microsoft.containerservice/managedclusters'
| mv-expand pool = properties.agentPoolProfiles
| extend osSku = tostring(pool.osSKU), k8s = tostring(pool.orchestratorVersion)
| where osSku in~ ('AzureLinux', 'CBLMariner')
| project cluster = name, resourceGroup, subscriptionId,
pool = tostring(pool.name), osSku, k8s,
image = tostring(pool.nodeImageVersion)
| order by k8s asc
" --first 1000 -o tableTrie par version : les lignes en 1.31 et moins sont ta liste de travail. Les pools Azure Linux en 1.32 ou plus sont déjà sur Azure Linux 3.0, sauf exception que l’image te révélera.
Deux chemins de migration, un seul bon ordre
Tu as deux façons de sortir d’Azure Linux 2.0 :
- Changer l’OS sans toucher à Kubernetes avec
az aks nodepool update --os-sku AzureLinux3. Cet OS SKU est supporté de Kubernetes 1.28 à 1.36, donc il fonctionne sur ton cluster actuel. Les nœuds sont réimagés, rien d’autre ne bouge. - Monter Kubernetes en 1.32 ou plus avec l’OS SKU
AzureLinux, qui bascule alors par défaut sur Azure Linux 3.0.
Mon conseil : fais la première option maintenant, et l’upgrade Kubernetes après, dans une fenêtre séparée. Un cluster encore en 1.31 doit de toute façon franchir plusieurs versions mineures pour revenir dans le support standard (AKS a mis fin au support de 1.31 le 1er novembre 2025). Changer l’OS et enchaîner trois ou quatre versions Kubernetes dans la même soirée, c’est empiler deux sources de casse sans pouvoir dire laquelle a cassé quoi. Avec trois semaines devant toi, une seule opération maîtrisée vaut mieux qu’un grand saut.
az aks nodepool update \
--resource-group rg-prod-aks \
--cluster-name aks-prod-01 \
--name userpool1 \
--os-sku AzureLinux3Avant de lancer la commande
- Vérifie tes PodDisruptionBudgets. La réimage passe par un cordon puis un drain des nœuds. Un PDB avec
maxUnavailable: 0(ou unminAvailableégal au nombre de réplicas) bloque le drain, et l’opération reste coincée. - Règle le surge du pool si ce n’est pas déjà fait (
az aks nodepool update --max-surge 33%, par exemple) pour accélérer le roulement sans saturer le quota de cœurs de ton abonnement. - Passe d’abord sur un pool hors production. Les agents tiers déployés en DaemonSet (EDR, agents de supervision) qui chargent un module noyau ou dépendent de paquets de l’OS sont les premiers à mal réagir à un changement de distribution. Demande à l’éditeur s’il supporte Azure Linux 3.0 avant le jour J.
- Commence par les pools utilisateurs, puis le pool système une fois que tu as vu le comportement.
Kubernetes 1.34 : l’autre échéance d’octobre
Côté upstream, Kubernetes 1.34 est en mode maintenance depuis le 27 août et atteint sa fin de vie le 27 octobre 2026, d’après la page des patch releases. Son dernier patch connu est le 1.34.12, publié le 15 septembre.
Sur AKS, tu as un peu plus de marge : le calendrier donne une fin de vie de 1.34 à fin novembre 2026. Ce n’est pas une raison pour attendre. Pour un cluster en 1.34, je viserais 1.36 plutôt que 1.37 : la 1.37 arrive tout juste en GA sur AKS ce mois-ci, et laisser passer les premiers patchs ne coûte rien. La 1.36 reste supportée jusqu’en juin 2027. Si tu veux savoir ce que la 1.37 apporte quand même, j’ai détaillé les nouveautés de Kubernetes 1.37 dans un article précédent.
Pour ne plus découvrir ces échéances par hasard, AKS publie maintenant des notifications de fin de support dans Azure Resource Graph : KubernetesVersionEOLTwoWeeks, KubernetesVersionEOLOneWeek, puis KubernetesVersionOutOfSupport chaque semaine une fois la date passée. Pas besoin d’add-on ni de fenêtre de maintenance pour les recevoir. Branche-les sur une alerte et tu auras deux semaines de préavis.
FAQ
Mon cluster est en LTS 1.30, je suis tranquille ?
Non. Le LTS couvre la version Kubernetes, pas Azure Linux 2.0. Tes nœuds sont concernés par le 31 octobre comme les autres.
Est-ce que az aks nodepool update --os-sku réimage tous les nœuds d’un coup ?
Non, AKS procède par vagues, avec cordon et drain, selon le surge configuré sur le pool. C’est justement pour ça que les PDB et le surge comptent.
Je peux revenir à Azure Linux 2.0 si ça se passe mal ?
Techniquement oui avant le 31 octobre, tant que la version Kubernetes supporte encore cet OS. Mais revenir sur un système sans correctif depuis onze mois, ce n’est pas un plan B, c’est un pansement. Prévois plutôt un pool de repli en Ubuntu si un composant résiste vraiment.
Et les pools Ubuntu, ils ont aussi une échéance ?
Oui, plus lointaine : Ubuntu 20.04 n’est plus supporté sur AKS à partir du 17 mars 2027, et Ubuntu 22.04 à partir du 30 juin 2027. Avec l’OS SKU Ubuntu, la bascule vers 24.04 se fait automatiquement quand tu passes Kubernetes en 1.35 ou plus.
Où suivre l’annonce officielle ?
Microsoft suit ce retrait dans l’issue GitHub AKS #4988. Les nouvelles dates éventuelles y apparaissent en premier.
Ce que tu peux faire aujourd’hui
Lance la requête Resource Graph ci-dessus. Si elle ne retourne rien, tu as gagné ta journée. Si elle sort des lignes, planifie la migration AzureLinux3 d’un premier pool hors production cette semaine, et garde l’upgrade Kubernetes pour novembre. Profite aussi du passage pour relire tes bonnes pratiques de sécurisation de cluster : un parc qui traînait des nœuds non patchés depuis un an a sûrement d’autres angles morts.
Laisser un commentaire