Konfigurieren von AKSNodeClass-Ressourcen für die automatische Bereitstellung von Knoten (Node Auto-Provisioning, NAP) in Azure Kubernetes Service (AKS)

In diesem Artikel wird erläutert, wie Sie AKSNodeClass-Ressourcen konfigurieren, um Azure spezifische Einstellungen für die automatische Bereitstellung von Knoten (NODE Auto-Provisioning, NAP) in Azure Kubernetes Service (AKS) mithilfe von Karpenter zu definieren. AKSNodeClass ermöglicht es Ihnen, verschiedene Aspekte der von Karpenter bereitgestellten Knoten anzupassen, wie zum Beispiel das VM-Image (virtuelle Maschine), die Größe des Betriebssystemdatenträgers, die maximale Anzahl von Pods pro Knoten und die Kubelet-Konfigurationen.

Von Bedeutung

Ab November 30, 2025 unterstützt Azure Kubernetes Service (AKS) keine Sicherheitsupdates mehr für Azure Linux 2.0. Das Azure Linux 2.0-Knoten-Image wurde mit der 202512.06.0-Veröffentlichung eingefroren. Ab dem 31. Oktober 2026 werden Knotenimages entfernt, und Sie können Ihre Knotenpools nicht skalieren. Migrieren Sie zu einer unterstützten Azure Linux-Version, indem Sie Ihre Knotenpools zu einer unterstützten Kubernetes-Version aktualisieren oder zu osSku AzureLinux3 migrieren. Weitere Informationen finden Sie im GitHub-Problem „Außerbetriebnahme“ und in der Ankündigung zur Außerbetriebnahme von Azure-Updates. Um über Ankündigungen und Updates auf dem Laufenden zu bleiben, folgen Sie den AKS-Versionshinweisen.

Übersicht über AKSNodeClass-Ressourcen

mit AKSNodeClass-Ressourcen können Sie Azure-spezifische Einstellungen für NAP konfigurieren. Jede NodePool Ressource muss unter Verwendung von AKSNodeClass auf eine spec.template.spec.nodeClassRef verweisen. Sie können mehrere NodePools haben, die auf dieselbe AKSNodeClass verweisen, sodass Sie gemeinsame Azure Konfigurationen für verschiedene Knotenpools freigeben können.

Von Bedeutung

Wenn Sie eine Einstellung für eine vorhandene AKSNodeClass ändern, werden ausgeführte Knoten nicht direkt neu konfiguriert. NAP kennzeichnet die von der vorherigen Konfiguration bereitgestellten Knoten als drifted und ersetzt sie, vorbehaltlich der Unterbrechungskontrollen für die referenzierenden NodePool Ressourcen. Das tags Feld ist die einzige Ausnahme, da Tagänderungen auf vorhandene Azure Ressourcen angewendet werden, ohne den Knoten zu ersetzen. Weitere Informationen finden Sie unter Drift und Disruption Budgets. Bevor Sie eine AKSNodeClass ändern, die von Produktionsworkloads verwendet wird, lesen Sie diese Anleitung.

Imagefamilienkonfiguration

Das Feld imageFamily legt das Standard-VM-Image und die Bootstrapping-Logik für Knoten fest, die über die AKSNodeClass bereitgestellt werden. Wenn Sie keine Imagefamilie angeben, wird die Standardversion des Betriebssystems gemäß Ihrer Kubernetes-Version verwendet. GPUs werden mit beiden Imagefamilien in kompatiblen VM-Größen unterstützt. Weitere Informationen zur Standardversion des Betriebssystems pro Kubernetes-Version finden Sie in der Dokumentation zur AKS-Betriebssystemversion.

