Correctif et la mise à niveau des nœuds worker du service Azure Kubernetes et les versions de Kubernetes

Cette section du guide des opérations de deuxième jour d'Azure Kubernetes Service (AKS) décrit les stratégies de correction et de mise à niveau des nœuds worker AKS et des versions Kubernetes. En tant qu’opérateur de cluster, vous devez maintenir vos clusters à jour et surveiller les modifications et dépréciations de l’API Kubernetes au fil du temps.

Arrière-plan et types de mises à jour

Il existe trois types de mises à jour pour AKS, et chacun s’appuie sur la mise à jour précédente.

Type de mise à jour	Fréquence de mise à niveau	Prise en charge de la maintenance planifiée	Méthodes d’opération prises en charge	Cible	Documentation
Correctifs de sécurité du système d’exploitation du Node OS	De nuit	Oui	Automatique (hebdomadaire), manuel/non géré (nocturne)	Nœud	Mettre automatiquement à niveau les images de nœud
Mise à niveau de la version de l’image de Node	Linux : hebdomadaire Windows : Mensuel	Oui	Automatique, manuel	Pool de nœuds	Mettre à niveau des images de nœud AKS
Mises à niveau de la version de Kubernetes (groupement)	Trimestrielle	Oui	Automatique, manuel	Groupement et pool de Node	Options de mise à niveau pour les clusters AKS

Types de mises à jour

Correctifs de sécurité du système d’exploitation Node (Linux uniquement) : Pour les nœuds Linux, Canonical Ubuntu et Azure Linux rendent les correctifs de sécurité du système d’exploitation disponibles une fois par jour. Microsoft teste et regroupe ces retouches dans les mises à jour hebdomadaires des images de nœud.
Mises à jour hebdomadaires des images de nœud : AKS fournit des mises à jour hebdomadaires des images de nœud. Ces mises à jour incluent les derniers correctifs de sécurité du système d’exploitation et AKS, les correctifs de bogues et les améliorations. Les mises à jour de Node ne modifient pas la version de Kubernetes. Les versions Linux sont mises en forme par date, par exemple, 202601.07.0. Les versions Windows sont formatées par le numéro de build et la date du système d'exploitation Windows Server, par exemple, 20348.2113.260115. Pour plus d’informations, consultez le statut de version AKS.
Versions trimestrielles de Kubernetes : AKS fournit des mises à jour trimestrielles pour les versions kubernetes. Ces mises à jour permettent aux utilisateurs AKS d’accéder aux dernières fonctionnalités et améliorations de Kubernetes, telles que les correctifs de sécurité et les mises à jour d’images de nœud. Pour plus d’informations, consultez la section Versions de Kubernetes prises en charge dans AKS.

Considérations relatives aux prégradations

Avant de mettre à niveau vos nœuds Worker AKS et vos versions kubernetes, tenez compte des effets et des meilleures pratiques suivants.

Impact global du groupement

Les mises à niveau sur place pour les nœuds et les clusters affectent les performances de votre environnement Kubernetes pendant qu’elles sont en cours. Réduisez cet effet grâce à la configuration appropriée des budgets d'interruption des pods (PDB), de la surcapacité des nœuds et à une planification appropriée.
Les stratégies de mise à jour bleue verte n’affectent pas les performances du cluster, mais elles augmentent les coûts et la complexité. Pour obtenir des modèles bleu-vert détaillés au niveau du cluster et du pool de nœuds, y compris les déploiements qui utilisent des Azure DNS, des Azure Traffic Manager et des Azure Front Door, consultez Déploiement vert bleu des clusters AKS.

Quelle que soit votre stratégie de mise à niveau et de mise à jour corrective, utilisez un processus de test et de validation robuste pour votre cluster. Tout d’abord, corrigez et mettez à niveau des environnements inférieurs, puis effectuez une validation post-maintenance pour vérifier l’intégrité des clusters, des nœuds, du déploiement et de l’application.

Meilleures pratiques relatives aux charges de travail AKS

Suivez ces bonnes pratiques pour vous assurer que votre cluster AKS fonctionne correctement pendant la maintenance :

