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

W tym artykule wyjaśniono, jak skonfigurować zasoby w celu zdefiniowania AKSNodeClass ustawień specyficznych dla platformy Azure na potrzeby automatycznej aprowizacji węzłów (NAP) w usłudze Azure Kubernetes Service (AKS) przy użyciu narzędzia 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

Od 30 listopada 2025 r. usługa Azure Kubernetes Service (AKS) nie obsługuje już ani nie zapewnia aktualizacji zabezpieczeń dla systemu Azure Linux 2.0. Obraz węzła systemu Linux 2.0 platformy Azure został 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 Linux platformy Azure, uaktualniając pule węzłów do obsługiwanej wersji rozwiązania Kubernetes lub migrując do systemu osSku AzureLinux3. Aby uzyskać więcej informacji, zobacz [Wycofywanie] pul węzłów Azure Linux 2.0 w usłudze AKS.

Omówienie zasobów AKSNodeClass

AKSNodeClass zasoby umożliwiają konfigurowanie ustawień specyficznych dla platformy Azure dla NAP. Każdy NodePool zasób musi odwoływać się do AKSNodeClass przy użyciu spec.template.spec.nodeClassRef. Możesz mieć wiele NodePools wskazujących na ten sam AKSNodeClass, co umożliwia współdzielenie typowych konfiguracji Azure w różnych grupach 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 firmy Microsoft dla obciążeń usługi AKS. Aby uzyskać więcej informacji, zobacz dokumentację systemu Linux platformy Azure

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 podsieci sieci wirtualnej

Pole vnetSubnetID określa, która podsieć sieci wirtualnej platformy Azure powinna być używana do aprowizowania 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 być w pełnym formacie 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 platformy Azure mogą mieć różne typy magazynu 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 zasobników

Pole maxPods określa maksymalną liczbę zasobników, które można zaplanować w 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ł
Sieć Azure CNI ze standardowym networkingiem (v1 lub NodeSubnet)	30
Azure CNI z siecią nakładkową	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 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 platformy Azure po prostu przekazuje je do narzędzia kubelet w 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 narzędzie 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 narzędzie kubelet wykonuje odzyskiwanie pamięci 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 platformy Azure

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

Ograniczenia tagów

• Tagi zasobów platformy Azure 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.
• Platforma 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

  # 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:

• Używanie automatycznej aprowizacji węzłów w niestandardowej sieci wirtualnej
• Konfigurowanie pul węzłów 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