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 aprowizowanych przez Karpenter, takich jak obraz maszyny wirtualnej, rozmiar dysku systemu operacyjnego, maksymalna liczba zasobników na węzeł i konfiguracje kubeletu.

Omówienie zasobów AKSNodeClass

AKSNodeClass zasoby umożliwiają konfigurowanie ustawień specyficznych dla Azure dla NAP. 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 ustawia domyślny obraz maszyny wirtualnej oraz logikę inicjalizacji dla węzłów aprowizowanych za pośrednictwem AKSNodeClass. Jeśli nie określisz rodziny obrazów, zostanie użyta domyślna wersja systemu operacyjnego zgodnie z wersją platformy Kubernetes. Procesory GPU są obsługiwane w obu rodzinach obrazów w zgodnych rozmiarach maszyn wirtualnych. Aby uzyskać więcej informacji na temat domyślnej wersji systemu operacyjnego na wersję platformy Kubernetes, zobacz dokumentację wersji systemu operacyjnego AKS.

Obsługiwane rodziny obrazów

• Ubuntu: Ubuntu jest domyślną dystrybucją systemu Linux dla węzłów usługi AKS.
  • Domyślne ustawienia wersji systemu operacyjnego zmieniają się na podstawie wersji rozwiązania Kubernetes. System Ubuntu 22.04 jest domyślny dla platformy Kubernetes w wersji 1.25 do 1.33. System Ubuntu 24.04 jest domyślny dla platformy Kubernetes w wersji 1.34 lub nowszej.
• AzureLinux: Azure Linux to alternatywna dystrybucja systemu Linux Microsoft dla obciążeń usługi AKS. Aby uzyskać więcej informacji, zobacz dokumentację Azure Linux.
• AzureContainerLinux: system Azure Container Linux jest obsługiwany w usłudze AKS 1.34 i nowszych wersjach. Użyj maszyny wirtualnej generacji 2 i jawnie włącz zarówno ustawienia zaufanego uruchamiania, nawet jeśli nie są wymagane w inny sposób:
  • Ustaw opcję security.trustedLaunch.vtpm na true.
  • Ustaw opcję security.trustedLaunch.secureBoot na true.
  • W przypadku ustawienia osDiskSizeGBużyj wartości co najmniej 60.
  • Nie należy łączyć tej rodziny obrazów z ustawieniami, których ten obraz nie obsługuje. Aby uzyskać szczegółowe informacje, zobacz Azure Container Linux on AKS.
• Windows2022: Windows Server 2022 jest w wersji zapoznawczej. Wymaga architektury AMD64 i nie jest obsługiwane w płaszczyźnie danych Cilium. System Windows2022 nie obsługuje standardu FIPS ani zaufanego uruchamiania. Nie należy konfigurować linuxOSConfig, włączać przesyłania strumieniowego artefaktów ani ustawiać LocalDNS na tryb inny niż Disabled.
• Windows2025: Windows Server 2025 jest w wersji zapoznawczej. Wymaga architektury AMD64 i nie jest obsługiwane w płaszczyźnie danych Cilium. Protokół FIPS jest wymagany i jest skutecznie włączony nawet wtedy, gdy fipsMode zostanie pominięty. Nie należy konfigurować linuxOSConfig, włączać przesyłania strumieniowego artefaktów ani ustawiać LocalDNS na tryb inny niż Disabled.

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 Azure Container Linux

W poniższym przykładzie użyto Azure Container Linux z wymaganymi ustawieniami zaufanego uruchamiania. Pomija element osDiskSizeGB, aby platforma wybrała obsługiwany rozmiar dysku.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: azure-container-linux
spec:
  imageFamily: AzureContainerLinux
  security:
    trustedLaunch:
      vtpm: true
      secureBoot: true

obsługa systemu operacyjnego Windows (wersja zapoznawcza)

NAP obsługuje obrazy Windows2022 i Windows2025.

• Windows2022: Windows Server 2022 jest w wersji zapoznawczej. Wymaga architektury AMD64 i nie jest obsługiwane w płaszczyźnie danych Cilium. System Windows2022 nie obsługuje standardu FIPS ani zaufanego uruchamiania. Nie należy konfigurować linuxOSConfig, włączać przesyłania strumieniowego artefaktów ani ustawiać LocalDNS na tryb inny niż Disabled.
• Windows2025: Windows Server 2025 jest w wersji zapoznawczej. Wymaga architektury AMD64 i nie jest obsługiwane w płaszczyźnie danych Cilium. Protokół FIPS jest wymagany i jest skutecznie włączony nawet wtedy, gdy fipsMode zostanie pominięty. Nie należy konfigurować linuxOSConfig, włączać przesyłania strumieniowego artefaktów ani ustawiać LocalDNS na tryb inny niż Disabled.

