Versions de Kubernetes prises en charge dans le service d’Azure Operator Nexus Kubernetes

Ce document fournit une vue d’ensemble du schéma de contrôle de version utilisé pour le service Kubernetes Nexus Operator, y compris les versions de Kubernetes prises en charge. Il explique les différences entre les versions majeures, mineures et correctives, et fournit des conseils sur la mise à niveau des versions de Kubernetes et sur l’expérience de mise à niveau. Le document couvre également le cycle de vie et la fin de vie de la prise en charge des versions pour chaque version mineure de Kubernetes.

La communauté Kubernetes publie des versions mineures à peu près tous les trois mois. À compter de la version 1.19, la communauté Kubernetes a prolongé la fenêtre de prise en charge de chaque version de neuf à un an.

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.24.7
  1.25.4

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

• Les numéros de version majeurs changent lorsque des modifications cassants apportées à l’API peuvent être introduites
• Les numéros de versions mineures changent lorsque des mises à jour de fonctionnalités rétrocompatibles avec les autres versions mineures sont apportées.
• Les numéros de versions des patchs changent quand des résolutions de bogues ont une compatibilité descendante.

Nous vous recommandons vivement de rester à jour avec les derniers correctifs disponibles. Par exemple, si votre cluster de production est sur 1.25.4, 1.25.6 est la dernière version de correctif disponible pour la série 1.25 . Vous devez effectuer la mise à niveau vers dès 1.25.6 que possible pour vous assurer que votre cluster est entièrement corrigé et pris en charge. Pour plus d’informations sur la mise à niveau de votre cluster, consultez la documentation sur la Mise à niveau des versions de Kubernetes.

Calendrier des versions de Nexus Kubernetes

Consultez les versions à venir sur le calendrier de publication Nexus Kubernetes.

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

* Indique que la version est désignée pour la prise en charge à long terme

Composants de version du service Nexus Kubernetes

Une version du service Operator Nexus Kubernetes est constituée de deux composants discrets qui sont combinés en une seule représentation :

• La version Kubernetes. Par exemple, la version 1.25.4 est la version de Kubernetes que vous déployez dans Operator Nexus. Ces packages sont fournis par Azure AKS, y compris toutes les versions correctives prises en charge par Operator Nexus. Pour plus d’informations sur les versions d’Azure AKS, consultez les versions Kubernetes prises en charge par AKS
• Le pack de versions, qui encapsule les fonctionnalités (modules complémentaires) et l’image du système d’exploitation utilisée par les nœuds dans le cluster Operator Nexus Kubernetes, sous la forme d’un seul nombre. Par exemple, « 2 ». La combinaison de ces valeurs est représentée dans l’API en tant que version unique de Kubernetes. Par exemple, 1.25.4-2 ou la notation « v » alternativement prise en charge : v1.25.4-2.

Packs de versions

En étendant la version de Kubernetes afin d’inclure une valeur secondaire pour la version corrective, les packs de versions, le service Operator Nexus Kubernetes peut tenir compte des cas où le déploiement est modifié pour inclure des mises à jour supplémentaires liées au système d’exploitation. Ces mises à jour peuvent inclure, mais ne sont pas limitées à : les images du système d’exploitation mises à jour, les mises à jour correctives pour les fonctionnalités (modules complémentaires) et ainsi de suite. Les packs de versions sont toujours rétrocompatibles avec les packs antérieurs dans la même version corrective, par exemple, la version 1.25.4-2 est à rétrocompatible avec la version 1.25.4-1.

Les modifications apportées à la configuration d’un cluster Operator Nexus Kubernetes déployé ne doivent être appliquées qu’au sein d’une mise à niveau de version mineure Kubernetes, et non lors d’une mise à niveau de version corrective. Voici quelques exemples de modifications de configuration qui peuvent être appliquées pendant la mise à niveau de version mineure :

• Modification de la configuration du kube-proxy avec des iptables en ipvs
• Modification du CNI d’un produit à un autre

Lorsque nous suivons ces principes, il devient plus facile de prédire et de gérer le processus de déplacement entre différentes versions des clusters Kubernetes proposés par le service Operator Nexus Kubernetes.

