Konfigurieren von Knotenpools für die automatische Bereitstellung von Knoten (Node Auto-Provisioning, NAP) in Azure Kubernetes Service (AKS)

In diesem Artikel wird erläutert, wie Sie Knotenpools für die automatische Bereitstellung (Node Auto-Provisioning, NAP) in Azure Kubernetes Service (AKS) konfigurieren, einschließlich SKU-Selektoren, Ressourcenbeschränkungen und Prioritätsgewichtungen. Außerdem finden Sie Beispiele, die Ihnen bei den ersten Schritten helfen.

AKS Automatic enthält standardmäßig NAP. Für AKS Standardcluster müssen Sie NAP aktivieren, bevor Sie die Knotenpools konfigurieren.

Wie NAP VMs für Knotenpools auswählt

NAP verwendet SKU-Anforderungen für virtuelle Computer (VM), um die besten virtuellen Computer für ausstehende Workloads zu entscheiden. Sie können Folgendes konfigurieren:

• SKU-Familien und bestimmte Instanztypen.
• Ressourcenlimits und Prioritäten.
• Spot- oder On-Demand-Instanzen.
• Anforderungen an Architektur, GPU und andere Funktionen.

Die Ressource NodePool legt Einschränkungen für die Knoten fest, die NAP erstellt, und die Pods, die auf diesen Knoten ausgeführt werden. Wenn Sie NAP mit der auf Auto festgelegten Standardknotenpoolkonfiguration aktivieren, werden Standardressourcen NodePool erstellt. Sie können diese Knotenpools ändern oder zusätzliche Knotenpools für Ihre Workloadanforderungen erstellen.

Wie NAP Knotenpools auswertet und auswählt

Beachten Sie bei der Konfiguration NodePools für NAP die folgenden Verhaltensweisen:

• NAP erfordert mindestens ein NodePool, um zu funktionieren.
• NAP wertet jede konfigurierte NodePool aus.
• NAP überspringt NodePools mit Taints, die ein Pod nicht toleriert.
• NAP wendet Startup-Taints auf bereitgestellte Knoten an, erfordert jedoch keine Podtoleranz.
• NAP funktioniert am besten mit sich gegenseitig ausschließenden NodePoolsElementen, deren Anforderungen nicht überlappen, sodass jeder Pod nur einem Pool entspricht. Wenn mehrere NodePools übereinstimmen, verwendet NAP den Eintrag mit der höchsten Gewichtung.

Überprüfen der Standardkonfiguration des Knotenpools

Die Konfiguration des standardmäßigen Karpenter-NodePool namens default, erstellt durch NAP, sieht wie folgt aus:

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 erstellt außerdem einen system-surge Knotenpool, der die On-Demand-Linux AMD64-Kapazität für wichtige System-Add-Ons bereitstellt. Wenn ein Pod im Status „Pending“ den CriticalAddonsOnly=true:NoSchedule Taint toleriert und die Anforderungen des Pools erfüllt, kann NAP einen Knoten aus diesem Pool provisionieren. Vom Pool erstellte Knoten weisen die kubernetes.azure.com/mode: system Bezeichnung auf.

Steuern der Standardknotenpools

Wenn Sie einen neuen AKS-Cluster erstellen, der mit NAP mit dem Azure CLI aktiviert ist, schließen Sie das --node-provisioning-default-pools Flag ein, um zu steuern, ob AKS den standardmäßigen NAP NodePoolserstellt. Sie können dieses Flag az aks update auch verwenden, wenn Sie NAP auf einem vorhandenen Cluster aktivieren.

Das --node-provisioning-default-pools Flag akzeptiert die folgenden Werte:

• Auto (Standard): Erstellt zwei Standard NodePools für die sofortige Verwendung.
• None: Erstellt NodePools nicht. Sie müssen Ihre eigenen definieren.

Konfigurationsoptionen für Knotenpools

In den folgenden Abschnitten werden verschiedene Konfigurationsoptionen für NodePools NAP beschrieben, darunter bekannte Bezeichnungen und SKU-Selektoren, Knotenpoolgrenzen und Knotenpoolgewichte.

Bekannte Etiketten und SKU-Auswähler

Kubernetes definiert wohlbekannte Bezeichnungen, die Azure implementiert. Sie können diese Bezeichnungen im spec.requirements Abschnitt der NodePool API definieren. NAP unterstützt auch Azure-spezifische Labels für eine fortgeschrittene Planung.

In der folgenden Tabelle sind die Bezeichnungen aufgeführt, die Sie im spec.requirements Abschnitt Ihrer NodePool API verwenden können, um VM-Merkmale für Ihre Knoten zu definieren.

