Partager via

Correctif et conseils de mise à niveau d’Azure Kubernetes Service

  • Article

Cette section du Guide des opérations Jour 2 AKS (Azure Kubernetes Service) décrit les pratiques de mise à niveau et de mise à jour corrective pour les Nodes Worker AKS et les versions Kubernetes. En tant qu’opérateur de groupement, vous devez disposer d’un plan pour maintenir vos groupements à 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, chacun s’appuyant sur la suivante :

Type de mise à jour Fréquence de mise à niveau Maintenance planifiée prise en charge Méthodes d’opération prises en charge Cible Lien vers la documentation
Correctifs de sécurité du système d’exploitation du Node OS Tous les soirs Oui Automatique (hebdomadaire), manuel/non géré (nocturne) Nœud Mettre à niveau automatiquement les images du nœud
Mise à niveau de la version de l’image de Node Linux : hebdomadaire
Windows : mensuel		 Oui Automatique, manuel Pool de nœuds Mise à niveau de l’image de nœud AKS
Mises à niveau de la version de Kubernetes (groupement) Trimestrielle Oui Automatique, manuel Groupement et pool de Node Mise à niveau d’un groupement AKS

Types de mises à jour

  • Correctifs de sécurité du système d’exploitation de Node (Linux uniquement). Pour les Nodes Linux, Canonical Ubuntu et Azure Linux mettent à disposition des correctifs de sécurité du système d’exploitation 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 Node. AKS fournit des mises à jour hebdomadaires des images de Node. 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 sont mises en forme par date (par exemple, 202311.07.0) pour Linux et par version et date du système d’exploitation Windows Server (par exemple, 20348.2113.231115) pour Windows. Pour plus d’informations, consultez les statuts de sortie AKS.

  • Versions trimestrielles de Kubernetes. AKS fournit des mises à jour trimestrielles pour les versions kubernetes. Ces mises à jour permettent aux utilisateurs AKS de bénéficier des dernières fonctionnalités et améliorations kubernetes. Ils incluent des correctifs de sécurité et des mises à jour d’images de Node. Pour plus d’informations, consultez les Versions de Kubernetes prises en charge dans AKS.

Considérations de mise à niveau

Impact global du groupement

  • Les mises à niveau sur place (à la fois le Node et le groupement) affectent les performances de votre environnement Kubernetes pendant qu’elles sont en cours. Vous pouvez réduire cet effet par le biais d’une configuration appropriée des budgets d’interruption des pods, de la configuration de la surtension des Nodes et de la planification appropriée.
  • L’utilisation d’une stratégie de mise à jour bleue/verte au lieu de la mise à niveau en place élimine tout impact sur les performances du groupement, mais augmente les coûts et la complexité.
  • Quelle que soit votre stratégie de mise à niveau et de mise à jour corrective, vous devez disposer d’un processus de test et de validation robuste pour votre groupement. Tout d’abord, corrigez et mettez à niveau des environnements inférieurs, puis effectuez une validation post-maintenance pour vérifier le groupement, Node, déploiement et l’intégrité de l’application.

Bonnes pratiques relatives aux charges de travail AKS

