Versions de Kubernetes prises en charge dans Azure Kubernetes Service (AKS)

La communauté Kubernetes publie des versions mineures à peu près tous les trois mois.

Les versions mineures contiennent de nouvelles fonctionnalités et des améliorations. Les publications de correctifs sont plus fréquentes (parfois hebdomadaires) et sont destinées aux correctifs de bogues critiques dans une version mineure. Les versions de correctif comportent des correctifs pour les failles de sécurité et les bogues majeurs.

Version de Kubernetes

Kubernetes utilise le schéma de contrôle de version standard Semantic Versioning pour chaque version :

[major].[minor].[patch]

Examples:
  1.29.2
  1.29.1

Chaque numéro de la version reflète la compatibilité avec les versions précédentes :

• Versions majeures : introduisez des modifications incompatibles de l’API ou interrompez la compatibilité descendante.
• Versions mineures : ajoutez de nouvelles fonctionnalités tout en conservant la compatibilité descendante.
• Versions correctives : incluent des correctifs de bogues rétrocompatibles.

Utilisez toujours la dernière version de correctif pour votre version mineure actuelle. Par exemple, si votre cluster de production est sur 1.29.1 et que 1.29.2 est la dernière version du correctif disponible pour la version mineure 1.29, vous devez effectuer une mise à niveau vers 1.29.2 dès que possible pour vous assurer que votre cluster est entièrement corrigé et pris en charge.

Calendrier des versions d’AKS Kubernetes

Consultez le calendrier de publication AKS Kubernetes pour connaître les versions à venir. Pour voir les mises à jour en temps réel de l’état de publication de la région et des notes de publication de version, visitez la page web d’état de la mise en production AKS. Pour en savoir plus sur la page web d’état de la mise en production, consultez Suivi de publication AKS.

Pour connaître l’historique des versions antérieures, cliquez sur historique Kubernetes.

Versions LTS

La prise en charge à long terme (LTS) doit être activée pour obtenir un support étendu. Vous trouverez plus d’informations sur l’activation de la prise en charge à long terme.

Diagramme de Gantt sur la planification de la mise en production AKS Kubernetes

Si vous préférez afficher ces informations visuellement, voici un diagramme de Gantt avec toutes les versions actuelles :

Changements cassants des composants AKS par version

Notez les modifications importantes suivantes avant de procéder à la mise à niveau vers l'une des versions mineures disponibles :

Kubernetes 1.34

Kubernetes 1.33

Kubernetes 1.32

Kubernetes 1.31

Kubernetes 1.30

Kubernetes 1.29

Version mineure de l’alias

Vous pouvez créer un cluster AKS sans spécifier de version de correctif. Lorsque vous créez un cluster sans désigner de correctif, le cluster exécute le correctif en disponibilité générale le plus récent de la version mineure. Par exemple, si vous créez un cluster avec 1.29 que 1.29.2 est le dernier correctif en disponibilité générale disponible, votre cluster est créé avec 1.29.2. Si vous souhaitez mettre à niveau votre version corrective dans la même version mineure, utilisez la mise à niveau automatique.

Pour voir le correctif que vous utilisez actuellement, exécutez la commande az aks show --resource-group myResourceGroup --name myAKSCluster. La propriété currentKubernetesVersion affiche l’intégralité de la version Kubernetes.

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.eastus.azmk8s.io",
  "currentKubernetesVersion": "1.29.2",
}

Stratégie de prise en charge des versions de Kubernetes

AKS définit une version en disponibilité générale (GA) comme une version disponible dans toutes les régions et activée dans toutes les mesures SLO ou SLA. AKS prend en charge trois versions mineures GA de Kubernetes :

AKS prend en charge trois versions mineures en disponibilité générale :

• Dernière version en disponibilité générale (N).
• Les deux versions mineures précédentes (N-1 et N-2).
  • Chaque version mineure prise en charge peut prendre en charge n’importe quel nombre de patchs à un moment donné. AKS se réserve le droit de rendre les patchs obsolètes si une vulnérabilité critique ou un CVE est détecté. Pour connaître la disponibilité des correctifs et toute détérioration ad hoc, reportez-vous aux notes de publication de version et consultez la page d'état de la version AKS.

AKS peut également prendre en charge des préversions, qui sont explicitement étiquetées et soumises aux Conditions générales des préversions.

AKS fournit une prise en charge de la plateforme uniquement pour une version mineure en disponibilité générale de Kubernetes après les versions normales prises en charge. La fenêtre de support des versions de Kubernetes sur AKS est connue sous le nom de « N-3 ». Pour plus d’informations, consultez politique de support.

