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.
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.29.2
1.29.1
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.29.1 et que 1.29.2 est la dernière version du correctif disponible pour la version mineure 1.29, vous devez effectuer une mise à niveau vers 1.29.2 dès 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.28 | Août 2023 | Septembre 2023 | Nov. 2023 | Janvier 2025 | Jusqu’à 1.32 en disponibilité générale |
| 1.29 | Déc. 2023 | Févr. 2024 | Mars 2024 | Mars 2025 | En disponibilité générale jusqu’à 1.33 |
| 1.30 | Avril 2024 | Juin 2024 | Juil. 2024 | Juillet 2025 | En disponibilité générale jusqu’à 1.34 |
| 1,31 | Août 2024 | Octobre 2024 | Novembre 2024 | Novembre 2025 | En disponibilité générale jusqu’à 1.35 |
| 1.32 | Décembre 2024 | Février 2025 | Mars 2025 | Mars 2026 | Disponibilité générale jusqu’à 1.36 |
LTS Versions
| Version de K8s | Sortie en amont | Préversion d’AKS | Version GA d’AKS | Fin de vie | Fin de vie LTS |
|---|---|---|---|---|---|
| 1,27 % | Avril 2023 | Juin 2023 | Juillet 2023 | Juil. 2024 | Juillet 2025 |
| 1.30 | Avril 2024 | Juin 2024 | Juil. 2024 | Juillet 2025 | Juillet 2026 |
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 cassantes 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.30
| Modules complémentaires gérés par AKS | Composants AKS | Composants OS | Dernières modifications | Notes |
|---|---|---|---|---|
| • Azure Policy 1.3.0 • cloud-provider-node-manager v1.30.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.14.0 • 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 • Identité Azure Workload 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 • Azure Active Directory Pod Identity 1.8.13.6 • GitOps 1.8.1 • CSI Secrets 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 (Azure CNI Overlay) • Cluster Autoscaler 1.27.3 • Tigera-Operator 1.30.7 |
• OS Image Ubuntu 22.04 Cgroups V2 • ContainerD 1.7.5 pour Linux et 1.7.1 pour Windows • Azure Linux 2.0 • Cgroups V2 • ContainerD 1.6 |
• KEDA 2.14.1 | S/O |
Kubernetes 1.29
| Modules complémentaires gérés par AKS | Composants AKS | Composants OS | Dernières modifications | Notes |
|---|---|---|---|---|
| • 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 • Identité Azure Workload 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 • Azure Active Directory Pod Identity 1.8.13.6 • GitOps 1.8.1 • CSI Secrets 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 (Azure CNI Overlay) • Cluster Autoscaler 1.27.3 • Tigera-Operator 1.30.7 |
• OS Image Ubuntu 22.04 Cgroups V2 • ContainerD 1.7.5 pour Linux et 1.7.1 pour Windows • Azure Linux 2.0 • Cgroups V2 • 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 |
S/O |
Kubernetes 1.28
| Modules complémentaires gérés par AKS | Composants AKS | Composants OS | Dernières modifications | Notes |
|---|---|---|---|---|
| • 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 • Identité Azure Workload v1.2.0 • MDC Defender Security Publisher 1.0.68 • CSI Secrets 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 • Azure Active Directory Pod Identity 1.8.13.6 • GitOps 1.8.1 |
• Cilium 1.13.10-1 • CNI v1.4.43.1 (par défaut)/v1.5.11 (Azure CNI Overlay) • Cluster Autoscaler 1.27.3 • Tigera-Operator 1.28.13 |
• OS Image 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 |
S/O |
Kubernetes 1.27
| Modules complémentaires gérés par AKS | Composants AKS | Composants OS | Dernières modifications | Notes |
|---|---|---|---|---|
| • Azure Policy 1.3.0 • azuredisk-csi driver v1.28.5 • azurefile-csi driver v1.28.10 • 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 • Open 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é Azure Workload v1.0.0 • MDC Defender 1.0.56 • Azure Active Directory Pod Identity 1.8.13.6 • GitOps 1.7.0 • azurefile-csi-driver 1.28.7 • KMS 0.5.0 • CSI Secrets Store Driver 1.3.4-1 |
• Cilium 1.13.10-1 • CNI 1.4.44 • Cluster Autoscaler 1.8.5.3 |
• OS Image 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. |
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.29 que 1.29.2 est le dernier correctif en disponibilité générale disponible, votre cluster sera créé avec 1.29.2. 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.29.2",
}
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 peut prendre en charge n’importe quel nombre de patchs à un moment donné. AKS se réserve le droit de déprécier des patchs si une vulnérabilité CVE ou de sécurité critique est détectée. Pour connaître la disponibilité des patchs et la dépréciation ad hoc, reportez-vous aux notes de publication des versions et visitez la page web des états de publication 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 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 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 :
| Nouvelle version mineure | Liste de versions mineures prises en charge |
|---|---|
| 1.29 | 1.29, 1.28, 1.27 |
Quand une nouvelle version mineure est introduite, la version mineure la plus ancienne est déconseillée et supprimée. Par exemple, disons que la liste des versions mineures actuellement prises en charge est :
1.29
1.28
1.27
Lorsque AKS publie la version 1.30, toutes les versions 1.27. ne seront plus prises en charge 30 jours plus tard.
AKS peut prendre en charge un certain nombre de patchs en fonction de la disponibilité des versions de 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 à toujours utiliser le dernier patch 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 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 pris en charge |
| Création d’un pool de nœuds | Prise en charge | Pris en charge |
| Création du cluster | Pris en charge | Non pris 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 | Pris en charge |
Remarque
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 pour kube-apiserver, vous avez 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, 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.29.2, 1.29.1, 1.28.7, 1.28.6, 1.27.11et 1.27.10, la version par défaut sélectionnée est 1.28.7.
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 mineure d’AKS prise en charge est 1.27 et que vous utilisez la version 1.26 ou une version antérieure, vous êtes hors support.
- Une fois la mise à niveau de la version 1.26 à la version 1.27 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.28.x - >1.29.x : autorisées.
- 1.27.x - >1.28.x : autorisées.
- 1.27.x - >1.29.x : non autorisées.
Notez que pour les mises à niveau des versions du plan de contrôle, vous pouvez aller jusqu’à 3 versions mineures pour les versions prises en charge par la communauté, de manière séquentielle.
Pour effectuer une mise à niveau depuis 1.27.x - >1.29.x :
- Mise à niveau depuis 1.27.x - >1.28.x.
- Mise à niveau depuis 1.28.x - >1.29.x.
Notez qu’à compter de la version 1.28, les versions du pool d’agents peuvent être jusqu’à 3 versions antérieures aux versions du plan de contrôle, par stratégie d’asymétrie de version. Lorsque votre version est de loin antérieure à la version minimale prise en charge, vous devrez peut-être effectuer plusieurs opérations de mise à niveau du plan de contrôle pour accéder à la version minimale prise en charge. Par exemple, si votre version actuelle du plan de contrôle est 1.23.x et que vous envisagez de procéder à une mise à niveau vers une version minimale prise en charge 1.27.x. Vous devrez peut-être effectuer une mise à niveau séquentielle 4 fois depuis 1.23.x pour arriver à 1.27.x. Notez également que les versions du pool d’agents peuvent être mises à niveau vers la version mineure du plan de contrôle. Cela signifie que, dans l’exemple ci-dessus, vous pouvez mettre à niveau deux fois la version du pool d’agents, c’est-à-dire une fois de 1.23.x à 1.25.x, lorsque la version du plan de contrôle est 1.25.x. Et par la suite, de 1.25.x à 1.27.x , lorsque la version du plan de contrôle est 1.27.x. Lors d’une mise à niveau « sur place », c’est-à-dire du plan de contrôle et du pool d’agents, les mêmes règles applicables à la mise à niveau du plan de contrôle écrites ci-dessus s’appliquent.
Lors de l’exécution d’une mise à niveau à partir d’une version non prise en charge, 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 flexibilité de découpler les mises à niveau du plan de contrôle avec des mises à niveau de 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 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 récemment déconseillée, qui est hors de la prise en charge de la plateforme, puis-je toujours ajouter de nouveaux pools de nœuds ? Ou une mise à niveau est-elle nécessaire ?
Oui, vous pouvez ajouter des pools d’agents tant qu’ils sont compatibles avec la version du plan de contrôle.
Étapes suivantes
Pour plus d’informations sur la mise à niveau de votre cluster, consultez :
Azure Kubernetes Service