Freigeben über

Konfigurieren von AKSNodeClass-Ressourcen für die automatische Bereitstellung (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 Knoten-Auto-Bereitstellung (NAP) im 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 dem 30. November 2025 unterstützt Azure Kubernetes Service (AKS) keine Sicherheitsupdates für Azure Linux 2.0 mehr oder stellt diese bereit. Das Azure Linux 2.0-Knotenimage ist eingefroren bei der Version 202512.06.0. Ab dem 31. März 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 auf eine unterstützte Kubernetes-Version aktualisieren oder zu osSku AzureLinux3 migrieren. Weitere Informationen finden Sie unter [Stilllegung] von Azure Linux 2.0-Knotenpools in AKS.

Übersicht über AKSNodeClass-Ressourcen

AKSNodeClass Mithilfe von 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 denselben AKSNodeClassPunkt verweisen, sodass Sie gemeinsame Azure-Konfigurationen für verschiedene Knotenpools freigeben können.

Imagefamilienkonfiguration

Das Feld imageFamily bestimmt das standardmäßige VM-Image und die Bootstrapping-Logik für Knoten, die über AKSNodeClass bereitgestellt werden. Wenn Sie keine Bildfamilie angeben, ist Ubuntu2204die Standardeinstellung . GPUs werden mit beiden Imagefamilien in kompatiblen VM-Größen unterstützt.

Unterstützte Imagefamilien

  • Ubuntu: Ubuntu 22.04 Long Term Support (LTS) ist die Standard-Linux-Verteilung für AKS-Knoten.
  • AzureLinux: Azure Linux ist die alternative Linux-Verteilung von Microsoft für AKS-Workloads. Weitere Informationen finden Sie in der Azure Linux-Dokumentation

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

VNet-Subnetzkonfiguration (Virtual Network)

Das vnetSubnetID Feld 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 kurzlebigem Speicher haben. 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:
        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

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 Überlagerungsnetzwerken 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

Kubelet-Konfiguration

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

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.

Konfiguration von Azure-Ressourcentags

Sie können Azure-Ressourcentags angeben, die für alle VM-Instanzen gelten, die mit einer bestimmten AKSNodeClass Ressource 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:
        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

Nächste Schritte

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

  • Last updated on