Édition

Partage via

Gestion des nœuds et des pools de nœuds Kubernetes

Azure Kubernetes Service (AKS)
Machines virtuelles Azure

L’architecture Kubernetes repose sur deux couches : le plan de contrôle et un ou plusieurs nœuds dans des pools de nœuds. Cet article décrit et compare la façon dont Amazon Elastic Kubernetes Service (Amazon EKS) et Azure Kubernetes Service (AKS) gèrent les nœuds d’agent ou Worker.

Remarque

Cet article fait partie d'une série d'articles qui aide les professionnels qui connaissent Amazon EKS à comprendre Azure Kubernetes Service (AKS).

Dans Amazon EKS et AKS, la plateforme cloud fournit et gère la couche du plan de contrôle, et le client gère la couche des nœuds. Le diagramme suivant montre la relation entre le plan de contrôle et les nœuds dans l’architecture AKS Kubernetes.

Diagramme montrant le plan de contrôle et les nœuds dans l’architecture AKS.

Groupes de nœuds managés Amazon EKS

Les groupes de nœuds managés Amazon EKS automatisent le provisionnement et la gestion de cycle de vie des nœuds Worker EC2 (Amazon Elastic Compute Cloud) pour les clusters Amazon EKS. Les utilisateurs d’AWS (Amazon Web Services) peuvent avoir recours à l’utilitaire de ligne de commande eksctl pour créer, mettre à jour ou arrêter des nœuds pour leurs clusters EKS. Les mises à jour et les arrêts de nœuds isolent et drainent automatiquement les nœuds pour garantir la disponibilité des applications.

Chaque nœud managé est provisionné dans le cadre d’un groupe Amazon EC2 Auto Scaling exploité et contrôlé par Amazon EKS. L’autoscaler de cluster Kubernetes ajuste automatiquement le nombre de nœuds Worker dans un cluster quand les pods échouent ou quand ils sont replanifiés sur d’autres nœuds. Chaque groupe de nœuds peut être configuré pour s’exécuter sur plusieurs zones de disponibilité au sein d’une région.

Pour plus d’informations sur les nœuds managés Amazon EKS, consultez Création d’un groupe de nœuds managés et Mise à jour d’un groupe de nœuds managés.

Vous pouvez également exécuter des pods Kubernetes sur AWS Fargate. Fargate fournit une capacité de calcul à la demande et de taille appropriée pour les conteneurs. Pour plus d’informations sur l’utilisation de Fargate avec Amazon EKS, consultez AWS Fargate.

Karpenter

Karpenter est un projet open source conçu pour améliorer la gestion du cycle de vie des nœuds dans les clusters Kubernetes. Il automatise l’approvisionnement et le déprovisionnement de nœuds en fonction des besoins de planification spécifiques des pods, ce qui permet une mise à l’échelle efficace et une optimisation des coûts. Ses principales fonctions sont les suivantes :

  • Surveillez les pods que le planificateur Kubernetes ne peut pas planifier en raison de contraintes de ressources.
  • Évaluez les exigences de planification (demandes de ressources, sélecteurs de nœuds, affinités, tolérances, etc.) des pods non planifiés.
  • Provisionnez de nouveaux nœuds qui répondent aux exigences de ces pods.
  • Supprimez les nœuds lorsqu’ils ne sont plus nécessaires.

Avec Karpenter, vous définissez NodePools avec des contraintes sur l’approvisionnement de nœuds, comme les teintes, les étiquettes, les exigences (types d’instances, zones, etc.) et les limites du nombre total de ressources provisionnées. Lors du déploiement de charges de travail, vous spécifiez différentes contraintes de planification dans les spécifications de pod, telles que les demandes/limites de ressources, les sélecteurs de nœuds, les affinités de nœud/pod, les tolérances et les contraintes de répartition de topologie. Karpenter provisionne ensuite des nœuds de taille appropriée en fonction de ces spécifications.

Avant le lancement de Karpenter, les utilisateurs d’Amazon EKS s’appuient principalement sur groupes de mise à l’échelle automatique Amazon EC2 et les autoscaler de cluster Kubernetes (CAS) pour ajuster dynamiquement la capacité de calcul de leurs clusters. Vous n’avez pas besoin de créer des dizaines de groupes de nœuds pour obtenir la flexibilité et la diversité que vous obtenez avec Karpenter. Contrairement à La mise à l’échelle automatique du cluster Kubernetes, Karpenter n’est pas aussi étroitement couplé aux versions de Kubernetes et ne vous oblige pas à passer entre les API AWS et Kubernetes.

Karpenter consolide les responsabilités d’orchestration des instances au sein d’un système unique, plus simple, plus stable et plus sensible au cluster. Karpenter a été conçu pour surmonter certains des défis présentés par Cluster Autoscaler en fournissant des méthodes simplifiées pour :

  • Provisionner des nœuds en fonction des exigences de charge de travail.
  • Créez diverses configurations de nœud par type d’instance, à l’aide d’options NodePool flexibles. Au lieu de gérer de nombreux groupes de nœuds personnalisés spécifiques, Karpenter peut vous permettre de gérer diverses capacités de charge de travail avec un nodePool unique et flexible.
  • Obtenez une planification améliorée des pods à grande échelle en lançant rapidement des nœuds et des pods de planification.

Pour plus d’informations et de documentation sur l’utilisation de Karpenter, visitez le site karpenter.sh.

Karpenter rapproche la gestion de la mise à l’échelle des API natives Kubernetes que groupes de mise à l’échelle automatique (ASG) et groupes de nœuds managés (MNG). Les GROUPES ASG et les MNG sont des abstractions natives AWS où la mise à l’échelle est déclenchée en fonction des métriques de niveau AWS, telles que la charge du processeur EC2. Cluster Autoscaler relie les abstractions Kubernetes en abstractions AWS, mais perd une certaine flexibilité en raison de cela, comme la planification d’une zone de disponibilité spécifique.

Karpenter supprime une couche d’abstraction AWS pour apporter une certaine flexibilité directement dans Kubernetes. Karpenter est mieux utilisé pour les clusters avec des charges de travail qui rencontrent des périodes de demande élevée, spiky ou ont des exigences de calcul variées. Les groupes de sécurité réseau et les asG sont adaptés aux clusters exécutant des charges de travail qui ont tendance à être plus statiques et cohérentes. Vous pouvez utiliser une combinaison de nœuds gérés dynamiquement et statiquement, en fonction de vos besoins.

Conteneurs Kata

Kata Containers est un projet open source qui fournit un runtime de conteneur sécurisé qui combine la nature légère des conteneurs avec les avantages de sécurité des machines virtuelles. Il répond au besoin d’une isolation et d’une sécurité de charge de travail plus fortes en démarrant chaque conteneur avec un système d’exploitation invité différent, contrairement aux conteneurs traditionnels qui partagent le même noyau Linux entre les charges de travail. Les conteneurs Kata exécutent des conteneurs dans une machine virtuelle conforme à OCI, ce qui offre une isolation stricte entre les conteneurs sur la même machine hôte. conteneurs Kata fournissent les fonctionnalités suivantes :

  • isolation améliorée de la charge de travail: chaque conteneur s’exécute sur sa propre machine virtuelle légère, garantissant ainsi l’isolation au niveau du matériel.
  • amélioration de la sécurité: l’utilisation de la technologie de machine virtuelle fournit une couche de sécurité supplémentaire, ce qui réduit le risque de ruptures de conteneur.
  • Compatibilité avec les normes du secteur: Kata Containers s’intègrent à des outils standard tels que le format de conteneur OCI et l’interface CRI Kubernetes.
  • prise en charge de plusieurs architectures et hyperviseurs: Kata Containers prend en charge les architectures AMD64 et ARM et peut être utilisée avec des hyperviseurs tels que Cloud-Hypervisor et Firecracker.
  • de déploiement et de gestion faciles : Kata Containers élimine la complexité de l’orchestration des charges de travail en tirant parti du système d’orchestration Kubernetes.

Les clients AWS peuvent configurer et exécuter Kata Containers sur AWS en configurant un cluster Amazon Elastic Kubernetes Service (EKS) pour utiliser Firecracker, une technologie de virtualisation open source développée par Amazon pour créer et gérer des services multilocataires sécurisés et basés sur des fonctions. Firecracker permet aux clients de déployer des charges de travail dans des machines virtuelles légères, appelées microVMs, qui fournissent une sécurité renforcée et une isolation des charges de travail sur des machines virtuelles traditionnelles, tout en permettant la vitesse et l’efficacité des ressources des conteneurs. L’activation de Kata Containers sur AWS EKS nécessite une série d’étapes manuelles décrites dans Amélioration de l’isolation et de la sécurité de la charge de travail Kubernetes à l’aide de Kata Containers.

Hôtes dédiés

Exécution de conteneurs sur des hôtes dédiés Amazon EC2 avec AWS EKS

Lorsque vous utilisez Amazon Elastic Kubernetes Service (EKS) pour déployer et exécuter des conteneurs, il est possible de les exécuter sur hôtes dédiés Amazon EC2. Toutefois, il est important de noter que cette fonctionnalité est disponible uniquement pour les groupes de nœuds auto-gérés. Cela signifie que les clients doivent créer manuellement un modèle de lancement , groupes de mise à l’échelle automatiqueet les inscrire auprès du cluster EKS. Le processus de création de ces ressources est identique à celui de la mise à l’échelle automatique EC2 générale.

Pour plus d’informations sur l’exécution de conteneurs sur des hôtes dédiés EC2 avec AWS EKS, consultez la documentation suivante :

Nœuds et pools de nœuds AKS

La création d’un cluster AKS crée et configure automatiquement un plan de contrôle qui fournit les services Kubernetes de base et l’orchestration des charges de travail d’application. La plateforme Azure fournit gratuitement le plan de contrôle AKS en tant que ressource Azure managée. Le plan de contrôle et ses ressources existent uniquement dans la région où vous avez créé le cluster.

Les nœuds, également appelés nœuds d’agent ou nœuds Worker, hébergent les charges de travail et les applications. Dans AKS, les clients gèrent et paient entièrement les nœuds d’agent attachés au cluster AKS.

Pour exécuter des applications et les services associés, un cluster AKS a besoin d’au moins un nœud : une machine virtuelle Azure pour exécuter les composants du nœud Kubernetes et le runtime de conteneur. Chaque cluster AKS doit contenir au moins un pool de nœuds système avec au moins un nœud.

AKS regroupe les nœuds de la même configuration dans des pools de nœuds de machines virtuelles qui exécutent des charges de travail AKS. Les pools de nœuds système sont principalement utilisés pour héberger des pods système critiques tels que CoreDNS. Les pools de nœuds utilisateur sont principalement utilisés pour héberger des pods de charge de travail. Si vous souhaitez n’avoir qu’un seul pool de nœuds dans votre cluster AKS, par exemple dans un environnement de développement, vous pouvez planifier des pods d’application sur le pool de nœuds système.

Diagramme montrant un seul nœud Kubernetes.

Vous pouvez également créer plusieurs pools de nœuds utilisateur pour séparer différentes charges de travail sur différents nœuds afin d’éviter le problème de voisin bruyant ou pour prendre en charge des applications avec différentes demandes de calcul ou de stockage.

Chaque nœud d’agent d’un pool de nœuds système ou utilisateur est une machine virtuelle provisionnée dans le cadre d’Azure Virtual Machine Scale Sets et gérée par le cluster AKS. Pour plus d’informations, consultez Nœuds et pools de nœuds.

Vous pouvez définir le nombre initial et la taille des nœuds Worker quand vous créez un cluster AKS ou quand vous ajoutez de nouveaux nœuds et pools de nœuds à un cluster AKS existant. Si vous ne spécifiez pas une taille de machine virtuelle, la taille par défaut est Standard_D2s_v3 pour les pools de nœuds Windows et Standard_DS2_v2 pour les pools de nœuds Linux.

Important

Pour que les appels intranœuds et les communications avec les services de plateforme bénéficient d’une meilleure latence, sélectionnez une série de machines virtuelles qui prend en charge les performances réseau accélérées.

Création d’un pool de nœuds

Vous pouvez ajouter un pool de nœuds à un cluster AKS nouveau ou existant en utilisant le portail Azure, Azure CLI, l’API REST AKS ou des outils IaC (Infrastructure as Code) tels que Bicep, des modèles Azure Resource Manager ou Terraform. Pour plus d’informations sur l’ajout de pools de nœuds à un cluster AKS existant, consultez Créer et gérer plusieurs pools de nœuds pour un cluster dans Azure Kubernetes Service (AKS).

Quand vous créez un pool de nœuds, le groupe de machines virtuelles identiques associé est créé dans le groupe de ressources de nœud, un groupe de ressources Azure qui contient toutes les ressources d’infrastructure du cluster AKS. Ces ressources incluent les nœuds Kubernetes, les ressources de réseau virtuel, les identités managées et le stockage.

Par défaut, le nom du groupe de ressources de nœud ressemble à ceci : MC_<resourcegroupname>_<clustername>_<location>. AKS supprime automatiquement le groupe de ressources de nœud lors de la suppression d’un cluster. Vous devez donc utiliser ce groupe de ressources uniquement pour les ressources qui partagent le cycle de vie du cluster.

Ajouter un pool de nœuds

L’exemple de code suivant utilise la commande Azure CLI az aks nodepool add pour ajouter un pool de nœuds nommé mynodepool avec trois nœuds à un cluster AKS existant appelé myAKSCluster dans le groupe de ressources myResourceGroup.

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

Pools de nœuds spot

Un pool de nœuds spot est un pool de nœuds associé à un groupe de machines virtuelles identiques spot. L’utilisation de machines virtuelles spot pour les nœuds avec votre cluster AKS vous permet de tirer parti de la capacité Azure inutilisée et de réaliser des économies importantes. La quantité de capacité inutilisée disponible varie en fonction de nombreux facteurs, notamment la taille des nœuds, la région et l’heure de la journée.

Lors du déploiement d’un pool de nœuds spot, Azure alloue les nœuds spot si de la capacité est disponible. Mais il n'y a pas de contrat SLA (Service Level Agreement) pour les nœuds ponctuels. Un groupe identique spot, sur lequel s’appuie le pool de nœuds spot, est déployé dans un domaine d’erreur unique. Il n’offre aucune garantie de haute disponibilité. Quand Azure a besoin de la capacité, l’infrastructure Azure supprime les nœuds spot et vous recevez au maximum un préavis de 30 secondes avant l’éviction. Sachez qu’un pool de nœuds spot ne peut pas être le pool de nœuds par défaut du cluster. Un pool de nœuds spot ne peut être utilisé que pour un pool secondaire.

Les nœuds spot sont destinés aux charges de travail capables de gérer les interruptions, les arrêts prématurés ou les évictions. Par exemple, les travaux de traitement par lots, les environnements de développement et de test ainsi que les charges de travail de calcul importantes se prêtent bien à la planification sur un pool de nœuds spot. Pour plus de détails, consultez les limitations de l’instance spot.

La commande az aks nodepool add suivante ajoute un pool de nœuds spot à un cluster existant avec la mise à l’échelle automatique activée.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

Pour plus d’informations sur les pools de nœuds spot, consultez Ajouter un pool de nœuds spot à un cluster Azure Kubernetes Service (AKS).

Disques de système d’exploitation éphémères

Par défaut, Azure réplique automatiquement le disque de système d’exploitation d’une machine virtuelle dans Stockage Azure pour éviter toute perte de données en cas de déplacement de la machine virtuelle vers un autre hôte. Toutefois, les conteneurs n’étant pas conçus pour conserver l’état local, le fait de conserver le disque de système d’exploitation dans le stockage offre à AKS une valeur limitée. Il existe certains inconvénients, notamment un provisionnement des nœuds plus lent et une latence en lecture/écriture plus élevée.

En revanche, les disques de système d’exploitation éphémères sont stockés uniquement sur l’ordinateur hôte, comme un disque temporaire, et réduisent la latence en lecture/écriture tout en accélérant la mise à l’échelle des nœuds et les mises à niveau des clusters. À l’instar d’un disque temporaire, un disque de système d’exploitation éphémère est inclus dans le prix de la machine virtuelle, ce qui signifie que vous n’encourez aucun coût de stockage supplémentaire.

Important

Si vous ne demandez pas explicitement de disques managés pour le système d’exploitation, AKS utilise par défaut un système d’exploitation éphémère, si possible, pour une configuration de pool de nœuds donnée.

Pour utiliser le système d’exploitation éphémère, le disque de système d’exploitation doit tenir dans le cache de la machine virtuelle. Dans la documentation sur les machines virtuelles Azure, la taille du cache des machines virtuelles est indiquée entre parenthèses à côté du débit d’E/S (taille du cache en gibibits Gio).

Par exemple, la taille de machine virtuelle Standard_DS2_v2 par défaut AKS avec une taille de disque de système d’exploitation par défaut de 100 Go prend en charge le système d’exploitation éphémère, mais ne dispose que de 86 Go de cache. Cette configuration utilise par défaut le disque managé si vous ne spécifiez pas explicitement le contraire. Si vous demandez explicitement le système d’exploitation éphémère pour cette taille, vous obtenez une erreur de validation.

Si vous demandez la même machine virtuelle Standard_DS2_v2 avec un disque de système d’exploitation de 60 Go, vous obtenez le système d’exploitation éphémère par défaut. La taille de système d’exploitation de 60 Go demandée est inférieure à la taille de cache maximale de 86 Go.

Standard_D8s_v3 avec un disque de système d’exploitation de 100 Go prend en charge le système d’exploitation éphémère et dispose de 200 Go d’espace de cache. Si un utilisateur ne spécifie pas le type de disque de système d’exploitation, un pool de nœuds obtient le système d’exploitation éphémère par défaut.

La commande az aks nodepool add suivante montre comment ajouter un nouveau pool de nœuds à un cluster existant avec un disque de système d’exploitation éphémère. Le paramètre --node-osdisk-type définit le type de disque de système d’exploitation sur Ephemeral et le paramètre --node-osdisk-size définit la taille du disque de système d’exploitation.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

Pour plus d’informations sur les disques de système d’exploitation éphémères, consultez la section Système d’exploitation éphémère.

Pools de nœuds de machines virtuelles dans Azure Kubernetes Service (AKS)