La fenêtre prise en charge des versions mineures de Kubernetes sur AKS est appelée « N-2 », où N fait référence à la dernière version, ce qui signifie que deux versions mineures précédentes sont également prises en charge.

Par exemple, le jour où AKS introduit la version 1.29, la prise en charge est fournie pour les versions suivantes :

Quand une nouvelle version mineure est introduite, la version mineure la plus ancienne est déconseillée et supprimée. Par exemple, disons que la liste des versions mineures actuellement prises en charge est :

1.29
1.28
1.27

Lorsque AKS publie la version 1.30, toutes les versions 1.27. ne seront plus prises en charge 30 jours plus tard.

AKS est susceptible de prendre en charge un certain nombre de correctifs en fonction de la disponibilité des versions publiées par la communauté en amont pour une version mineure donnée. AKS se réserve le droit de déprécier l’un de ces patchs à tout moment en cas de CVE ou de bogue potentiel. Nous vous encourageons à toujours utiliser le dernier patch pour une version mineure.

Stratégie de prise en charge de la plateforme

La stratégie de support de la plateforme est un plan de support réduit pour certaines versions de Kubernetes non prises en charge. Pendant la prise en charge de la plateforme, les clients reçoivent uniquement le support de Microsoft pour les problèmes liés à la plateforme AKS/Azure. Les problèmes liés aux fonctionnalités et aux composants Kubernetes ne sont pas pris en charge.

La stratégie de prise en charge de la plateforme s’applique aux clusters dans une version n-3 (où n est la dernière version mineure d’AKS GA prise en charge), avant que le cluster ne passe à n-4. Par exemple, Kubernetes v1.26 est considéré comme bénéficiant du support de la plateforme lorsque v1.29 est la dernière version en disponibilité générale. Si vous utilisez une version n-2, dès qu'elle devient n-3, la version n'est plus officiellement supportée et vous entrez dans la politique de support de la plateforme.

AKS s’appuie sur les versions et les correctifs de Kubernetes, qui est un projet Open Source qui ne prend en charge qu’une fenêtre glissante de trois versions mineures. AKS ne peut garantir un support complet que lorsque ces versions sont en cours de maintenance vers une version amont. Plus aucun correctif amont n’étant produit, AKS peut laisser ces versions non corrigées ou les dupliquer. En raison de cette limite, le support de la plateforme ne prend rien en charge qui dépende de Kubernetes en amont.

Ce tableau décrit les instructions de prise en charge du support communautaire par rapport à la prise en charge de la plateforme.

Versions de kubectl prises en charge

Vous pouvez utiliser une kubectl version mineure antérieure ou ultérieure à votre version kube-apiserver, la stratégie de prise en charge de Kubernetes pour kubectl.

Par exemple, si votre kube-apiserver est à la version 1.28, vous pouvez utiliser les versions 1.27 à 1.29 de kubectl avec ce kube-apiserver.

Pour installer ou mettre à jour kubectl vers la dernière version, exécutez :

az aks install-cli

Install-AzAksKubectl -Version latest

Support à long terme (LTS)

AKS offre un an de support communautaire et un an de support à long terme (LTS), y compris les correctifs de sécurité rétroportés fournis par la communauté en amont. Notre groupe de travail LTS en amont contribue aux efforts de la communauté pour offrir à nos clients une fenêtre de support plus longue.

Pour plus d’informations sur LTS, consultez la prise en charge à long terme d’Azure Kubernetes Service (AKS).

Processus de publication et de dépréciation

Pour consulter la référence sur les versions à venir et les dépréciations, consultez le Calendrier de publication AKS Kubernetes.

Pour les nouvelles versions mineures de Kubernetes :

• AKS annonce les nouvelles dates de publication de version et la dépréciation de l’ancienne version dans les notes de publication AKS au moins 30 jours avant la suppression.
• AKS utilise Azure Advisor pour vous alerter au cas où une nouvelle version poserait des problèmes dans votre cluster en raison d’API dépréciées. Azure Advisor vous alerte également si vous n’avez plus de support
• AKS publie une notification d’intégrité des services accessible à tous les utilisateurs disposant d’un accès à AKS et au portail, et envoie un e-mail aux administrateurs des abonnements avec les dates prévisionnelles de suppression des versions.

  Note

  Pour savoir qui est votre administrateur d’abonnement ou pour le modifier, reportez-vous à la gestion des abonnements Azure.

• Vous avez 30 jours à compter de la suppression d’une version pour effectuer une mise à niveau vers une version mineure prise en charge afin de continuer à bénéficier du support.

Pour les nouvelles versions de correctif de Kubernetes :