Pour garantir la bonne opération de votre groupement AKS pendant la maintenance, suivez les bonnes pratiques suivantes :

  • Définir des budgets de perturbation de pod (PDB). La configuration des budgets d’interruption de pod pour vos déploiements est essentielle. 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 et le drain nécessaires qui se produisent avec une mise à niveau propagée d’image de Node. En outre, si trop de pods sont déplacés simultanément, une panne d’application peut se produire. La configuration PDB atténue ce risque.

  • 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 de quota du 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 de machine virtuelle pour vos Nodes, ainsi que le nombre de machines virtuelles et de groupes de machines virtuelles identiques. Si vous êtes proche d’une limite, demandez une augmentation du quota avant de procéder à la mise à niveau.
  • Vérifiez l’espace IP disponible dans les sous-réseaux de Nodes. Pendant les mises à jour, des Node de surtension supplémentaires sont créés dans votre groupement et les pods sont déplacés vers ces Nodes. Il est important de surveiller l’espace d’adressage IP dans vos sous-réseaux de Nodes pour vous assurer qu’il existe suffisamment d’espace d’adressage pour que ces modifications se produisent. Différentes configurations réseau Kubernetes ont des exigences IP différentes. En guise de point de départ, passez en revue ces considérations :
    • Pendant une mise à niveau, le nombre d’adresses IP de Node augmente en fonction de votre valeur de surtension. (La valeur minimale de surtension est 1)
    • Les groupements basés sur Azure CNI attribuent des adresses IP à des pods individuels. Il doit donc y avoir suffisamment d’espace IP pour le déplacement des pods.
    • Votre groupement continue à fonctionner pendant les mises à niveau. Assurez-vous qu’il reste suffisamment d’espace IP pour autoriser la mise à l’échelle des Nodes (si elle est activée).
  • Configurez plusieurs environnements. Nous vous recommandons de configurer des environnements distincts, tels que le développement, la préproduction et la production, pour vous permettre de tester et de valider les modifications avant de les déployer en production.
  • 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. Vous pouvez augmenter la vitesse d’une mise à niveau AKS en augmentant cette valeur. 33% de surtension 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.
  • Régler le délai d’expiration du drainage du nœud. Le délai d’expiration du drainage du nœud spécifie la durée maximale pendant laquelle un cluster attend pendant la tentative de replanifier les pods sur un nœud qui est mis à jour. La valeur par défaut est 30 minutes. Pour les charges de travail qui ont du mal à replanifier les pods, il peut être utile d’ajuster cette valeur par défaut.
  • 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 maximale et surveillez les performances du groupement pour garantir un dimensionnement adéquat, en particulier pendant les processus de mise à jour.
  • Vérifiez les autres dépendances dans votre groupement. Les opérateurs Kubernetes déploient souvent d’autres outils sur le groupement Kubernetes dans le cadre d’opérations, comme les scalers KEDA, Dapr et les maillages de service. Lorsque vous planifiez vos processus de mise à niveau, case activée notes de publication pour tous les composants que vous utilisez pour garantir la compatibilité avec la version cible.

Gestion des mises à jour hebdomadaires des images de Node

Microsoft crée une image de Node pour les nœuds AKS environ une fois par semaine. Une image de Node contient des correctifs de sécurité du système d’exploitation à jour, des mises à jour du noyau du système d’exploitation, des mises à jour de sécurité de Kubernetes, des versions mises à jour de binaires comme kubelet, et des mises à jour de versions de composants qui sont répertoriées dans les notes de publication.

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

  • Un Node avec l’image mise à jour est ajouté au pool de Nodes. Le nombre de nœuds ajoutés en même temps est régi par la valeur de surtension.
  • En fonction de la valeur de la surtension, un lot de nœuds existants sont isolés 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 que ces nœuds sont entièrement vidés, ils sont retirés du pool de nœuds. Les nœuds mis à jour ajoutés par la surtension les remplacent.
  • Ce processus est répété pour chaque lot restant de nœuds à mettre à 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

En règle générale, la plupart des groupements doivent utiliser le canal de mise à jour NodeImage. Ce canal fournit un VHD d’image de Node mis à jour chaque semaine et est mis à jour en fonction de la fenêtre de maintenance de votre groupement.

Les canaux disponibles sont les suivants :

  • None. Aucune mise à jour n’est appliquée automatiquement.
  • Unmanaged. Les mises à jour Ubuntu et Linux Azure sont appliquées par le système d’exploitation tous les soirs. Les redémarrages doivent être gérés séparément. AKS n’est pas en mesure de tester cela ni d’en contrôler la cadence.
  • SecurityPatch. Les patches de sécurité du système d’exploitation qui sont testés par l’AKS, entièrement gérés et appliqués avec des pratiques de déploiement sûres. Il ne contient pas de corrections de bogues du système d’exploitation, mais uniquement des mises à jour de sécurité.
  • NodeImage. AKS met à jour les nœuds avec un disque dur virtuel récemment corrigé contenant des correctifs de sécurité et des correctifs de bogues à une cadence hebdomadaire. Il est entièrement testé et déployé selon des pratiques de déploiement sûres. 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 comprendre les cadences par défaut sans fenêtre de maintenance établie, consultez la section Propriété et cadence 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. Unmanaged n’est pas fourni avec les pratiques de déploiement sûres d’AKS et ne fonctionnera pas pendant les fenêtres de maintenance. Si vous choisissez la chaîne de mise à jour SecurityPatch, les mises à jour peuvent être appliquées jusqu’à une fréquence hebdomadaire. Ce niveau de correctif nécessite que les VHD soient stockés dans votre groupe de ressources, ce qui entraîne des frais nominals. Contrôlez le moment où le SecurityPatch est appliqué en définissant un aksManagedNodeOSUpgradeSchedule approprié qui s’aligne sur une cadence qui convient le mieux à votre charge de travail. Pour plus d’informations, consultez la section Création d’une fenêtre de maintenance. 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 bonne pratique, utilisez le canal de mise à jour NodeImage et configurez une fenêtre de maintenance aksManagedNodeOSUpgradeSchedule à un moment où le groupement est en dehors des fenêtres d’utilisation maximales. Consultez Création d’une fenêtre de maintenance pour les attributs que vous pouvez utiliser pour configurer la fenêtre de maintenance du groupement. 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.