Chaque groupe de nœuds managés dans EKS est soutenu par un groupe de mise à l’échelle automatique Amazon EC2 , géré par Amazon EKS. Cette intégration permet à EKS de gérer automatiquement l’approvisionnement et la mise à l’échelle d’instances EC2 au sein du groupe de nœuds. Bien que les groupes de mise à l’échelle automatique puissent être configurés pour prendre en charge plusieurs types d’instances EC2, ils ne fournissent pas la possibilité de spécifier le nombre de nœuds à créer ou à mettre à l’échelle pour chaque type d’instance. Au lieu de cela, EKS gère la mise à l’échelle du groupe de nœuds en fonction de la configuration et des stratégies souhaitées définies par l’utilisateur. Cela garantit un processus de gestion simplifié et automatisé pour le groupe de nœuds tout en offrant une flexibilité en sélectionnant les types d’instances EC2 qui répondent aux besoins de votre charge de travail. Toutefois, les clients AWS peuvent lancer nœuds Amazon Linux auto-gérés avec eksctl ou la console de gestion AWS.

Avec pools de nœuds machines virtuelles, Azure Kubernetes Service (AKS) gère l’approvisionnement et le démarrage de chaque nœud d’agent. Pour les pools de nœuds Virtual Machine Scale Sets, AKS gère le modèle des groupes de machines virtuelles identiques et l’utilise pour assurer la cohérence entre tous les nœuds de l’agent dans le pool de nœuds. Au lieu de cela, les pools de nœuds machines virtuelles vous permettent d’orchestrer votre cluster avec des machines virtuelles qui correspondent le mieux à vos charges de travail individuelles et de spécifier le nombre de nœuds à créer ou à mettre à l’échelle pour chaque taille de machine virtuelle.

Un pool de nœuds se compose d’un ensemble de machines virtuelles, avec différentes tailles (SKU) désignées pour prendre en charge différents types de charges de travail. Ces tailles de machine virtuelle, appelées références SKU, sont classées dans différentes familles optimisées à des fins spécifiques. Pour plus d’informations sur les références SKU de machine virtuelle, consultez la vue d’ensemble des références SKU de machine virtuelle .

Pour activer la mise à l’échelle de plusieurs tailles de machine virtuelle, le type de pool de machines virtuelles utilise un ScaleProfile qui configure la façon dont le pool de nœuds est mis à l’échelle, en particulier la liste souhaitée de la taille et du nombre de machines virtuelles. Un ManualScaleProfile est un profil de mise à l’échelle qui spécifie la taille et le nombre de machines virtuelles souhaitées. Une seule taille de machine virtuelle est autorisée dans un ManualScaleProfile. Vous devez créer un ManualScaleProfile distinct pour chaque taille de machine virtuelle dans votre pool de nœuds.

Lorsque vous créez un pool de nœuds machines virtuelles, vous avez besoin d’au moins un ManualScaleProfile dans le ScaleProfile. Plusieurs profils de mise à l’échelle manuelle peuvent être créés pour un pool de nœuds de machines virtuelles unique.

Les avantages des pools de nœuds de machines virtuelles sont les suivants :

  • Flexibilité: les spécifications de nœud peuvent être mises à jour en fonction de vos charges de travail et besoins.
  • contrôle affiné: les contrôles au niveau du nœud unique permettent de spécifier et de mélanger des nœuds de différentes spécifications afin d’améliorer la cohérence.
  • Efficacité: vous pouvez réduire l’encombrement du nœud pour votre cluster, ce qui simplifie vos besoins opérationnels.

Les pools de nœuds de machines virtuelles offrent une meilleure expérience pour les charges de travail dynamiques et les exigences de haute disponibilité. Ils vous permettent de configurer plusieurs machines virtuelles de la même famille dans un pool de nœuds, avec votre charge de travail automatiquement planifiée sur les ressources disponibles que vous configurez.

Le tableau suivant compare les pools de nœuds de machines virtuelles à des pools de nœuds standard groupe identique de nœuds.

Type de pool de nœuds Capacités
Pool de nœuds machines virtuelles Vous pouvez ajouter, supprimer ou mettre à jour des nœuds dans un pool de nœuds. Les types de machines virtuelles peuvent être n’importe quelle machine virtuelle du même type de famille (par exemple, série D, série A, etc.).
Pool de nœuds basé sur des groupes de machines virtuelles identiques Vous pouvez ajouter ou supprimer des nœuds de la même taille et du même type dans un pool de nœuds. Si vous ajoutez une nouvelle taille de machine virtuelle au cluster, vous devez créer un pool de nœuds.

Les pools de nœuds de machine virtuelle présentent les limitations suivantes :

  • mise à l’échelle automatique de cluster n’est pas prise en charge.
  • infiniBand n’est pas disponible.
  • Les pools de nœuds Windows ne sont pas pris en charge.
  • Cette fonctionnalité n’est pas disponible dans le portail Azure. Utilisez api AZURE CLI ou REST pour effectuer des opérations CRUD ou gérer le pool.
  • capture instantanée du pool de nœuds n’est pas prise en charge.
  • Toutes les tailles de machine virtuelle sélectionnées dans un pool de nœuds doivent provenir de la même famille de machines virtuelles. Par exemple, vous ne pouvez pas combiner un type de machine virtuelle série N avec un type de machine virtuelle série D dans le même pool de nœuds.
  • Les pools de nœuds machines virtuelles autorisent jusqu’à cinq tailles de machines virtuelles différentes par pool de nœuds.

Nœuds virtuels

Vous pouvez utiliser des nœuds virtuels pour effectuer rapidement un scale-out des charges de travail d’application dans un cluster AKS. Les nœuds virtuels permettent un provisionnement rapide des pods, et vous payez uniquement le temps d’exécution par seconde. Vous n’avez pas besoin d’attendre que l’autoscaler de cluster déploie de nouveaux nœuds Worker pour exécuter davantage de réplicas de pod. Les nœuds virtuels sont uniquement pris en charge avec les nœuds et pods Linux. Le module complémentaire Nœuds virtuels pour AKS est basé sur le projet open source Virtual Kubelet.

La fonctionnalité de nœud virtuel dépend d’Azure Container Instances. Pour plus d’informations sur les nœuds virtuels, consultez Créer et configurer un cluster Azure Kubernetes Services (AKS) pour utiliser des nœuds virtuels.

Taints, étiquettes et balises

Quand vous créez un pool de nœuds, vous pouvez ajouter des taints et des étiquettes Kubernetes ainsi que des balises Azure à ce pool de nœuds. Quand vous ajoutez un taint, une étiquette ou une balise, tous les nœuds du pool reçoivent ce taint, cette étiquette ou cette balise.