• En raison de leur nature urgente, les versions correctives peuvent être introduites dans le service dès qu’elles sont disponibles. Une fois disponibles, les correctifs ont un cycle de vie d’au moins deux mois.
• En général, AKS ne communique pas beaucoup lors de la publication de nouvelles versions correctives. Pourtant, AKS surveille et valide constamment les correctifs CVE disponibles afin de les intégrer rapidement. Si un correctif critique est trouvé ou qu’une action de l’utilisateur est requise, AKS vous informe qu’il faut effectuer une mise à niveau vers le nouveau correctif.
• Vous avez 30 jours à compter de la suppression d’une version corrective d’AKS pour effectuer une mise à niveau vers un correctif pris en charge et ainsi continuer de bénéficier du support. Toutefois, vous ne pourrez plus créer de clusters ni de pools de nœuds une fois la version dépréciée/supprimée.

Exceptions à la politique des versions supportées

AKS se réserve le droit d'ajouter ou de supprimer de nouvelles versions ou des versions existantes comportant un ou plusieurs bogues critiques affectant la production ou des problèmes de sécurité sans préavis.

Certaines versions de correctifs spécifiques peuvent être ignorées, ou leur lancement peut être accéléré en fonction de la gravité du bogue ou du problème de sécurité.

Versions du Portail Azure et de l’interface CLI

Si vous déployez un cluster AKS avec le portail Azure, Azure CLI, Azure PowerShell, le cluster est défini par défaut sur la version mineure N-1 et le dernier correctif. Par exemple, si AKS prend en charge 1.29.2, 1.29.1, 1.28.7, 1.28.6, 1.27.11et 1.27.10, la version par défaut sélectionnée est 1.28.7.

az aks get-versions --location eastus --output table

Get-AzAksVersion -Location eastus

FAQ

Comment Microsoft m’informe-t-il des nouvelles versions de Kubernetes ?

L’équipe AKS annonce les nouvelles dates de publication de la version kubernetes dans notre documentation, sur GitHub, et par e-mail aux administrateurs d’abonnements avec des clusters proches de la fin du support. AKS utilise également Azure Advisor pour vous alerter dans le portail Azure si vous ne bénéficiez plus de support et pour vous informer des API dépréciées qui affectent votre application ou processus de développement.

À quelle fréquence dois-je prévoir de mettre à niveau les versions de Kubernetes pour continuer à bénéficier de la prise en charge ?

À partir de Kubernetes 1.19, la communauté open source a étendu le support à un an. AKS s’engage à activer les correctifs et à prendre en charge le respect des engagements en amont. Pour les clusters AKS sur la version 1.19 et ultérieure, vous pouvez effectuer une mise à niveau au moins une fois par an pour rester sur une version prise en charge.

Que se passe-t-il quand vous mettez à niveau un cluster Kubernetes avec une version mineure non prise en charge ?

Si vous utilisez la version n-3 ou une version antérieure, cela signifie que vous êtes en dehors du support et que vous devez effectuer une mise à niveau. Si votre mise à niveau de la version n-3 à n-2 réussit, vous êtes de retour dans nos stratégies de support. Par exemple:

• Si la plus ancienne version mineure d’AKS prise en charge est 1.27 et que vous utilisez la version 1.26 ou une version antérieure, vous êtes hors support.
• Si vous effectuez une mise à niveau de la version 1.26 vers la version 1.27 ou ultérieure, vous revenez dans nos stratégies de support.

Les passages à une version antérieure ne sont pas pris en charge.

Que signifie « être hors support » ?

« Ne plus disposer du support technique » signifie que :

• La version que vous exécutez n’est pas dans la liste des versions prises en charge.
• Vous serez invité à mettre à niveau le cluster vers une version prise en charge lorsque vous demandez de l'assistance, sauf si vous êtes dans la période de grâce de 30 jours après l'obsolescence de la version.

Par ailleurs, AKS n’offre aucune garantie d’exécution ou autre pour les clusters qui ne figurent pas dans la liste des versions prises en charge.

Que se passe-t-il lorsque vous faites évoluer un cluster Kubernetes avec une version mineure qui n'est pas prise en charge ?

Pour les versions mineures non prises en charge par AKS, le scale-in ou le scale-out devrait continuer à fonctionner. Étant donné qu’il n’existe aucune garantie de qualité de service, nous vous recommandons d’effectuer une mise à niveau pour que votre cluster soit pris en charge.

Pouvez-vous rester éternellement sur une version Kubernetes ?

Si un cluster n’est pas pris en charge pour plus de trois versions mineures et comporte des risques de sécurité, Azure vous contacte de manière proactive. Ils vous conseillent de mettre à niveau votre cluster. À défaut d’action supplémentaire de votre part, Azure se réserve le droit d’effectuer automatiquement la mise à niveau de votre cluster à votre place.

