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

La communauté Kubernetes publie des versions mineures toutes les quatre mois environ.

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]

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 : ajouter de nouvelles fonctionnalités. Les API stables restent généralement compatibles, mais les API et fonctionnalités déconseillées peuvent être supprimées en fonction de la stratégie de dépréciation Kubernetes.
• Versions correctives : incluent des correctifs de bogues rétrocompatibles.

Utilisez toujours la dernière version de correctif pour votre version mineure actuelle. Lorsqu’un correctif ultérieur est disponible pour votre version mineure, mettez à niveau dès que possible pour vous assurer que votre cluster est entièrement corrigé et pris en charge.

Calendrier des versions et versions à venir 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.

La colonne Mise à niveau déclenchée par la plateforme indique le mois de déploiement prévu pour les clusters qui exécutent encore cette version après la période de grâce du support de la plateforme de 60 jours. Le mois répertorié est une estimation de planification, et non une date de mise à niveau exacte pour un cluster. Les mises à niveau peuvent se produire pendant ou après le mois répertorié, car AKS applique une limitation du débit par région, abonnement et version. Les versions incluses dans le déploiement initial partagent le même mois de déploiement : juin 2027. Pour plus d’informations, consultez mises à niveau initiées par la plateforme.

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

Versions LTS

Vous devez activer le support à long terme (LTS) pour obtenir un support étendu. Pour plus d’informations, consultez Activer la prise en charge à long terme.

Pour les clusters LTS, le mois de mise à niveau initié par la plateforme commence après la période de grâce de 60 jours suivant la date de fin de vie du LTS. AKS met à niveau ces clusters vers la version LTS prise en charge suivante. L’inscription dans LTS n’est jamais automatique. Le mois répertorié est une estimation de planification, et non une date de mise à niveau exacte pour un cluster.

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

Le diagramme de Gantt suivant affiche 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.37

Kubernetes 1.36

Kubernetes 1.35

Kubernetes 1.34

Kubernetes 1.33

Kubernetes 1.32

Kubernetes 1.31

Kubernetes 1.30

Version mineure de l’alias dans AKS

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. 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. Dans la sortie, la currentKubernetesVersion propriété affiche l’intégralité de la version Kubernetes. Par exemple:

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.eastus.azmk8s.io",
  "currentKubernetesVersion": "<major>.<minor>.<patch>",
}

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 :