Cet exemple montre comment définir 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

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

Cette configuration serait idéalement déployée dans le cadre du déploiement d’infrastructure en tant que code du groupement.

Vous pouvez vérifier les fenêtres de maintenance configurées à l’aide d’Azure CLI :

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

Vous pouvez également case activée les détails d’une fenêtre de maintenance spécifique à l’aide de 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. Autant que possible, la maintenance AKS se produit dans la fenêtre configurée, mais le temps de maintenance n’est pas garanti.

Important

Si vous disposez d’un pool de nœuds avec un grand nombre de nœuds mais qu’il n’est pas configuré avec une surcharge de nœuds, l’événement de mise à niveau automatique peut 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 cette situation, vous pouvez envisager l’une des solutions suivantes :

  • division des nœuds en différents pools de nœuds si votre quota vCPU est presque plein et que vous ne pouvez pas augmenter le quota vCPU.
  • configurer le surnombre de nœuds pour réduire le temps de mise à niveau estimé si votre quota de vCPU est suffisant

Vous pouvez vérifier l’état des événements de mise à niveau via vos Journaux d’activité Azure ou en examinant les journaux des ressources sur votre groupement.

Vous pouvez vous Abonner aux événements Azure Kubernetes Service (AKS) avec Azure Event Grid qui incluent les événements de mise à niveau AKS. Ces événements peuvent vous alerter quand 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.

Processus de mise à jour manuelle des Nodes

Utilisez la commande kubectl describe nodes pour déterminer la version du noyau du système d’exploitation et la version de l’image du système d’exploitation des Nodes de votre groupement :

kubectl describe nodes <NodeName>

Exemple de sortie (tronquée) :

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

Utilisez la commande Azure CLI az aks nodepool list pour déterminer les versions des images des Nodes d’un groupement :

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

Exemple de sortie :

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

Utilisez az aks nodepool get-upgrades pour découvrir la dernière version de l’image de nœud pour un pool de Nodes spécifique :

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

Exemple de sortie :

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

Mise à niveau des clusters

La communauté Kubernetes publie des versions mineures de Kubernetes environ tous les trois mois. Pour vous informer des nouvelles versions et versions d’AKS, la page des notes de publication AKS est mise à jour régulièrement. Vous pouvez également vous abonner au flux RSS GITHub 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 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 la Politique de prise en charge AKS.

Pour vous assurer que vos groupements AKS restent pris en charge, vous devez établir un processus de mise à niveau de groupement continu. 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 peut maintenir la prévisibilité dans votre processus de mise à niveau et réduire les interruptions des applications. Pour plus d’informations, consultez Mettre à niveau un cluster AKS.

Si votre groupement nécessite un cycle de mise à niveau plus long, utilisez les versions AKS qui prennent en charge l’option LTS (Long Term Support). Si vous activez l’option LTS, Microsoft fournit une prise en charge étendue des versions de Kubernetes pendant deux ans, ce qui permet un cycle de mise à niveau plus prolongé et contrôlé. Pour plus d’informations, consultez les Versions de Kubernetes prises en charge dans AKS.

Une mise à niveau de groupement inclut une mise à niveau de Node et utilise un processus similaire de cordon et de vidange.

Avant de procéder à la mise à niveau

En guise de bonne pratique, vous devez toujours mettre à niveau et tester 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éconseillées. Dans la page de présentation du groupement dans le Portail Azure, vous pouvez sélectionner Diagnostiquer et résoudre les problèmes, accéder à la catégorie Créer, Mettre à niveau, Supprimer et Mettre à l’échelle, puis sélectionner Déconseillés dans l’API Kubernetes Kubernetes. Cette opération exécute un classeur qui case activée pour les versions d’API déconseillées utilisées dans votre groupement. 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 versions 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, qui mettent en évidence les informations critiques susceptibles d’affecter votre groupement AKS.
  • Les composants AKS cassant les modifications par version. Ce tableau fournit une vue d’ensemble complète des changements cassants dans les composants AKS, par version. En faisant référence à ce guide, vous pouvez résoudre de manière proactive tous les problèmes de compatibilité potentiels avant le processus de mise à niveau.