Nous pouvons facilement effectuer une mise à niveau à partir de n’importe quelle petite mise à jour dans une version Kubernetes vers une petite mise à jour dans la version suivante, ce qui vous offre une flexibilité. Par exemple, une mise à niveau de 1.24.1-x à 1.25.4-x est autorisée, quelle que soit la présence d’une version intermédiaire 1.24.2-x.

Versions des composants et changements cassants

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

Fonctionnalités du pack de versions

Mise à niveau des versions de Kubernetes

Pour plus d’informations sur la mise à niveau de votre cluster, consultez Mettre à niveau un cluster Azure Operator Nexus Kubernetes Service.

Stratégie de prise en charge des versions de Kubernetes

L’Operator Nexus prend en charge trois versions mineures de Kubernetes :

• La dernière version mineure en disponibilité générale publiée dans Operator Nexus (que nous appelons N).
• Deux versions mineures précédentes.
  • Chaque version mineure prise en charge prend également en charge un maximum de deux derniers correctifs stables tandis que les correctifs précédents sont sous stratégie de disponibilité étendue pour la durée de vie de la version mineure.

Les services Operator Nexus Kubernetes fournit une durée standardisée de prise en charge pour chaque version mineure de Kubernetes publiée. Les versions respectent deux chronologies différentes, reflétant :

• Durée de prise en charge : durée de maintenance active d’une version. À la fin de la période prise en charge, la version est « Fin de vie ».
• Disponibilité étendue : durée de sélection d’une version pour le déploiement après « Fin de vie ».

La fenêtre prise en charge des versions de Kubernetes sur Operator Nexus est appelée « N-2 » : (N (dernière publication) - 2 (versions mineures)), et « .lettre » représente les versions correctives.

Par exemple, si Operator Nexus introduit 1.17.a aujourd’hui, une prise en charge est assurée pour les versions suivantes :

Quand une nouvelle version mineure est introduite, la version mineure qui est prise en charge et les publications des correctifs les plus anciennes ne sont plus prises en charge. Par exemple, si la liste des versions actuellement prises en charge est :

1.17.a
1.17.b
1.16.c
1.16.d
1.15.e
1.15.f

Lorsque l’Operator Nexus publie la version 1.18.*, toutes les versions 1.15.* sortent de la prise en charge.

Chronologie de prise en charge

Les services Operator Nexus Kubernetes prend en charge 12 mois à partir de la version générale AKS initiale d’une version mineure généralement. Cette chronologie suit le minutage d’Azure AKS, qui inclut une prise en charge à long terme déclarée version 1.27.

Versions prises en charge :

• Peut être déployé en tant que nouveaux clusters Operator Nexus Kubernetes.
• Il peut s’agir de la cible des mises à niveau à partir des versions antérieures. Limité par les chemins de mise à niveau normaux.
• Peut avoir des correctifs supplémentaires ou des bundles de versions dans la version mineure.

Fin de vie

Fin de vie (EOL) signifie qu’aucun ensemble de correctifs ou de versions n’est produit. Il est possible que le cluster que vous avez configuré ne puisse plus être mis à niveau, car les dernières versions prises en charge ne sont plus disponibles. Dans ce cas, la seule façon de procéder à la mise à niveau consiste à recréer complètement le cluster Nexus Kubernetes à l’aide de la version plus récente prise en charge. Les mises à niveau Extended availability non prises en charge peuvent être utilisées pour revenir à une version prise en charge.

Stratégie de disponibilité étendue

Pendant la période de disponibilité étendue pour les versions Kubernetes non prises en charge (c’est-à-dire les versions de Kubernetes EOL), les utilisateurs ne reçoivent pas de correctifs de sécurité ni de correctifs de bogues. Pour plus d’informations sur les catégories de support, reportez-vous au tableau suivant.

Clusters Kubernetes Nexus abandonnés

Après la fin de la période de disponibilité prolongée, la version K8s est complètement supprimée de Nexus. À ce stade, tous les clusters Kubernetes Nexus existants basés sur cette version K8s seront abandonnés. La seule opération prise en charge sur les clusters abandonnés est la suppression. Il est important de noter qu’une fois qu’un cluster est abandonné, la mise à niveau vers une version ultérieure de K8s ne fonctionnera pas.

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 vous avez la version 1.17 de kube-apiserver, vous pouvez utiliser les versions 1.16 à 1.18 de kubectl.

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)

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 publication de nouvelles versions vous offre d’énormes avantages, cela complique la mise à jour des versions de Kubernetes, et plus encore en fonction du nombre de clusters que vous devez maintenir.

