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.

Übersicht über Knotenpools in NAP

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 und 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 zum ersten Mal installieren, wird eine Standardeinstellung NodePoolerstellt. Sie können diesen Knotenpool ändern oder zusätzliche Knotenpools für Ihre Workloadanforderungen erstellen.

Wichtige Verhaltensweisen von NodePools in NAP

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 NodePools. Wenn mehrere NodePools übereinstimmen, wird die mit der höchsten Gewichtung verwendet.

Ü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
    expireAfter: Never
  template:
    spec:
      nodeClassRef:
        name: default

      # 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

Außerdem wird ein system-surge Knotenpool erstellt, der dazu beiträgt, Systempoolknoten automatisch zu skalieren.

Steuern der Konfiguration des Standardknotenpools während der Clustererstellung

Wenn Sie einen neuen AKS-Cluster erstellen, der mit NAP mithilfe der Azure CLI aktiviert ist, können Sie das --node-provisioning-default-pools Flag einschließen, um die Konfiguration des Standard-NAP NodePoolzu steuern.

Das --node-provisioning-default-pools Flag steuert die Standard-NAP-Konfiguration NodePool und 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 bekannte Bezeichnungen , die Azure implementiert. Sie können diese Bezeichnungen im spec.requirements Abschnitt der NodePool API definieren. NAP unterstützt auch Azure-spezifische Bezeichnungen für eine erweiterte Planung.

karpenter.azure.com SKU-Selektoren

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

kubernetes.io Bekannte Bezeichnungen

In der folgenden Tabelle sind die kubernetes.io bekannten Labels aufgeführt, die Sie im spec.requirements-Abschnitt Ihrer NodePool API verwenden können, um Knotenmerkmale für Ihre Knoten zu definieren:

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

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. Sie können auch die obere Grenze von Ressourcen angeben, die ein Knotenpool verwendet, indem Sie Grenzwerte innerhalb der Knotenpoolspezifikation angeben. Zum Beispiel:

spec:
  # Resource limits constrain the total size of the cluster.
  # 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 festlegen, wo eine Workload geplant werden soll, indem Sie die relative Gewichtung in Ihren Knotenpooldefinitionen festlegen. 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

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