En plus de ces ressources Microsoft, envisagez d’utiliser des outils open source pour optimiser votre processus de mise à niveau de groupement. L’un de ces outils est Fairwinds pluto, qui peut analyser vos déploiements et graphiques Helm pour les API Kubernetes déconseillés. Ces outils peuvent vous aider à vous assurer que vos applications restent compatibles avec les dernières versions de Kubernetes.

Mise à niveau

Pour vérifier le moment où votre groupement nécessite une mise à niveau, utilisez az aks get-upgrades afin d’obtenir la liste des versions de mise à niveau disponibles pour votre plan de contrôle AKS. Déterminez la version cible pour votre cluster à partir des résultats.

Voici un exemple :

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

Exemple de sortie :

MasterVersion  Upgrades
-------------  ---------------------------------
1.26.6         1.27.1, 1.27.3

Vérifiez les versions Kubernetes des Nodes dans vos pools de Nodes pour déterminer les pools qui doivent être mis à niveau :

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

Exemple de sortie :

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

Mise à niveau manuelle

Pour réduire les interruptions et garantir une mise à niveau fluide pour votre groupement AKS, suivez cette approche de mise à niveau :

  1. Mettre à niveau le plan de contrôle AKS. Commencez par mettre à niveau le plan de contrôle AKS. Cette étape implique la mise à niveau des composants du plan de contrôle responsables de la gestion et de l’orchestration de votre groupement. La mise à niveau du plan de contrôle permet d’abord de garantir la compatibilité et la stabilité avant de mettre à niveau les pools de Node individuels.
  2. 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 Nodes se composent des instances de machine virtuelle qui exécutent vos charges de travail d’application. La mise à niveau des pools de Nodes permet séparément une mise à niveau contrôlée et systématique de l’infrastructure sous-jacente qui prend en charge vos applications.
  3. Mettre à niveau des pools de Nodes utilisateurs. Après avoir mis à niveau le pool de Nodes de votre système, mettez à niveau tous les pools de Nodes utilisateur dans votre groupement AKS.

En suivant cette approche, vous pouvez réduire les interruptions pendant le processus de mise à niveau et maintenir la disponibilité de vos applications. Voici les étapes détaillées :

  1. Exécutez la commande az aks upgrade avec l’indicateur --control-plane-only pour mettre à niveau uniquement le plan de contrôle de groupement, et non les pools de Nodes du groupements :

    az aks upgrade \
   --resource-group <ResourceGroupName> --name <AKSClusterName> \
   --control-plane-only \
   --kubernetes-version <KubernetesVersion>

  2. Exécutez 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 Nodes, AKS crée un Node de surtension, cordonne et draine les pods dans le Node en cours de mise à niveau, réimage le Node, puis dé-cordonne les pods. Ce processus se répète ensuite pour tous les autres Nodes du pool de Nodes.

Vous pouvez vérifier 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 des groupements, consultez la documentation de dépannage d’AKS.

Inscrire des clusters dans des canaux de mise à niveau automatique

AKS offre également une solution de mise à niveau automatique de groupement pour maintenir votre cluster à jour. Si vous utilisez cette solution, vous devez l’associer à 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 groupement offre différentes options de canal de mise en production. Voici un environnement recommandé et une configuration de canal de mise en production :

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 Pour vous assurer que vos tests sont représentatifs de la version vers laquelle vous mettrez à jour votre environnement de production, utilisez le même canal de diffusion que la production.
Contrôle de validité rapid Pour tester les dernières versions de Kubernetes et les nouvelles fonctionnalités ou API d’AKS, utilisez le canal rapid. Vous pouvez améliorer votre délai de mise sur le marché lorsque la version rapid est promue sur le canal que vous utilisez pour la production.

À propos de l’installation

Le tableau suivant décrit les caractéristiques des différents scénarios de mise à niveau et de mise à jour corrective d’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 No 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 du pool de Nodes Oui No 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 groupement 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 de l’image d’un Node peut installer une version plus récente du noyau que celle qu’installerait la création d’un nouveau groupement.
  • 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 quand des correctifs de sécurité sont appliqués et que les Nodes redémarrent.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Autres contributeurs :

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

Étapes suivantes