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.
Remarque
En savoir plus sur notre stratégie de support pour le contrôle de version Kubernetes.
Pour connaître l’historique des versions antérieures, cliquez sur historique Kubernetes.
| Version de K8s | Nexus GA | Fin de vie | Disponibilité étendue |
|---|---|---|---|
| 1,25 | Juin 2023 | Déc. 2023 | Jusqu’à 1.31 en disponibilité générale |
| 1,26 | Sept. 2023 | Mars 2024 | Jusqu’à 1.32 en disponibilité générale |
| 1.27* | Sept. 2023 | Juillet 2024, LTS jusqu’en juillet 2025 | En disponibilité générale jusqu’à 1.33 |
| 1.28 | Nov. 2023 | Octobre 2024 | En disponibilité générale jusqu’à 1.34 |
* 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-2ou 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 :
| Version de Kubernetes | Pack de version | Composants | Composants OS | Changements cassants | Notes |
|---|---|---|---|---|---|
| 1.25.6 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.5.1 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.25.6 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.25.6 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.25.6 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | Les nœuds de cluster sont compatibles avec Azure Arc |
| 1.25.6 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.25.11 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.25.11 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | Les nœuds de cluster sont compatibles avec Azure Arc |
| 1.25.11 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.26.3 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.5.1 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.26.3 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.26.3 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.26.3 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | Les nœuds de cluster sont compatibles avec Azure Arc |
| 1.26.3 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.26.6 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.26.6 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | Les nœuds de cluster sont compatibles avec Azure Arc |
| 1.26.6 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.27.1 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.5.1 |
Azure Linux 2.0 | Cgroupv2 | Les étapes de désactivation de cgroupv2 sont disponibles ici |
| 1.27.1 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | Les étapes de désactivation de cgroupv2 sont disponibles ici |
| 1.27.1 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | Les étapes de désactivation de cgroupv2 sont disponibles ici |
| 1.27.1 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | Les nœuds de cluster sont compatibles avec Azure Arc |
| 1.27.1 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.27.3 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | Les étapes de désactivation de cgroupv2 sont disponibles ici |
| 1.27.3 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | Les nœuds de cluster sont compatibles avec Azure Arc |
| 1.27.3 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.28.0 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | |
| 1.28.0 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Pas de changements cassants | Les nœuds de cluster sont compatibles avec Azure Arc |
| 1.28.0 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Pas de changements cassants |
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 :
| Nouvelle version mineure | Liste des versions prises en charge |
|---|---|
| 1.17.a | 1.17.a, 1.17.b, 1.16.c, 1.16.d, 1.15.e, 1.15.f |
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.
Remarque
Dans des circonstances exceptionnelles, la prise en charge du service Nexus Kubernetes peut être arrêtée tôt ou immédiatement si une vulnérabilité ou une préoccupation de sécurité est identifiée. Microsoft avertit de manière proactive les clients s’il s’agissait d’un problème potentiel et de travailler pour atténuer les éventuels problèmes.
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.
| Catégorie de support | N-2 à N | Disponibilité étendue |
|---|---|---|
| Mises à niveau de N-3 vers une version prise en charge | Pris en charge | Pris en charge |
| Mise à l’échelle du pool de nœuds | Pris en charge | Prise en charge |
| Création d’un cluster ou d’un pool de nœuds | Prise en charge | Prise en charge |
| Composants Kubernetes (y compris les modules complémentaires) | Pris en charge | Non prise en charge |
| Mises à jour de composants | Pris en charge | Non prise en charge |
| Correctifs logiciels de composant | Pris en charge | Non pris en charge |
| Application de correctifs de bogues Kubernetes | Prise en charge | Non pris en charge |
| Application de correctifs de sécurité Kubernetes | Prise en charge | Non pris en charge |
| Correctifs de sécurité des images de nœud | Prise en charge | Non pris en charge |
Remarque
L’Operator Nexus 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. L’Operator Nexus ne peut garantir une prise en charge intégrale que lorsque ces versions sont en cours de maintenance vers une version amont. Plus aucun patch amont n’étant produit, Operator Nexus peut laisser ces versions non corrigées ou les dupliquer. En raison de cette limitation, la disponibilité étendue ne prend pas en charge quoi que ce soit de s’appuyer sur Kubernetes en amont.
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
Support à long terme (LTS)
Azure Kubernetes Service (AKS) fournit une version de support à long terme (LTS) de Kubernetes pendant deux ans. Il n’existe qu’une seule version mineure de Kubernetes considérée comme LTS à la fois.
| Support de la communauté | Prise en charge à long terme | |
|---|---|---|
| Quand utiliser | Quand vous pouvez continuer avec les versions Kubernetes en amont | Scénarios où vos applications ne sont pas compatibles avec les modifications introduites dans les versions de Kubernetes plus récentes et que vous ne pouvez pas passer à un cycle de mise en production continu en raison de contraintes techniques ou d’autres facteurs |
| Versions prises en charge | Trois versions mineures en disponibilité générale | Une version de Kubernetes (actuellement 1.27) pendant deux ans |
La communauté amont conserve une version mineure de Kubernetes pendant un an à compter de la publication. Au terme de cette période, Microsoft crée et applique des mises à jour de sécurité à la version LTS de Kubernetes pour offrir un total de deux ans de support sur AKS.
Important
Kubernetes version 1.27 est la première version LTS prise en charge de Kubernetes sur l’opérateur Nexus Kubernetes service.
FAQ
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 :
- Mise à niveau depuis 1.12.x ->1.13.x.
- 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.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour