Configurer des pools de nœuds pour l’approvisionnement automatique de nœuds (NAP) dans Azure Kubernetes Service (AKS)

Cet article explique comment configurer des pools de nœuds pour l’approvisionnement automatique de nœuds (NAP) dans Azure Kubernetes Service (AKS), notamment les sélecteurs de référence SKU, les limites de ressources et les pondérations de priorité. Il fournit également des exemples pour vous aider à commencer.

AKS Automatic inclut NAP par défaut. Pour les clusters AKS Standard, vous devez activer NAP avant de configurer ses pools de nœuds.

Comment NAP sélectionne des machines virtuelles pour les pools de nœuds

NAP utilise les exigences de référence SKU de machine virtuelle pour déterminer les meilleures machines virtuelles pour les charges de travail en attente. Vous pouvez configurer les éléments suivants :

  • Familles de références SKU et types d’instances spécifiques.
  • Limites et priorités des ressources.
  • Instances Spot ou à la demande.
  • Architecture, GPU et autres fonctionnalités requises.

La NodePool ressource définit des contraintes sur les nœuds créés par NAP et les pods qui s’exécutent sur ces nœuds. Lorsque vous activez NAP avec la configuration du groupe de nœuds par défaut définie sur Auto, cela crée des ressources par défaut NodePool. Vous pouvez modifier ces pools de nœuds ou créer des pools de nœuds supplémentaires en fonction de vos besoins en charge de travail.

Comment NAP évalue et sélectionne les pools de nœuds

Lors de la configuration NodePools de NAP, gardez à l’esprit les comportements suivants :

  • NAP nécessite au moins un NodePool pour fonctionner.
  • NAP évalue chaque NodePool configuré.
  • NAP ignore les NodePools avec des taints non tolérés par un pod.
  • NAP applique des taints de démarrage aux nœuds provisionnés, mais ne nécessite pas de tolérance au pod.
  • NAP fonctionne de manière optimale avec des NodePools mutuellement exclusifs, dont les exigences ne se recoupent pas, de sorte que chaque pod ne corresponde qu’à un seul pool. Lorsque plusieurs éléments correspondent à NodePools, NAP utilise celui qui a le poids le plus élevé.

Passer en revue la configuration du pool de nœuds par défaut

La configuration du Karpenter NodePool par défaut nommé default par NAP est la suivante :

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
  template:
    spec:
      nodeClassRef:
        group: karpenter.azure.com
        kind: AKSNodeClass
        name: default
      expireAfter: Never
      # Requirements that constrain the parameters of provisioned nodes.
      # These requirements are combined with pod.spec.affinity.nodeAffinity rules.
      # Operators { In, NotIn, Exists, DoesNotExist, Gt, and Lt } are supported.
      # https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#operators
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      - key: karpenter.azure.com/sku-family
        operator: In
        values:
        - D

NAP crée également un system-surge groupe de nœuds qui fournit une capacité Linux AMD64 à la demande pour les modules complémentaires critiques du système. Lorsqu’un pod en attente tolère le CriticalAddonsOnly=true:NoSchedule rejet et correspond aux exigences du pool, NAP peut provisionner un nœud à partir de ce pool. Les nœuds créés par le pool ont l’étiquette kubernetes.azure.com/mode: system .

Contrôler les pools de nœuds par défaut

Lorsque vous créez un cluster AKS activé avec NAP à l’aide de l’Azure CLI, incluez l’indicateur --node-provisioning-default-pools pour contrôler si AKS crée le nap NodePoolspar défaut. Vous pouvez également utiliser cet indicateur az aks update lorsque vous activez NAP sur un cluster existant.

L’indicateur --node-provisioning-default-pools accepte les valeurs suivantes :

  • Auto (valeur par défaut) : crée deux normes NodePools pour une utilisation immédiate.
  • None : ne crée aucun NodePools. Vous devez définir votre propre.

Avertissement

Passage de Auto à None : si vous modifiez le paramètre d’un cluster existant de Auto à None, la valeur par défaut NodePools n’est pas supprimée automatiquement. Avant de les supprimer, définissez une capacité de remplacement appropriée pour les modules complémentaires système critiques. Vous devez supprimer manuellement la valeur par défaut NodePools si vous n’en avez plus besoin.

Options de configuration du pool de nœuds

Les sections suivantes décrivent différentes options de configuration dans NodePools NAP, notamment les étiquettes connues et les sélecteurs de référence SKU, les limites du pool de nœuds et les pondérations du pool de nœuds.

Étiquettes connues et sélecteurs de référence SKU

Kubernetes définit étiquettes connues que Azure implémente. Vous pouvez définir ces étiquettes dans la spec.requirements section de l’API NodePool . NAP prend également en charge les étiquettes spécifiques à Azure pour une planification avancée.