Windows 2022 configuration

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: windows-2025
spec:
  imageFamily: Windows2025

Konfiguracja systemu Windows2025

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: windows-2025
spec:
  imageFamily: Windows2025
  security:
    trustedLaunch:
      vtpm: true
      secureBoot: true

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 publicznego adresu IP na poziomie wystąpienia

Publiczny adres IPv4 można przypisać do każdego węzła aprowizowanego przez NAP, ustawiając nodePublicIP.enabled na true. Opcjonalnie możesz określić ipTags lub prefixIDs. Użyj jednego lub drugiego, a nie obu.

Używanie publicznego adresu IP na poziomie wystąpienia z prefiksami

Opcjonalnie określ jeden prefiks publicznego adresu IP IPv4 przy użyciu polecenia prefixIDs. Prefiks musi znajdować się w tym samym regionie co klaster. W przypadku prefiksu strefowego ogranicz odpowiednie NodePool do tej samej strefy dostępności. Nie można określić ipTags i prefixIDs razem — użyj tylko jednego.

Tożsamość klastra musi mieć uprawnienia do używania prefiksu publicznego adresu IP, jeśli jest określony, oraz do tworzenia zasobów publicznego adresu IP węzła i zarządzania nimi. Aby uzyskać pełne wskazówki dotyczące konfiguracji, zabezpieczeń sieci i weryfikacji, zobacz Używanie publicznych adresów IP węzła.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: public-ip-nodes
spec:
  nodePublicIP:
    enabled: true
    # Optional. Specify at most one IPv4 public IP prefix resource ID.
    prefixIDs:
      - /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/publicIPPrefixes/<prefix-name>

Użyj publicznego adresu IP na poziomie wystąpienia z tagami IP i preferencją routingu internetowego

W poniższym przykładzie pokazano, jak używać publicznego adresu IP na poziomie wystąpienia z tagiem IP:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: public-ip-nodes
spec:
  nodePublicIP:
    enabled: true
    ipTags:
      - ipTagType: RoutingPreference
        tag: Internet
    # Optional. Specify at most one IPv4 public IP prefix resource ID.
    prefixIDs:
      - /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/publicIPPrefixes/<prefix-name>

Przesyłanie strumieniowe artefaktów

Przesyłanie strumieniowe artefaktów umożliwia przesyłanie strumieniowe obrazów kontenerów z Azure Container Registry (ACR) do Azure Kubernetes Service (AKS). Usługa AKS ściąga tylko niezbędne warstwy do początkowego uruchamiania zasobnika, co skraca czas wdrażania obciążeń.

Prerequisites

• Przesyłanie strumieniowe artefaktów wymaga posiadania rejestru ACR w warstwie Premium zintegrowanego z klastrem AKS.
• Przesyłanie strumieniowe artefaktów musi być włączone w usłudze ACR.

Zobacz dokumentację Artifact Streaming, aby uzyskać instrukcje dotyczące włączania Artifact Streaming w usłudze ACR.

Włącz strumieniowe przesyłanie artefaktów w klastrach NAP

Klastry z włączonym automatycznym aprowizowaniem węzłów (NAP) mogą włączyć strumieniowanie artefaktów za pomocą pola spec.artifactStreaming.enabled w obiekcie AKSNodeClass CRD. Ustaw to pole na true, aby włączyć strumieniowanie artefaktów dla wszystkich nowych lub istniejących węzłów zarządzanych przez NAP, powiązanych z tą definicją CRD AKSNodeClass.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: my-node-class
spec:
  # Enables artifact streaming; To use this feature container images must also enable artifact streaming on ACR
  # Valid values: true, false; defaults to false if not specified
  artifactStreaming:
    enabled: 
      true

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 grupy rezerwacji mocy

Użyj spec.capacityReservation.groupID, aby skojarzyć węzły aprowizowane z AKSNodeClass z istniejącą Azure grupą rezerwacji pojemności (CRG). Określ pełny identyfikator zasobu grupy, a nie rezerwację składową. Każdy węzeł utworzony na podstawie odpowiedniej klasy AKSNodeClass jest kierowany do tej grupy.