Pour créer un pool de nœuds avec un taint, vous pouvez utiliser la commande az aks nodepool add avec le paramètre --node-taints. Pour étiqueter les nœuds d’un pool de nœuds, vous pouvez utiliser le paramètre --labels et spécifier une liste d’étiquettes, comme indiqué dans le code suivant :

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

Pour plus d’informations, consultez Spécifier une teinte, une balise ou une étiquette pour un pool de nœuds.

Étiquettes système réservées

Amazon EKS ajoute des étiquettes Kubernetes automatisées à tous les nœuds d’un groupe de nœuds managés. Par exemple, eks.amazonaws.com/capacityType spécifie le type de capacité. De plus, AKS ajoute automatiquement des étiquettes système aux nœuds d’agent.

Les préfixes suivants sont réservés à AKS et ne peuvent pas être utilisés avec un nœud :

  • kubernetes.azure.com/
  • kubernetes.io/

Pour les autres préfixes réservés, consultez Étiquettes, annotations et taints bien connus de Kubernetes.

Le tableau suivant liste les étiquettes réservées à AKS. Vous ne pouvez pas les utiliser avec un nœud. Dans le tableau, la colonne Utilisation de nœud virtuel indique si l’étiquette est prise en charge sur les nœuds virtuels.

Dans la colonne Utilisation de nœud virtuel :

  • N/A signifie que la propriété ne s’applique pas aux nœuds virtuels, car cela nécessiterait de modifier l’hôte.
  • Identique signifie que les valeurs attendues sont les mêmes pour un pool de nœuds virtuels que pour un pool de nœuds standard.
  • Virtuel remplace les valeurs SKU de machine virtuelle, car les pods de nœuds virtuels n’exposent aucune machine virtuelle sous-jacente.
  • Version du nœud virtuel fait référence à la version actuelle de la version du connecteur Kubelet-ACI virtuel.
  • Nom du sous-réseau de nœuds virtuels est le sous-réseau qui déploie les pods de nœuds virtuels dans Azure Container Instances.
  • Réseau virtuel de nœuds virtuels est le réseau virtuel qui contient le sous-réseau de nœuds virtuels.
Étiquette Value Exemple, options Utilisation de nœud virtuel
kubernetes.azure.com/agentpool <agent pool name> nodepool1 Identique
kubernetes.io/arch amd64 runtime.GOARCH N/A
kubernetes.io/os <OS Type> Linux ou Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 Identique
topology.kubernetes.io/zone <Azure zone> 0 Identique
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 Identique
kubernetes.azure.com/mode <mode> User ou System User
kubernetes.azure.com/role agent Agent Identique
kubernetes.azure.com/scalesetpriority <scale set priority> Spot ou Regular N/A
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 Identique
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed N/A
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS N/A
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 Version du nœud virtuel
kubernetes.azure.com/subnet <nodepool subnet name> subnetName Nom de sous-réseau de nœud virtuel
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName Réseau virtuel de nœud virtuel
kubernetes.azure.com/ppg <nodepool ppg name> ppgName N/A
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name N/A
kubernetes.azure.com/accelerator <accelerator> Nvidia N/A
kubernetes.azure.com/fips_enabled <fips enabled> True N/A
kubernetes.azure.com/os-sku <os/sku> Consultez Créer ou mettre à jour une référence SKU de système d’exploitation. Référence SKU Linux

Pools de nœuds Windows

AKS prend en charge la création et l’utilisation de pools de nœuds de conteneur Windows Server par le biais du plug-in réseau Azure container network interface (CNI). Pour planifier les plages de sous-réseaux requises et les considérations relatives au réseau, consultez la section Configurer la mise en réseau d'Azure CNI.

La commande az aks nodepool add suivante ajoute un pool de nœuds qui exécute des conteneurs Windows Server.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

La commande précédente utilise le sous-réseau par défaut dans le réseau virtuel du cluster AKS. Pour plus d’informations sur la création d’un cluster AKS avec un pool de nœuds Windows, consultez Créer un conteneur Windows Server dans AKS.

Considérations relatives aux pools de nœuds

Les considérations et limitations suivantes s’appliquent quand vous créez et gérez des pools de nœuds et plusieurs pools de nœuds :

  • Les quotas, les restrictions de taille de machine virtuelle et la disponibilité des régions s’appliquent aux pools de nœuds AKS.
  • Les pools système doivent contenir au moins un nœud. Vous pouvez supprimer un pool de nœuds système si un autre pool de nœuds système peut prendre sa place dans le cluster AKS. Les pools de nœuds utilisateur peuvent contenir zéro ou plusieurs nœuds.
  • Vous ne pouvez pas changer la taille des machines virtuelles d’un pool de nœuds, une fois que vous l’avez créé.
  • Pour plusieurs pools de nœuds, le cluster AKS doit utiliser les équilibreurs de charge avec la référence SKU Standard. Les équilibreurs de charge avec la référence SKU De base ne prennent pas en charge plusieurs pools de nœuds.
  • Tous les pools de nœuds de cluster doivent se trouver dans le même réseau virtuel, et tous les sous-réseaux affectés à un pool de nœuds doivent se trouver dans le même réseau virtuel.
  • Si vous créez plusieurs pools de nœuds au moment de la création du cluster, les versions de Kubernetes de tous les pools de nœuds doivent correspondre à la version du plan de contrôle. Vous pouvez mettre à jour les versions une fois le cluster provisionné en utilisant des opérations par pool de nœuds.

Mise à l’échelle du pool de nœuds

À mesure que votre charge de travail d’application change, vous pouvez être amené à modifier le nombre de nœuds dans un pool de nœuds. Vous pouvez augmenter ou réduire manuellement le nombre de nœuds en utilisant la commande az aks nodepool scale. L’exemple suivant fait passer le nombre de nœuds dans mynodepool à cinq :

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

Mettre automatiquement à l’échelle des pools de nœuds avec l’autoscaler de cluster

AKS prend en charge la mise à l’échelle automatique des pools de nœuds avec l’autoscaler de cluster. Vous devez activer cette fonctionnalité sur chaque pool de nœuds et définir un nombre minimal et un nombre maximal de nœuds.

La commande az aks nodepool add suivante ajoute un nouveau pool de nœuds appelé mynodepool à un cluster existant. Le paramètre --enable-cluster-autoscaler active l’autoscaler de cluster sur le nouveau pool de nœuds, et les paramètres --min-count et --max-count spécifient les nombres minimal et maximal de nœuds dans le pool.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

La commande az aks nodepool update suivante fait passer le nombre minimal de nœuds de un à trois pour le pool de nœuds mynewnodepool.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

Vous pouvez désactiver l’autoscaler de cluster avec az aks nodepool update en passant le paramètre --disable-cluster-autoscaler.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

Pour réactiver l’autoscaler de cluster sur un cluster existant, utilisez az aks nodepool update en spécifiant les paramètres --enable-cluster-autoscaler, --min-count et --max-count.

Pour plus d’informations sur l’utilisation de l’autoscaler de cluster pour des pools de nœuds individuels, consultez Mettre automatiquement à l’échelle un cluster pour répondre aux demandes applicatives sur Azure Kubernetes Service (AKS).

Bac à sable de pod

Les clients AKS peuvent facilement configurer et exécuter kata Containers sur AKS de manière entièrement managée. Cela est rendu possible grâce à l’utilisation de pod sandboxing, une fonctionnalité qui crée une limite d’isolation entre l’application conteneur et le noyau partagé et les ressources de calcul de l’hôte de conteneur.

AKS inclut un mécanisme appelé sandboxing pod qui fournit une limite d’isolation entre l’application conteneur et le noyau partagé et les ressources de calcul de l’hôte de conteneur, comme le processeur, la mémoire et la mise en réseau. Le sandboxing pod complète d’autres mesures de sécurité ou contrôles de protection des données pour aider les charges de travail des locataires à sécuriser les informations sensibles et à répondre aux exigences réglementaires, sectorielles ou de conformité de la gouvernance, telles que la norme PCI DSS (Payment Card Industry Data Security Standard), l’Organisation internationale de normalisation (ISO) 27001 et la loi HIPAA (Health Insurance Portability and Accountability Act).

En déployant des applications sur des clusters ou des pools de nœuds distincts, vous pouvez isoler fortement les charges de travail client de différentes équipes ou clients. L’utilisation de plusieurs clusters et pools de nœuds peut convenir aux exigences d’isolation de nombreuses organisations et solutions SaaS, mais il existe des scénarios dans lesquels un seul cluster avec des pools de nœuds de machine virtuelle partagée est plus efficace. Par exemple, vous pouvez utiliser un cluster unique lorsque vous exécutez des pods non approuvés et approuvés sur le même nœud ou colocalisez des DaemonSets et des conteneurs privilégiés sur le même nœud pour accélérer la communication locale et le regroupement fonctionnel. pod sandboxing peut vous aider à isoler fortement les applications client sur les mêmes nœuds de cluster sans avoir à exécuter ces charges de travail dans des clusters ou des pools de nœuds distincts. D’autres méthodes nécessitent de recompiler votre code ou de provoquer d’autres problèmes de compatibilité, mais le bac à sable pod dans AKS peut exécuter n’importe quel conteneur non modifié à l’intérieur d’une limite de machine virtuelle de sécurité améliorée.

Le bac à sable de pod sur AKS est basé sur conteneurs Kata qui s’exécutent sur l’hôte de conteneur Linux Azure pour AKS pile pour fournir une isolation matérielle appliquée. Les conteneurs Kata sur AKS reposent sur un hyperviseur Azure renforcé par la sécurité. Elle permet d’isoler chaque pod via une machine virtuelle Kata imbriquée et légère qui utilise des ressources à partir d’un nœud de machine virtuelle parente. Dans ce modèle, chaque pod Kata obtient son propre noyau dans une machine virtuelle invitée Kata imbriquée. Utilisez ce modèle pour placer de nombreux conteneurs Kata dans une seule machine virtuelle invitée tout en continuant à exécuter des conteneurs dans la machine virtuelle parente. Ce modèle fournit une limite d’isolation forte dans un cluster AKS partagé.

Pour plus d’informations, consultez :

Hôte dédié Azure

'hôte dédié Azure est un service qui fournit des serveurs physiques dédiés à un abonnement Azure unique et qui fournissent une isolation matérielle au niveau du serveur physique. Vous pouvez provisionner ces hôtes dédiés au sein d’une région, d’une zone de disponibilité et d’un domaine d’erreur, et placer des machines virtuelles directement dans les hôtes approvisionnés.

Il existe plusieurs avantages à l’utilisation d’Azure Dedicated Host avec AKS, notamment :

  • L’isolation matérielle garantit qu’aucune autre machine virtuelle n’est placée sur les hôtes dédiés, ce qui fournit une couche supplémentaire d’isolation pour les charges de travail client. Les hôtes dédiés sont déployés dans les mêmes centres de données et partagent la même infrastructure de stockage réseau et sous-jacente que d’autres hôtes non isolés.
  • L’hôte dédié Azure assure le contrôle des événements de maintenance lancés par la plateforme Azure. Vous pouvez choisir une fenêtre de maintenance pour réduire l’impact sur les services et garantir la disponibilité et la confidentialité des charges de travail de locataire.

L’hôte dédié Azure peut aider les fournisseurs SaaS à garantir que les applications clientes répondent aux exigences réglementaires, sectorielles et de conformité de gouvernance pour sécuriser les informations sensibles. Pour plus d’informations, consultez Ajouter un hôte dédié Azure à un cluster AKS.

Karpenter

Karpenter est un projet de gestion du cycle de vie des nœuds open source conçu pour Kubernetes. L’ajout de Karpenter à un cluster Kubernetes peut améliorer l’efficacité et le coût de l’exécution des charges de travail sur ce cluster. Karpenter surveille les pods que le planificateur Kubernetes marque comme non planifié. Il provisionne et gère dynamiquement les nœuds qui peuvent répondre aux exigences du pod.