Types de support

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.

Migrer vers la prochaine version LTS

Les clusters Nexus Kubernetes ne prennent pas en charge les mises à niveau directes entre les versions LTS. Pour passer d’une version LTS à la suivante, vous avez deux options : créer un cluster avec la version LTS souhaitée et déplacer vos charges de travail vers ce nouveau cluster, ou effectuer une série de mises à niveau intermédiaires via les versions prises en charge avant d’atteindre la prochaine version LTS.

Forum aux questions

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

Ce document est mis à jour régulièrement avec des dates planifiées des nouvelles versions de Kubernetes.

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

À compter de Kubernetes 1.19, la communauté open source a étendu la durée de prise en charge à une année. L’Operator Nexus s’engage à activer les correctifs et à prendre en charge le respect des engagements en amont. Pour les clusters l’Operator Nexus 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 êtes sur la version N-3 ou une version antérieure, vous êtes en dehors de la fenêtre de support. Lorsque vous effectuez une mise à niveau de la version N-3 vers N-2, vous revenez dans notre fenêtre de support. Par exemple :

• Si la plus ancienne version d’AKS prise en charge est 1.25.x et que vous utilisez la version 1.24.x ou une version antérieure, vous êtes hors support.
• La mise à niveau réussie de la version 1.24.x vers la version 1.25.x ou ultérieure vous ramène dans notre fenêtre de support.
• Les « mises à niveau de niveau skip » ne sont pas prises en charge. Pour effectuer une mise à niveau de la version 1.23.x vers la version 1.25.x, vous devez d’abord effectuer une mise à niveau vers la version 1.24.x, puis vers 1.25.x.

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

Que se passe-t-il si je ne mets à niveau mon cluster ?

Si vous ne mettez pas à niveau votre cluster, vous continuez à recevoir la prise en charge de la version Kubernetes que vous exécutez jusqu’à la fin de la période de prise en charge. Après cela, vous ne recevrez plus de prise en charge pour votre cluster. Vous devez mettre à niveau votre cluster vers une version prise en charge pour continuer à recevoir la prise en charge.

Que se passe-t-il si je ne mets pas à niveau mon cluster avant la fin de la période de disponibilité étendue ?

Si vous ne mettez pas à niveau votre cluster avant la fin de la période de disponibilité étendue, vous ne pourrez plus mettre à niveau votre cluster vers une version prise en charge ou des pools d’agents Scale-out. Vous devez recréer votre cluster à l’aide d’une version prise en charge pour continuer à recevoir la prise 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 êtes invité à mettre à niveau le cluster vers une version prise en charge lors de la demande de prise en charge.

Par ailleurs, Operator Nexus 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 quand un utilisateur fait évoluer (scaling) un cluster Kubernetes avec une version mineure non prise en charge ?

Pour les versions mineures non prises en charge par l’Operator Nexus, 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 ignorer plusieurs versions de Kubernetes durant la mise à niveau d’un cluster ?

Lorsque vous mettez à niveau un cluster Operator Nexus Kubernetes 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.12.x ->1.13.x : autorisées.
• 1.13.x ->1.14.x : autorisées.
• 1.12.x ->1.14.x : non autorisées.

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.

Puis-je créer un cluster pendant sa fenêtre de disponibilité étendue ?

Oui, vous pouvez créer un cluster 1.xx.x pendant sa fenêtre de disponibilité étendue. Toutefois, nous vous recommandons de créer un cluster avec la dernière version prise en charge.

Puis-je mettre à niveau un cluster vers une version plus récente pendant sa fenêtre de disponibilité étendue ?

Oui, vous pouvez mettre à niveau un cluster N-3 vers N-2 pendant sa fenêtre de disponibilité étendue. Si votre cluster est actuellement sur N-4, vous pouvez utiliser la disponibilité étendue pour commencer la mise à niveau de N-4 vers N-3, puis passer à la mise à niveau vers une version prise en charge (N-2).

Je suis sur une fenêtre de disponibilité étendue, puis-je toujours ajouter de nouveaux pools de nœuds ? Ou une mise à niveau est-elle nécessaire ?

Oui, vous êtes autorisé à ajouter des pools de nœuds au cluster.