Przed rozpoczęciem skonfiguruj uprawnienia tożsamości CRG. Użyj grupy Targeted w tej samej subskrypcji i regionie co klaster, z co najmniej jedną rezerwacją członkowską w stanie aprowizacji Succeeded dla zgodnego rozmiaru i rozmieszczenia maszyny wirtualnej. Przed włączeniem w NAP zapoznaj się z ograniczeniami grupy rezerwacji pojemności usługi AKS.

Kojarzenie grupy rezerwacji pojemności z węzłami zarządzanymi przez NAP

Poniższy przykład tworzy klasę i pulę dla rezerwacji członkowskiej Standard_D8s_v5 maszyn wirtualnych w eastus-1. Zastąp identyfikator zasobu, rozmiar maszyny wirtualnej i strefę wartościami dla Twojej rezerwacji.

    apiVersion: karpenter.azure.com/v1beta1
    kind: AKSNodeClass
    metadata:
      name: reserved
    spec:
      capacityReservation:
        groupID: /subscriptions/<subscription-id>/resourceGroups/<crg-resource-group>/providers/Microsoft.Compute/capacityReservationGroups/<crg-name>

W przypadku regionalnego członu bez strefy zastąp wymaganie topology.kubernetes.io/zone:

- key: karpenter.azure.com/placement-scope
  operator: In
  values: ["regional"]

Dodanie, zmiana lub usunięcie groupID w istniejącej klasie powoduje dryf i wymianę węzłów, z zastrzeżeniem mechanizmów kontroli zakłóceń pul odwołujących się do tej klasy. Nie aktualizuje uruchomionych węzłów. Jeśli chcesz uniknąć zastępowania węzłów odwołujących się do istniejącej klasy, użyj nowej klasy i puli.

status.capacityReservationGroup raportuje identyfikator grupy, lokalizację, strefy i rezerwacje członków grupy, w tym ich rozmiary maszyn wirtualnych, ilości i stany aprowizacji. Opisuje on konfigurację rezerwacji, a nie bieżące wykorzystanie lub które węzły zajmują jednostki zarezerwowane.

Po ustawieniu capacityReservationstatus.conditions musi zawierać CapacityReservationGroupReady ze stanem "True", zanim klasa stanie się gotowa. Ten warunek weryfikuje odnajdywanie i zgodność grup, a nie pomyślne skojarzenie maszyny wirtualnej.

Jeśli klasa nie stanie się gotowa lub węzły nie uruchamiają się:

• Sprawdź przyczynę i komunikat warunku. W przypadku błędów dostępu sprawdź uprawnienia do odczytu i poczekaj na propagację przypisań ról. Jeśli klasa jest gotowa, ale skojarzenie maszyny wirtualnej zakończy się niepowodzeniem, sprawdź, czy tożsamość zarządzana przypisana przez użytkownika klastra ma Contributor w grupie zasobów CRG.
• Sprawdź, czy grupa istnieje i zawiera co najmniej jedną rezerwację członka w stanie Succeeded aprowizacji. Pusta grupa nie powoduje uruchomienia przez NAP niepowiązanych węzłów.
• Sprawdź, czy klasa obsługuje rozmiar zarezerwowanej maszyny wirtualnej i czy rozmiar i wymagania dotyczące umieszczania maszyny wirtualnej w puli są zgodne z rezerwacją składową. Gotowa klasa nie gwarantuje, że wymagania puli są zgodne z rezerwacjami tej grupy.

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:
        group: karpenter.azure.com
        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:

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 wymuszany 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"

Aktualizowanie konfiguracji localDNS dla istniejącej klasy AKSNodeClass

Ustawienie localDNS uczestniczy w wykrywaniu dryfu, jak w przypadku innych AKSNodeClass ustawień. Po zmianie spec.localDNS, do którego odwołują się już istniejące węzły AKSNodeClass, NAP stosuje tę zmianę za pośrednictwem standardowego mechanizmu Dryfowania. NAP nie wykonuje ponownego obrazowania istniejących węzłów.

Następujące zachowanie ma zastosowanie w przypadku zmiany trybu LocalDNS lub zastąpień, takich jak zmiana mode z Disabled na Required:

• Nowe węzły: każdy węzeł aprowizujący zabezpieczenia dostępu do sieci po zaktualizowaniu AKSNodeClass nowej konfiguracji LocalDNS.
• Istniejące węzły: ochrona dostępu do sieci oznacza istniejące NodeClaim obiekty jako dryfowane, ponieważ ich zarejestrowana konfiguracja nie jest już zgodna z .AKSNodeClass NAP uruchamia węzeł zastępczy, który używa nowej konfiguracji LocalDNS, a następnie izoluje, opróżnia i usuwa dryfowany węzeł.
• Bez ponownego tworzenia obrazu: Włączenie LocalDNS w puli zarządzanych węzłów usługi AKS powoduje ponowne utworzenie obrazu każdego węzła w puli. NAP zamiast tego zastępuje węzeł. Tak czy inaczej pody na węzłach, których dotyczy problem, są usuwane i ponownie przydzielane, więc należy uwzględnić taki sam wpływ na obciążenie.

Gdy rozpoczyna się zamiana

Ocena dryfu i wymiana zaczynają się natychmiast po zastosowaniu zaktualizowanego AKSNodeClasspliku . Zastąpienie przebiega zgodnie ze standardowym cyklem życia zakłóceń NAP, więc tempo i czas zależą od mechanizmów kontroli zakłóceń skonfigurowanych w zasobach NodePool odwołujących się do AKSNodeClass.

Jak NAP koordynuje zastępowanie

Odchylenie spowodowane zmianą LocalDNS jest zgodne ze standardowymi mechanizmami obsługi zakłóceń NAP opisanymi w poniższej tabeli:

Zamiana nie jest ani w pełni szeregowa, ani w pełni równoległa. NAP aprowizuje pojemność zastępczą przed usunięciem węzła, który uległ dryfowi, ale może jednocześnie zastąpić wiele węzłów odwołujących się do tego samego AKSNodeClass, do limitu określonego przez budżety zakłóceń.

Zmniejsz ryzyko niedostępności podczas włączania LocalDNS

1. Upewnij się, że niestandardowe serwery DNS odpowiadają na zapytania zarówno przez UDP, jak i TCP na porcie 53 z podsieci węzła. Aby uzyskać więcej informacji, zobacz Weryfikowanie niestandardowego systemu DNS przed włączeniem LocalDNS.

2. Zdefiniuj budżety zakłóceń podów dla każdego krytycznego obciążenia roboczego.

3. Ustaw konserwatywny budżet zakłóceń dla zasobów, których dotyczy NodePool, przed zmianą AKSNodeClass, jak pokazano w poniższym przykładzie:

   apiVersion: karpenter.sh/v1
   kind: NodePool
   metadata:
     name: default
   spec:
     disruption:
       budgets:
       - nodes: "1"   # Replace one node at a time
   

4. Najpierw zastosuj zmianę localDNS do środowiska nieprodukcyjnego AKSNodeClass. Alternatywnie utwórz obiekt AKSNodeClass z włączoną funkcją LocalDNS i zmigruj obciążenia do obiektu NodePool, który się do niego odwołuje.

5. Monitoruj postęp wymiany, wyświetlając listę roszczeń węzłów. Zastąpienie jest ukończone, gdy żaden claim węzła nie zgłasza warunku stanu Drifted.

   # List node claims and watch replacements appear as drifted nodes are removed
   kubectl get nodeclaims
   
   # Inspect the status conditions on a specific node claim
   kubectl describe nodeclaim <nodeclaim-name>
   

6. Upewnij się, że LocalDNS jest aktywny w węzłach zastępczych. Aby uzyskać więcej informacji, zobacz Weryfikowanie operacji LocalDNS.

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.

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, w jaki kubelet przydziela zasoby procesora. Ustaw wartość na "static" w przypadku przypinania procesora CPU w obciążeniach wrażliwych na opóźnienia.
• cpuCFSQuota: włącza wymuszanie przydziału kwot CPU przez harmonogram CFS dla kontenerów, które określają limity procesora CPU.
• cpuCFSQuotaPeriod: Ustawia okres kwoty 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 docelowego użycia dysku po odśmiecaniu.

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 sysctl, 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 dozwolonych w dowolnym zasobniku.

Niestandardowe ustawienia konfiguracji systemu operacyjnego Linux

Sekcja LinuxOSConfig umożliwia skonfigurowanie różnych parametrów kubelet, które wpływają na zachowanie węzła. Są to typowe niestandardowe argumenty systemowe, więc NAP po prostu przekazuje je do kubeletu na węźle.