Karpenter fournit un contrôle précis sur l’approvisionnement de nœuds et le placement des charges de travail dans un cluster managé. Ce contrôle améliore l’architecture multilocataire en optimisant l’allocation des ressources, en garantissant l’isolation entre les applications de chaque locataire et en réduisant les coûts opérationnels. Lorsque vous créez une solution mutualisée sur AKS, Karpenter fournit des fonctionnalités utiles pour vous aider à gérer diverses exigences d’application pour prendre en charge différents locataires. Par exemple, vous devrez peut-être exécuter des applications de locataires sur des pools de nœuds optimisés par GPU et d’autres pour s’exécuter sur des pools de nœuds à mémoire optimisée. Si votre application nécessite une faible latence pour le stockage, vous pouvez utiliser Karpenter pour indiquer qu’un pod nécessite un nœud qui s’exécute dans une zone de disponibilité spécifique afin de pouvoir colocaliser votre niveau de stockage et d’application.

AKS active le provisionnement automatique des nœuds sur les clusters AKS via Karpenter. La plupart des utilisateurs doivent utiliser le mode de provisionnement automatique de nœud pour activer Karpenter en tant que module complémentaire managé. Pour plus d’informations, consultez de provisionnement automatique de nœud . Si vous avez besoin d’une personnalisation plus avancée, vous pouvez choisir d’héberger karpenter auto-hôte. Pour plus d’informations, consultez le fournisseur AKS Karpenter.

Machines virtuelles confidentielles

L’informatique confidentielle est une mesure de sécurité destinée à protéger les données en cours d’utilisation via l’isolation et le chiffrement assistés par logiciel ou matériel. Cette technologie ajoute une couche supplémentaire de sécurité aux approches traditionnelles, en protégeant les données au repos et en transit.

La plateforme AWS prend en charge l’informatique confidentielle via Nitro Enclaves, qui sont disponibles sur des instances EC2 ainsi que sur Amazon Elastic Kubernetes Service (EKS). Pour plus d’informations, consultez cet article sur Amazon. En outre, les instances Amazon EC2 prennent en charge AMD SEV-SNP . Ce référentiel GitHub fournit des artefacts pour générer et déployer un Amazon Machine Image (AMI) pour EKS avec prise en charge AMD SEV-SNP.

En revanche, Azure fournit aux clients des machines virtuelles confidentielles pour répondre à des exigences strictes d’isolation, de confidentialité et de sécurité au sein d’un cluster AKS. Ces machines virtuelles confidentielles utilisent un environnement d’exécution approuvé basé sur le matériel. Plus précisément, les machines virtuelles confidentielles Azure utilisent la technologie AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP), qui refuse l’accès aux hyperviseurs et à d’autres codes de gestion de l’hôte à la mémoire et à l’état de la machine virtuelle. Cela ajoute une couche supplémentaire de défense et de protection contre l’accès des opérateurs. Pour plus d’informations, vous pouvez consulter la documentation sur à l’aide de machines virtuelles confidentielles dans un de cluster AKS et la vue d’ensemble des machines virtuelles confidentielles dans Azure.

Normes de processus d’information fédérales (FIPS)

FIPS 140-3 est une norme gouvernementale américaine qui définit les exigences de sécurité minimales pour les modules de chiffrement dans les produits et systèmes informatiques. En activant conformité FIPS pour les pools de nœuds AKS, vous pouvez améliorer l’isolation, la confidentialité et la sécurité de vos charges de travail de locataire. conformité fiPS garantit l’utilisation de modules de chiffrement validés pour le chiffrement, le hachage et d’autres opérations liées à la sécurité. Avec les pools de nœuds AKS compatibles FIPS, vous pouvez répondre aux exigences de conformité réglementaires et sectorielles en utilisant des algorithmes et mécanismes de chiffrement robustes. Azure fournit une documentation sur la façon d’activer FIPS pour les pools de nœuds AKS, ce qui vous permet de renforcer la posture de sécurité de vos environnements AKS multilocataires. Pour plus d’informations, consultez Activer FIPS pour les pools de nœuds AKS.

Chiffrement basé sur l’hôte

Dans EKS, votre architecture peut avoir utilisé les fonctionnalités suivantes pour améliorer la sécurité des données :

chiffrement basé sur l’hôte sur AKS renforce davantage l’isolation, la confidentialité et la sécurité des charges de travail client. Lorsque vous activez le chiffrement basé sur l’hôte, AKS chiffre les données au repos sur les machines hôtes sous-jacentes, ce qui permet de s’assurer que les informations de locataire sensibles sont protégées contre un accès non autorisé. Les disques temporaires et les disques de système d’exploitation éphémères sont chiffrés au repos avec des clés gérées par la plateforme lorsque vous activez le chiffrement de bout en bout.

Dans AKS, les disques de système d’exploitation et de données utilisent le chiffrement côté serveur avec des clés gérées par la plateforme par défaut. Les caches de ces disques sont chiffrés au repos avec des clés gérées par la plateforme. Vous pouvez spécifier votre propre clé de chiffrement de clé pour chiffrer la clé de protection des données à l’aide du chiffrement d’enveloppe, également appelé de création de package de restrictions. Le cache du système d’exploitation et des disques de données est également chiffré via le BYOK que vous spécifiez.

Le chiffrement basé sur l’hôte ajoute une couche de sécurité pour les environnements multilocataires. Les données de chaque locataire dans le système d’exploitation et les caches de disque de données sont chiffrées au repos avec des clés gérées par le client ou gérées par la plateforme, en fonction du type de chiffrement de disque sélectionné. Pour plus d’informations, consultez :

Mises à jour et mises à niveau

Azure met régulièrement à jour sa plateforme d’hébergement de machines virtuelles pour améliorer la fiabilité, les performances et la sécurité. Ces mises à jour vont de l’application d’une mise à jour corrective aux composants logiciels de l’environnement d’hébergement à la mise à niveau des composants réseau ou à la désactivation de matériel. Pour plus d’informations sur la façon dont Azure met à jour les machines virtuelles, consultez Maintenance des machines virtuelles dans Azure.

Les mises à jour de l’infrastructure d’hébergement de machines virtuelles n’affectent généralement pas les machines virtuelles hébergées, notamment les nœuds d’agent de clusters AKS existants. Pour les mises à jour qui affectent les machines virtuelles hébergées, Azure minimise les cas nécessitant des redémarrages en suspendant la machine virtuelle pendant la mise à jour de l’hôte ou en migrant en direct la machine virtuelle vers un hôte déjà mis à jour.

Si une mise à jour nécessite un redémarrage, Azure fournit une notification et une fenêtre de temps pour que vous puissiez démarrer la mise à jour quand cela vous convient. La fenêtre d’automaintenance des machines hôtes est généralement de 35 jours, sauf si la mise à jour est urgente.