Définissez des PDB. Il est essentiel de configurer des PDB pour vos déploiements. Les PDB appliquent un nombre minimal de réplicas d’application disponibles pour garantir la fonctionnalité continue pendant les événements d’interruption. Les PDB aident à maintenir la stabilité de votre groupement pendant les défaillances de maintenance ou de Node.

Avertissement

Les fichiers PDB mal configurés peuvent bloquer le processus de mise à niveau, car l’API Kubernetes empêche le cordon nécessaire et le drain qui se produit avec une mise à niveau d’image de nœud propagé. De plus, une panne de l’application peut se produire si trop de pods sont déplacés en même temps. La configuration PDB appropriée atténue ce risque.
Activez les protections de déploiement. Les protections de déploiement appliquent les meilleures pratiques Kubernetes, notamment la validation PDB, les limites des ressources, les sondes d’intégrité et les règles d’antiaffinité. Les protections de déploiement utilisent des contrôles Azure Policy lors du déploiement pour vous assurer que les charges de travail sont correctement configurées avant le début d’une mise à niveau.
Vérifiez les limites de calcul et de réseau disponibles. Vérifiez les limites de calcul et de réseau disponibles dans votre abonnement Azure via la page quota dans le portail Azure ou à l’aide de la commande az quota. Vérifiez les ressources de calcul et de réseau, en particulier les processeurs virtuels (vCPUs) des machines virtuelles (VM) pour vos nœuds, ainsi que le nombre de machines virtuelles et de jeux d'échelles de machines virtuelles. Si vous êtes proche d’une limite, demandez une augmentation du quota avant de procéder à la mise à niveau.
Vérifiez l’espace d’adressage IP disponible dans les sous-réseaux de nœuds. Pendant les mises à jour, des nœuds de surtension supplémentaires sont créés dans votre cluster, et les pods sont déplacés vers ces nœuds. Surveillez l’espace d’adressage IP dans vos sous-réseaux de nœuds pour vous assurer qu’il existe suffisamment d’espace d’adressage IP pour que ces modifications se produisent. Différentes configurations réseau Kubernetes ont des exigences d’adresse IP différentes. Pour commencer, passez en revue les considérations suivantes :
- Pendant une mise à niveau, le nombre d’adresses IP de nœud augmente en fonction de l’augmentation du nombre de nœuds. La valeur minimale d’augmentation est 1.
- Les clusters basés sur Azure l’interface de mise en réseau de conteneurs (CNI) attribuent des adresses IP à des pods individuels. Vérifiez qu’il y a suffisamment d’espace d’adressage IP pour le déplacement des pods.
- Votre groupement continue à fonctionner pendant les mises à niveau. Vérifiez qu’il y a suffisamment d’espace d’adressage IP pour la mise à l’échelle des nœuds.
Configurez plusieurs environnements. Configurez plusieurs environnements Kubernetes, tels que le développement, la préproduction et les environnements de production. Utilisez ces environnements pour tester et valider les modifications avant de les déplacer en production. La validation est particulièrement importante lorsque vous passez de plusieurs versions d’AKS, par exemple de 1.32 à 1.34.
Planifiez des fenêtres de maintenance. Les processus de mise à niveau peuvent affecter les performances globales de votre groupement Kubernetes. Planifiez des processus de mise à niveau sur place en dehors des fenêtres d’utilisation maximales à l’aide de fenêtres de maintenance et surveillez les performances du cluster pour garantir un dimensionnement adéquat, en particulier pendant les processus de mise à jour.
Optimisez les clusters pour un comportement de nœud non drainable. Par défaut, si un nœud ne parvient pas à se vider correctement, la mise à jour corrective sur votre cluster échoue également. Configurez le cordon de drainage de nœud pour résoudre ce problème. Ce processus met en quarantaine les nœuds insécurisables afin que votre cluster puisse effectuer une mise à niveau correctement, et pour que vous puissiez corriger manuellement les nœuds qui n’ont pas pu être mis à jour en les mettant à jour ou en les supprimant. Vous pouvez configurer le paramètre --max-blocked-nodes pour spécifier le nombre de nœuds pouvant échouer à se vider avant l’échec de la mise à niveau. Par exemple : az aks nodepool update --undrainable-node-behavior Cordon --max-blocked-nodes 2 --drain-timeout 30.
Utilisez la mise à niveau forcée pour les scénarios d’urgence. Pour les correctifs de sécurité d’urgence, les opérateurs peuvent utiliser le drapeau --enable-force-upgrade avec --upgrade-override-until pour contourner les protections PDB et les vérifications de validation. Lorsque la mise à niveau forcée est activée, elle a priorité sur toutes les autres configurations de vidage, y compris les paramètres de comportement des nœuds insécables.