Que se passe-t-il si vous faites évoluer un cluster Kubernetes avec une version mineure qui n'est pas prise en charge ?

Pour les versions mineures non prises en charge par AKS, le scale-in ou le scale-out devrait continuer à fonctionner. Étant donné qu’il n’existe aucune garantie de qualité de service, nous vous recommandons d’effectuer une mise à niveau pour que votre cluster soit pris en charge.

Quelle version le plan de contrôle prend-il en charge si le pool de nœuds n’est pas dans une des versions d’AKS prises en charge ?

Le plan de contrôle doit se trouver dans une fenêtre de versions pour tous les pools de nœuds. Pour plus d’informations sur la mise à niveau du plan de contrôle ou des pools de nœuds, consultez la documentation sur la mise à niveau des pools de nœuds.

Quelle est la différence autorisée dans les versions entre le plan de contrôle et le pool de nœuds ?

La stratégie de décalage de versions autorise désormais une différence pouvant aller jusqu’à trois versions entre le plan de contrôle et les pools d’agents. AKS suit cette modification de stratégie de version asymétrique à partir de la version 1.28.

Puis-je ignorer plusieurs versions d’AKS durant la mise à niveau d’un cluster ?

Si vous mettez à niveau un cluster AKS pris en charge, les versions mineures de Kubernetes ne peuvent pas être ignorées. La stratégie d’asymétrie de version des plans de contrôle Kubernetes ne prend pas en charge l’omission de la version mineure. Par exemple, les mises à niveau entre :

• 1.28.x - >1.29.x : autorisé.
• 1.27.x - >1.28.x : autorisées.
• 1.27.x - >1.29.x : non autorisées.

Pour les mises à niveau des versions du plan de contrôle, vous pouvez atteindre jusqu’à trois versions mineures pour les versions prises en charge par la communauté de manière séquentielle.

Pour effectuer une mise à niveau depuis 1.27.x - >1.29.x :

1. Mise à niveau depuis 1.27.x - >1.28.x.
2. Mise à niveau depuis 1.28.x - >1.29.x.

Notez qu'à partir de la version 1.28, les versions du pool d’agents peuvent être jusqu’à trois versions antérieures par rapport aux versions du plan de contrôle selon la politique de divergence de versions. Si votre version se trouve bien derrière la version minimale prise en charge, vous devrez peut-être effectuer plusieurs opérations de mise à niveau du plan de contrôle pour accéder à la version minimale prise en charge. Par exemple, si votre version actuelle du plan de contrôle est 1.23.x et que vous envisagez de procéder à une mise à niveau vers une version minimale prise en charge 1.27.x. Vous devrez peut-être effectuer une mise à niveau séquentielle quatre fois à partir de 1.23.x pour accéder à 1.27.x. Notez également que les versions du pool d’agents peuvent être mises à niveau vers la version mineure du plan de contrôle. Dans l’exemple précédent, vous pouvez mettre à niveau la version de agentpool deux fois, une fois de 1.23.x à 1.25.x, lorsque la version du plan de contrôle est à 1.25.x. Puis de 1.25.x à 1.27.x, lorsque la version du plan de contrôle est à 1.27.x. Lorsque vous procédez à une mise à niveau sur place, en mettant à jour à la fois le plan de contrôle et le pool d’agents ensemble, les mêmes règles applicables à la mise à niveau du plan de contrôle s’appliquent.

Si vous effectuez une mise à niveau à partir d’une version non prise en charge , la mise à niveau est effectuée sans aucune garantie de fonctionnalité et est exclue des contrats de niveau de service et de la garantie limitée. Les clusters exécutant une version non prise en charge ont la flexibilité de découpler les mises à niveau du plan de contrôle avec des mises à niveau de pool de nœuds. Toutefois, si votre version est obsolète, nous vous recommandons de recréer le cluster.

Puis-je créer un nouveau cluster 1.xx.x pendant la fenêtre de prise en charge de la plateforme ?

Non, la création de nouveaux clusters n’est pas possible pendant la période de support de la plateforme.

Je suis sur une version récemment déconseillée, qui est hors de la prise en charge de la plateforme, puis-je toujours ajouter de nouveaux pools de nœuds ? Ou dois-je effectuer une mise à niveau ?

Oui, vous pouvez ajouter des pools d’agents tant qu’ils sont compatibles avec la version du plan de contrôle.

Étapes suivantes

Pour plus d’informations sur la mise à niveau de votre cluster, consultez :

• Mise à jour d’un cluster Azure Kubernetes Service (AKS)
• Mettre à niveau plusieurs clusters AKS par le biais d’Azure Kubernetes Fleet Manager