• 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 prise en charge de la plateforme des versions de Kubernetes sur AKS est appelée 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, supposons que la liste actuelle des versions mineures prises en charge est 1.29, 1.28 et 1.27. Lorsqu’AKS publiera la version 1.30, toutes les versions 1.27 ne seront plus prises en charge 30 jours plus tard et passeront sous le régime du support de la plateforme.

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 à utiliser le dernier correctif 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 d’une version N-3 (où N est la dernière version mineure AKS 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. Supposons que vous exécutez une version N-2 . Le moment où cette version devient N-3, elle met également fin à son support officiel et vous entrez dans la stratégie de support de la plateforme.

La prise en charge de la plateforme vous offre une période de grâce de 60 jours pour effectuer une mise à niveau en fonction de vos propres conditions. Lorsque la période de grâce se termine, AKS met automatiquement à niveau le cluster vers une version prise en charge. Pour plus d’informations, consultez mises à niveau initiées par la plateforme.

AKS s’appuie sur les versions et les correctifs de Kubernetes, qui est un projet open source qui prend uniquement en charge 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.

Le tableau suivant présente les instructions de prise en charge de la communauté par rapport à la prise en charge de la plateforme :

Mises à niveau initiées par la plateforme

AKS met à niveau les clusters qui restent sur une version kubernetes non prise en charge après la fin de la période de grâce de la plateforme. Cette stratégie garantit qu’aucun cluster ne reste indéfiniment sur une version qui ne reçoit plus de correctifs de sécurité.

AKS met à niveau le cluster vers la version la plus faible prise en charge au sein de son niveau de support actuel : les clusters de support communautaire passent à la version mineure de la communauté la plus faible prise en charge et les clusters LTS passent à la version LTS applicable. AKS n’inscrit pas de clusters dans LTS et ne modifie pas votre niveau de facturation.

Contrairement à une mise à niveau manuelle, une mise à niveau automatique du cluster ou une exécution de mise à jour Fleet Manager, une mise à niveau initiée par la plateforme ne suit pas votre fenêtre de maintenance et n’exécute pas la vérification de l’API déconseillée. Conserver votre cluster sur une version prise en charge est la seule façon d’éviter une mise à niveau initiée par la plateforme.

Pour consulter l’ensemble de la stratégie, notamment les modalités de notification et les étapes de préparation, consultez Mises à niveau déclenchées par la plateforme.

Versions de kubectl prises en charge

Vous pouvez utiliser une kubectl version mineure antérieure ou ultérieure à votre version kube-apiserver. Pour plus d’informations, consultez la stratégie de prise en charge 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.

Pour installer ou mettre à jour kubectl vers la dernière version, utilisez la commande basée sur votre outil préféré :

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 connaître les prochaines versions et les fonctionnalités déconseillées, consultez le calendrier des versions de Kubernetes AKS.

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 avertit également si vous n’êtes pas pris en charge.

• 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 afficher ou modifier vos administrateurs d’abonnements, consultez gérer les abonnements Azure.

• Vous disposez d’une période de grâce de prise en charge de la plateforme de 60 jours après la date de fin de vie publiée pour effectuer une mise à niveau vers une version mineure prise en charge. La suppression d’une version dans une région peut avoir lieu à une date différente de celle publiée. Si le cluster reste sur une version non prise en charge après la période de grâce, AKS le met automatiquement à niveau. Pour plus d’informations, consultez mises à niveau initiées par la plateforme.

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 60 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 ou de pools de nœuds une fois que la version est dépréciée ou 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 à l’aide du portail Azure, Azure CLI ou Azure PowerShell, le cluster est défini par défaut sur la version mineure N-1 et le dernier correctif.

Pour savoir quelles versions sont actuellement disponibles pour votre abonnement et votre région, utilisez la commande basée sur votre outil préféré :

# The following example lists the available Kubernetes versions for the EastUS region:

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

# The following example lists the available Kubernetes versions for the EastUS region:

Get-AzAksVersion -Location eastus

Questions fréquemment posées (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.

Un cluster exécutant une version non prise en charge signale également un état Dégradé dans Azure Resource Health et affiche une bannière sur la ressource de cluster dans le portail Azure, indiquant quand AKS mettra le cluster à niveau. Pour plus d’informations, consultez mises à niveau initiées par la plateforme.

À 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 votre version ne prend pas en charge la liste des versions de Kubernetes prises en charge, vous devez effectuer une mise à niveau. Vous pouvez effectuer une mise à niveau à partir de versions non prises en charge vers des versions prises en charge. Par exemple:

• Si la version mineure AKS la plus basse prise en charge est 1.33 et que vous êtes sur la version 1.32 ou antérieure, vous êtes en dehors du support.
• Si vous effectuez une mise à niveau de la version 1.32 vers la version 1.33 ou ultérieure, vous êtes de retour dans les stratégies de support.

Les rétrogradations ou restaurations vers une version non prise en charge ne sont pas prises en charge. Plus la version du cluster est éloignée de la version la plus faible prise en charge, plus les API supprimées et les modules complémentaires autogérés incompatibles que vous devrez peut-être résoudre avant la mise à niveau seront nombreux.

Si vous ne mettez pas à niveau, AKS met à niveau le cluster pour vous lorsque la période de grâce de la prise en charge de la plateforme prend fin. AKS déplace le cluster une version mineure à la fois jusqu’à ce qu’il atteigne une version prise en charge. Pour plus d’informations, consultez mises à niveau initiées par la plateforme.

Qu’est-ce que cela signifie de ne plus être pris en charge ?

« En dehors de l'assistance » signifie :

• La version que vous exécutez n’est pas dans la liste des versions prises en charge.
• Vous êtes invité à mettre à niveau le cluster vers une version prise en charge lors de la demande de support, sauf si vous êtes dans la période de grâce de 60 jours du support de la plateforme après la dépréciation 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.

Pouvez-vous rester éternellement sur une version Kubernetes ?

Non. Un cluster qui reste sur une version non prise en charge ne reçoit plus de correctifs de sécurité, de sorte qu’AKS le met automatiquement à niveau lorsque la période de grâce de 60 jours du support de la plateforme prend fin. Azure vous avertit également par Azure Resource Health, Azure Advisor et par e-mail avant l’exécution de la mise à niveau.

Vous conservez le contrôle en conservant le cluster sur une version mineure de la communauté prise en charge ou une version de support à long terme (LTS) que vous inscrivez explicitement. Il n’est pas possible de désactiver cette fonctionnalité. Pour plus d’informations, consultez Mises à niveau déclenchées par la plateforme.

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 et tous les pools de nœuds doivent rester dans la fenêtre de décalage de version prise en charge. À partir de Kubernetes 1.28, le plan de contrôle peut avoir jusqu’à trois versions mineures d’avance sur les pools de nœuds. Pour plus d’informations, consultez les règles de mise à niveau de version kubernetes.

Quelle est la différence autorisée dans les versions entre le plan de contrôle et les pools 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 AKS pendant la mise à niveau d’un cluster ?

Oui, vous pouvez ignorer les versions mineures dans certains cas. Toutefois, si vous mettez à niveau le plan de contrôle indépendamment des pools de nœuds, vous devez respecter les règles de compatibilité entre versions de Kubernetes. La stratégie d’asymétrie de version Kubernetes prend actuellement en charge uniquement N-3. Par conséquent, le plan de contrôle et les pools d’agents doivent se trouver dans N-3.

• LTS : version avec le plan de support akS Long-Term activé. Consultez les versions LTS.
• LTS non pris en charge : version avec prise en charge LTS dont la date de fin de vie LTS est dépassée dans le tableau Versions LTS.
• Non-LTS pris en charge : version qui n’est pas LTS, mais qui est toujours répertoriée comme prise en charge dans le calendrier de publication AKS Kubernetes.
• Version non-LTS non prise en charge : Une version qui n’est pas LTS et qui n’est plus indiquée comme prise en charge dans le calendrier des versions de Kubernetes AKS.

Exemples :

• Si votre cluster se trouve sur la version 1.29 LTS et que vous souhaitez passer à la version 1.32 LTS, vous pouvez ignorer plusieurs versions mineures tant que la version 1.32 LTS est toujours proposée par AKS et que la mise à niveau satisfait aux vérifications d’asymétrie et de validation de version.
• Si votre cluster se trouve sur la version 1.28 non-LTS, vous pouvez passer à AKS LTS 1.30 LTS à l’aide du chemin de récupération non pris en charge, tant que la version cible est répertoriée par AKS, satisfait aux vérifications de validation et que vous exécutez une mise à niveau complète du cluster plutôt que control-plane-only.
• Si votre cluster exécute une version non-LTS prise en charge, 1.33, et que vous souhaitez passer à la version non-LTS prise en charge 1.35, vous ne pouvez pas passer directement de 1.33 à 1.35. Vous devez mettre à niveau une version mineure à la fois, telle que 1.33 vers la version 1.34, puis 1.34 vers 1.35.

Dans le tableau précédent, Unsupported recovery path indique que le chemin de mise à niveau est exécuté d’une manière qui ne peut pas être garantie sécurisée et est donc considéré en dehors de la prise en charge. AKS permet à la mise à niveau de continuer, mais elle n’est pas prise en charge et risque de porter des risques.

Pour choisir le chemin d’accès approprié, vérifiez les cibles disponibles en exécutant az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>. Passez en revue le tableau précédent, puis tenez compte du risque de mise à niveau par rapport à la recréation du cluster et à la migration des charges de travail.

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 prise en charge de la plateforme.

Je suis sur une version fraîchement déconseillée qui n’est pas prise en charge par 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.

Contenu connexe

Pour plus d’informations sur les mises à niveau de cluster AKS, consultez :

• Mise à jour d’un cluster Azure Kubernetes Service (AKS)
• Mises à niveau initiées par la plateforme dans AKS
• Mettre à niveau plusieurs clusters AKS par le biais d’Azure Kubernetes Fleet Manager