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

W tym artykule wyjaśniono, jak skonfigurować zasoby AKSNodeClass w celu określenia ustawień specyficznych dla Azure do automatycznego aprowizowania węzłów (NAP) w Azure Kubernetes Service (AKS) z użyciem Karpenter. AKSNodeClass umożliwia dostosowanie różnych aspektów węzłów, które Karpenter aprowizuje, takich jak obraz maszyny wirtualnej (VM), rozmiar dysku systemu operacyjnego (OS), maksymalna liczba pods na węzeł oraz konfiguracje kubeleta.

Ważne

Począwszy od November 30, 2025 Azure Kubernetes Service (AKS) nie obsługuje już aktualizacji zabezpieczeń dla systemu Azure Linux 2.0. Obraz węzła systemu Azure Linux 2.0 jest zamrożony w wersji 202512.06.0. Od 31 marca 2026 r. obrazy węzłów zostaną usunięte i nie będzie można skalować pul węzłów. Przeprowadź migrację do obsługiwanej wersji systemu Azure Linux, uaktualniając swoje pule węzłów do obsługiwanej wersji Kubernetes lub przechodząc na osSku AzureLinux3. Aby uzyskać więcej informacji, zobacz problem na GitHub dotyczący zakończenia oraz ogłoszenie o wycofaniu aktualizacji Azure. Aby być na bieżąco z ogłoszeniami i aktualizacjami, obserwuj notatki dotyczące wydań AKS.

Omówienie zasobów AKSNodeClass

AKSNodeClass zasoby umożliwiają konfigurowanie ustawień specyficznych dla NAP w Azure. Każdy NodePool zasób musi odwoływać się do AKSNodeClass przy użyciu spec.template.spec.nodeClassRef. Można mieć wiele NodePools, które wskazują na ten sam AKSNodeClass, co umożliwia współużytkowanie typowych konfiguracji Azure w różnych pulach węzłów.

Konfiguracja rodziny obrazów

Pole imageFamily określa domyślny obraz maszyny wirtualnej i logikę inicjalizacji dla węzłów dostarczanych za pośrednictwem elementu AKSNodeClass. Jeśli nie określisz rodziny obrazów, wartość domyślna to Ubuntu2204. Procesory GPU są obsługiwane w obu rodzinach obrazów w zgodnych rozmiarach maszyn wirtualnych.

Obsługiwane rodziny obrazów

Ubuntu: Ubuntu 22.04 Long Term Support (LTS) to domyślna dystrybucja systemu Linux dla węzłów usługi AKS.
AzureLinux: Azure Linux to alternatywna dystrybucja systemu Linux Microsoft dla obciążeń usługi AKS. Aby uzyskać więcej informacji, zobacz dokumentację Azure Linux

Przykładowa konfiguracja rodziny obrazów

W poniższym przykładzie skonfigurowaliśmy element AKSNodeClass tak, aby korzystał z rodziny obrazów AzureLinux :

spec:
  imageFamily: AzureLinux

Konfiguracja obrazu węzła zgodnego ze standardem FIPS

Można również włączyć obrazy węzłów zgodne ze standardami FIPS (Federal Information Processing Standards). Aby uzyskać więcej informacji na temat FIPS w usłudze AKS, zobacz dokumentację FIPS.

Pole fipsMode jest domyślnie ustawione na Wyłączone i można ustawić na następujące opcje:

FiPS — wybieranie obrazów węzłów zgodnych ze standardem FIPS
Wyłączone — nie używaj obrazów węzłów zgodnych ze standardem FIPS

W poniższym przykładzie skonfigurowano klasę "AKSNodeClass", aby wybrać obrazy węzłów zgodne ze standardem FIPS, ustawiając wartość fipsMode na :FIPS

spec:
  fipsMode: FIPS

Konfiguracja podsieci sieci wirtualnej

Pole vnetSubnetID określa, która podsieć sieci wirtualnej Azure powinna być używana do aprowizacji interfejsów sieciowych węzłów. To pole jest opcjonalne. Jeśli nie określisz podsieci, NAP używa domyślnej podsieci skonfigurowanej podczas instalacji Karpenter. Aby uzyskać więcej informacji, zobacz Konfiguracje podsieci dla ochrony dostępu do sieci (NAP).

Przykładowa konfiguracja podsieci