Unterstützte Imagefamilien

  • Ubuntu: Ubuntu ist die Standardmäßige Linux-Verteilung für AKS-Knoten.
    • Die Standardversion des Betriebssystems ändert sich basierend auf Ihrer Kubernetes-Version. Ubuntu 22.04 ist standard für Kubernetes-Versionen 1.25 bis 1.33. Ubuntu 24.04 ist standardmäßig für Kubernetes-Versionen 1.34 und höher.
  • AzureLinux: Azure Linux ist Microsofts alternative Linux-Distribution für AKS-Workloads. Weitere Informationen finden Sie in der Azure Linux-Dokumentation.
  • AzureContainerLinux: Azure Container Linux wird mit AKS 1.34 und höher unterstützt. Verwenden Sie einen virtuellen Computer der Generation 2, und aktivieren Sie beide Einstellungen für den vertrauenswürdigen Start explizit, auch wenn Sie sie sonst nicht benötigen:
    • Setze security.trustedLaunch.vtpm auf true.
    • Setze security.trustedLaunch.secureBoot auf true.
    • Wenn Sie osDiskSizeGB festlegen, verwenden Sie einen Wert von mindestens 60.
    • Kombinieren Sie diese Bildfamilie nicht mit Einstellungen, die von dieser Bildfamilie nicht unterstützt werden. Weitere Informationen finden Sie unter Azure Container Linux on AKS.
  • Windows2022: Windows Server 2022 befindet sich in der Vorschau. Es erfordert die AMD64-Architektur und wird von der Cilium-Datenebene nicht unterstützt. Windows2022 unterstützt weder FIPS noch Trusted Launch. Konfigurieren Sie linuxOSConfig nicht, aktivieren Sie das Artefaktstreaming, oder legen Sie LocalDNS auf einen anderen Modus als Disabled fest.
  • Windows2025: Windows Server 2025 befindet sich in der Vorschau. Es erfordert die AMD64-Architektur und wird von der Cilium-Datenebene nicht unterstützt. FIPS ist erforderlich und wird auch dann effektiv aktiviert, wenn fipsMode weggelassen wird. Konfigurieren Sie linuxOSConfig nicht, aktivieren Sie das Artefaktstreaming nicht, oder legen Sie LocalDNS auf einen anderen Modus als Disabled fest.

Beispiel für die Konfiguration der Image-Familie

Im folgenden Beispiel wird die AKSNodeClass so konfiguriert, dass die Bildfamilie AzureLinux verwendet wird.

spec:
  imageFamily: AzureLinux

Azure Container-Linux-Konfiguration

Im folgenden Beispiel wird Azure Container Linux mit den erforderlichen Trusted Launch-Einstellungen verwendet. Es lässt osDiskSizeGB weg, sodass die Plattform eine unterstützte Datenträgergröße auswählt.

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

Windows Betriebssystemunterstützung (Vorschau)

Note

AKS-Preview-Funktionen stehen auf Selbstbedienungs- und Opt-in-Basis zur Verfügung. Vorschauversionen werden „im Istzustand“ und „wie verfügbar“ bereitgestellt und sind von den Service Level Agreements und der eingeschränkten Garantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

NAP unterstützt Windows2022 und Windows2025 Bilder.

  • Windows2022: Windows Server 2022 befindet sich in der Vorschau. Es erfordert die AMD64-Architektur und wird von der Cilium-Datenebene nicht unterstützt. Windows2022 unterstützt weder FIPS noch Trusted Launch. Konfigurieren Sie linuxOSConfig nicht, aktivieren Sie das Artefaktstreaming nicht, oder legen Sie LocalDNS auf einen anderen Modus als Disabled fest.
  • Windows2025: Windows Server 2025 befindet sich in der Vorschau. Es erfordert die AMD64-Architektur und wird von der Cilium-Datenebene nicht unterstützt. FIPS ist erforderlich und wird auch dann effektiv aktiviert, wenn fipsMode weggelassen wird. Konfigurieren Sie linuxOSConfig nicht, aktivieren Sie das Artefaktstreaming nicht, oder legen Sie LocalDNS auf einen anderen Modus als Disabled fest.

Windows2022-Konfiguration

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

Windows2025-Konfiguration

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

Von Bedeutung

Windows-Bildfamilien sind eine Vorschaufunktion. Verwenden Sie ein Windows-NodePool, das kubernetes.io/os: windows und kubernetes.io/arch: amd64 auswählt, und stellen Sie sicher, dass die Workloads auch Windows-Knoten auswählen. Ausführliche Informationen finden Sie unter Konfigurieren von Knotenpools für die automatische Bereitstellung von Knoten auf AKS.

