Mise à jour d’un cluster Azure Kubernetes Service (AKS)
Une partie du cycle de vie du cluster AKS implique l’exécution de mises à niveau périodiques vers la dernière version de Kubernetes. Il est important d’appliquer les dernières publications de sécurité ou d’opérer une mise à niveau pour obtenir les dernières fonctionnalités. Cet article explique comment vérifier, configurer et appliquer des mises à niveau à votre cluster AKS.
Pour en savoir plus sur les clusters AKS utilisant plusieurs pools de nœuds ou des nœuds Windows Server, consultez Mettre à niveau un pool de nœuds dans AKS. Pour mettre à niveau un pool de nœuds spécifique sans effectuer de mise à niveau de cluster Kubernetes, consultez Mettre à niveau un pool de nœuds spécifique.
Notes
Toute opération de mise à niveau, qu’elle soit effectuée manuellement ou automatiquement, met à niveau la version de l’image de nœud s’il ne s’agit pas de la dernière version. La dernière version est subordonnée à une version complète d’AKS, et peut être déterminée en visitant le suivi des mises en production AKS.
Notes
L’exécution d’opérations de mise à niveau nécessite le rôle RBACMicrosoft.ContainerService/managedClusters/agentPools/write. Pour plus d’informations sur les rôles RBAC Azure, consultez les [opérations du fournisseur de ressources Azure]
Avant de commencer
- Si vous utilisez Azure CLI, cet article nécessite que vous exécutiez Azure CLI version 2.34.1 ou ultérieure. Exécutez
az --versionpour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI. - Si vous utilisez Azure PowerShell, ce tutoriel nécessite que vous exécutiez Azure PowerShell version 5.9.0 ou ultérieure. Exécutez
Get-InstalledModule -Name Azpour trouver la version. Si vous avez besoin de procéder à une installation ou à une mise à niveau, consultez Installer Azure PowerShell.
Avertissement
Une mise à niveau de cluster AKS déclenche une isolation et un drainage de vos nœuds. Si vous n’avez qu’un quota de calcul faible, la mise à niveau peut échouer. Pour plus d’informations, consultez Augmenter les quotas.
Recherchez les mises à niveau du cluster AKS disponibles
Pour rechercher les publications de Kubernetes disponibles pour votre cluster, utilisez la commande az aks get-upgrades. L’exemple suivant recherche les mises à niveau disponibles pour myAKSCluster dans myResourceGroup :
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table
Notes
Quand vous mettez à niveau un cluster AKS pris en charge, les versions mineures de Kubernetes ne peuvent pas être ignorées. Toutes les mises à niveau doivent être effectuées de façon séquentielle par le numéro de version principale. Par exemple, les mises à niveau 1.14.x ->1.15.x ou 1.15.x ->1.16.x sont autorisées, mais pas 1.14.x ->1.16.x.
Vous pouvez ignorer plusieurs versions uniquement pour une mise à niveau d’une version non prise en charge vers une version prise en charge. Par exemple, la mise à niveau d’une version 1.10.x non prise en charge --> une version 1.15.x prise en charge peut être effectuée si disponible. 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. Si votre version est considérablement obsolète, il est recommandé de recréer le cluster.
L’exemple de sortie suivant montre que le cluster peut être mis à niveau vers les versions 1.19.1 et 1.19.3:
Name ResourceGroup MasterVersion Upgrades
------- --------------- --------------- --------------
default myResourceGroup 1.18.10 1.19.1, 1.19.3
L’exemple de sortie suivant signifie que l’extension appservice-kube n’est pas compatible avec votre version d’Azure CLI (la version minimale requise est 2.34.1) :
The 'appservice-kube' extension is not compatible with this version of the CLI.
You have CLI core version 2.0.81 and this extension requires a min of 2.34.1.
Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.
Si vous recevez cette sortie, vous devez mettre à jour votre version d’Azure CLI. La commande az upgrade a été ajoutée dans la version 2.11.0, et elle ne fonctionne pas avec les versions antérieures à 2.11.0. Les anciennes versions peuvent être mises à jour en réinstallant Azure CLI comme décrit dans Installer l’interface Azure CLI. Si votre version d’Azure CLI est 2.11.0 ou ultérieure, vous recevrez un message vous invitant à exécuter az upgrade pour mettre à niveau Azure CLI vers la dernière version.
Si votre interface Azure CLI est mise à jour et que vous recevez l’exemple de sortie suivant, cela signifie qu’aucune mise à niveau n’est disponible :
ERROR: Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.
Si aucune mise à niveau n’est disponible, créez un cluster avec une version prise en charge de Kubernetes et migrez vos charges de travail du cluster existant vers le nouveau cluster. La mise à niveau d’un cluster vers une version plus récente de Kubernetes quand az aks get-upgrades montre qu’aucune mise à niveau disponible n’est pas prise en charge.
Personnaliser l’augmentation du nombre de nœuds pendant une mise à niveau
Important
Une augmentation du nombre de nœuds nécessite un quota d’abonnement pour l’augmentation maximale (max-surge) demandée pour chaque opération de mise à niveau. Par exemple, un cluster comprenant 5 pools de 4 nœuds a 20 nœuds en tout. Si chaque pool de nœuds a une valeur max-surge de 50 %, un quota de calcul et d’adresse IP supplémentaire de 10 nœuds (2 nœuds * 5 pools) est nécessaire pour effectuer la mise à niveau.
Si vous utilisez Azure CNI, vérifiez que des adresses IP sont disponibles dans le sous-réseau et assurez-vous de satisfaire aux exigences IP d’Azure CNI.
Par défaut, AKS configure les mises à niveau avec un nœud supplémentaire. La valeur par défaut 1 pour les paramètres max-surge permet à AKS de réduire les interruptions de la charge de travail en créant un nœud supplémentaire avant l’isolation et le drainage des applications existantes pour remplacer un nœud de version antérieure. La valeur max-surge peut être personnalisée par pool de nœuds pour obtenir un compromis entre la vitesse de mise à niveau et l’interruption causée par la mise à niveau. En augmentant la valeur max-surge, le processus de mise à niveau se termine plus rapidement, bien que celui-ci puisse faire l’objet d’interruptions.
Par exemple, une valeur max-surge de 100 % offre le processus de mise à niveau le plus rapide possible (doublant le nombre de nœuds), mais entraîne également la vidange simultanée de tous les nœuds du pool de nœuds. Il est donc préférable d’utiliser des valeurs élevées telles que celle-ci pour les environnements de test. Pour les pools de nœuds de production, nous vous recommandons d’utiliser un paramètre max-surge de 33 %.
AKS accepte à la fois des valeurs entières et des valeurs en pourcentage pour max-surge. Ainsi, l’entier « 5 » indique une augmentation de cinq nœuds. La valeur « 50 % » indique une augmentation égale à la moitié du nombre de nœuds actuel dans le pool. Les valeurs en pourcentage de max-surge vont de 1 % (minimum) à 100 % (maximum). Si vous utilisez une valeur en pourcentage, le nombre de nœuds est arrondi à la valeur entière la plus proche. Si la valeur de surtension maximale est supérieure au nombre requis de nœuds à mettre à niveau, le nombre de nœuds à mettre à niveau est utilisé pour la valeur de surtension maximale.
Pendant une mise à niveau, la valeur max-surge peut être égale au minimum à 1 et au maximum au nombre de nœuds dans votre pool de nœuds. Vous pouvez définir des valeurs plus élevées, mais le nombre maximal de nœuds utilisés pour max-surge ne sera pas supérieur au nombre de nœuds dans le pool au moment de la mise à niveau.
Important
Le paramètre max-surge sur un pool de nœuds est persistant. Les mises à niveau ultérieures de Kubernetes ou les mises à niveau des versions de nœud utiliseront ce paramètre. Vous pouvez modifier la valeur de max-surge pour vos pools de nœuds à tout moment. Pour les pools de nœuds de production, nous vous recommandons de définir un paramètre max-surge de 33 %.
Utilisez les commandes suivantes pour définir des valeurs max-surge pour des pools de nœuds nouveaux ou existants.
# Set max surge for a new node pool
az aks nodepool add -n mynodepool -g MyResourceGroup --cluster-name MyManagedCluster --max-surge 33%
# Update max surge for an existing node pool
az aks nodepool update -n mynodepool -g MyResourceGroup --cluster-name MyManagedCluster --max-surge 5
Mettre à niveau un cluster AKS
Avec une liste des versions disponibles pour votre cluster AKS, utilisez la commande az aks upgrade pour opérer la mise à niveau. Au cours du processus de mise à niveau, AKS effectuera les opérations suivantes :
- Il ajoute un nouveau nœud de tampon (ou autant de nœuds que ceux configurés dans max-surge) au cluster qui exécute la version de Kubernetes spécifiée.
- Il effectue l’isolation et le drainage de l’un des anciens nœuds afin de limiter la perturbation des applications en cours d’exécution. Si vous utilisez max-surge, l’isolation et le drainage portent sur autant de nœuds que le nombre de nœuds de tampon spécifiés.
- Lorsque l’ancien nœud est entièrement drainé, il est réinitialisé pour recevoir la nouvelle version et devient le nœud de mémoire tampon pour le nœud suivant à mettre à niveau.
- Ce processus se répète jusqu’à ce que tous les nœuds du cluster soient mis à niveau.
- À la fin du processus, le dernier nœud tampon est supprimé, ce qui a pour effet de maintenir le nombre de nœuds d’agent existants et l’équilibre de la zone.
Notes
Si aucun correctif n’est spécifié, le cluster sera automatiquement mis à niveau vers le dernier correctif en disponibilité générale de la version mineure spécifiée. Par exemple, la définition de --kubernetes-version sur 1.21 entraîne la mise à niveau du cluster vers 1.21.9.
Lors de la mise à niveau par version mineure d’alias, seule une version mineure supérieure est prise en charge. Par exemple, la mise à niveau de 1.20.x vers 1.20 ne déclenche pas de mise à niveau vers le dernier correctif 1.20 en disponibilité générale, mais la mise à niveau vers 1.21 déclenche une mise à niveau vers le dernier correctif 1.21 en disponibilité générale.
az aks upgrade \
--resource-group myResourceGroup \
--name myAKSCluster \
--kubernetes-version KUBERNETES_VERSION
Quelques minutes suffisent pour mettre à niveau le cluster. Le temps nécessaire varie en fonction du nombre de nœuds.
Important
Assurez-vous que les PodDisruptionBudgets (PDB) permettent de déplacer au moins un réplica de pod à la fois, sinon l’opération de drainage/d’exclusion échouera.
Si l’opération de drainage échoue, l’opération de mise à niveau échouera de par sa conception afin de garantir que les applications ne soient pas interrompues. Corrigez ce qui a provoqué l’arrêt de l’opération (PDB incorrects, manque de quota, etc.), puis recommencez l’opération.
Pour vérifier si la mise à niveau a réussi, utilisez la commande az aks show :
az aks show --resource-group myResourceGroup --name myAKSCluster --output table
L’exemple de sortie suivant montre que le cluster exécute à présent la version 1.19.1 :
Name Location ResourceGroup KubernetesVersion ProvisioningState Fqdn
------------ ---------- --------------- ------------------- ------------------- ----------------------------------------------
myAKSCluster eastus myResourceGroup 1.19.1 Succeeded myakscluster-dns-379cbbb9.hcp.eastus.azmk8s.io
Afficher les événements de mise à niveau
Lorsque vous mettez votre cluster à niveau, les événements Kubernetes suivants peuvent se produire sur chaque nœud :
- Surge (Surtension) : Création d’un nœud de surtension.
- Drain (Vidage) : Éviction des pods du nœud en cours. Chaque pod dispose d’un délai de 30 secondes pour terminer l’expulsion.
- Update (Mise à jour) : Réussite ou échec de la mise à jour d’un nœud.
- Delete (Suppression) : Suppression d’un nœud de surtension.
Utilisez kubectl get events pour afficher les événements dans les espaces de noms par défaut lors de l’exécution d’une mise à niveau. Par exemple :
kubectl get events
L’exemple de sortie suivant montre certains des événements ci-dessus listés pendant une mise à niveau.
...
default 2m1s Normal Drain node/aks-nodepool1-96663640-vmss000001 Draining node: [aks-nodepool1-96663640-vmss000001]
...
default 9m22s Normal Surge node/aks-nodepool1-96663640-vmss000002 Created a surge node [aks-nodepool1-96663640-vmss000002 nodepool1] for agentpool %!s(MISSING)
...
Définir un canal de mise à niveau automatique
En plus de mettre à niveau manuellement un cluster, vous pouvez définir un canal de mise à niveau automatique sur votre cluster. Pour plus d’informations, consultez Mise à niveau automatique d’un cluster AKS.
Considérations spéciales pour les pools de nœuds qui s’étendent sur plusieurs zones de disponibilité
AKS utilise l’équilibrage de zone best-effort dans les groupes de nœuds. Pendant un afflux de mises à niveau, la ou les zones des nœuds de surtension dans les groupes de machines virtuelles identiques sont inconnues à l’avance. Cela peut entraîner temporairement une configuration de zone déséquilibrée pendant une mise à niveau. Toutefois, AKS supprime les nœuds de surtension une fois la mise à niveau terminée et préserve l’équilibre d’origine des zones. Si vous souhaitez que vos zones restent équilibrées pendant la mise à niveau, augmentez le nombre de nœuds à un multiple de 3. Les groupes de machines virtuelles identiques équilibrent ensuite vos nœuds entre les Zones de disponibilité avec un équilibrage de zone d’effort optimal.
Si des PVC sont soutenues par des disques LRS Azure, elles seront liées à une zone particulière et risquent de ne pas être récupérées immédiatement si le nœud de surtension ne correspond pas à la zone de la PVC. Cela peut entraîner un temps d’arrêt sur votre application lorsque l’opération de mise à niveau continue à drainer les nœuds, mais que les PV sont liés à une zone. Pour gérer ce cas et maintenir la haute disponibilité, configurez un budget de perturbation des pods sur votre application. Cela permet à Kubernetes de respecter vos exigences en matière de disponibilité pendant l’opération de drainage de la mise à niveau.
Étapes suivantes
Cet article vous a montré comment mettre à niveau un cluster AKS existant. Pour en savoir plus sur le déploiement et la gestion des clusters d’AKS, reportez-vous aux didacticiels.