Importante

Utilisez cette option uniquement pour les scénarios de réponse de vulnérabilité et d’exposition courants urgents (CVE). Pour plus d’informations, consultez Forcer la mise à niveau d’un cluster AKS.
Paramétrez les valeurs de mise à niveau de la montée en tension. Par défaut, AKS a une valeur de surtension de 1, ce qui signifie qu’un Node supplémentaire est créé à la fois dans le cadre du processus de mise à niveau. Augmentez la vitesse d’une mise à niveau AKS en augmentant cette valeur. 33% d’augmentation du nombre de nœuds est la valeur maximale recommandée pour les charges de travail sensibles aux perturbations. Pour plus d’informations, consultez Personnaliser la mise à niveau de l’augmentation des nœuds.
Ajuster le paramètre de délai d’attente pour le drainage d’un nœud.Le délai d’attente de drainage d’un nœud spécifie la durée maximale pendant laquelle un cluster attend qu’une charge de travail tente de reprogrammer les pods sur un nœud en cours de mise à jour. La valeur par défaut est 30 minutes. Si votre charge de travail a des difficultés à replanifier des pods, envisagez d’augmenter cette valeur.
Configurer le délai d'attente de test du nœud. Par défaut, la configuration de rodage du nœud passe au reformatage du nœud suivant après qu’un nœud a terminé son processus de mise à jour. Pour certaines charges de travail héritées ou sensibles, il peut être utile d’ajouter un délai avant de passer au nœud suivant. Ajoutez un délai en configurant un délai d’attente d’imbipage de nœud.
Vérifiez les autres dépendances dans votre groupement. Les opérateurs Kubernetes déploient souvent d’autres outils sur le cluster Kubernetes dans le cadre d’opérations, comme les scalers de mise à l’échelle automatique pilotée par les événements Kubernetes (KEDA), le runtime d’application distribué (DAPR) et les maillages de service. Lorsque vous planifiez vos processus de mise à niveau, consultez les notes de publication des composants que vous utilisez pour garantir la compatibilité avec la version cible.
Ajustez les configurations zonales de l'AKS. Pour les clusters AKS zonaux, la mise à niveau par augmentation peut entraîner une distribution temporairement déséquilibrée des charges de travail entre les zones. Définissez la valeur d’augmentation sur un multiple de 3, par exemple 33%, pour éviter ce déséquilibre.

Gérer les mises à jour hebdomadaires des images de nœud

Microsoft crée une image de nœud pour les nœuds AKS environ une fois par semaine. Une image de nœud contient des correctifs de sécurité à jour pour le système d'exploitation, des mises à jour du noyau du système d'exploitation, des mises à jour de sécurité de Kubernetes, ainsi que des versions mises à jour de fichiers binaires comme kubelet et des mises à jour des versions des composants.

Lorsqu’une image de nœud est mise à jour, une action de cordon et de drainage est déclenchée sur les nœuds du pool de nœuds cibles :

Un Node avec l’image mise à jour est ajouté au pool de Nodes. La valeur d’augmentation régit le nombre de nœuds ajoutés en même temps.
Selon la valeur de surcharge, un lot de nœuds existants est mis en quarantaine et vidés. Le cordonage garantit que le Node ne planifie pas de pods. Le drainage supprime ses pods et les planifie sur d’autres Nodes.
Une fois ces nœuds entièrement vidés, ils sont supprimés du pool de nœuds. Les nœuds drainés sont remplacés par les nœuds mis à jour ajoutés par le surcroît.

AKS répète ce processus pour chaque lot restant de nœuds qui nécessite une mise à jour dans le pool de nœuds. Un processus similaire se produit lors d’une mise à niveau de cluster.

Mises à niveau automatiques de l’image de Node