FIPS-kompatible Knotenimagekonfiguration

Sie können auch FIPS-kompatible Knotenbilder (Federal Information Processing Standards) aktivieren. Weitere Informationen zu FIPS in AKS finden Sie in der FIPS-Dokumentation.

Das fipsMode Feld ist standardmäßig auf "Deaktiviert" festgelegt und kann auf die folgenden Optionen festgelegt werden:

  • FIPS – FIPS-kompatible Knotenimages auswählen
  • Deaktiviert – Verwenden Sie keine FIPS-kompatiblen Knotenbilder

Im folgenden Beispiel wird die 'AKSNodeClass' so konfiguriert, dass FIPS-kompatible Knotenimages ausgewählt werden, indem Sie folgendes festlegen fipsModeFIPS:

spec:
  fipsMode: FIPS

Öffentliche IP-Konfiguration auf Instanzebene

Sie können jedem nap-bereitgestellten Knoten eine öffentliche IPv4-Adresse zuweisen, indem Sie nodePublicIP.enabled auf true setzen. Sie können optional angeben ipTags oder prefixIDs. Verwenden Sie eine oder die andere, nicht beide.

Öffentliche IP-Adressen auf Instanzebene mit Präfixen verwenden

Geben Sie optional ein öffentliches IPv4-IP-Präfix mithilfe von prefixIDs. Das Präfix muss sich in derselben Region wie der Cluster befinden. Beschränken Sie für ein Zonalpräfix die entsprechende NodePool auf dieselbe Verfügbarkeitszone. Sie können ipTags und prefixIDs nicht zusammen angeben - verwenden Sie nur eines von beiden.

Die Clusteridentität benötigt die Berechtigung, das öffentliche IP-Präfix (sofern angegeben) zu verwenden und die öffentlichen IP-Ressourcen des Knotens zu erstellen und zu verwalten. Vollständige Einrichtungs-, Netzwerksicherheits- und Überprüfungsleitfäden finden Sie unter Verwenden von öffentlichen Knoten-IPs.

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>

Verwenden Sie die öffentliche IP-Adresse auf Instanzebene mit IP-Tags einer Internetroutingpräferenz

Das folgende Beispiel zeigt, wie eine öffentliche IP-Adresse auf Instanzebene mit einem IP-Tag verwendet wird:

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>

Artefaktstreaming

Mit Artefaktstreaming können Sie Containerimages von Azure Container Registry (ACR) auf Azure Kubernetes Service (AKS) streamen. AKS pullt nur die erforderlichen Ebenen für den anfänglichen Podstart, wodurch die Zeit für die Bereitstellung Ihrer Workloads verkürzt wird.

Voraussetzungen

  • Artefaktstreaming erfordert, dass Sie über einen Premium-ACR verfügen, der in Ihren AKS-Cluster integriert ist.
  • Artefaktstreaming muss in ACR aktiviert sein.

Anweisungen zum Aktivieren von Artifact Streaming in ACR finden Sie in der Artefaktstreaming-Dokumentation .

Aktivieren des Artefaktstreamings in NAP-Clustern

Cluster mit aktiviertem Node Auto Provisioning (NAP) können das Artifact-Streaming mithilfe des Felds spec.artifactStreaming.enabled der AKSNodeClass CRD aktivieren. Setzen Sie dieses Feld auf true, um das Artefaktstreaming für alle neuen oder vorhandenen NAP-verwalteten Knoten zu aktivieren, die dieser AKSNodeClass-CRD zugeordnet sind.

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

Note

Um das Artefaktstreaming auf verwalteten AKS NAP-Knoten zu verwenden, müssen Sie auch das Artefaktstreaming in Azure Container Registry (ACR) aktivieren. Wenn Sie diese Option in ACR nicht festlegen, wird das Feld standardmäßig auf "false" festgelegt.

VNet-Subnetzkonfiguration (Virtual Network)

Das Feld vnetSubnetID gibt an, welches Azure VNet-Subnetz für die Bereitstellung von Knotennetzwerkschnittstellen verwendet werden soll. Dieses Feld ist optional. Wenn Sie kein Subnetz angeben, verwendet NAP das Standardsubnetz, das während der Karpenter-Installation konfiguriert ist. Weitere Informationen finden Sie unter Subnetzkonfigurationen für NAP.

