Mettre à niveau le plan de contrôle du cluster Azure Kubernetes Service (AKS)

Les clusters Azure Kubernetes Service (AKS) se composent de deux composants principaux : le plan de contrôle géré par Azure et les pools de nœuds sur lesquels vos charges de travail s’exécutent. Cet article se concentre sur la mise à niveau du plan de contrôle indépendamment, ce qui vous permet d’adopter de nouvelles versions de Kubernetes pour les fonctionnalités du serveur d’API tout en gérant séparément les mises à niveau des pools de nœuds.

Avant de commencer

• Si vous utilisez l’interface de ligne de commande Azure, cet article nécessite Azure CLI version 2.34.1 ou ultérieure. Utilisez la az --version commande pour rechercher la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
• Si vous utilisez Azure PowerShell, cet article nécessite Azure PowerShell version 5.9.0 ou ultérieure. Utilisez l’applet Get-InstalledModule -Name Az de commande pour rechercher la version. Si vous avez besoin de procéder à une installation ou à une mise à niveau, consultez Installer Azure PowerShell.
• Pour effectuer des opérations de mise à niveau, vous avez besoin du rôle contributeur Azure Kubernetes Service ou des autorisations équivalentes.
• Les API bêta sont désactivées par défaut lorsque vous effectuez une mise à niveau vers Kubernetes version 1.30 et 1.27 LTS.

Vue d’ensemble des types de mise à niveau AKS

Le tableau suivant présente trois types de mises à niveau AKS, en mettant en évidence leur étendue et leurs cas d’usage :

Règles de mise à niveau de version Kubernetes

Lorsque vous mettez à niveau un cluster AKS non LTS pris en charge, vous ne pouvez pas ignorer les versions mineures de Kubernetes. Vous devez effectuer toutes les mises à niveau séquentiellement par numéro de version secondaire. Par exemple, les mises à niveau entre 1.28.x ->1.29.x ou 1.29.x ->1.30.x sont autorisées. 1.28.x ->1.30.x n’est pas autorisé.

Un cluster LTS peut ignorer les versions mineures lors du passage à une version LTS supérieure proposée par AKS, à condition que la mise à niveau réponde aux exigences et aux vérifications de validation des versions. Pour plus d’informations, voir Puis-je ignorer plusieurs versions AKS lors d’une mise à niveau de cluster ?.

À compter de Kubernetes 1.28, le plan de contrôle peut comporter jusqu’à trois versions mineures devant les pools de nœuds. Par exemple, si votre plan de contrôle est à 1.35.x, vos pools de nœuds peuvent être à 1.32.x, 1.33.x, 1.34.x ou 1.35.x. Pour connaître les contraintes actuelles, consultez la stratégie d’asymétrie de version AKS.

Rechercher les mises à niveau AKS disponibles

az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output table

Name     ResourceGroup          MasterVersion    Upgrades
-------  ---------------        ---------------  --------------
default  <resource-group-name>  1.28.9           1.29.2, 1.29.4

Get-AzAksVersion -Location <your-region> | Where-Object { $_.OrchestratorVersion }

Mettre à niveau le plan de contrôle AKS uniquement

Mettre à niveau le cluster AKS complet

az aks upgrade \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --kubernetes-version 1.29.4

Set-AzAksCluster -ResourceGroupName <resource-group-name> -Name <cluster-name> -KubernetesVersion 1.29.4

Forum aux questions (FAQ) sur la mise à niveau du plan de contrôle AKS

Une mise à niveau de plan de contrôle uniquement met-elle également à niveau les pools de nœuds ?

Non. Une mise à niveau de plan de contrôle uniquement ne modifie pas les pools de nœuds. La mise à niveau automatique du cluster fonctionne différemment : elle ne prend pas en charge les mises à niveau de plan de contrôle uniquement et met à niveau le plan de contrôle et tous les pools de nœuds ensemble.

Puis-je mettre à niveau des pools de nœuds avant le plan de contrôle ?

Non. La version du plan de contrôle doit toujours être égale ou supérieure à n’importe quelle version du pool de nœuds. Vous devez d’abord mettre à niveau le plan de contrôle.

Combien de temps prend une mise à jour du plan de contrôle ?

La durée de mise à niveau varie en fonction de l’état du cluster et des conditions de Azure. Surveiller provisioningState à l’aide az aks show ou Get-AzAksCluster. La mise à niveau est terminée lorsque l’état d’approvisionnement est Succeeded.

Résoudre les problèmes de mise à niveau du plan de contrôle

Aucune mise à niveau disponible

Pour un cluster non pris en charge, utilisez cette propriété az aks get-upgrades pour vérifier si AKS offre une cible prise en charge éligible. Si une cible est disponible, effectuez une mise à niveau complète du cluster. Les mises à niveau de plan de contrôle uniquement ne sont pas prises en charge pour ce chemin de récupération.

Si aucune cible n’est disponible, votre cluster peut déjà se trouver sur la dernière version prise en charge. Si le cluster exécute une version non prise en charge, créez un cluster avec une version prise en charge et migrez vos charges de travail.

Échec de la mise à jour en raison des API obsolètes

Avant de procéder à la mise à niveau, recherchez les API déconseillées à l’aide d’outils tels que kube-no-trouble (kubent) :

kubent

La commande analyse les ressources accessibles via le contexte kubeconfig actuel pour les versions dépréciées de l’API Kubernetes. Les résultats des groupes de sortie par version kubernetes et identifient chaque ressource affectée par KIND, NAMESPACE, NAMEet API_VERSION. Mettez à jour le manifeste source de chaque ressource répertoriée pour utiliser une version d’API prise en charge avant la mise à niveau.

Contenu connexe

• Configurer des mises à niveau propagées pour les pools de nœuds
• Configurer des mises à niveau automatiques de cluster
• Configurer les mises à niveau automatiques de l’image du système d’exploitation de nœud