La plupart des clusters doivent utiliser le canal de mise à jour NodeImage. Ce canal fournit un disque dur virtuel d’image de nœud mis à jour chaque semaine. L’image de nœud est mise à jour en fonction de la fenêtre de maintenance de votre cluster.

Les canaux disponibles sont les suivants :

None. Aucune mise à jour n’est appliquée automatiquement.
Unmanaged. Le système d’exploitation applique des mises à jour pour Ubuntu et Azure Linux chaque nuit. Les redémarrages doivent être gérés séparément. AKS ne peut pas tester ou contrôler la cadence de ces mises à jour.
SecurityPatch. Le système d’exploitation déploie des correctifs de sécurité entièrement managés testés par AKS à l’aide de pratiques de déploiement sécurisées. Ce correctif ne contient pas de correctifs de bogues de système d’exploitation. Le correctif contient uniquement les mises à jour de sécurité. Le SecurityPatch canal applique généralement des correctifs CVE dans un délai d’environ cinq jours et réimage les nœuds moins fréquemment que NodeImage par le biais de correctifs en direct.
NodeImage. AKS met à jour les nœuds chaque semaine avec un VHD nouvellement corrigé qui contient des correctifs de sécurité et des correctifs de bugs. Ces mises à jour sont entièrement testées et déployées à l’aide de pratiques de déploiement sécurisées. Pour des informations en temps réel sur les images de nœuds actuellement déployées, veuillez consulter la section Mises à jour d’images de nœuds AKS.

Pour plus d’informations sur les cadences par défaut sans fenêtre de maintenance établie, consultez La propriété et la planification des mises à jour.

Si vous choisissez le canal de mise à jour Unmanaged, vous devez gérer le processus de redémarrage à l’aide d’un outil tel que kured. Le canal Unmanaged n’est pas accompagné des pratiques de déploiement sécurisées fournies par AKS et ne fonctionne pas avec les fenêtres de maintenance.
Si vous choisissez le SecurityPatch canal de mise à jour, vous pouvez appliquer des mises à jour aussi fréquemment que chaque semaine. Ce niveau de correctif nécessite que les VHD soient stockés dans votre groupe de ressources, ce qui entraîne des frais nominals. Définissez une aksManagedNodeOSUpgradeSchedule cadence qui convient le mieux à votre charge de travail pour contrôler le moment où SecurityPatch elle est appliquée. Si vous avez également besoin des corrections de bogues qui accompagnent généralement les nouvelles images de nœuds (VHD), vous devez choisir la chaîne NodeImage au lieu de SecurityPatch.

En guise de meilleure pratique, utilisez le NodeImage canal de mise à jour et configurez une aksManagedNodeOSUpgradeSchedule fenêtre de maintenance pendant l’utilisation hors pointe du cluster. Pour configurer les attributs de la fenêtre de maintenance du cluster, consultez Créer une fenêtre de maintenance. Les attributs de clé sont les suivants :

name. Utilisez aksManagedNodeOSUpgradeSchedule pour les mises à jour du système d’exploitation de Node.
utcOffset. Configurer le fuseau horaire.
startTime. Définissez l’heure de début de la fenêtre de maintenance.
dayofWeek. Définissez les jours de la semaine pour la fenêtre, par exemple Saturday.
schedule. Définissez la fréquence de la fenêtre. Pour les mises à jourNodeImage, nous vous recommandons weekly.
durationHours. Définissez cet attribut sur au moins quatre heures.

L’exemple suivant définit une fenêtre de maintenance hebdomadaire à 18h00 heure de l’Est le samedi.

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

Dans l’idéal, déployez cette configuration dans le cadre du déploiement d’infrastructure en tant que code (IaC) du cluster.

Pour plus d’exemples, consultez Ajouter une configuration de fenêtre de maintenance.

Recherchez les fenêtres de maintenance configurées à l’aide de la Azure CLI.

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

Vérifiez les détails d’une fenêtre de maintenance spécifique à l’aide de l’interface CLI.

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

Si une fenêtre de maintenance de groupement n’est pas configurée, les mises à jour d’images de Node se produisent toutes les deux semaines. La maintenance AKS se produit dans la fenêtre configurée autant que possible, mais le temps de maintenance n’est pas garanti.

