Konfigurowanie pul węzłów na potrzeby automatycznej aprowizacji węzłów (NAP) w Azure Kubernetes Service (AKS)

W tym artykule wyjaśniono, jak skonfigurować pule węzłów na potrzeby automatycznej aprowizacji węzłów (NAP) w Azure Kubernetes Service (AKS), w tym selektory jednostek SKU, limity zasobów i wagi priorytetów. Zawiera również przykłady ułatwiające rozpoczęcie pracy.

AKS Automatic domyślnie obejmuje funkcję NAP. W przypadku klastrów AKS w warstwie Standard należy włączyć NAP, zanim skonfigurujesz ich pule węzłów.

Jak NAP wybiera maszyny wirtualne dla pul węzłów

NAP używa wymagań SKU maszyn wirtualnych, aby wybrać najlepsze maszyny wirtualne dla oczekujących obciążeń. Można skonfigurować:

• Rodziny jednostek SKU i określone typy wystąpień.
• Limity zasobów i priorytety.
• Wystąpienia typu spot lub na żądanie.
• Architektura, procesor GPU i inne wymagania dotyczące możliwości.

Zasób NodePool ustawia ograniczenia dotyczące węzłów tworzonych przez NAP oraz zasobników (pods) uruchamianych na tych węzłach. Po włączeniu NAP przy domyślnej konfiguracji puli węzłów ustawionej na Auto tworzone są zasoby default NodePool. Możesz zmodyfikować te pule węzłów lub utworzyć dodatkowe pule węzłów zgodnie z wymaganiami dotyczącymi obciążenia.

Jak NAP ocenia i wybiera pule węzłów

Podczas konfigurowania NodePools dla NAP, należy pamiętać o następujących zachowaniach:

• System NAP wymaga co najmniej jednego NodePool do działania.
• NAP ocenia każdą skonfigurowaną NodePool.
• NAP pomija NodePools z skażeniami, które nie są akceptowane przez zasobnik.
• Funkcjonalność NAP stosuje startowe 'tainty' do zaaprowizowanych węzłów, ale nie wymaga 'toleracji' dla podów.
• NAP działa najlepiej z wzajemnie wykluczającymi się NodePools, których wymagania nie nakładają się na siebie, dzięki czemu każdy pod pasuje tylko do jednej puli. Gdy pasuje wiele elementów NodePools, NAP używa tego o najwyższej wadze.

Przejrzyj domyślną konfigurację puli węzłów

Konfiguracja domyślnego Karpentera NodePool o nazwie default utworzonej przez NAP jest następująca:

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 tworzy również pulę węzłów system-surge, która zapewnia zasoby Linux AMD64 dostępne na żądanie dla krytycznych dodatków systemowych. Jeśli oczekujący pod toleruje skażenie CriticalAddonsOnly=true:NoSchedule i spełnia wymagania puli, NAP może utworzyć węzeł z tej puli. Węzły utworzone przez pulę mają etykietę kubernetes.azure.com/mode: system .

Kontrolowanie domyślnych pul węzłów

Podczas tworzenia nowego klastra AKS z włączoną funkcją NAP za pomocą interfejsu wiersza polecenia Azure CLI uwzględnij flagę --node-provisioning-default-pools, aby określić, czy usługa AKS tworzy domyślny NodePools NAP. Możesz również użyć tej flagi wraz z az aks update, gdy włączasz NAP w istniejącym klastrze.

Flaga --node-provisioning-default-pools akceptuje następujące wartości:

• Auto (ustawienie domyślne): tworzy dwa standardy NodePools do natychmiastowego użycia.
• None: nie tworzy żadnego elementu NodePools. Musisz zdefiniować własne.

Opcje konfiguracji puli węzłów

W poniższych sekcjach opisano różne opcje konfiguracji dla NodePools w NAP, w tym powszechnie znane etykiety i selektory SKU, a także limity puli węzłów i wagi puli węzłów.

Dobrze znane etykiety i selektory SKU

Kubernetes określa dobrze znane etykiety, które Azure implementuje. Te etykiety można zdefiniować w spec.requirements sekcji interfejsu NodePool API. NAP obsługuje również etykiety specyficzne dla Azure w celu bardziej zaawansowanego planowania.

W poniższej tabeli wymieniono etykiety, których można użyć w spec.requirements sekcji interfejsu NodePool API, aby zdefiniować charakterystyki VM dla węzłów:

Wartości selektora pamięci w tej tabeli to wartości w MiB raportowane dla węzłów utworzonych przez NAP. Przed dodaniem selektora sprawdź etykiety w węzłach, aby potwierdzić wartość używaną przez klaster.

Przykłady rodziny jednostek SKU

Selektor karpenter.azure.com/sku-family umożliwia kierowanie określonych rodzin maszyn wirtualnych.

Przykładowa konfiguracja przy użyciu rodziny jednostek SKU:

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

Przykład jednostki SKU procesora GPU

Aby udostępnić węzły GPU NVIDIA przy użyciu NAP, utwórz obiekt NodePool, który wybiera rozmiary maszyn wirtualnych z obsługą GPU. Poniższy przykład umożliwia usłudze NAP wybór jednostek SKU procesorów graficznych NVIDIA z serii N:

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

Jeśli chcesz, aby usługa AKS instalowała i zarządzała sterownikiem GPU NVIDIA, wtyczką urządzenia, eksporterem metryk Data Center GPU Manager (DCGM) oraz sygnałami kondycji GPU na węzłach GPU aprowizowanych przez NAP, skonfiguruj zarządzany GPU w przywołanym elemencie AKSNodeClass. Aby uzyskać więcej informacji, zobacz Tworzenie puli węzłów procesora GPU zarządzanego przez usługę AKS.

Przykłady nazw SKU

Selektor karpenter.azure.com/sku-name pozwala określić dokładny typ maszyny wirtualnej.

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

Przykłady wersji jednostki SKU

Selektor karpenter.azure.com/sku-version jest przeznaczony dla określonych generacji jednostek SKU maszyny wirtualnej.

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

Przykład strefy dostępności

Selektor topology.kubernetes.io/zone umożliwia określenie stref dostępności dla węzłów.

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

Przykład architektury

Selektor kubernetes.io/arch umożliwia określenie architektury CPU w węzłach. NAP obsługuje zarówno węzły amd64 i arm64.

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

Przykład systemu operacyjnego

Selektor kubernetes.io/os umożliwia określenie systemu operacyjnego dla węzłów.

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

Przykład typu pojemności

Selektor karpenter.sh/capacity-type umożliwia określenie, czy mają być używane instancje typu Spot czy On-demand.

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

Limity puli węzłów

Domyślnie NAP próbuje zaplanować twoje obciążenia w ramach dostępnego limitu przydziału Azure. W przypadku dynamicznej puli węzłów można określić zagregowane limity zasobów dla wszystkich węzłów udostępnionych przez tę pulę. W poniższym przykładzie cpu: "1000" ogranicza pulę do 1000 rdzeni procesorów wirtualnych i memory: 1000Gi ogranicza ją do 1000 gibajtów pamięci:

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

Wagi puli węzłów

Jeśli zdefiniowano wiele pul węzłów, można ustawić preferencję miejsca, w którym ma być zaplanowane obciążenie, definiując względną wagę w definicjach puli węzłów. Pole weight akceptuje liczbę całkowitą z zakresu od 1 do 100, a wyższe wartości dają puli węzłów wyższy priorytet. Jeśli pominiesz weight, jego wartość jest efektywnie równa 0. Przykład:

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

Pule węzłów statycznych

Statyczne pule węzłów utrzymują stałą liczbę węzłów udostępnionych przez NAP, określoną w polu replicas, niezależnie od zapotrzebowania na pody. Aby zmienić liczbę węzłów, jawnie zmień skalę NodePool, na przykład przy użyciu kubectl scale z nodepool static-node-pool --replicas=7. Opcjonalna wartość limits.nodes ogranicza jawne skalowanie i tymczasową pojemność utworzoną podczas wymiany węzła. W przypadku statycznych pul węzłów tylko pole nodes jest obsługiwane w sekcji limits; nie można ustawić limitów CPU ani pamięci.

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

Dalsze kroki

Aby uzyskać więcej informacji o automatycznym aprowizowaniu węzłów w AKS, zobacz następujące artykuły:

• Konfigurowanie sieci na potrzeby automatycznej aprowizacji węzłów w usłudze AKS
• Konfigurowanie zasad zakłóceń na potrzeby automatycznej aprowizacji węzłów w usłudze AKS
• Tworzenie klastra automatycznego aprowizowania węzłów w niestandardowej sieci wirtualnej w usłudze AKS