Partage via

Support à long terme des versions d’Azure Kubernetes Service (AKS)

  • Article

La communauté Kubernetes publie une nouvelle version mineure environ tous les quatre mois, avec une fenêtre de support pour chaque version pendant un an. Dans Azure Kubernetes Service (AKS), cette fenêtre de support est appelée support communautaire.

AKS prend en charge les versions de Kubernetes qui se trouvent dans cette fenêtre de support communautaire pour envoyer (push) des correctifs de bogues et des mises à jour de sécurité à partir des versions de la communauté. Bien que la cadence de mise en production du support communautaire assure certains avantages, elle exige que vous soyez à jour avec les versions de Kubernetes les plus récentes. Il se peut que cela soit compliqué par les dépendances de votre application et l’allure des modifications de l’écosystème Kubernetes.

Pour vous aider à gérer vos mises à niveau de version Kubernetes, AKS propose une option de support à long terme (LTS) qui prolonge le créneau de support d’une version Kubernetes afin de vous donner plus de temps pour planifier et tester les mises à niveau vers des versions Kubernetes plus récentes.

Types de support AKS

Au bout d’un an environ, une version mineure quelconque de Kubernetes cesse d’être prise en charge par le support communautaire. Cela rend les correctifs de bogues et les mises à jour de sécurité indisponibles pour vos clusters AKS.

AKS fournit un an de support communautaire et un an de support à long terme afin de rétroporter en amont les correctifs de sécurité de la communauté dans le référentiel AKS public. Le groupe de travail de LTS en amont contribue aux efforts de la communauté afin d’offrir aux clients une fenêtre de support plus longue. Le LTS envisage de prolonger ce délai pour vous permettre de planifier et tester les mises à niveau sur une période de deux ans à partir de la disponibilité générale (GA) de la version de Kubernetes désignée.

Support de la communauté pour les objets blob Prise en charge à long terme
Quand utiliser Quand vous pouvez continuer avec les versions Kubernetes en amont Quand vous avez besoin de contrôler quand migrer d’une version vers une autre
Versions prises en charge Trois versions mineures en disponibilité générale Une version de Kubernetes (actuellement 1.27) pendant deux ans

Activer le support à long terme

L’activation du LTS exige de déplacer votre cluster vers le niveau Premium et de sélectionner explicitement le plan de support LTS. Bien qu’il soit possible d’activer le LTS lorsque le cluster se trouve dans le *support communautaire, vous serez facturé une fois le niveau Premium activé.

Activer le LTS pour un nouveau cluster

  • Créez un cluster avec le LTS activé à l’aide de la commande az aks create.

    La commande suivante crée un cluster AKS avec le LTS activé en utilisant la version 1.27 de Kubernetes comme exemple. Pour passer en revue les versions disponibles de Kubernetes, consultez le suivi de versions AKS.

    az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --tier premium \
    --k8s-support-plan AKSLongTermSupport \
    --kubernetes-version 1.27 \
    --generate-ssh-keys

Activer le LTS sur un cluster existant

  • Activez le LTS sur un cluster existant à l’aide de la commande az aks update.

    az aks update --resource-group <resource-group-name> --name <cluster-name> --tier premium --k8s-support-plan AKSLongTermSupport

Migrer vers la dernière version du LTS

La communauté Kubernetes en amont prend en charge une procédure de mise à niveau de deux versions mineures. Le processus migre les objets de votre cluster Kubernetes dans le cadre du processus de mise à niveau et fournit une procédure de migration testée et accréditée.

Si vous souhaitez effectuer une migration sur place, le service AKS migre votre plan de contrôle de la version de LTS précédente vers la dernière version, puis migre votre plan de données. Pour effectuer une mise à niveau sur place vers la dernière version LTS, vous devez spécifier une version Kubernetes compatible LTS comme cible de mise à niveau.

  • Migrez vers la dernière version de LTS à l’aide de la commande az aks upgrade.

    La commande suivante utilise la version 1.32.2 de Kubernetes comme exemple de version. Pour passer en revue les versions disponibles de Kubernetes, consultez le suivi de versions AKS.

    az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version 1.32.2

    Remarque

    1.30 est la version LTS suivante après la version 1.27. Vous pouvez opter pour LTS à partir d’un cluster version 1.30 en suivant les étapes ci-dessus. La version 1.27 de LTS sera mise en fin de service (EOL) d’ici juillet 2025.

Désactiver le support à long terme sur un cluster existant

Pour désactiver le LTS sur un cluster existant, vous devez déplacer votre cluster vers le niveau gratuit ou standard et sélectionner explicitement le plan de support KubernetesOfficial.

