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 mises à jour et mises à niveau de sécurité pour obtenir les fonctionnalités les plus récentes. Cet article explique comment vérifier et appliquer des mises à niveau à votre cluster AKS.
Mises à niveau de version de Kubernetes
Quand vous mettez à niveau un cluster AKS 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 principale. Par exemple, les mises à niveau 1.14.x ->1.15.x ou 1.15.x ->1.16.x sont autorisées. 1.14.x ->1.16.x ne le sont pas. Vous ne pouvez ignorer plusieurs versions que lors d’une mise à niveau d’une version non prise en charge vers une version prise en charge. Par exemple, vous pouvez effectuer une mise à niveau à partir d’une version 1.10.x non prise en charge vers une version 1.12.x prise en charge, si disponible.
Lorsque vous exécutez une mise à niveau à partir d’une version non prise en charge qui ignore au moins deux versions mineures, le fonctionnement de la mise à niveau n’est pas garanti et celle-ci est exclue des contrats de niveau de service et de la garantie limitée. Si votre version est considérablement obsolète, nous vous recommandons de recréer votre cluster à la place.
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. Exécutez
az --versionpour trouver 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. 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. - L’exécution d’opérations de mise à niveau nécessite le rôle RBAC
Microsoft.ContainerService/managedClusters/agentPools/write. Pour plus d’informations sur les rôles RBAC Azure, consultez les opérations du fournisseur de ressources Azure. - À compter de la version Kubernetes 1.30 et des versions 1.27 LTS, les API bêta sont désactivées par défaut lorsque vous effectuez une mise à niveau vers ces versions.
Avertissement
Une mise à niveau de cluster AKS déclenche une isolation et un drainage de vos nœuds. Si vous disposez d’un faible quota, la mise à niveau peut échouer. Pour plus d’informations, consultez Augmenter les quotas.
Recherchez les mises à niveau du cluster AKS disponibles
Remarque
Pour rester au courant des correctifs, des versions et des mises à jour AKS, consultez le suivi des versions AKS.
Recherchez les publications de Kubernetes disponibles pour votre cluster au moyen de la commande
az aks get-upgrades.az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output tableL’exemple de sortie suivant montre que la version actuelle est 1.26.6 et répertorie les versions disponibles sous
upgrades:{ "agentPoolProfiles": null, "controlPlaneProfile": { "kubernetesVersion": "1.26.6", ... "upgrades": [ { "isPreview": null, "kubernetesVersion": "1.27.1" }, { "isPreview": null, "kubernetesVersion": "1.27.3" } ] }, ... }
Résoudre les messages d’erreur de mise à niveau du cluster AKS
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. Vous pouvez mettre à jour les anciennes versions 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, exécutez 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. AKS ne prend pas en charge la mise à niveau d’un cluster vers une version plus récente de Kubernetes lorsque az aks get-upgrades montre qu’aucune mise à niveau disponible n’est disponible.
Mettre à niveau un cluster AKS
Pendant le processus de mise à niveau du cluster, AKS effectue 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, il isole et draine autant de nœuds que le nombre de nœuds de tampon spécifiés.
- Pour les pods de longue durée, vous pouvez configurer le délai d’expiration du drainage de nœud, afin de personnaliser le délai d’attente avant éviction des pods et l’arrêt normal de chaque nœud. Si aucun délai n’est spécifié, la valeur par défaut est de 30 minutes. La valeur minimale autorisée du délai d’expiration est de 5 minutes.
- 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.
- En option, vous pouvez définir une durée d’attente entre le drainage d’un nœud et sa réinitialisation, avant de passer au nœud suivant. Un intervalle court vous permet d’effectuer d’autres tâches, comme vérifier l’intégrité de l’application depuis un tableau de bord Grafana pendant le processus de mise à niveau. Nous vous recommandons un délai court pour le processus de mise à niveau, aussi près que possible de 0 minute. Dans le cas contraire, un temps d'immersion du nœud plus élevé influe sur le délai de découverte d'un problème. La valeur minimale de la période d’absorption des nœuds est de 0 minute, avec un maximum de 30 minutes. Si elle n’est pas spécifiée, sa valeur par défaut est de 0 minute.
- 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.
Remarque
Si aucun patch n’est spécifié, le cluster est automatiquement mis à niveau vers le dernier patch GA de la version mineure spécifiée. Par exemple, la définition de --kubernetes-version sur 1.28 entraîne la mise à niveau du cluster vers 1.28.9.
Pour plus d’informations, consultez Mises à niveau des versions mineures de Kubernetes prises en charge dans AKS.
Mettez à niveau votre cluster à l’aide de la commande
az aks upgrade.az aks upgrade \ --resource-group myResourceGroup \ --name myAKSCluster \ --kubernetes-version <KUBERNETES_VERSION>Vérifiez si la mise à niveau a réussi avec la commande
az aks show.az aks show --resource-group myResourceGroup --name myAKSCluster --output tableL’exemple de sortie suivant montre que le cluster exécute à présent la version 1.27.3 :
Name Location ResourceGroup KubernetesVersion ProvisioningState Fqdn ------------ ---------- --------------- ------------------- ------------------- ---------------------------------------------- myAKSCluster eastus myResourceGroup 1.27.3 Succeeded myakscluster-dns-379cbbb9.hcp.eastus.azmk8s.io
Définir un canal de mise à niveau automatique
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.
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 cinq pools de nœuds avec quatre nœuds chacun comporte en tout 20 nœuds. 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.
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 surtension maximale (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 %.
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.
AKS configure les mises à niveau avec un nœud supplémentaire par défaut. La valeur par défaut un pour les paramètres de surtension maximale (max-surge) permet à AKS de réduire les interruptions de la charge de travail en créant un nœud avant l’isolation ou le drainage des applications existantes pour remplacer un nœud de version antérieure. Vous pouvez personnaliser la valeur de surtension maximale par pool de nœuds. Lorsque vous augmentez la valeur de surtension maximale, le processus de mise à niveau se termine plus rapidement, et vous risquez de subir des interruptions pendant le processus de mise à niveau.
Par exemple, une valeur de surtension maximale de 100 % offre le processus de mise à niveau le plus rapide possible, 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 la surtension maximale ne peut pas être supérieur au nombre de nœuds dans le pool au moment de la mise à niveau.
Définir la valeur de surtension maximale
Définissez les valeurs de surtension maximale des pools de nœuds nouveaux ou existants à l’aide de la commande
az aks nodepool addouaz aks nodepool update.# Set max surge for a new node pool az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% # Update max surge for an existing node pool az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 5
Définir la valeur du délai d’expiration pour le drainage de nœud
Il peut arriver qu’une charge de travail durable s’exécute sur un pod donné et qu’elle ne puisse pas être replanifiée sur un autre nœud pendant son exécution, par exemple une charge de travail avec état utilisant intensivement la mémoire dont l’exécution doit se terminer. Dans ces scénarios, vous pouvez configurer un délai d’expiration pour le drainage des nœuds qui va être appliqué par AKS dans le workflow de mise à niveau. Si aucune valeur de délai d’expiration de drainage de nœud n’est spécifiée, la valeur par défaut est de 30 minutes. La valeur minimale autorisée du délai d’expiration du vidage est de 5 minutes.
Si la valeur du délai d’expiration du drainage s’écoule et que les pods sont toujours en cours d’exécution, l’opération de mise à niveau est arrêtée. Les opérations PUT ultérieures reprendront la mise à niveau arrêtée.
Définissez une valeur de délai d’expiration du drainage des nœuds sur les pools de nœuds nouveaux ou existants en utilisant la commande
az aks nodepool addouaz aks nodepool update.# Set drain timeout for a new node pool az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --drain-timeout 100 # Update drain timeout for an existing node pool az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --drain-timeout 45
Définir la valeur du temps d'immersion du nœud
Pour autoriser un délai d’attente entre le drainage d’un nœud et sa réinitialisation avant de passer au nœud suivant, vous pouvez définir un délai d’absorption sur une valeur comprise entre 0 et 30 minutes. Si aucune valeur de délai d’absorption des nœuds n’est spécifiée, la valeur par défaut est de 0 minute.
Définissez le délai d’absorption des nœuds sur les pools de nœuds nouveaux ou existants en utilisant la commande
az aks nodepool add,az aks nodepool updateouaz aks nodepool upgrade.# Set node soak time for a new node pool az aks nodepool add --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --node-soak-duration 10 # Update node soak time for an existing node pool az aks nodepool update --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 5 # Set node soak time when upgrading an existing node pool az aks nodepool upgrade --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 20
Afficher les événements de mise à niveau
Affichez les événements de mise à niveau à l’aide de la commande
kubectl get events.kubectl get eventsL’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 1m45s Normal Upgrade node/aks-nodepool1-96663640-vmss000001 Soak duration 5m0s after 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 nodepool1 ...
Étapes suivantes
Pour savoir comment configurer des mises à niveau automatiques, consultez Configurer des mises à niveau automatiques pour un cluster AKS.
Pour obtenir une discussion détaillée sur les meilleures pratiques de mise à niveau et d’autres considérations, consultez Instructions de mise à jour corrective et de mise à niveau AKS.
Azure Kubernetes Service