Vous pouvez utiliser la maintenance planifiée pour mettre à jour les machines virtuelles et gérer les notifications de maintenance planifiée avec Azure CLI, PowerShell ou le portail Azure. La maintenance planifiée détecte si vous utilisez la mise à niveau automatique de cluster et planifie automatiquement les mises à niveau durant votre fenêtre de maintenance. Pour plus d’informations sur la maintenance planifiée, consultez la commande az aks maintenanceconfiguration et Utiliser la maintenance planifiée pour planifier des fenêtres de maintenance pour votre cluster Azure Kubernetes Service (AKS).

Mises à niveau de Kubernetes

Une partie du cycle de vie d’un cluster AKS consiste à effectuer périodiquement des mises à niveau vers la dernière version de Kubernetes. Il est important d’appliquer les mises à niveau pour bénéficier des dernières versions et fonctionnalités de sécurité. Pour mettre à niveau la version de Kubernetes des machines virtuelles dans un pool de nœuds existant, vous devez isoler et drainer les nœuds et les remplacer par de nouveaux nœuds basés sur une image de disque Kubernetes mise à jour.

Par défaut, AKS configure les mises à niveau avec un nœud supplémentaire. Une valeur par défaut de un pour les paramètres max-surge minimise l’interruption de la charge de travail en créant un nœud supplémentaire pour remplacer les nœuds avec une version antérieure avant d’isoler ou de drainer les applications existantes. Vous pouvez personnaliser la valeur max-surge par pool de nœuds pour permettre un compromis entre la vitesse de la mise à niveau et l’interruption de la mise à niveau. Le fait d’augmenter la valeur max-surge accélère le processus de mise à niveau, mais une valeur élevée pour max-surge peut entraîner des interruptions pendant le processus de mise à niveau.

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 le drainage simultané de tous les nœuds du pool de nœuds. Vous pouvez utiliser cette valeur élevée à des fins de tests, mais un paramètre max-surge de 33 % est préférable pour les pools de nœuds de production.

AKS accepte à la fois des valeurs entières et des pourcentages pour max-surge. Un entier comme 5 indique une augmentation de cinq nœuds. Les pourcentages pour max-surge vont de 1% au minimum à 100% au maximum, le nombre de nœuds étant arrondi à la valeur entière la plus proche. Une valeur de 50% indique une augmentation égale à la moitié du nombre de nœuds actuel dans le pool.

Durant une mise à niveau, la valeur max-surge peut être égale au minimum à 1 et au maximum au nombre de nœuds dans le 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.

Important

Pour les opérations de mise à niveau, les augmentations de nœuds ont besoin d’un quota d’abonnement suffisant pour le nombre max-surge demandé. Par exemple, un cluster comprenant cinq pools de nœuds avec quatre nœuds chacun a 20 nœuds en tout. Si chaque pool de nœuds a une valeur max-surge de 50 %, vous avez besoin d’un quota de capacité de calcul et d’adresse IP supplémentaire de 10 nœuds (2 nœuds x 5 pools) pour effectuer la mise à niveau.

Si vous utilisez Azure Container Networking Interface (CNI), vérifiez également que vous avez suffisamment d’adresses IP dans le sous-réseau pour répondre aux exigences de CNI pour AKS.

Mettre à niveau des pools de nœuds

Pour voir les mises à niveau disponibles, utilisez az aks get-upgrades.

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

Pour voir l’état des pools de nœuds, utilisez az aks nodepool list.

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

La commande suivante utilise az aks nodepool upgrade pour mettre à niveau un pool de nœuds unique.

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

Pour plus d’informations sur la mise à niveau de la version de Kubernetes pour un plan de contrôle de cluster et des pools de nœuds, consultez :

Points importants relatifs à la mise à niveau

Notez ces bonnes pratiques et considérations relatives à la mise à niveau de la version de Kubernetes dans un cluster AKS.

  • Il est préférable de mettre à niveau tous les pools de nœuds dans un cluster AKS vers la même version de Kubernetes. Le comportement par défaut de az aks upgrade met à niveau tous les pools de nœuds et le plan de contrôle.

  • Effectuez la mise à niveau manuellement ou définissez un canal de mise à niveau automatique sur votre cluster. Si vous utilisez la maintenance planifiée pour appliquer des correctifs aux machines virtuelles, les mises à niveau automatiques démarrent également pendant la fenêtre de maintenance spécifiée. Pour plus d’informations, consultez Mettre à niveau un cluster Azure Kubernetes Service (AKS).

  • La commande az aks upgrade avec l’indicateur --control-plane-only met uniquement à niveau le plan de contrôle du cluster et ne modifie aucun des pools de nœuds associés dans le cluster. Pour mettre à niveau des pools de nœuds individuels, spécifiez le pool de nœuds cible et la version de Kubernetes dans la commande az aks nodepool upgrade.

  • Une mise à niveau de cluster AKS déclenche une isolation et un drainage de vos nœuds. Si votre quota de capacité de calcul est faible, la mise à niveau peut échouer. Pour plus d’informations sur l’augmentation de votre quota, consultez Augmenter les quotas de processeurs virtuels régionaux.

  • Configurez le paramètre max-surge en fonction de vos besoins, en utilisant un entier ou un pourcentage. Pour les pools de nœuds de production, utilisez un paramètre max-surge de 33 %. Pour plus d’informations, consultez Personnaliser la mise à niveau de l’augmentation des nœuds.

  • Quand vous mettez à niveau un cluster AKS qui utilise un réseau CNI, vérifiez que le sous-réseau a suffisamment d’adresses IP privées disponibles pour les nœuds supplémentaires créés par les paramètres max-surge. Pour plus d’informations, consultez Configurer le réseau Azure CNI dans Azure Kubernetes Service (AKS).

  • Si vos pools de nœuds de cluster s’étendent sur plusieurs zones de disponibilité au sein d’une région, le processus de mise à niveau peut provoquer temporairement une configuration de zone déséquilibrée. Pour plus d’informations, consultez Considérations spéciales relatives aux pools de nœuds qui s’étendent sur plusieurs zones de disponibilité.

Contributeurs

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

Auteurs principaux :

Autres contributeurs :

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

Étapes suivantes