Beispiel für eine Subnetzkonfiguration

Die Subnetz-ID muss im vollständigen Azure Resource Manager (ARM)-Format vorliegen, wie im folgenden Beispiel gezeigt:

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

Konfiguration der Größe des Betriebssystemdatenträgers

Das Feld osDiskSizeGB gibt die Größe des Betriebssystemdatenträgers in Gigabyte an. Der Standardwert ist 128 GB, und der Mindestwert beträgt 30 GB.

Verwenden Sie größere Betriebssystemdatenträger für Arbeitslasten mit folgenden Anforderungen:

  • Speichern Sie wichtige Daten lokal.
  • Benötigen Sie zusätzlichen Speicherplatz für Containerimages.
  • Haben hohe Festplatten-I/O-Anforderungen.

Beispielkonfiguration der Betriebssystemdatenträgergröße

spec:
  osDiskSizeGB: 256  # 256 GB OS disk

Kurzlebige Betriebssystemdatenträgerkonfiguration

NAP verwendet automatisch ephemerale Betriebssystemdatenträger , wenn verfügbar und für die angeforderte Datenträgergröße geeignet ist. Flüchtige Betriebssystemdatenträger bieten im Vergleich zu verwalteten Datenträgern eine bessere Leistung und geringere Kosten.

Kurzlebige Datenträgerauswahlkriterien

Das System wählt automatisch ephemerale Datenträger in den folgenden Szenarien aus:

  • Der VM-Instanztyp unterstützt ephemerale Betriebssystemdatenträger.
  • Die flüchtige Festplattenkapazität ist größer oder gleich der angeforderten osDiskSizeGB.
  • Der virtuelle Computer verfügt über ausreichende ephemere Speicherkapazität.

Wenn diese Bedingungen nicht erfüllt sind, greift das System auf verwaltete Datenträger zurück.

Kurzlebige Datenträgertypen und Priorisierung

Azure VMs können unterschiedliche Arten von ephemerem Speicher aufweisen. Das System verwendet die folgende Prioritätsreihenfolge:

  • NVMe-Datenträger (höchste Leistung)
  • Cachedatenträger (ausgewogene Leistung)
  • Ressourcendatenträger (grundlegende Leistung)

Beispiel für eine kurzlebige Datenträgerkonfiguration

Sie können die Anforderungen des Knotenpools verwenden, um sicherzustellen, dass Knoten über ausreichende ephemere Datenträgerkapazität verfügen, wie im folgenden Beispiel gezeigt:

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

Diese Konfiguration stellt sicher, dass nur VM-Instanztypen mit kurzlebigen Datenträgern größer als 128 GB ausgewählt werden, wodurch die Verwendung kurzlebiger Datenträger für die angegebene Größe des Betriebssystemdatenträgers gewährleistet wird.

Maximale Pods-Konfiguration

Das Feld maxPods gibt die maximale Anzahl von Pods an, die auf einem Knoten geplant werden können. Diese Einstellung wirkt sich sowohl auf die Clusterdichte als auch auf die Netzwerkkonfiguration aus.

Der Mindestwert für maxPods 10 und der Maximalwert ist 250.

Standardverhalten für maxPods

Das Standardverhalten für maxPods hängt von der Netzwerk-Plugin-Konfiguration ab. In der folgenden Tabelle sind die Standardwerte zusammengefasst:

Netzwerk-Plug-In-Konfiguration Standard maxPods pro Knoten
Azure CNI mit Standardnetzwerken (v1 oder NodeSubnet) 30
Azure CNI mit Overlaynetzwerk 250
None (kein Netzwerk-Plug-In) 250
Weitere Konfigurationen 110 (Standard Kubernetes-Voreinstellung)

Beispiel für maximale Podkonfiguration

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

LocalDNS-Konfiguration