Importante

Si vous disposez d'un pool de nœuds avec un grand nombre de nœuds et qu'il n'est pas configuré avec un surge de nœuds, l'événement de mise à niveau automatique pourrait ne pas se déclencher. Les images de nœuds d’un pool de nœuds ne seront mises à niveau que si la durée totale estimée de la mise à niveau est inférieure à 24 heures.

Dans ce cas, envisagez l’une des options suivantes :

Fractionnez les nœuds en différents pools de nœuds si votre quota de processeurs virtuels est presque complet et que vous ne pouvez pas augmenter le quota de processeurs virtuels.
Configurez l’augmentation du nœud pour réduire le temps de mise à niveau estimé si votre quota de processeurs virtuels est suffisant.

Pour surveiller automatiquement l’état des mises à jour, utilisez le gestionnaire de communication AKS pour fournir des alertes automatiques pour les activités de maintenance planifiées. Vous pouvez également surveiller l’état des mises à jour via Azure Monitor journaux d’activité ou en consultant les journaux d’activité resource sur le cluster via kubectl get events.

Abonnez-vous aux événements de mise à niveau AKS à l’aide de Azure Event Grid pour obtenir des événements de mise à niveau AKS. Ces événements peuvent vous alerter lorsqu’une nouvelle version de Kubernetes est disponible et vous aider à suivre les modifications d’état des nœuds pendant les processus de mise à niveau.

Vous pouvez également gérer le processus de mise à jour hebdomadaire à l’aide de GitHub Actions. Cette méthode fournit un contrôle plus précis du processus de mise à jour.

D’autres outils de surveillance et d’observabilité pour les opérations de mise à niveau sont les suivants :

Diagnostics d'AKS. Sélectionnez Diagnose et résolvez les problèmes dans le portail Azure pour obtenir des diagnostics spécifiques sur les échecs d’opération de création, de lecture, de mise à jour et de suppression, les problèmes de mise à niveau et l’intégrité des nœuds.
Container Insights. Configurez des alertes de recherche personnalisées sur la table KubeEvents pour les événements de mise à niveau à partir de la source du composant upgrader.
Azure Advisor. Advisor recommande de manière proactive des mises à niveau à l'approche de la fin du support des clusters et fournit des recommandations pour la mise à niveau et la mise hors service des services.
Suivi des versions AKS. Utilisez le AKS release tracker pour surveiller les déploiements de versions dans les régions Azure et suivre la disponibilité des images de nœud en temps réel.

Processus de mise à jour manuelle des Nodes

Vous pouvez utiliser la commande kubectl décrire les nœuds pour déterminer la version du noyau du système d’exploitation et la version d’image du système d’exploitation des nœuds de votre cluster.

kubectl describe nodes <NodeName>

La sortie suivante affiche les informations système du nœud.

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             6.6.87.1-1.azl3
  OS Image:                   Microsoft Azure Linux 3.0
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.27
  Kubelet Version:            v1.33.1
  Kube-Proxy Version:         v1.33.1

Utilisez la commande Azure CLI az aks nodepool list pour déterminer les versions d’image de nœud des nœuds d’un cluster.

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

La sortie suivante montre les versions d’image de nœud.

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202601.13.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202601.13.0

Utilisez la commande az aks nodepool get-upgrades pour déterminer la dernière version d’image de nœud disponible pour un pool de nœuds spécifique.

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

La sortie suivante montre les dernières versions d’image de nœud disponibles pour le pool de nœuds.

Name    NodeImageVersion
------  -------------------------------------
system  AKSAzureLinux-V3gen2-202601.13.0
user    AKSAzureLinux-V3gen2arm64-202601.13.0

Mise à niveau des clusters

La communauté Kubernetes publie des versions mineures de Kubernetes environ tous les trois mois. La page des notes de publication AKS est régulièrement mise à jour avec des informations sur les versions et mises à jour d'AKS. Vous pouvez également vous abonner au GitHub flux RSS AKS, qui fournit des mises à jour en temps réel sur les modifications et les améliorations.