Identyfikator podsieci musi mieć pełny format Azure Resource Manager (ARM), jak pokazano w poniższym przykładzie:

spec:
  vnetSubnetID: "/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Network/virtualNetworks/{vnet-name}/subnets/{subnet-name}"

Konfiguracja rozmiaru dysku systemu operacyjnego

Pole osDiskSizeGB określa rozmiar dysku systemu operacyjnego w gigabajtach. Wartość domyślna to 128 GB, a minimalna wartość to 30 GB.

Rozważ większe rozmiary dysków systemu operacyjnego dla obciążeń, które:

Lokalne przechowywanie znaczących danych.
Wymagaj dodatkowego miejsca dla obrazów kontenerów.
Mają wysokie wymagania dotyczące operacji we/wy dysku.

Przykładowa konfiguracja rozmiaru dysku systemu operacyjnego

spec:
  osDiskSizeGB: 256  # 256 GB OS disk

Efemeryczna konfiguracja dysku systemu operacyjnego

NAP automatycznie używa Efemerycznych Dysków Systemu Operacyjnego, jeśli są dostępne i odpowiednie dla żądanego rozmiaru dysku. Efemeryczne dyski systemu operacyjnego zapewniają lepszą wydajność i niższe koszty w porównaniu z dyskami zarządzanymi.

Kryteria wyboru dysku efemerycznego

System automatycznie wybiera dyski efemeryczne w następujących scenariuszach:

Typ wystąpienia maszyny wirtualnej obsługuje efemeryczne dyski systemu operacyjnego.
Pojemność dysku efemerycznego jest większa lub równa żądanej osDiskSizeGBwartości .
Maszyna wirtualna ma wystarczającą pojemność magazynu efemerycznego.

Jeśli te warunki nie zostaną spełnione, system wróci do korzystania z dysków zarządzanych.

Typy dysków efemerycznych i priorytetyzacja

Maszyny wirtualne Azure mogą mieć różne typy przechowywania efemerycznego. System używa następującej kolejności priorytetu:

Dyski NVMe (najwyższa wydajność)
Dyski pamięci podręcznej (zrównoważona wydajność)
Dyski zasobów (podstawowa wydajność)

Przykładowa konfiguracja dysku efemerycznego

Możesz użyć wymagań puli węzłów, aby upewnić się, że węzły mają wystarczającą pojemność dysku efemerycznego, jak pokazano w poniższym przykładzie:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ephemeral-disk-pool
spec:
  template:
    spec:
      requirements:
        - key: karpenter.azure.com/sku-storage-ephemeralos-maxsize
          operator: Gt
          values: ["128"]  # Require ephemeral disk larger than 128 GB
      nodeClassRef:
        apiVersion: karpenter.azure.com/v1beta1
        kind: AKSNodeClass
        name: my-node-class
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: my-node-class
spec:
  osDiskSizeGB: 128  # This will use ephemeral disk if available and large enough

Ta konfiguracja gwarantuje, że wybrano tylko typy wystąpień maszyn wirtualnych z dyskami efemerycznym większymi niż 128 GB, co gwarantuje użycie efemerycznego dysku dla określonego rozmiaru dysku systemu operacyjnego.

Maksymalna konfiguracja podów

Pole maxPods określa maksymalną liczbę podów, które można zaplanować na węźle. To ustawienie ma wpływ zarówno na gęstość klastra, jak i konfigurację sieci.

Wartość minimalna parametru maxPods to 10, a maksymalna wartość to 250.

Domyślne zachowanie dla `maxPods`

Domyślne zachowanie dla parametru maxPods zależy od konfiguracji wtyczki sieciowej. Poniższa tabela zawiera podsumowanie wartości domyślnych:

Konfiguracja wtyczki sieciowej	Wartość domyślna `maxPods` na węzeł
Azure CNI ze standardowym sieciowaniem (v1 lub NodeSubnet)	30
Azure CNI z siecią overlay	250
Brak (brak wtyczki sieciowej)	250
Inne konfiguracje	110 (standardowa domyślna wartość Kubernetes)

Przykładowa konfiguracja maksymalnych podów

spec:
  maxPods: 50  # Allow up to 50 pods per node

Konfiguracja lokalnych sieciDNS