LocalDNS stellt einen DNS-Proxy auf Knotenebene bereit, der DNS-Abfragen näher an Workloads löst, wodurch die Abfragelatenz reduziert und die Resilienz während vorübergehender DNS-Unterbrechungen verbessert wird. Weitere Informationen finden Sie in der LocalDNS-Dokumentation. LocalDNS ist standardmäßig auf "Deaktiviert" festgelegt und kann mit den folgenden Optionen konfiguriert werden:

  • Disabled (Standard) – Deaktiviert das LocalDNS-Feature. DNS-Abfragen werden nicht lokal auf dem Knoten aufgelöst.
  • Preferred – AKS verwaltet die LocalDNS-Aktivierung basierend auf der Kubernetes-Version des Knotenpools. Die Konfiguration wird immer validiert und einbezogen, aber LocalDNS wird nur aktiviert, wenn die richtige Kubernetes-Version verwendet wird.
  • Required - LocalDNS wird für den Knoten-Pool erzwungen, wenn alle Voraussetzungen erfüllt sind. Wenn die Anforderungen nicht erfüllt sind, schlägt die Bereitstellung fehl.

Beispielkonfiguration für LocalDNS

Sie können LocalDNS-Konfigurationen wie vnetDNSOverrides und kubeDNSOverrides anpassen. Weitere Informationen zu den unterstützten Plug-Ins finden Sie unter Customize LocalDNS.

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"

Aktualisieren Sie die LocalDNS-Konfiguration für eine vorhandene AKSNodeClass

Die localDNS Einstellung nimmt wie andere AKSNodeClass Einstellungen an der Drifterkennung teil. Wenn Sie spec.localDNS an einem AKSNodeClass ändern, auf den vorhandene Knoten bereits verweisen, wendet NAP die Änderung über den Standard-Drift-Mechanismus an. NAP führt kein Reimaging auf bestehenden Knoten durch.

Das folgende Verhalten gilt, wenn Sie den LocalDNS-Modus oder Überschreibungen ändern, z. B. beim Ändern von mode von Disabled in Required:

  • Neue Knoten: Jeder Knoten, den NAP bereitstellt, nachdem Sie die AKSNodeClass aktualisiert haben, verwendet die neue LocalDNS-Konfiguration.
  • Vorhandene Knoten: NAP kennzeichnet die vorhandenen NodeClaim-Objekte als abgewichen, da ihre aufgezeichnete Konfiguration nicht mehr mit der AKSNodeClass übereinstimmt. NAP startet einen Ersatzknoten, der die neue LocalDNS-Konfiguration verwendet, und sperrt, entleert und entfernt anschließend den abgewichenen Knoten.
  • Kein Reimaging: Durch das Aktivieren von LocalDNS für einen verwalteten AKS-Knotenpool wird bei jedem Knoten im Pool ein Reimaging durchgeführt. NAP ersetzt stattdessen den Knoten. In beiden Fällen werden Pods auf den betroffenen Knoten entfernt und neu eingeplant. Planen Sie daher mit denselben Auswirkungen auf die Workload.

Von Bedeutung

Die Einstellung mode auf Preferred oder Disabled ändert auch die aufgelöste AKSNodeClass-Konfiguration und führt dazu, dass vorhandene Knoten abweichen. Jede Änderung innerhalb des Abschnitts localDNS, einschließlich der Werte vnetDNSOverrides und kubeDNSOverrides, führt zum Ersetzen von Knoten.

Wenn der Austausch beginnt

Die Drift-Auswertung und der Austausch beginnen, sobald Sie die aktualisierte AKSNodeClass anwenden. Der Austausch folgt dem standardmäßigen NAP-Unterbrechungslebenszyklus, sodass die Rate und der Zeitpunkt von den Unterbrechungskontrollen abhängen, die Sie für die NodePool-Ressourcen konfigurieren, die auf AKSNodeClass verweisen.

Wie NAP den Ersatz orchestriert

Der von einer LocalDNS-Änderung verursachte Drift entspricht den standardmäßigen NAP-Unterbrechungskontrollen, die in der folgenden Tabelle beschrieben sind:

Steuerung Auswirkung auf die durch LocalDNS verursachte Ersetzung
Unterbrechungsbudgets (spec.disruption.budgets) Die Rate begrenzt, wie viele Knoten NAP gleichzeitig ersetzt. Wenn Sie keine Budgets definieren, verwendet NAP standardmäßig ein Budget von nodes: 10%, sodass maximal 10 Prozent der Knoten des Knotenpools gleichzeitig unterbrochen werden.
Budget schedule und duration Beschränkt den Austausch auf ein Wartungsfenster. Platzieren Sie nodes: "0" außerhalb des Fensters, um den Austausch zu blockieren.
Pod disruption budgets (PDBs) Während des Node-Drain anwenden. NAP wartet, anstatt Pods zu löschen, die gegen eine PDB verstoßen.
karpenter.sh/do-not-disrupt Anmerkung Schließt mit Anmerkungen versehene Pods und Knoten von freiwilligen Unterbrechungen aus, einschließlich Drift.
terminationGracePeriod Obergrenzen beanspruchen Zeit. Diese Einstellung umgeht PDBs und die karpenter.sh/do-not-disrupt-Anmerkungen, wenn der Zeitraum abläuft.

Der Ersatz ist weder vollständig seriell noch vollständig parallel. NAP stellt Ersatzkapazität bereit, bevor ein abgewichener Knoten entfernt wird, kann jedoch mehrere Knoten, die auf denselben AKSNodeClass-Wert verweisen, gleichzeitig ersetzen – bis zu dem Limit, das durch Ihre Unterbrechungsbudgets festgelegt ist.

Warning

Wenn Sie keine Unterbrechungsbudgets für Ihre Knotenpools und keine Pod-Unterbrechungsbudgets für Ihre Workloads definieren, kann das Ändern von localDNS bei einem stark ausgelasteten AKSNodeClass bis zu 10 Prozent Ihrer Knoten gleichzeitig ohne Schutz auf Anwendungsebene beeinträchtigen, was zu Ausfallzeiten der Workloads führen kann. Definieren Sie PDBs für kritische Workloads und legen Sie ein konservatives Unterbrechungsbudget fest, bevor Sie localDNS auf einem Produktionscluster ändern.

Verringern Sie das Verfügbarkeitsrisiko, wenn Sie LocalDNS aktivieren

  1. Vergewissern Sie sich, dass Ihre benutzerdefinierten DNS-Server Abfragen sowohl über UDP als auch über TCP-Port 53 aus dem Knotensubnetz beantworten. Weitere Informationen finden Sie unter Benutzerdefiniertes DNS vor dem Aktivieren von LocalDNS überprüfen.

  2. Definieren Sie Pod-Unterbrechungsbudgets für jede kritische Workload.

  3. Legen Sie ein konservatives Unterbrechungsbudget für die betroffenen NodePool-Ressourcen fest, bevor Sie die AKSNodeClass ändern, wie im folgenden Beispiel gezeigt:

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

  4. Wenden Sie die localDNS Änderung zuerst auf eine Nichtproduktionsumgebung AKSNodeClass an. Erstellen Sie alternativ ein AKSNodeClass, für das LocalDNS aktiviert ist, und migrieren Sie Workloads zu einem NodePool, das darauf verweist.

  5. Überwachen Sie den Ersetzungsfortschritt, indem Sie die Node-Claims auflisten. Der Austausch ist abgeschlossen, wenn kein NodeClaim die Statusbedingung Drifted meldet.

    # 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. Stellen Sie sicher, dass LocalDNS auf den Ersatzknoten aktiv ist. Weitere Informationen finden Sie unter Überprüfen des LocalDNS-Betriebs.

Kubelet-Konfiguration

Im Abschnitt kubelet können Sie verschiedene Kubelet-Parameter konfigurieren, die sich auf das Knotenverhalten auswirken. Diese Parameter sind typische Kubelet-Argumente, daher übergibt der Azure Anbieter sie einfach an das Kubelet auf dem Knoten.

Von Bedeutung

Konfigurieren Sie kubelet-Einstellungen sorgfältig, und testen Sie zuerst alle Änderungen in Nichtproduktionsumgebungen.

CPU-Verwaltung

Die folgenden Einstellungen steuern das Verhalten der CPU-Verwaltung für das Kubelet:

spec:
  kubelet:
    cpuManagerPolicy: "static"  # or "none"
    cpuCFSQuota: true
    cpuCFSQuotaPeriod: "100ms"
  • cpuManagerPolicy: Steuert, wie das Kubelet CPU-Ressourcen zuordnet. Legen Sie dies für CPU-Anheften bei latenzempfindlichen Workloads auf "static" fest.
  • cpuCFSQuota: Ermöglicht die Erzwingung des CPU-Kontingents durch den Completely Fair Scheduler (CFS) für Container, die CPU-Grenzwerte angeben.
  • cpuCFSQuotaPeriod: Legt den CPU-CFS-Kontingentzeitraum fest.

Automatische Speicherbereinigung für Images

Die folgenden Einstellungen steuern das GC-Verhalten von Images für Kubelet:

spec:
  kubelet:
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

Diese Einstellungen legen fest, wann das Kubelet die Garbage Collection von Containerimages durchführt:

  • imageGCHighThresholdPercent: Prozentsatz der Festplattenspeichernutzung, der die Bild-Garbage-Collection auslöst.
  • imageGCLowThresholdPercent: Zielwert für die prozentuale Datenträgernutzung nach GC.

Topologieverwaltung

Die folgende Einstellung steuert die Topologie-Manager-Richtlinie für das Kubelet:

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

Der Topologie-Manager unterstützt die Koordination der Ressourcenzuweisung für latenzempfindliche Workloads über CPU- und Geräte-Ressourcen (wie GPU) hinweg.

Systemkonfiguration

Mit den folgenden Einstellungen können Sie zusätzliche Systemparameter für das Kubelet konfigurieren:

spec:
  kubelet:
    allowedUnsafeSysctls:
      - "kernel.msg*"
      - "net.ipv4.route.min_pmtu"
    containerLogMaxSize: "50Mi"
    containerLogMaxFiles: 5
    podPidsLimit: 4096
  • allowedUnsafeSysctls: Liste der zulässigen unsicheren sysctls, die Pods verwenden können.
  • containerLogMaxSize: Maximale Größe von Container-Logdateien vor der Rotierung.
  • containerLogMaxFiles: Maximale Anzahl der containerprotokolldateien, die aufbewahrt werden sollen.
  • podPidsLimit: Maximale Anzahl von Prozessen, die in einem beliebigen Pod zulässig sind.

Konfigurationseinstellungen für benutzerdefinierte Linux-Betriebssysteme

Im Abschnitt LinuxOSConfig können Sie verschiedene Kubelet-Parameter konfigurieren, die sich auf das Knotenverhalten auswirken. Diese Parameter sind typische benutzerdefinierte OS-Argumente, daher leitet NAP sie unverändert an das kubelet auf dem Knoten weiter.

Weitere Informationen zu benutzerdefinierten Linux-Betriebssystemkonfigurationseinstellungen, Standardwerten und Überlegungen finden Sie in der Referenz zu benutzerdefinierten Knotenkonfigurationsparametern.

Von Bedeutung

Konfigurieren Sie die Linux-Betriebssystemeinstellungen sorgfältig, und testen Sie zuerst alle Änderungen in Nichtproduktionsumgebungen.

Einstellungen für Linux-Dateihandle-Grenzwerte

Verwenden Sie die folgenden Einstellungen, um die Dateisystemeinstellungen festzulegen.

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

Linux-Socket- und Netzwerkoptimierungseinstellungen

Verwenden Sie die folgenden Einstellungen, um die TCP- und Netzwerkeinstellung festzulegen.

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

Limiteinstellungen für Linux-Worker

Verwenden Sie die folgenden Einstellungen, um die Kerneleinstellung festzulegen.

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

Einstellungen für den virtuellen Speicher unter Linux

Verwenden Sie die folgenden Optionen, um den Betrieb des virtuellen Linux-Speicher-Subsystems des Linux-Kernels und das Schreiben von schmutzigen Daten auf den Datenträger zu optimieren.

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

GPU-Einstellungen

Verwenden Sie das folgende Feld, um die Installation benutzerdefinierter GPU-Treiber zu aktivieren, z. B. mit dem 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

Verwaltete GPU