AKS suit une stratégie de prise en charge N - 2 , ce qui signifie que la prise en charge complète est fournie pour la dernière version (N) et les deux versions mineures précédentes. La prise en charge limitée de la plateforme est proposée pour la troisième version mineure antérieure. Pour plus d’informations, consultez Stratégies de support pour AKS.

Établissez un processus de mise à niveau continue du cluster pour vous assurer que vos clusters AKS restent pris en charge. Ce processus implique de tester de nouvelles versions dans des environnements inférieurs et de planifier la mise à niveau vers la production avant que la nouvelle version ne devienne la version par défaut. Cette approche permet de maintenir la prévisibilité dans votre processus de mise à niveau et de réduire les interruptions des applications. Pour plus d’informations, consultez Les options de mise à niveau pour les clusters AKS.

Si votre cluster nécessite un cycle de mise à niveau plus long, utilisez les versions AKS qui prennent en charge l’option de support à long terme (LTS). Chaque version d’AKS Kubernetes prise en charge à partir de la version 1.27 est éligible pour un LTS de 24 mois via le niveau Premium. LTS fournit un cycle de mise à niveau plus prolongé et contrôlé. Il prend en charge les mises à niveau de versions majeures toutes les 24 mois au lieu du cycle standard de 12 mois. Pour activer LTS, utilisez --tier premium --k8s-support-plan AKSLongTermSupport.

Note

Pendant la fenêtre LTS, seules les deux dernières versions correctives sont prises en charge et certaines contraintes de compatibilité d’extension peuvent s’appliquer. Si vous utilisez LTS, envisagez de l’associer au canal de mise à niveau automatique du patch cluster.

Pour plus d’informations, consultez la section Versions de Kubernetes prises en charge dans AKS.

Une mise à niveau de cluster comprend une mise à niveau de nœud et utilise un cordon et un processus de drainage.

Avant de procéder à la mise à niveau

Comme meilleure pratique, mettez à niveau et testez dans des environnements inférieurs pour réduire le risque d’interruption en production. Les mises à niveau de cluster nécessitent des tests supplémentaires, car elles impliquent des modifications d’API, ce qui peut affecter les déploiements Kubernetes. Les ressources suivantes peuvent vous aider dans le processus de mise à niveau.

classeur AKS pour les API dépréciées : À partir de la page vue d’ensemble du cluster dans le portail Azure, sélectionnez Diagnoser et résoudre des problèmes, accédez à la catégorie Création, mise à niveau, suppression et mise à l'échelle, puis sélectionnez Dépréciations de l'API Kubernetes. Cette procédure exécute un classeur qui vérifie les versions déconseillées de l’API que votre cluster utilise toujours. Pour plus d’informations, consultez Supprimer l’utilisation des API déconseillées.
page des notes de publication AKS : Cette page fournit des informations complètes sur les nouvelles versions et mises à jour d’AKS. Passez en revue ces notes pour rester informé des dernières mises à jour et modifications.
Page des notes de publication Kubernetes : Cette page fournit des informations détaillées sur les dernières versions de Kubernetes. Faites attention aux notes de mise à niveau urgentes. Ils mettent en évidence les informations critiques susceptibles d’affecter votre cluster AKS.
Modifications incompatibles des composants AKS par version : Ce tableau fournit une vue d’ensemble complète des modifications incompatibles dans les composants AKS par version. Résolvez de manière proactive les problèmes de compatibilité potentiels avant le processus de mise à niveau en faisant référence à ce guide.

En plus de ces ressources Microsoft, envisagez d’utiliser des outils open source pour optimiser votre processus de mise à niveau de groupement. Par exemple, Fairwinds pluto analyse vos déploiements et graphiques Helm pour les API Kubernetes dépréciées. Ces outils peuvent vous aider à vous assurer que vos applications restent compatibles avec les dernières versions de Kubernetes.

Processus de mise à niveau

Pour rechercher les mises à niveau de cluster, utilisez la commande az aks get-upgrades pour obtenir la liste des versions de mise à niveau disponibles pour votre cluster AKS. Déterminez la version cible pour votre cluster à partir des résultats.

La commande suivante montre les versions de mise à niveau disponibles.

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

La sortie suivante montre les versions de mise à niveau Kubernetes disponibles pour le cluster.