LocalDNS wdraża serwer proxy DNS na poziomie węzła, który rozwiązuje zapytania DNS bliżej obciążeń, zmniejszając opóźnienia zapytań i poprawiając odporność podczas przejściowych zakłóceń DNS. Aby uzyskać więcej informacji, zobacz dokumentację LocalDNS. Domyślnie wartość LocalDNS jest ustawiona na Wyłączone i można ją skonfigurować, wybierając jedną z następujących opcji:

Disabled (ustawienie domyślne) — wyłącza funkcję LocalDNS. Zapytania DNS nie są rozwiązywane lokalnie w węźle.
Preferred — Usługa AKS zarządza włączaniem LocalDNS w oparciu o wersję platformy Kubernetes puli węzłów. Konfiguracja jest zawsze weryfikowana i uwzględniana, ale usługa LocalDNS nie jest włączona, chyba że jest używana poprawna wersja platformy Kubernetes.
Required — LocalDNS jest wymuszana w puli węzłów, jeśli zostały spełnione wszystkie wymagania wstępne. Jeśli wymagania nie zostaną spełnione, wdrożenie zakończy się niepowodzeniem.

Przykładowa konfiguracja localDNS

Konfiguracje localDNS, takie jak vnetDNSOverrides i kubeDNSOverrides, można dostosować. Aby uzyskać więcej informacji na temat obsługiwanych wtyczek, zobacz Dostosowywanie lokalnych sieciDNS.

spec:
  LocalDNS:
    mode: Required
    vnetDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: VnetDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
    kubeDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"

Konfiguracja rozwiązania Kubelet

Sekcja kubelet umożliwia skonfigurowanie różnych parametrów kubelet, które wpływają na zachowanie węzła. Te parametry są typowymi argumentami kubelet, więc dostawca Azure po prostu przekazuje je do kubelet na węźle.

Ważne

Dokładnie skonfiguruj ustawienia narzędzia kubelet i przetestuj wszelkie zmiany w środowiskach nieprodukcyjnych.

Zarządzanie procesorem CPU

Następujące ustawienia kontrolują zachowanie zarządzania procesorem CPU dla narzędzia kubelet:

spec:
  kubelet:
    cpuManagerPolicy: "static"  # or "none"
    cpuCFSQuota: true
    cpuCFSQuotaPeriod: "100ms"

cpuManagerPolicy: Określa sposób przydzielania zasobów procesora CPU przez kubelet. Ustaw wartość na "static" w przypadku przypinania procesora CPU w obciążeniach wrażliwych na opóźnienia.
cpuCFSQuota: włącza wymuszanie limitów przydziału CPU Całkowicie Sprawiedliwego Harmonogramu (CFS) dla kontenerów, które określają limity CPU.
cpuCFSQuotaPeriod: Ustawia okres przydziału procesora CPU CFS.

Odzyskiwanie pamięci obrazu

Następujące ustawienia kontrolują zachowanie usuwania nieużywanych obrazów przez kubelet.

spec:
  kubelet:
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

Te ustawienia kontrolują, kiedy kubelet wykonuje zbieranie śmieci obrazów kontenera.

imageGCHighThresholdPercent: Procent użycia dysku, który wyzwala odśmiecanie obrazów.
imageGCLowThresholdPercent: Procent użycia dysku docelowego po usunięciu pamięci.

Zarządzanie topologią

Następujące ustawienie steruje zasadami menedżera topologii dla narzędzia kubelet:

spec:
  kubelet:
    topologyManagerPolicy: "best-effort"  # none, restricted, best-effort, single-numa-node

Menedżer topologii pomaga koordynować alokację zasobów dla obciążeń wrażliwych na opóźnienia w zasobach procesora CPU i urządzenia (na przykład procesora GPU).

Konfiguracja systemu

Następujące ustawienia umożliwiają skonfigurowanie dodatkowych parametrów systemowych dla narzędzia kubelet:

spec:
  kubelet:
    allowedUnsafeSysctls:
      - "kernel.msg*"
      - "net.ipv4.route.min_pmtu"
    containerLogMaxSize: "50Mi"
    containerLogMaxFiles: 5
    podPidsLimit: 4096