Das gpu.modeFeld steuert die INSTALLATION des GPU-Treibers. Sie akzeptiert Driver oder None und ist standardmäßig auf Driver eingestellt. Legen Sie None fest, dass die Treiberinstallation übersprungen wird, z. B. bei Verwendung des NVIDIA GPU-Operators.

Um die verwaltete NVIDIA-GPU-Nutzung zu aktivieren, verwenden Sie mode: Driver und setzen Sie nvidia.managementMode: Managed. Verwaltete GPUs werden für Linux-NVIDIA-GPU-Knoten unterstützt, die den Bereitstellungsmodus der AKS Machine API verwenden. Der standardmäßige NVIDIA-Verwaltungsmodus ist Unmanaged.

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

Ein vollständiges NAP-verwaltetes GPU-Beispiel und überprüfungsschritte finden Sie unter AKS-verwaltete GPU-Knoten.

Sicherheitseinstellungen

Verschlüsselung auf dem Host

Das folgende Feld gibt an, ob die Verschlüsselung auf Hostebene für bereitgestellte Knoten aktiviert ist. Wenn Sie dieses Feld auf true setzen, umfasst NAP nur Instanzoptionen, die eine Verschlüsselung auf Hostebene unterstützen.

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

Weitere Informationen zur hostbasierten Verschlüsselung finden Sie in der Hostdokumentation zur Verschlüsselung.

Benutzerdefinierte verwaltete Schlüssel und Datenträgerverschlüsselungssätze

NAP unterstützt Cluster, die vom Kunden verwaltete Schlüssel und Datenträgerverschlüsselungssätze verwenden. Aktivieren Sie diese Optionen auf Clusterebene. Sie verfügen nicht über AKSNodeClass Felder, die Sie festlegen müssen. Stellen Sie sicher, dass Ihre Clusteridentität über die richtige rollenbasierte Zugriffssteuerung (RBAC) verfügt:

  • Die Clusteridentität hat Reader-Zugriff auf den Datenträgerverschlüsselungssatz.
  • Die Disk Encryption Set-Ressource hat Key Vault Crypto Service Encryption User Zugriff auf den Azure-Schlüsseltresor.

Informationen zu kundenseitig verwalteten Schlüsseln und Datenträgerverschlüsselungssätzen, die bei der Clustererstellung aktiviert werden, finden Sie in der Dokumentation zu kundenseitig verwalteten Schlüsseln.

Aktivieren des vertrauenswürdigen Starts in NAP-Clustern

Cluster mit aktiviertem Node Auto Provisioning (NAP) können den vertrauenswürdigen Start mithilfe des Felds spec.security.trustedLaunch der AKSNodeClass CRD aktivieren. Legen Sie die secureBoot- und vTPM-Felder auf true fest, um den vertrauenswürdigen Start für alle neuen oder vorhandenen NAP-verwalteten Knoten zu aktivieren, die dieser AKSNodeClass CRD zugeordnet sind.

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

Konfiguration Azure Ressourcentags

Sie können Azure Ressourcentags angeben, die für alle VM-Instanzen gelten, die mit einer bestimmten AKSNodeClassRessource erstellt wurden. Tags sind nützlich für die Kostenverfolgung, die Organisation von Ressourcen und die Einhaltung von Compliance-Anforderungen.

Tag-Einschränkungen

  • Azure Ressourcentags haben einen Grenzwert von 50 Tags pro Ressource.
  • Bei Tagnamen wird die Groß-/Kleinschreibung nicht berücksichtigt, bei Tagwerten hingegen schon.
  • Azure reserviert einige Tagnamen, die nicht verwendet werden können. Weitere Informationen finden Sie unter Tag-Anleitungen und Grenzwerte.

Beispielkonfiguration für Tags

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

Umfassendes AKSNodeClass Konfigurationsbeispiel

Im folgenden Beispiel wird eine umfassende AKSNodeClass Konfiguration veranschaulicht, die alle in diesem Artikel behandelten Einstellungen enthält:

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

Nächste Schritte

Weitere Informationen zur automatischen Bereitstellung von Knoten in AKS finden Sie in den folgenden Artikeln:

  • Zuletzt aktualisiert um