MasterVersion  Upgrades
-------------  ---------------------------------
1.32.4         1.33.1, 1.33.2, 1.33.3

Pour rechercher des pools qui nécessitent une mise à niveau, vérifiez les versions Kubernetes des nœuds de vos pools de nœuds.

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

La sortie suivante montre les versions de Kubernetes pour chaque pool de nœuds.

Name          K8version
------------  ------------
systempool    1.32.4
usernodepool  1.32.4

Mises à niveau manuelles

Pour réduire les interruptions et garantir une mise à niveau fluide pour votre cluster AKS, procédez comme suit :

Mettre à niveau le plan de contrôle AKS. Mettez à niveau les composants du plan de contrôle responsables de la gestion et de l’orchestration de votre cluster. Mettez d’abord à niveau le plan de contrôle pour garantir la compatibilité et la stabilité avant de mettre à niveau les pools de nœuds individuels.
Mettez à niveau le pool de Nodes de votre système. Après avoir mis à niveau le plan de contrôle, mettez à niveau le pool de Nodes de votre système dans votre groupement AKS. Les pools de nœuds se composent des instances de machine virtuelle qui exécutent vos charges de travail d’application. Mettez à niveau les pools de nœuds séparément pour maintenir le contrôle et appliquer des modifications à l’infrastructure sous-jacente qui prend en charge vos applications.
Mettre à niveau des pools de Nodes utilisateurs. Après avoir mis à niveau le pool de nœuds système, mettez à niveau les pools de nœuds utilisateur dans votre cluster AKS.

Suivez cette approche pour réduire les interruptions pendant le processus de mise à niveau et maintenir la disponibilité de vos applications. Effectuez les étapes suivantes :

Exécutez la commande az aks upgrade avec l’indicateur --control-plane-only pour mettre à niveau uniquement le plan de contrôle du cluster et non les pools de nœuds du cluster.
```
az aks upgrade \
   --resource-group <ResourceGroupName> --name <AKSClusterName> \
   --control-plane-only \
   --kubernetes-version <KubernetesVersion>
```
Exécutez la commande az aks nodepool upgrade pour mettre à niveau les pools de nœuds vers la version cible.
```
az aks nodepool upgrade \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
   --no-wait --kubernetes-version <KubernetesVersion>
```
Pendant la mise à niveau du pool de nœuds, AKS crée un nœud de hausse, isole et draine les pods dans le nœud en cours de mise à niveau, transforme l’image du nœud, puis annule l’isolement des pods. Ce processus se répète pour les autres nœuds du pool de nœuds.

Vérifiez l’état du processus de mise à niveau en exécutant kubectl get events. Pour plus d’informations sur la résolution des problèmes de mise à niveau de cluster, consultez la documentation de résolution des problèmes AKS.

Inscrire des clusters dans des canaux de mise à niveau automatique

AKS fournit également une solution de mise à niveau automatique de cluster pour maintenir votre cluster à jour. Si vous utilisez cette solution, associez-la à une fenêtre de maintenance pour contrôler le minutage des mises à niveau. La fenêtre de mise à niveau doit être de quatre heures ou plus.

Lorsque vous inscrivez un groupement dans un canal de distribution, Microsoft gère automatiquement la version et la cadence de mise à jour pour le groupement et ses pools de Nodes.

La mise à niveau automatique du cluster fournit différentes options de canal de mise en production. Le tableau suivant présente un environnement et une configuration de canal de mise en production recommandés.

Environnement	Canal de mise à niveau	Description
Production	`stable`	Pour la stabilité et la maturité des versions, utilisez le canal stable ou normal pour les charges de travail de production.
Préproduction, test, développement	Identique à la production	Utilisez le même canal de mise en production que la production pour vous assurer que vos tests indiquent la version vers laquelle vous mettez à niveau votre environnement de production.
Contrôle de validité	`rapid`	Utilisez le `rapid` canal pour tester les dernières versions de Kubernetes et les nouvelles fonctionnalités ou API AKS. Améliorez votre délai de mise sur le marché lorsque la version dans `rapid` est promue sur le canal que vous utilisez pour la production.

