Lire en anglais

Partager via

Versions de Kubernetes prises en charge dans AKS Arc

  • Article

Cet article décrit les versions de Kubernetes prises en charge pour Azure Kubernetes Service activé par Azure Arc. AKS Arc publie de nouvelles versions mineures de Kubernetes environ tous les trois mois.

Version de Kubernetes

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

Output 
[major].[minor].[patch]

Example:
  1.29.2
  1.29.5

Chaque chiffre de la version indique la compatibilité générale avec la version précédente :

  • Les versions majeures changent lorsque des mises à jour d'API incompatibles ou une rétrocompatibilité peuvent être rompues.
  • Les versions mineures changent lorsque des mises à jour de fonctionnalités sont effectuées et qu'elles sont rétrocompatibles avec les autres versions mineures.
  • Les versions des patches changent lorsque des corrections de bogues rétrocompatibles sont apportées.

Vous devez installer la dernière version de patches de la version mineure que vous exécutez. Par exemple, supposez que votre cluster de production est sur 1.29.2. 1.29.5est la dernière version de patch disponible pour la série 1.29, vous devez mettre à niveau vers la version 1.29.5 dès que possible pour vous assurer que votre cluster Kubernetes est entièrement patché et pris en charge.

Calendrier de publication des versions de Kubernetes par AKS Arc.

Version mineure de K8s Versions locales Azure supportées Statut actuel Dernière version avec les mises à jour de patchs/CVE de Kubernetes
1,30 TBD À venir TBD
1.29 2411, 2408 Mise à la disposition générale TBD
1.28 2411, 2408, 2405 Mise à la disposition générale TBD
1,27 % 2411, 2408, 2405, 2402 Mise à la disposition générale Version 2411
1,26 2405, 2402 et versions antérieures Plus de versions patchées/mises à jour CVE Version 2405

AKS Arc prend en charge les versions mineures et correctives de Kubernetes par mise à jour

Libérer Versions mineures et correctifs
2411 1.27.7, 1.27.9, 1.28.5, 1.28.9, 1.29.2, 1.29.4
2408 1.27.7, 1.27.9, 1.28.5, 1.28.9, 1.29.2, 1.29.4
2405 1.26.10, 1.26.12, 1.27.7, 1.27.9, 1.28.3, 1.28.5

Stratégie de prise en charge des versions de Kubernetes

AKS définit une version généralement disponible (GA) comme une version disponible au téléchargement lors du déploiement ou de la mise à jour d'AKS activé par Arc. AKS prend en charge trois versions mineures GA de Kubernetes :

  • La dernière version mineure de l'AG publiée pour AKS (appelée N).
  • Deux versions mineures précédentes. Chaque version mineure prise en charge prend également en charge les patches stables.

AKS pourrait également prendre en charge des versions d'aperçu, qui sont explicitement étiquetées comme des aperçus.

Notes

AKS applique des pratiques de déploiement sécurisé qui impliquent un déploiement graduel des régions. Cela signifie qu'il peut s'écouler jusqu'à 10 jours ouvrables avant qu'une nouvelle version soit disponible dans toutes les régions.

La fenêtre prise en charge des versions de Kubernetes sur AKS est connue sous le nom de « N-2 » : (N (dernière version) – 2 (versions mineures)).

Par exemple, si AKS introduit aujourd'hui la version 1.30, le support est assuré pour les versions suivantes :

Nouvelle version mineure Liste des versions prises en charge
1,30 1.30, 1.29, 1.28

Quand une nouvelle version mineure est introduite, la version mineure et les publications des correctifs les plus anciennes prises en charge sont déconseillées et mises hors service. Par exemple, si la liste des versions actuellement prises en charge est :

  • 1.29
  • 1.28
  • 1,27 %

Lorsque AKS publie la version 1.30.*, toutes les versions 1.27.* sont supprimées et cessent d'être prises en charge dans les 30 jours.

Notes

Si vous exécutez une version de Kubernetes non prise en charge, il vous est demandé de la mettre à niveau lors de la requête de prise en charge du cluster. Les clusters exécutant des versions de Kubernetes non supportées ne sont pas couverts par les politiques de support AKS.

En plus de cette stratégie, AKS prend en charge un maximum de deux versions de patches d'une version mineure donnée. Compte tenu des versions prises en charge suivantes :

Output 
Current Supported Version List
------------------------------
1.29.8, 1.29.7, 1.28.10, 1.28.9

Si AKS publie les versions 1.29.9 et 1.28.11, les versions de patches les plus anciennes sont obsolètes et supprimées, et la liste des versions prises en charge devient :

Output 
New Supported Version List
----------------------
1.29.*9*, 1.29.*8*, 1.28.*11*, 1.28.*10*

