Prise en charge à long terme
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 des correctifs de bogues et les mises à jour de sécurité des versions de la communauté.
Bien que l’innovation permise par cette cadence de mise en production vous offre d’énormes avantages, vous peinez à maintenir à jour les versions de Kubernetes, ce qui peut être rendu plus difficile en fonction du nombre de clusters AKS que vous devez maintenir.
Types de support AKS
Au bout d’un an environ, une version de Kubernetes cesse d’être prise en charge par le support communautaire et vos clusters AKS sont désormais à risque, car les correctifs de bogues et les mises à jour de sécurité deviennent indisponibles.
AKS fournit un an de support communautaire et un an de support à long terme (LTS) pour rétroporter les correctifs de sécurité de la communauté en amont dans notre référentiel public. Notre groupe de travail LTS en amont contribue aux efforts de la communauté pour offrir à nos clients une fenêtre de support plus longue.
LTS a l’intention de vous donner une période prolongée pour planifier et tester les mises à niveau sur une période de deux ans à partir de la disponibilité générale 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 et la désactivation du support à long terme sont une combinaison de déplacement de votre cluster vers le niveau Premium et de sélection explicite du plan de support LTS.
Remarque
Bien qu’il soit possible d’activer le LTS lorsque le cluster est dans le support communautaire, vous serez facturé une fois le niveau Premium activé.
Créer un cluster avec LTS activé
az aks create --resource-group myResourceGroup --name myAKSCluster --tier premium --k8s-support-plan AKSLongTermSupport --kubernetes-version 1.27
Remarque
Pour activer ou désactiver le LTS, vous devez à la fois déplacer votre cluster par rapport au niveau Premium, et régler l’activation du support à long terme. Les deux doivent être activés ou désactivés.
Activer le LTS sur un cluster existant
az aks update --resource-group myResourceGroup --name myAKSCluster --tier premium --k8s-support-plan AKSLongTermSupport
Désactiver le LTS sur un cluster existant
az aks update --resource-group myResourceGroup --name myAKSCluster --tier [free|standard] --k8s-support-plan KubernetesOfficial
Support à long terme, extensions et fonctionnalités
L’équipe AKS effectue actuellement le suivi des versions du module complémentaire dans lesquelles le support communautaire Kubernetes existe. Une fois qu’une version cesse d’être prise en charge par le support communautaire, nous nous appuyons sur des projets open source pour les modules complémentaires gérés afin de poursuivre le support. En raison de différents facteurs externes, certaines extensions et fonctionnalités peuvent ne pas prendre en charge les versions de Kubernetes en dehors de ces fenêtres du support communautaire en amont.
Consultez le tableau suivant pour obtenir la liste des modules complémentaires et des fonctionnalités qui ne sont pas prises en charge et le motif.
| 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 lorsque le support communautaire arrive à échéance |
| Cillium | Nécessite un contrat Cillium Enterprise lorsque le support communautaire arrive à é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 sera déconseillé. |
| AAD Pod Identity | Déconseillé à la place de l’identité de charge de travail |
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 modules complémentaires managés AKS ne soient pas pris en charge par Microsoft, vous pouvez installer leurs versions Open Source sur votre cluster si vous souhaitez l’utiliser une fois le support communautaire arrivé à échéance.
Comment nous décidons de la prochaine version LTS
Les versions de Kubernetes LTS sont disponibles pendant deux ans à partir de la disponibilité générale, nous marquerons une version ultérieure de Kubernetes en tant que LTS en fonction des critères ci-dessous.
- Délai suffisant pour que les clients migrent de la version LTS précédente vers la nouvelle version.
- La version précédente a eu une fenêtre de support de deux ans.
Lisez les notes de publication AKS pour rester informé du moment opportun pour planifier votre migration.
Migrer de LTS vers le support de la communauté
L’utilisation de LTS est un moyen d’étendre votre fenêtre pour planifier une mise à niveau de version Kubernetes. Vous pouvez migrer vers une version de Kubernetes qui se trouve dans la fenêtre de support standard.
Pour passer d’un cluster LTS activé à une version de Kubernetes qui se trouve dans la fenêtre de support standard, vous devez désactiver le LTS sur le cluster :
az aks update --resource-group myResourceGroup --name myAKSCluster --tier [free|standard] --k8s-support-plan KubernetesOfficial
Puis mettez à niveau le cluster vers une version ultérieure prise en charge :
az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.28.3
Remarque
Kubernetes 1.28.3 est utilisé comme exemple ici, consultez le suivi des versions d’AKS pour découvrir les versions Kubernetes disponibles.
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.
Migrer vers la prochaine version 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 un chemin de migration testé et accrédité.
Pour les clients qui souhaitent effectuer une migration sur place, le service AKS migre votre plan de contrôle de la version 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.
az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.32.2
Remarque
Kubernetes version 1.32 est la version LTS (Prise en charge à long terme) suivante après la version 1.27. Les clients bénéficieront d’un chevauchement minimal de 6 mois entre les versions 1.27 LTS et 1.32 LTS pour planifier les mises à niveau.
Kubernetes 1.32.2 est utilisé comme exemple de version dans cet article. Vérifiez le suivi des versions d’AKS pour connaître les versions Kubernetes disponibles.