Aby uzyskać więcej informacji na temat niestandardowych ustawień konfiguracji systemu operacyjnego Linux, wartości domyślnych i zagadnień, zobacz dokumentację niestandardowych parametrów konfiguracji węzła.

Ustawienia limitów obsługi plików systemu Linux

Użyj następujących ustawień, aby ustawić ustawienia systemu plików.

spec:
  linuxOSConfig: 
    # Sysctl Settings  
    sysctls:  
      # File System Settings  
      fsFileMax: 2000000               # Range: 8192-12000500  Default: Max of available range
      fsInotifyMaxUserWatches: 1000000 # Range: 781250-2097152 Default: 1048576
      fsAioMaxNr: 1000000              # Range: 65536-6553500  Default: 65536
      fsNrOpen: 1000000                # Range: 8192-20000500  Default: 1048576

Ustawienia dostrajania gniazd systemu Linux i sieci

Użyj następujących ustawień, aby ustawić ustawienie TCP i sieci.

spec:
  linuxOSConfig:
      # Network Settings  
      netCoreSomaxconn: 65535          # Range: 4096-3240000  Default: 16384
      netCoreNetdevMaxBacklog: 5000    # Range: 1000-3240000  Default: 1000
      netCoreRmemMax: 134217728        # Range: 212992-134217728  Default: 1048576
      netCoreOptmemMax: 102400         # Range: 20480-4194304     Default: 131072 
      netCoreWmemMax: 134217728        # Range: 212992-134217728  Default: 212992
      netCoreRmemDefault: 212992       # Range: 212992-134217728  
      netCoreWmemDefault: 212992       # Range: 212992-134217728  
      netIPv4IPLocalPortRange: "1024 65535" # Format: "first last", first: 1024-60999, last: 32768-65535  

      # Neighbor Table GC Thresholds  
      netIPv4NeighDefaultGcThresh1: 1024   # Range: 128-80000  Default: 4096
      netIPv4NeighDefaultGcThresh2: 2048   # Range: 512-80000  Default: 8192
      netIPv4NeighDefaultGcThresh3: 4096   # Range: 1024-80000  Default: 16384
      # Note: thresh1 <= thresh2 <= thresh3  

      # Connection Tracking  
      netNetfilterNfConntrackBuckets: 131072  # Range: 65536-524288   Default: dynamically calculated 
      netNetfilterNfConntrackMax: 262144       # Range: 131072-2097152 Default: dynamically calculated 

Ustawienia limitu workerów w systemie Linux

Użyj następujących ustawień, aby ustawić ustawienie jądra.

spec:
  linuxOSConfig:
      # Kernel Settings  
      kernelThreadsMax: 100000         # Range: 20-513785  Default: Dynamically calculated

Ustawienia pamięci wirtualnej systemu Linux

Użyj poniższych opcji, aby dostroić działanie podsystemu pamięci wirtualnej systemu Linux jądra systemu Linux i zapisu brudnych danych na dysku.

spec:
  linuxOSConfig:
      # Memory Management  
      vmMaxMapCount: 262144          # Range: 65530-262144 Default: Max of available range
      vmVfsCachePressure: 100        # Range: 0-100  Default: 100
      vmSwappiness: 60               # Range: 0-100  Default: 60

      # Swap File Configuration  
      swapFileSize: "2Gi"             # Default: (not set) | Pattern: quantity with units Note: Requires kubelet.failSwapOn: false  

      # Transparent Huge Pages  
      transparentHugePageEnabled: "madvise"    # Values: [always, madvise, never]  Default: always
      transparentHugePageDefrag: "defer+madvise" # Values: [always, defer, defer+madvise, madvise, never]  Default: madvise

Ustawienia procesora GPU

Użyj następującego pola, aby włączyć niestandardową instalację sterownika GPU, na przykład za pomocą NVIDIA GPU Operator.

spec:
  gpu:
    mode: 
      # acceptable values: [driver, none] default(or if not specified): driver
      # none skips gpu driver installation, driver has NAP manage the GPU driver installation  
      none

Zarządzany GPU

Pole gpu.mode steruje instalacją sterownika GPU. Akceptuje Driver wartość lub None i domyślnie przyjmuje wartość Driver. Ustaw wartość None, aby pominąć instalację sterownika, na przykład podczas korzystania z NVIDIA GPU Operator.

