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

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.

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.

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.

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.

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.

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 ARM (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. Il n’existe, par contre, aucun contrat de niveau de service pour les nœuds spot. 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.

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 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.

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.

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 nécessaires et les considérations relatives au réseau, consultez Configurer un réseau 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).

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.

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 :

• Mise à niveau des images de nœud Azure Kubernetes service (AKS)
• Mettre à niveau un plan de contrôle de cluster avec plusieurs pools de nœuds

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é.

Réseaux virtuels de nœuds

Quand vous créez un cluster ou ajoutez un nouveau pool de nœuds à un cluster existant, vous spécifiez l’ID de ressource d’un sous-réseau dans le réseau virtuel du cluster où vous déployez les nœuds d’agent. Une charge de travail peut nécessiter le fractionnement des nœuds d’un cluster en pools de nœuds distincts à des fins d’isolation logique. Vous pouvez réaliser cette isolation avec des sous-réseaux distincts, chaque sous-réseau étant dédié à un pool de nœuds distinct. Les machines virtuelles du pool de nœuds obtiennent chacune une adresse IP privée de leur sous-réseau associé.

AKS prend en charge deux plug-ins réseau :

• Kubenet est un plug-in réseau simple pour Linux. Avec kubenet, les nœuds obtiennent une adresse IP privée du sous-réseau du réseau virtuel Azure. Les pods obtiennent une adresse IP d’un espace d’adressage logiquement différent. La traduction d’adresses réseau (NAT) permet aux pods d’accéder aux ressources sur le réseau virtuel Azure en traduisant l’adresse IP du trafic source en adresse IP principale du nœud. Cette approche réduit le nombre d’adresses IP que vous devez réserver aux pods dans votre espace réseau.

• Azure Container Networking Interface (CNI) attribue une adresse IP à chaque pod pour autoriser les appels et les accès directs. Ces adresses IP doivent être uniques dans votre espace réseau. Chaque nœud possède un paramètre de configuration pour le nombre maximal de pods qu’il prend en charge. Le nombre équivalent d’adresses IP par nœud est alors réservé pour ce nœud. Cette approche nécessite une planification préalable et peut conduire à l’épuisement des adresses IP ou à la nécessité de regénérer les clusters dans un sous-réseau plus grand à mesure que les demandes des applications augmentent.

  Quand vous créez un cluster ou ajoutez un nouveau pool de nœuds à un cluster qui utilise Azure CNI, vous pouvez spécifier l’ID de ressource de deux sous-réseaux distincts : un pour les nœuds et un pour les pods. Pour plus d’informations, consultez Allocation dynamique des adresses IP et prise en charge améliorée des sous-réseaux.

Allocation d’adresses IP dynamiques

Les pods qui utilisent Azure CNI obtiennent des adresses IP privées d’un sous-réseau du pool de nœuds d’hébergement. L’allocation d’adresses IP dynamiques par Azure CNI peut allouer des adresses IP privées aux pods d’un sous-réseau distinct du sous-réseau d’hébergement du pool de nœuds. Cette fonctionnalité offre les avantages suivants :

• Le sous-réseau de pod alloue dynamiquement des adresses IP aux pods. L’allocation dynamique permet d’améliorer l’utilisation des adresses IP par rapport à la solution CNI traditionnelle qui effectue une allocation statique des adresses IP pour chaque nœud.

• Vous pouvez mettre à l’échelle et partager des sous-réseaux de nœud et de pod indépendamment. Vous pouvez partager un sous-réseau de pod unique sur plusieurs pools de nœuds ou clusters déployés dans le même réseau virtuel. Vous pouvez également configurer un sous-réseau de pod distinct pour un pool de nœuds.

• Étant donné que les pods ont des adresses IP privées de réseau virtuel, ils bénéficient d’une connectivité directe aux autres pods et ressources du cluster dans le réseau virtuel. Cette capacité se traduit par de meilleures performances pour les clusters très volumineux.

• Si les pods ont un sous-réseau distinct, vous pouvez configurer des stratégies de réseau virtuel pour les pods qui diffèrent des stratégies de nœud. Des stratégies distinctes permettent de prendre en charge de nombreux scénarios utiles, notamment l’autorisation de la connectivité Internet uniquement pour les pods et pas pour les nœuds, la correction de l’adresse IP source pour un pod dans un pool de nœuds avec une passerelle NAT et l’utilisation de groupes de sécurité réseau pour filtrer le trafic entre les pools de nœuds.

• Les stratégies réseau Kubernetes Stratégie réseau et Calico fonctionnent avec l’allocation d’adresses IP dynamiques.

Contributeurs

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

Auteurs principaux :

• Paolo Salvatori | Ingénieur système principal

Autres contributeurs :

• Laura Nicolas | Ingénieur logiciel senior
• Chad Kittel | Ingénieur logiciel principal
• Ed Price | Responsable de programme senior
• Theano Petersen | Rédacteur technique

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

Étapes suivantes

• AKS pour les professionnels Amazon EKS
• Gestion de l’identité et de l’accès Kubernetes
• Monitoring et journalisation Kubernetes
• Sécuriser l’accès réseau à Kubernetes
• Options de stockage pour un cluster Kubernetes
• Gestion des coûts pour Kubernetes
• Gouvernance des clusters
• Parcours de solution Azure Kubernetes Service (AKS)
• Guide des opérations Jour 2 Azure Kubernetes Service (AKS)
• Choisir une option de calcul Kubernetes à la périphérie
• GitOps pour Azure Kubernetes Service

Ressources associées

• Bonnes pratiques relatives aux clusters AKS
• Créer un cluster AKS privé avec une zone DNS publique
• Créer un cluster Azure Kubernetes Service privé à l’aide de Terraform et d’Azure DevOps
• Créer un cluster Azure Kubernetes Service public ou privé avec Azure NAT Gateway et Azure Application Gateway
• Utiliser des points de terminaison privés avec un cluster AKS privé
• Créer un cluster Azure Kubernetes Service avec le contrôleur d’entrée Application Gateway
• Présentation de Kubernetes
• Présentation de Kubernetes dans Azure
• Implémenter Azure Kubernetes Service (AKS)
• Développer et déployer des applications sur Kubernetes
• Optimiser les coûts de calcul sur Azure Kubernetes Service (AKS)