Versions de kubectl prises en charge

Vous pouvez utiliser une version mineure de kubectl plus ancienne ou plus récente que votre version de kube-apiserver, conforme à la stratégie de prise en charge de Kubernetes pour kubectl.

Par exemple, si votre kube-apiserver est à la version 1.17, vous pouvez utiliser les versions 1.16 à 1.18 de kubectl avec ce kube-apiserver. Pour installer ou mettre à jour votre version de kubectl, exécutez az aks install-cli.

Processus de publication et de dépréciation

Pour les nouvelles versions mineures de Kubernetes :

  • AKS publie une pré-annonce avec la date prévue de la sortie d'une nouvelle version et de l'obsolescence de l'ancienne version dans les notes de version d'AKS au moins 30 jours avant le retrait.
  • Les utilisateurs ont 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.
  • En général, AKS ne communique pas beaucoup lors de la publication de nouvelles versions correctives. Toutefois, il surveille et valide constamment les correctifs CVE disponibles pour les prendre en charge en temps utile. Si un patch critique est trouvé ou si une action de l'utilisateur est requise, AKS notifie les utilisateurs pour qu'ils effectuent une mise à niveau vers le nouveau patch disponible.
  • Les utilisateurs disposent de 30 jours à compter du retrait d'une version de correctif d'AKS pour mettre à niveau vers un correctif pris en charge et continuer à bénéficier de l'assistance.

Exceptions de la stratégie de version prise en charge

AKS se réserve le droit d'ajouter ou de supprimer de nouvelles versions ou des versions existantes avec une ou plusieurs productions critiques ayant un impact sur des bogues ou des problèmes de sécurité sans préavis.

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

Questions fréquentes (FAQ)

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

L'équipe d'AKS publie des pré-annonces avec les dates prévues des nouvelles versions de Kubernetes dans la documentation de l'Arc AKS.

À 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 Kubernetes sur 1.19 et plus, vous pourrez effectuer une mise à niveau au minimum une fois par an pour rester sur une version prise en charge.

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

Si vous êtes sur la version n-3 ou plus ancienne, cela signifie que vous n'êtes plus supporté et qu'il vous est demandé de faire une mise à jour. Une fois votre mise à niveau de la version n-3 à la version n-2 réussie, vous bénéficierez à nouveau de nos stratégies de support. Exemple :

  • Si la plus ancienne version de Kubernetes prise en charge est la version 1.27 et que vous êtes sur la version 1.26 ou une version plus ancienne, vous n'êtes plus pris en charge.
  • Lorsque vous passez avec succès de la version 1.26 à la version 1.27 ou à une version supérieure, vous revenez dans la fenêtre de support.

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

Que signifie l'expression « hors support » ?

L'expression « hors support » 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 lors de la demande d'assistance, sauf si vous êtes dans la période de grâce de 30 jours après la dépréciation de la version.

De plus, AKS ne donne aucune garantie de durée d'exécution (ou autre) pour les clusters en dehors de la liste des versions prises en charge.

Que se passe-t-il lorsque je mets à l'échelle 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.

Puis-je sauter plusieurs versions de Kubernetes lors d'une mise à niveau du cluster ?

Quand vous mettez à niveau un cluster AKS pris en charge, les versions mineures de Kubernetes ne peuvent pas être ignorées. Par exemple, les mises à niveau entre :

  • 1.12.x ->1.13.x : autorisé.
  • 1.13.x ->1.14.x : autorisé.
  • 1.12.x ->1.14.x: non autorisé.

Pour effectuer une mise à niveau depuis 1.12.x ->1.14.x :

  1. Mise à niveau depuis 1.12.x ->1.13.x.
  2. Mise à niveau depuis 1.13.x ->1.14.x.

Vous ne pouvez sauter plusieurs versions que lors de la mise à niveau d'une version non prise en charge vers une version prise en charge. Par exemple, vous pouvez mettre à niveau à partir d'une version 1.10.x non prise en charge vers une version 1.15.x prise en charge.

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

Non. Une fois qu'une version est déconseillée/supprimée, il n'est plus possible de créer de cluster avec cette version. Au fur et à mesure que la modification est apportée, l'ancienne version est supprimée de votre liste de versions. Ce processus peut prendre jusqu'à deux semaines à compter de l'annonce, progressivement par région.

Je suis sur une version fraîchement obsolescente. Puis-je encore ajouter de nouveaux pools de nœuds ou dois-je procéder à une mise à niveau ?

Non. Vous ne pouvez pas ajouter à votre cluster des pools de nœuds provenant d'une version obsolète.

Étapes suivantes

Pour plus d'informations sur la mise à niveau de votre cluster, voir Mettre à jour la version Kubernetes des clusters AKS.