Aby skorzystać z zarządzanego środowiska GPU NVIDIA, użyj mode: Driver i ustaw nvidia.managementMode: Managed. Zarządzany GPU jest obsługiwany w przypadku węzłów GPU NVIDIA z systemem Linux przy użyciu trybu aprowizacji AKS Machine API. Domyślnym trybem zarządzania NVIDIA jest Unmanaged.

spec:
  gpu:
    mode: Driver
    nvidia:
      managementMode: Managed

Aby zapoznać się z kompletnym przykładem GPU zarządzanego przez NAP i krokami weryfikacji, zobacz Węzły GPU zarządzane przez usługę AKS.

Ustawienia zabezpieczeń

Szyfrowanie na hoście

Poniższe pole określa, czy szyfrowanie na poziomie hosta jest włączone dla aprowizowanych węzłów. Gdy ustawisz to pole na true, NAP uwzględnia tylko opcje instancji, które obsługują szyfrowanie na hoście.

spec:
  security:
    encryptionatHost: 
      # acceptable values: [true, false] default(or if not specified): false  
      false

Aby uzyskać więcej informacji na temat szyfrowania opartego na hoście, zobacz Szyfrowanie w dokumentacji hosta.

Klucze zarządzane przez klienta i zestawy szyfrowania dysków

NAP obsługuje klastry korzystające z kluczy zarządzanych przez klienta i zestawów szyfrowania dysków. Włącz te opcje na poziomie klastra. Nie mają AKSNodeClass pól, które należy ustawić. Upewnij się, że tożsamość klastra ma właściwą kontrolę dostępu opartą na rolach (RBAC):

• Tożsamość klastra ma Reader dostęp do zestawu szyfrowania dysków.
• Zasób zestawu szyfrowania dysków ma Key Vault Crypto Service Encryption User dostęp do Azure Key Vault.

Aby uzyskać informacje na temat kluczy zarządzanych przez klienta i zestawów szyfrowania dysków włączonych podczas tworzenia klastra, zobacz dokumentacjęCustomer-Managed Keys.

Włączanie zaufanego uruchamiania w klastrach NAP

Klastry z włączonym automatycznym aprowizowaniem węzłów (NAP) mogą włączyć zaufane uruchamianie przy użyciu pola spec.security.trustedLaunchCRD AKSNodeClass. Ustaw pola secureBoot i vTPM na true, aby włączyć zaufane uruchamianie dla wszystkich nowych lub istniejących węzłów zarządzanych przez NAP skojarzonych z tym obiektem CRD AKSNodeClass.

spec:
  security:
  # Enables trusted lunch
  # Valid values: true, false; defaults to false if not specified
     trustedLaunch:
       secureBoot: true
       vTPM: true   

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:
        group: karpenter.azure.com
        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, AzureContainerLinux
  imageFamily: Ubuntu

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

  # Artifact Streaming- allows use of artifact streaming feature; To use this feature container images must also enable artifact streaming on ACR
  # Valid values: true, false; defaults to false if not specified
  artifactStreaming:
    enabled: true

  # LocalDNS mode - allows use of LocalDNS feature
  # Default: Disabled
  # Valid values: Preferred, Required, Disabled
  # vnetDNSOverrides and kubeDNSOverrides are both required, even when mode is Disabled
  # Each list must include the "." and "cluster.local" zones, and each zone must set all nine fields
  localDNS:
    mode: Disabled
    # vnetDNSOverrides apply to DNS traffic from pods with dnsPolicy:default and from kubelet
    vnetDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: VnetDNS   # the "." zone can't forward to ClusterCoreDNS in vnetDNSOverrides
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS   # cluster.local can't forward to VnetDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
    # kubeDNSOverrides apply to DNS traffic from pods with dnsPolicy:ClusterFirst
    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"

  # 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

  # GPU driver installation (optional)
  # Default: driver - NAP manages gpu driver installation
  # none skips gpu driver installation
  # Valid values: driver, none
  gpu:
    mode: 
      driver

  # 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

  security:
  # Enables trusted lunch
  # Valid values: true, false; default(or if not specified): false  
     trustedLaunch:
      secureBoot: true
      vTPM: true
  # Encryption at host
     encryptionatHost: 
      # acceptable values: [true, false] default(or if not specified): false  
      false

Dalsze kroki

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

• Używać 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 dotyczących zakłóceń dla automatycznej aprowizacji węzłów w usłudze AKS