Die Speicherauswahlwerte in dieser Tabelle sind die MiB-Werte, die auf NAP-erstellten Knoten gemeldet werden. Bevor Sie einen Selektor hinzufügen, überprüfen Sie die Labels Ihrer Knoten, um zu bestätigen, welchen Wert Ihr Cluster verwendet.

Beispiele für SKU-Familien

Mit der karpenter.azure.com/sku-family Auswahl können Sie bestimmte VM-Familien ansprechen.

Beispielkonfiguration mit SKU-Familie:

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

BEISPIEL für GPU-SKU

Um NVIDIA-GPU-Knoten mit NAP bereitzustellen, erstellen Sie eine NodePool, die GPU-fähige VM-Größen auswählt. Das folgende Beispiel ermöglicht NAP die Auswahl von NVIDIA GPU-SKUs der N-Serie:

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

Wenn AKS den NVIDIA-GPU-Treiber, das Geräte-Plug-in, den Data Center GPU Manager (DCGM)-Metrik-Exporter und GPU-Zustandssignale auf von NAP bereitgestellten GPU-Knoten installieren und verwalten soll, konfigurieren Sie verwaltete GPUs im referenzierten AKSNodeClass. Weitere Informationen finden Sie unter Erstellen eines AKS-verwalteten GPU-Knotenpools.

Beispiele für SKU-Namen

Mit der karpenter.azure.com/sku-name Auswahl können Sie den genauen VM-Instanztyp angeben.

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

Beispiele für SKU-Versionen

Der karpenter.azure.com/sku-version Selektor zielt auf bestimmte Generationen von VM-SKUs ab.

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

Beispiel für verfügbarkeitszone

Mit der topology.kubernetes.io/zone Auswahl können Sie die Verfügbarkeitszonen für Ihre Knoten angeben.

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

Architekturbeispiel

Mit der kubernetes.io/arch Auswahl können Sie die CPU-Architektur für Ihre Knoten angeben. NAP unterstützt sowohl amd64- als auch arm64-Knoten.

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

Beispiel für das Betriebssystem

Mit der kubernetes.io/os Auswahl können Sie das Betriebssystem für Ihre Knoten angeben.

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

Beispiel für kapazitätstyp

Mit der karpenter.sh/capacity-type Auswahl können Sie angeben, ob Spot- oder On-Demand-Instanzen verwendet werden sollen.

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

Grenzwerte für Knotenpools

Standardmäßig versucht NAP, Ihre Workloads innerhalb des verfügbaren Azure Kontingents zu planen. Für einen dynamischen Knotenpool können Sie aggregierte Ressourcengrenzwerte für alle Knoten angeben, die von diesem Pool bereitgestellt werden. Im folgenden Beispiel cpu: "1000" wird der Pool auf 1.000 vCPU-Kerne beschränkt und memory: 1000Gi auf 1.000 Gibibyte Arbeitsspeicher beschränkt:

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

Gewichtung des Knotenpools

Wenn Sie mehrere Knotenpools definiert haben, können Sie eine Präferenz dafür festlegen, wo ein Workload eingeplant werden soll, indem Sie in Ihren Knotenpooldefinitionen die relative Gewichtung festlegen. Das weight Feld akzeptiert eine ganze Zahl zwischen 1 und 100, und höhere Werte geben einem Knotenpool höhere Priorität. Wenn Sie weglassen weight, ist der Wert effektiv 0. Beispiel:

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

Statische Knotenpools

Statische Knotenpools behalten die im Feld replicas angegebene feste Anzahl von durch NAP bereitgestellten Knoten unabhängig vom Pod-Bedarf bei. Um die Anzahl der Knoten zu ändern, skalieren Sie das NodePool explizit, zum Beispiel mithilfe von kubectl scale mit nodepool static-node-pool --replicas=7. Der optionale limits.nodes Wert schränkt explizite Skalierung und temporäre Kapazität ein, die während der Knotenersetzung erstellt wurde. Bei statischen Knotenpools nodes ist das einzige unterstützte Feld unter limits; Sie können keine CPU- oder Arbeitsspeichergrenzen festlegen.

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

Nächste Schritte

Weitere Informationen zur automatischen Bereitstellung von Knoten in AKS finden Sie in den folgenden Artikeln:

• Konfigurieren von Netzwerken für die automatische Bereitstellung von Knoten auf AKS
• Konfigurieren von Störungsrichtlinien für die automatische Knotenbereitstellung auf AKS
• Erstellen eines Clusters mit automatischer Bereitstellung von Knoten in einem benutzerdefinierten virtuellen Netzwerk in AKS