Le tableau suivant répertorie les étiquettes que vous pouvez utiliser dans la spec.requirements section de votre NodePool API pour définir les caractéristiques de machine virtuelle pour vos nœuds :

Selector Descriptif Example
karpenter.sh/capacity-type Type d’allocation de machine virtuelle (Spot / À la demande) Zone
karpenter.azure.com/sku-family Famille SKU de VM D, F, L, etc.
karpenter.azure.com/sku-series Série de références SKU de machine virtuelle Dpls_v6
karpenter.azure.com/sku-name Nom explicite de la référence SKU Standard_A1_v2
karpenter.azure.com/sku-version Version de référence SKU (sans « v », peut utiliser 1) 1, 2
karpenter.azure.com/sku-cpu Nombre de processeurs dans la machine virtuelle 16
karpenter.azure.com/sku-memory Mémoire de la machine virtuelle en MiB 131 072
karpenter.azure.com/sku-gpu-name Nom du GPU A100
karpenter.azure.com/sku-gpu-manufacturer Fabricant de GPU nvidia
karpenter.azure.com/sku-gpu-count Nombre de GPU par machine virtuelle 2
karpenter.azure.com/sku-networking-accelerated Indique si la machine virtuelle a une mise en réseau accélérée [vrai, faux]
karpenter.azure.com/sku-storage-premium-capable Indique si la machine virtuelle prend en charge le stockage d’E/S Premium [vrai, faux]
karpenter.azure.com/sku-storage-ephemeralos-maxsize Limite de taille pour le disque du système d’exploitation éphémère en Go 92
kubernetes.azure.com/sku-cpu Nombre de processeurs dans la machine virtuelle 16
kubernetes.azure.com/sku-memory Mémoire de la machine virtuelle en MiB 131 072
kubernetes.azure.com/cluster Nom du cluster AKS my-cluster
kubernetes.azure.com/mode Mode de pool de nœuds [système, utilisateur]
kubernetes.azure.com/priority Priorité [spot, régulier]
kubernetes.azure.com/os-sku Référence SKU du système d’exploitation [Ubuntu, AzureLinux]
kubernetes.azure.com/fips_enabled Indique si FIPS est activé true
topology.kubernetes.io/zone Zone(s) de disponibilité [RoyaumeUniSud-1, RoyaumeUniSud-2, RoyaumeUniSud-3]
kubernetes.io/os Système d’exploitation linux
kubernetes.io/arch Architecture du processeur (AMD64 ou ARM64) [amd64, arm64]

Les valeurs de sélecteur de mémoire de ce tableau sont les valeurs MiB signalées sur les nœuds créés par NAP. Avant d’ajouter un sélecteur, inspectez les étiquettes sur vos nœuds pour confirmer la valeur utilisée par votre cluster.

Exemples de famille de références SKU

Le karpenter.azure.com/sku-family sélecteur vous permet de cibler des familles de machines virtuelles spécifiques.

Famille Descriptif
Série D Machines virtuelles à usage général avec un ratio processeur/mémoire équilibré
Série F Machines virtuelles optimisées pour le calcul avec un ratio processeur/mémoire élevé
Série E Machines virtuelles optimisées en mémoire pour les applications gourmandes en mémoire
Série L Machines virtuelles optimisées pour le stockage avec un débit de disque élevé
Série N Machines virtuelles compatibles GPU pour les charges de travail nécessitant beaucoup de ressources de calcul

Exemple de configuration utilisant la famille de références SKU :

requirements:
- key: karpenter.azure.com/sku-family
  operator: In
  values:
  - D
  - F

Exemple de référence SKU GPU

Pour provisionner des nœuds GPU NVIDIA avec NAP, créez un NodePool qui sélectionne des tailles de machines virtuelles avec prise en charge des GPU. L’exemple suivant permet à NAP de sélectionner des références SKU NVIDIA GPU de série N :

requirements:
- key: karpenter.azure.com/sku-family
  operator: In
  values:
  - N
- key: karpenter.azure.com/sku-gpu-manufacturer
  operator: In
  values:
  - nvidia

Si vous souhaitez qu’AKS installe et gère le pilote GPU NVIDIA, le plugin de périphérique, l’exportateur de métriques Data Center GPU Manager (DCGM) et les signaux d’état de santé du GPU sur les nœuds GPU provisionnés par NAP, configurez la gestion du GPU dans l’élément référencé AKSNodeClass. Pour plus d’informations, consultez Créer un pool de nœuds GPU géré par AKS.

Exemples de noms de référence SKU

Le karpenter.azure.com/sku-name sélecteur vous permet de spécifier le type d’instance de machine virtuelle exacte.

