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. Récemment, la communauté Kubernetes a prolongé la fenêtre de prise en charge de chaque version de neuf à un an, à compter de la version 1.19.
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.17.7
1.17.8
Chaque chiffre de la version indique la compatibilité générale avec la version précédente :
- Les versions principales changent lorsque des mises à jour incompatibles de l’API ou la compatibilité descendante risquent d’être rompues.
- Les versions mineures changent lorsque des mises à jour de fonctionnalités rétrocompatibles avec les autres versions mineures sont apportées.
- Les versions des patchs changent quand des résolutions de bogues ont une compatibilité descendante.
Essayez d’exécuter la dernière version corrective de la version mineure que vous exécutez. Par exemple, si votre cluster de production est sur 1.17.7, 1.17.8 est la dernière version de correctif disponible pour la série 1.17 . Vous devez effectuer la mise à niveau vers dès 1.17.8 que possible pour vous assurer que votre cluster est entièrement corrigé et pris en charge.
Calendrier des versions d’AKS Kubernetes
Consultez les versions à venir sur le calendrier de publication AKS Kubernetes. 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 état de la version AKS. Pour en savoir plus sur la page web d’état de la mise en production, consultez Suivi de publication AKS.
Notes
AKS assure 12 mois de support pour une version de Kubernetes en disponibilité générale (GA). Pour en savoir plus sur notre politique de support pour le versioning de Kubernetes, consultez nos questions fréquentes (FAQ).
Pour connaître l’historique des versions antérieures, cliquez sur historique Kubernetes.
| Version de K8s | Sortie en amont | Préversion d’AKS | Version GA d’AKS | Fin de vie | Plateforme prise en charge |
|---|---|---|---|---|---|
| 1,26 | Décembre 2022 | Février 2023 | Avril 2023 | Mars 2024 | Jusqu’à 1.30 en disponibilité générale |
| 1.27* | avril 2023 | Juin 2023 | juil. 2023 | Juillet 2024, LTS jusqu’en juillet 2025 | Jusqu’à 1.31 en disponibilité générale |
| 1.28 | Août 2023 | Septembre 2023 | Nov. 2023 | Novembre 2024 | Jusqu’à 1.32 en disponibilité générale |
| 1.29 | Déc. 2023 | Févr. 2024 | Mars 2024 | En disponibilité générale jusqu’à 1.33 | |
| 1.30 | Avril 2024 | Mai 2024 | Juin 2024 | En disponibilité générale jusqu’à 1.34 |
* Indique que la version est désignée pour 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 :
Modifications cassant les composants AKS par version
Notez les modifications importantes suivantes avant de procéder à la mise à niveau vers l'une des versions mineures disponibles :
| Version de Kubernetes | Addons managés AKS | Composants AKS | Composants OS | Changements cassants | Notes |
|---|---|---|---|---|---|
| 1,26 | Azure Policy 1.3.0 Metrics-Server 0.6.3 KEDA 2.10.1 Ouvrir Service Mesh 1.2.3 Core DNS V1.9.4 Superposition VPA 0.11.0 Azure-Keyvault-SecretsProvider 1.4.1 Contrôleur d’entrée Application Gateway (AGIC) 1.5.3 Image Cleaner v1.2.3 Identité de charge de travail Azure v1.0.0 MDC Defender 1.0.56 Identité de pod Azure Active Directory 1.8.13.6 Gitops 1.7.0 KMS 0.5.0 azurefile-csi-driver 1.26.10 |
Cilium 1.12.8 CNI 1.4.44 Cluster Autoscaler 1.8.5.3 |
Image du système d’exploitation Ubuntu 22.04 Cgroups V2 ContainerD 1.7 Azure Linux 2.0 Cgroups V1 ContainerD 1.6 |
azurefile-csi-driver 1.26.10 | Aucun |
| 1,27 % | Azure Policy 1.3.0 azuredisk-csi driver v1.28.5 azurefile-csi driver v1.28.7 blob-csi v1.22.4 csi-attacher v4.3.0 csi-resizer v1.8.0 csi-snapshotter v6.2.2 snapshot-controller v6.2.2 Metrics-Server 0.6.3 Keda 2.11.2 Ouvrir Service Mesh 1.2.3 Core DNS V1.9.4 Superposition VPA 0.11.0 Azure-Keyvault-SecretsProvider 1.4.1 Contrôleur d’entrée Application Gateway (AGIC) 1.7.2 Image Cleaner v1.2.3 Identité de charge de travail Azure v1.0.0 MDC Defender 1.0.56 Identité de pod Azure Active Directory 1.8.13.6 Gitops 1.7.0 azurefile-csi-driver 1.28.7 KMS 0.5.0 CSI Secret store driver 1.3.4-1 |
Cilium 1.13.10-1 CNI 1.4.44 Cluster Autoscaler 1.8.5.3 |
Image du système d’exploitation Ubuntu 22.04 Cgroups V2 ContainerD 1.7 pour Linux et 1.6 pour Windows Azure Linux 2.0 Cgroups V1 ContainerD 1.6 |
Keda 2.11.2 Cilium 1.13.10-1 azurefile-csi-driver 1.28.7 azuredisk-csi driver v1.28.5 blob-csi v1.22.4 csi-attacher v4.3.0 csi-resizer v1.8.0 csi-snapshotter v6.2.2 snapshot-controller v6.2.2 |
En raison de l’état de la certification FIPS Ubuntu 22.04, nous allons basculer les nœuds AKS FIPS de la version 18.04 à la version 20.04 à partir de la version 1.27. |
| 1.28 | Azure Policy 1.3.0 azurefile-csi-driver 1.29.2 csi-node-driver-registrar v2.9.0 csi-livenessprobe 2.11.0 azuredisk-csi-linux v1.29.2 azuredisk-csi-windows v1.29.2 csi-provisioner v3.6.2 csi-attacher v4.5.0 csi-resizer v1.9.3 csi-snapshotter v6.2.2 snapshot-controller v6.2.2 Metrics-Server 0.6.3 KEDA 2.11.2 Open Service Mesh 1.2.7 Core DNS V1.9.4 Superposition VPA 0.13.0 Azure-Keyvault-SecretsProvider 1.4.1 Contrôleur d’entrée Application Gateway (AGIC) 1.7.2 Image Cleaner v1.2.3 Azure Workload Identity v1.2.0 MDC Defender Security Publisher 1.0.68 CSI Secret store driver 1.3.4-1 MDC Defender Old File Cleaner 1.3.68 MDC Defender Pod Collector 1.0.78 MDC Defender Low Level Collector 1.3.81 Identité de pod Azure Active Directory 1.8.13.6 GitOps 1.8.1 |
Cilium 1.13.10-1 CNI v1.4.43.1 (par défaut)/v1.5.11 (superposition Azure CNI) Cluster Autoscaler 1.27.3 Tigera-Operator 1.28.13 |
Image du système d’exploitation Ubuntu 22.04 Cgroups V2 ContainerD 1.7.5 pour Linux et 1.7.1 pour Windows Azure Linux 2.0 Cgroups V1 ContainerD 1.6 |
azurefile-csi-driver 1.29.2 csi-resizer v1.9.3 csi-attacher v4.4.2 csi-provisioner v4.4.2 blob-csi v1.23.2 azurefile-csi driver v1.29.2 azuredisk-csi driver v1.29.2 csi-livenessprobe v2.11.0 csi-node-driver-registrar v2.9.0 |
Aucun |
| 1.29 | Azure Policy 1.3.0 csi-provisioner v4.0.0 csi-attacher v4.5.0 csi-snapshotter v6.3.3 snapshot-controller v6.3.3 Metrics-Server 0.6.3 KEDA 2.11.2 Open Service Mesh 1.2.7 Core DNS V1.9.4 Superposition VPA 0.13.0 Azure-Keyvault-SecretsProvider 1.4.1 Contrôleur d’entrée Application Gateway (AGIC) 1.7.2 Image Cleaner v1.2.3 Azure Workload Identity v1.2.0 MDC Defender Security Publisher 1.0.68 MDC Defender Old File Cleaner 1.3.68 MDC Defender Pod Collector 1.0.78 MDC Defender Low Level Collector 1.3.81 Identité de pod Azure Active Directory 1.8.13.6 GitOps 1.8.1 CSI Secret store driver 1.3.4-1 azurefile-csi-driver 1.29.3 |
Cilium 1.13.5 CNI v1.4.43.1 (par défaut)/v1.5.11 (superposition Azure CNI) Cluster Autoscaler 1.27.3 Tigera-Operator 1.30.7 |
Image du système d’exploitation Ubuntu 22.04 Cgroups V2 ContainerD 1.7.5 pour Linux et 1.7.1 pour Windows Azure Linux 2.0 Cgroups V1 ContainerD 1.6 |
Tigera-Operator 1.30.7 csi-provisioner v4.0.0 csi-attacher v4.5.0 csi-snapshotter v6.3.3 snapshot-controller v6.3.3 |
Aucun |
Version mineure de l’alias
Notes
La version mineure de l’alias nécessite Azure CLI version 2.37 ou ultérieure, ainsi que la version d’API 20220401 ou ultérieure. Utilisez az upgrade pour installer la dernière version de la CLI.
AKS vous permet de créer un cluster sans spécifier la version exacte du 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.21, votre cluster exécute 1.21.7, qui est la dernière version du correctif en disponibilité générale (1.21). Si vous souhaitez mettre à niveau votre version corrective dans la même version mineure, utilisez 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.21.7",
}
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. Il prend en charge trois versions mineures GA de Kubernetes :
- La dernière version mineure en disponibilité générale publiée dans AKS (que nous appelons N).
- Deux versions mineures précédentes.
- Chaque version mineure prise en charge gère également deux correctifs stables au maximum.
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 plateforme de prise en charge de la fenêtre des versions de Kubernetes sur AKS est appelée « N-3 ». Pour plus d’informations, consultez politique de support.
Notes
AKS applique des pratiques de déploiement sécurisé qui impliquent un déploiement graduel des régions. Par conséquent, la mise à disposition d’une nouvelle version dans toutes les régions peut prendre jusqu’à 10 jours ouvrables.
La fenêtre prise en charge des versions de Kubernetes sur AKS est appelée « N-2 » : (N (dernière publication) - 2 (versions mineures)), et « .lettre » représente les versions correctives.
Par exemple, si AKS 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 et les publications des correctifs les plus anciennes prises en charge sont déconseillées et mises hors service. Par exemple, disons que 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 AKS publie la version 1.18.*, toutes les versions 1.15.* ne sont plus prises en charge 30 jours plus tard.
AKS prend en charge au maximum deux versions correctives d’une version mineure donnée. Par exemple, étant donné les versions supportées suivantes :
Current Supported Version List
------------------------------
1.17.8, 1.17.7, 1.16.10, 1.16.9
Si AKS publie les versions 1.17.9 et 1.16.11, les versions correctives les plus anciennes sont dépréciées et supprimées, et la liste des versions prises en charge devient :
New Supported Version List
----------------------
1.17.*9*, 1.17.*8*, 1.16.*11*, 1.16.*10*
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. Toutefois, pendant la mise en production de la version 1.30 en disponibilité générale, la version 1.26 sera automatiquement mise à niveau vers la version 1.27. Si vous exécutez une version n-2, au moment où elle devient n-3, elle devient également dépréciée et vous entrez dans la stratégie de prise en charge 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 patch 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 aucun élément en charge s’appuyant sur 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.
| Catégorie de support | Support de la communauté (N-2) | Plateforme prise en charge (N-3) |
|---|---|---|
| Mises à niveau de N-3 vers une version prise en charge | Pris en charge | Prise en charge |
| Disponibilité de la plateforme (Azure) | Pris en charge | Pris en charge |
| Mise à l’échelle du pool de nœuds | Pris en charge | Prise en charge |
| Disponibilité des machines virtuelles | Prise en charge | Prise en charge |
| Problèmes liés au stockage et à la mise en réseau | Pris en charge | Pris en charge à l’exception des correctifs de bogues et des composants mis hors service |
| Démarrer/arrêter | Prise en charge | Pris en charge |
| Effectuer une rotation des certificats | Pris en charge | Pris en charge |
| Infrastructure SLA | Prise en charge | Pris en charge |
| Plan de contrôle SLA | Pris en charge | Pris en charge |
| Plateforme (AKS) SLA | Pris en charge | Non 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 prise en charge |
| Application de correctifs de bogues | Pris en charge | Non prise en charge |
| Application de correctifs de sécurité | Pris en charge | Non prise en charge |
| Support d’API Kubernetes | Pris en charge | Non prise en charge |
| Création d’un cluster ou d’un pool de nœuds | Pris en charge | Non prise en charge |
| Instantané des pools de nœuds | Pris en charge | Non prise en charge |
| Mise à niveau d’image de nœud | Prise en charge | Non pris en charge |
Notes
Le tableau ci-dessus est susceptible d’être modifié et décrit les scénarios de support courants. Les scénarios liés aux fonctionnalités et aux composants Kubernetes ne sont pas pris en charge pour N-3. Pour plus d’informations sur la prise en charge, consultez Support et résolution des problèmes pour AKS.
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)
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.
Pour plus d’informations sur LTS, consultez Support à 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 publie une annonce avec la date prévue d’une nouvelle version et la dépréciation de l’ancienne version correspondante 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.
Notes
Pour savoir qui sont les administrateurs de votre abonnement ou pour les modifier, consultez Gérer les 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. Toutefois, il surveille et valide constamment les correctifs CVE disponibles pour les prendre en charge en temps utile. 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 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 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
Quand vous déployez un cluster AKS avec le portail Azure, Azure CLI ou Azure PowerShell, le cluster est toujours défini par défaut sur la version mineure n-1 et le dernier patch. Par exemple, si AKS prend en charge 1.17.a, 1.17.b, 1.16.c, 1.16.d, 1.15.e et 1.15.f, la version sélectionnée par défaut est 1.16.c.
Pour savoir quelles sont les versions disponibles pour vos abonnement et région, utilisez la commande az aks get-versions. L’exemple suivant répertorie les versions Kubernetes disponibles pour la région EastUS :
az aks get-versions --location eastus --output table
Forum aux questions
Comment Microsoft m’informe-t-il des nouvelles versions de Kubernetes ?
L’équipe AKS publie des annonces avec les dates prévues des nouvelles versions de Kubernetes dans notre documentation, notre GitHub et dans des e-mails adressés aux administrateurs d’abonnements qui détiennent des clusters qui ne vont plus être pris en charge. 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 ?
À compter de Kubernetes 1.19, la communauté open source a étendu la durée de prise en charge à une année. 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, vous êtes hors support et il vous sera demandé d’effectuer une mise à niveau. 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. Par exemple :
- Si la plus ancienne version d’AKS prise en charge est 1.15.a et que vous utilisez la version 1.14.b ou une version antérieure, vous êtes hors support.
- Une fois la mise à niveau de la version 1.14.b à la version 1.15.a ou à une version ultérieure réussie, vous bénéficierez à nouveau de 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 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.
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 ne bénéficie plus du support depuis plus de trois (3) versions mineures et se révèle présenter des risques de sécurité, Azure vous contactera pour mettre à niveau votre cluster de manière proactive. À 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 d’asymétrie de version permet désormais une différence de 3 versions maximales 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 ?
Quand 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.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.
Vous pouvez ignorer plusieurs versions seulement quand vous mettez à niveau une version non prise en charge vers la version minimale prise en charge. Par exemple, vous pouvez mettre à niveau une version 1.10.x non prise en charge vers une version 1.15.x prise en charge si 1.15 est la version mineure minimale prise en charge.
Lors de l’exécution d’une mise à niveau à partir d’une version non prise en charge qui ignore au moins deux versions mineures, 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 possibilité de découpler les mises à niveau du plan de contrôle avec les mises à niveau du pool de nœuds. Cependant, si votre version est considérablement obsolète, nous vous recommandons de recréer le cluster.
Puis-je créer un nouveau cluster 1.xx.x pendant la période 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. Quand la modification est déployée, l’ancienne version est supprimée de votre liste de versions. Ce processus peut durer jusqu’à deux semaines à partir de l’annonce et s’effectue progressivement par région.
Je travaille sur une version désormais déconseillée, puis-je toujours ajouter de nouveaux pools de nœuds ? Ou une mise à niveau est-elle nécessaire ?
Non. Vous n’êtes pas autorisé à ajouter des pools de nœuds de la version déconseillée à votre cluster. La création ou la mise à niveau de pools de nœuds jusqu’à la version non prise en charge de la version du plan de contrôle est autorisée, quelle que soit la différence de version entre le pool de nœuds et le plan de contrôle. Seules les mises à niveau mineures d’alias sont autorisées.
Quelle est la fréquence de mise à jour des correctifs ?
Les correctifs ont un cycle de vie minimal de deux mois. Pour vous tenir informé quand de nouveaux correctifs sont publiés, suivez les notes de publication AKS.
Étapes suivantes
Pour plus d’informations sur la mise à niveau de votre cluster, consultez :