allowedUnsafeSysctls: Lista dozwolonych niebezpiecznych systemów, których mogą używać zasobniki.
containerLogMaxSize: Maksymalny rozmiar plików dziennika kontenera przed rotacją.
containerLogMaxFiles: Maksymalna liczba plików dziennika kontenera do zachowania.
podPidsLimit: Maksymalna liczba procesów dozwolona w dowolnym podzie.

konfiguracja tagów zasobów Azure

Można określić tagi zasobów Azure, które mają zastosowanie do wszystkich wystąpień maszyn wirtualnych utworzonych przy użyciu określonego zasobu AKSNodeClass. Tagi są przydatne w przypadku śledzenia kosztów, organizacji zasobów i wymagań dotyczących zgodności.

Ograniczenia tagów

Azure tagi zasobów mają limit 50 tagów na zasób.
Nazwy tagów są niewrażliwe na wielkość liter, ale wartości tagów rozróżniają wielkość liter.
Azure rezerwuje niektóre nazwy tagów, których nie można użyć. Aby uzyskać więcej informacji, zobacz Wskazówki i limity tagów.

Przykładowa konfiguracja tagów

spec:
  tags:
    Environment: "production"
    Team: "platform"
    Application: "web-service"
    CostCenter: "engineering"

Kompleksowy `AKSNodeClass` przykład konfiguracji

W poniższym przykładzie przedstawiono kompleksową AKSNodeClass konfigurację obejmującą wszystkie ustawienia omówione w tym artykule:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      nodeClassRef:
        apiVersion: karpenter.azure.com/v1beta1
        kind: AKSNodeClass
        name: comprehensive-example
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: comprehensive-example
spec:
  # Image family configuration
  # Default: Ubuntu
  # Valid values: Ubuntu, AzureLinux
  imageFamily: Ubuntu

  # FIPS compliant mode - allows support for FIPS-compliant node images
  # Default: Disabled
  # Valid values: FIPS, Disabled
  fipsMode: Disabled

  # LocalDNS mode - allows use of LocalDNS feature
  # Default: Disabled
  # Valid values: Preferred, Required, Disabled
  LocalDNS:
    mode: Disabled
    # additional details on vnetDNSOverrides and kubeDNSOverrides can be added here

  # Virtual network subnet configuration (optional)
  # If not specified, uses the default --vnet-subnet-id from Karpenter installation
  vnetSubnetID: "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/my-rg/providers/Microsoft.Network/virtualNetworks/my-vnet/subnets/my-subnet"

  # OS disk size configuration
  # Default: 128 GB
  # Minimum: 30 GB
  osDiskSizeGB: 128

  # Maximum pods per node configuration
  # Default behavior depends on network plugin:
  # - Azure CNI with standard networking: 30 pods
  # - Azure CNI with overlay networking: 250 pods
  # - Other configurations: 110 pods
  # Range: 10-250
  maxPods: 30

  # Azure resource tags (optional)
  # Applied to all VM instances created with this AKSNodeClass
  tags:
    Environment: "production"
    Team: "platform-team"
    Application: "web-service"
    CostCenter: "engineering"

  # Kubelet configuration (optional)
  # All fields are optional with sensible defaults
  kubelet:
    # CPU management policy
    # Default: "none"
    # Valid values: none, static
    cpuManagerPolicy: "static"

    # CPU CFS quota enforcement
    # Default: true
    cpuCFSQuota: true

    # CPU CFS quota period
    # Default: "100ms"
    cpuCFSQuotaPeriod: "100ms"

    # Image garbage collection thresholds
    # imageGCHighThresholdPercent must be greater than imageGCLowThresholdPercent
    # Range: 0-100
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

    # Topology manager policy
    # Default: "none"
    # Valid values: none, restricted, best-effort, single-numa-node
    topologyManagerPolicy: "best-effort"

    # Allowed unsafe sysctls (optional)
    # Comma-separated list of unsafe sysctls or patterns
    allowedUnsafeSysctls:
      - "kernel.msg*"
      - "net.ipv4.route.min_pmtu"

    # Container log configuration
    # containerLogMaxSize default: "50Mi"
    containerLogMaxSize: "50Mi"
    
    # containerLogMaxFiles default: 5, minimum: 2
    containerLogMaxFiles: 5

    # Pod process limits
    # Default: -1 (unlimited)
    podPidsLimit: 4096

Dalsze kroki

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

Opinia

Czy ta strona była pomocna?

Last updated on 2026-04-07