requirements:
- key: karpenter.azure.com/sku-name
  operator: In
  values:
  - Standard_D4s_v3
  - Standard_F8s_v2

Exemples de versions SKU

Le karpenter.azure.com/sku-version sélecteur cible des générations spécifiques de références SKU de machine virtuelle.

requirements:
- key: karpenter.azure.com/sku-version
  operator: In
  values:
  - "3"  # v3 generation
  - "5"  # v5 generation

Exemple de zone de disponibilité

Le topology.kubernetes.io/zone sélecteur vous permet de spécifier les zones de disponibilité de vos nœuds.

requirements:
- key: topology.kubernetes.io/zone
  operator: In
  values:
  - eastus-1
  - eastus-2

Note

Pour répertorier les tailles de machine virtuelle qui prennent en charge les zones de disponibilité dans une région, utilisez la az vm list-skus commande avec les --location <region> --zone --output table paramètres. Vérifiez que la taille de votre machine virtuelle sélectionnée prend en charge les zones requises NodePool .

Exemple d’architecture

Le kubernetes.io/arch sélecteur vous permet de spécifier l’architecture du processeur pour vos nœuds. NAP prend en charge à la fois les nœuds amd64 et arm64.

requirements:
- key: kubernetes.io/arch
  operator: In
  values:
  - amd64
  - arm64

Exemple de système d’exploitation

Le kubernetes.io/os sélecteur vous permet de spécifier le système d’exploitation de vos nœuds.

requirements:
- key: kubernetes.io/os
  operator: In
  values:
  - linux

Exemple de type de capacité

Le karpenter.sh/capacity-type sélecteur vous permet de spécifier s’il faut utiliser des instances Spot ou à la demande.

Note

NAP hiérarchise les instances Spot lorsque Spot et À la demande sont spécifiés.

requirements:
- key: karpenter.sh/capacity-type
  operator: In
  values:
  - spot
  - on-demand

Limites du pool de nœuds

Par défaut, NAP tente de planifier vos charges de travail dans le quota Azure que vous avez disponible. Pour un pool de nœuds dynamiques, vous pouvez spécifier des limites de ressources agrégées sur tous les nœuds approvisionnés par ce pool. Dans l’exemple suivant, cpu: "1000" limite le pool à 1 000 cœurs de processeurs virtuels et memory: 1000Gi le limite à 1 000 gibioctets de mémoire :

spec:
  # Resource limits constrain the total size of the node pool.
  # Limits prevent Node Auto Provisioning from creating new instances once the limit is exceeded.
  limits:
    cpu: "1000"
    memory: 1000Gi

Pondérations du pool de nœuds

Lorsque vous avez défini plusieurs pools de nœuds, vous pouvez définir une préférence pour l’endroit où une charge de travail doit être planifiée en définissant le poids relatif dans vos définitions de pool de nœuds. Le weight champ accepte un entier compris entre 1 et 100, et les valeurs supérieures donnent une priorité supérieure au pool de nœuds. Si vous omettez weight, sa valeur est effectivement 0. Par exemple:

spec:
  # Priority given to the node pool when the scheduler considers which to select. 
  # Higher weights indicate higher priority when comparing node pools.
  # Specifying no weight is equivalent to specifying a weight of 0.
  weight: 10

Pools de nœuds statiques

Les pools de nœuds statiques conservent le nombre fixe de nœuds provisionnés par NAP spécifié dans le champ replicas, quelle que soit la demande en pods. Pour modifier le nombre de nœuds, mettez explicitement à l’échelle le NodePool, par exemple à l’aide de kubectl scalenodepool static-node-pool --replicas=7. La valeur facultative limits.nodes limite la mise à l’échelle explicite et la capacité temporaire créée lors du remplacement du nœud. Pour les pools de nœuds statiques, nodes est le seul champ pris en charge sous limits; vous ne pouvez pas définir de limites de processeur ou de mémoire.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: static-node-pool
spec:
  replicas: 5
  template:
    spec:
      requirements:
      - key: karpenter.azure.com/sku-name
        operator: In
        values:
          - Standard_D4s_v3
          - Standard_F8s_v2
      - key: topology.kubernetes.io/zone
        operator: In
        values:
          - eastus-1
          - eastus-2
          - eastus-3
  limits:
    nodes: 10

Note

Pour les pools de nœuds statiques, vous ne pouvez définir que nodes dans le limits champ. Vous ne pouvez pas définir de limites de ressources or weight, et la consolidation des perturbations ne s’applique pas. Après avoir créé un NodePool, vous ne pouvez pas basculer entre les modes statiques et dynamiques en ajoutant ou en supprimant le replicas champ.

Étapes suivantes

Pour plus d’informations sur le provisionnement automatique de nœuds dans AKS, consultez les articles suivants :

  • Dernière mise à jour :