Vous pouvez appliquer des configurations de canal de mise à niveau automatique et de canal de mise à niveau automatique du système d’exploitation pour votre charge de travail à l’aide des définitions intégrées d'Azure Policy pour AKS. Ces stratégies peuvent exiger que les clusters utilisent un canal de mise à niveau automatique spécifique, appliquent des canaux de mise à niveau automatique du système d’exploitation de nœud comme SecurityPatch ou NodeImage, et nécessitent des fenêtres de maintenance planifiée.

AKS Automatic

AKS Automatic est une expérience AKS entièrement managée où Azure gère automatiquement la configuration du cluster, la gestion des nœuds, la mise à l’échelle et les mises à niveau automatiquement. AKS Automatic applique par défaut la mise à niveau automatique via le stable canal de cluster et le NodeImage canal du système d’exploitation de nœud, utilise le provisionnement automatique de nœuds pour le provisionnement dynamique des nœuds et inclut des protections de déploiement. Si votre charge de travail a besoin d’un modèle d’exploitation qui gère automatiquement la plupart des instructions de mise à niveau manuelle de cet article, envisagez AKS Automatic comme alternative.

Mises à niveau à plusieurs clusters avec Azure Kubernetes Fleet Manager

Pour les charges de travail qui gèrent plusieurs clusters AKS, Azure Kubernetes Fleet Manager fournit une gestion de mise à niveau orchestrée sur l’ensemble de votre flotte. Fleet Manager fournit :

Exécutions de mises à jour en phases. Définissez les phases de mise à jour, telles que le développement, la préproduction et la production, avec des périodes d’attente configurables entre les phases.
Mettez à jour des groupes et des stratégies. Créez des stratégies de mise à jour réutilisables qui définissent l’ordre et le minutage des mises à niveau entre les groupes de cluster.
Profils de mise à niveau automatique. Configurez des profils de mise à niveau automatique au niveau de la flotte qui appliquent des stratégies de mise à niveau cohérentes sur tous les clusters membres.

Vous pouvez utiliser Fleet Manager pour coordonner les mises à niveau des versions et des images de nœud Kubernetes sur plusieurs clusters AKS. Pour plus d’informations, consultez Orchestrer les mises à jour sur plusieurs clusters AKS à l’aide de Fleet Manager.

Considérations

Le tableau suivant décrit les caractéristiques des différents scénarios de mise à niveau et de mise à jour corrective AKS.

Scénario	À l’initiative de l’utilisateur	Mise à niveau de Kubernetes	Mise à niveau du noyau du système d’exploitation	Mise à niveau d’image de nœud
Correctifs de sécurité	Non	Non	Oui, après le redémarrage	Oui
Création du cluster	Oui	Peut-être	Oui, si une image de Node mise à jour utilise un noyau mis à jour	Oui, par rapport à un groupement existant si une nouvelle version est disponible
Mise à niveau Kubernetes du plan de contrôle	Oui	Oui	Non	Non
Mise à niveau Kubernetes du pool de Nodes	Oui	Oui	Oui, si une image de Node mise à jour utilise un noyau mis à jour	Oui, si une nouvelle version est disponible
Scale-up des pools de nœuds	Oui	Non	Non	Non
Mise à niveau d’image de nœud	Oui	Non	Oui, si une image de Node mise à jour utilise un noyau mis à jour	Oui
Mise à niveau automatique du cluster	Non	Oui	Oui, si une image de Node mise à jour utilise un noyau mis à jour	Oui, si une nouvelle version est disponible

Un correctif de sécurité du système d’exploitation appliqué dans le cadre d’une mise à niveau d’image de nœud peut installer une version du noyau plus récente que celle qu’une nouvelle création de cluster pourrait installer.
Le scale-up du pool de Nodes utilise le modèle actuellement associé au groupe de machines virtuelles identiques. Les noyaux du système d’exploitation sont mis à niveau lorsque des correctifs de sécurité sont appliqués et que les nœuds redémarrent.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

Anthony Nevico | Principal architecte de solution cloud

Autres contributeurs :

Sam Cogan | Architecte de solution cloud senior
Rishabh Saha | Architecte de solution principal
Paolo Salvatori | Ingénieur client principal, FastTrack pour Azure
Ali Yousefi | Architecte de solution cloud

Pour afficher les profils de LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-03-06