Les versions LTS se succèdent généralement tous les deux ans. Au lieu du support en amont de la migration de plus de deux versions mineures, il existe une probabilité élevée que votre application dépende des API Kubernetes qui ont été déconseillées. Nous vous recommandons de tester soigneusement votre application sur la version de Kubernetes LTS cible et d’effectuer un déploiement bleu/vert d’une version à une autre.

  1. Désactivez le LTS sur un cluster existant à l’aide de la commande az aks update.

    az aks update --resource-group <resource-group-name> --name <cluster-name> --tier [free|standard] --k8s-support-plan KubernetesOfficial

  2. Mettez à niveau le cluster sur une version ultérieure prise en charge à l’aide de la commande az aks upgrade.

    La commande suivante utilise la version 1.28.3 de Kubernetes comme exemple de version. Pour passer en revue les versions disponibles de Kubernetes, consultez le suivi de versions AKS.

    az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version 1.28.3

Extensions et fonctionnalités non prises en charge

L’équipe AKS effectue actuellement le suivi des versions du module complémentaire dans lesquelles le support de la communauté Kubernetes existe. Une fois qu’une version cesse d’être prise en charge par le support communautaire, nous nous basons sur des projets open source pour fournir les extensions gérées permettant de poursuivre ce support. En raison de différents facteurs externes, il se peut que certaines extensions et fonctionnalités ne prennent pas en charge les versions de Kubernetes en dehors de ces fenêtres de support communautaire en amont.

Le tableau suivant fournit une liste des extensions et fonctionnalités qui ne sont pas prises en charge et explique pourquoi c’est le cas :

Module supplémentaire / Fonctionnalité Motif de non-prise en charge
Istio Le cycle de support Istio est court (six mois) et il n’y aura pas de versions de maintenance pour Kubernetes 1.27.
Keda Impossible de garantir la compatibilité future de la version avec Kubernetes 1.27.
Calico Nécessite un contrat Calico Enterprise une fois le support communautaire arrivé à échéance.
Service de gestion de clés (KMS) KMSv2 remplace KMS pendant ce cycle de LTS.
Dapr Les extensions AKS ne sont pas prises en charge.
Contrôleur d’entrée Application Gateway La migration vers App Gateway pour conteneurs se produit pendant la période de LTS.
Open Service Mesh OSM est déconseillé.
AAD Pod Identity Déconseillé et remplacé par Workload Identity.

Remarque

Vous ne pouvez pas déplacer votre cluster vers le support à long terme si l’un de ces modules complémentaires ou fonctionnalités est activé.

Bien que ces extensions managées AKS ne soient pas prises en charge par Microsoft, vous pouvez installer leurs versions open source sur votre cluster si vous souhaitez les utiliser une fois le support communautaire arrivé à échéance.

Comment nous décidons de la prochaine version LTS

Les versions de LTS de Kubernetes sont disponibles pendant deux ans à partir de la disponibilité générale. Nous signalerons une version ultérieure de Kubernetes en tant que LTS en fonction des critères suivants :

  • Un délai suffisant a été alloué pour permettre aux clients de migrer depuis la version de LTS précédente vers la nouvelle version.
  • La version précédente a disposé d’une fenêtre de support de deux ans.

Lisez les notes de publication AKS pour rester informé du moment opportun pour planifier votre migration.

Forum aux questions

Le support communautaire pour AKS 1.27 expire en juillet 2024. Puis-je créer un cluster AKS avec la version 1.27 après cette date ?

Oui, tant que LTS est activé sur le cluster, vous pouvez créer un cluster AKS avec la version 1.27 une fois la fenêtre de support de la communauté terminée.

Puis-je activer et désactiver LTS sur AKS 1.27 après la fin du support communautaire ?

Vous pouvez activer le plan de support LTS sur AKS 1.27 après la fin du support communautaire. Toutefois, vous ne pouvez pas désactiver LTS sur AKS 1.27 après la fin du support communautaire.

J’ai un cluster qui s’exécute sur la version 1.27. Cela signifie-t-il qu’il est automatiquement en LTS ?

Non, vous devez activer explicitement LTS sur le cluster pour bénéficier de la prise en charge LTS. L’activation de LTS nécessite également d’être au niveau Premium.

Quel est le modèle de tarification pour LTS ?

LTS est disponible au niveau Premium. Pour plus d’informations, consultez la tarification du niveau Premium.

Après l’activation de LTS, l’autoUpgradeChannel de mon cluster a basculé sur le canal de correctif

Ceci est normal. Si aucun autoUpgradeChannel n’a été défini pour le cluster AKS, il est défini par défaut sur patch avec LTS.