Bewährte Methoden für GPU in Azure Kubernetes Service (AKS)

Gilt für: ✔️ AKS Automatic ✔️ AKS Standard

Das Ausführen von GPU-Workloads auf AKS erfordert ein ordnungsgemäßes Setup und eine kontinuierliche Überprüfung, um sicherzustellen, dass Computeressourcen barrierefrei, sicher und optimal genutzt werden können. In diesem Artikel werden bewährte Methoden für die Verwaltung von GPU-aktivierten Knoten, die Überprüfung von Konfigurationen und das Reduzieren von Arbeitsauslastungsunterbrechungen beschrieben.

Für die meisten Produktions-AKS-Workloads ist AKS Automatic die empfohlene Standardeinstellung. AKS Automatic bietet eine produktionsreife Grundlage mit vorkonfigurierten Betriebsfunktionen, Sicherheitsvorkehrungen und SLA-gestützter Pod-Bereitschaft und hilft Teams so, den Plattformbetriebsaufwand ab Tag 2 zu reduzieren.

Auswählen von AKS Automatic oder AKS Standard für GPU-Workloads

Verwenden Sie die folgenden Anleitungen als Ausgangspunkt:

Weitere Informationen finden Sie in der Einführung in Azure Kubernetes Service (AKS) Automatisch.

Was AKS Automatic für GPU-Produktionsarbeitslasten bereitstellt

AKS Automatic hilft dabei, einen starken Betriebsgrundwert für GPU-Produktionsarbeitslasten zu schaffen, indem Folgendes bereitgestellt wird:

• Produktionsbereite Standardwerte für die Clusterkonfiguration.
• Integrierte bewährte Methoden und Garantien.
• SLA-gestützte Pod-Bereitschaft für vorhersehbares Startverhalten.
• Verwalteter Clusterbetrieb, der den manuellen Aufwand bei Day-2-Aufgaben reduziert.

Diese Standardeinstellungen der Plattform ersetzen keine Best Practices auf Workloadebene wie Platzierungsrichtlinien, Validierungsprüfungen und Isolationsrichtlinien, die in diesem Artikel beschrieben werden.

GPU-Workloads, z. B. KI-Modellschulungen, Echtzeit-Rückschlüsse, Simulationen und Videoverarbeitung, sind häufig von folgenden Faktoren abhängig:

• Korrekte GPU-Treiber- und Runtimekompatibilität.
• Genaue Planung von GPU-Ressourcen.
• Zugriff auf GPU-Hardwaregeräte innerhalb von Containern.

Fehlkonfigurationen können zu hohen Kosten, unerwarteten Auftragsfehlern oder GPU-Unterauslastungen führen.

Erzwungene Platzierung der GPU-Workload

Standardmäßig platziert der AKS-Scheduler Pods auf jedem verfügbaren Knoten mit ausreichend CPU und Arbeitsspeicher. Ohne Steuerelemente zur Workload-Platzierung können zwei Probleme auftreten:

• Der Scheduler platziert gpu-Workloads möglicherweise auf Knoten ohne GPUs, was dazu führt, dass die Workloads nicht gestartet werden.
• Allgemeine Workloads belegen möglicherweise GPU-Knoten und verschwenden kostspielige Ressourcen.

So erzwingen Sie die richtige Platzierung

• Versehen Sie Ihre GPU-Knoten mit einem Taint, indem Sie einen Schlüssel wie [gpu-vendor].com/gpu: NoSchedule verwenden (z. B. nvidia.com/gpu: NoSchedule). Dieser Taint verhindert, dass Workloads ohne GPU auf diesen Knoten eingeplant werden.

• Fügen Sie der Podspezifikation Ihrer GPU-Workload eine entsprechende Tolerierung hinzu, damit sie auf den verfälschten GPU-Knoten geplant werden kann.

• Definieren Sie GPU-Ressourcenanforderungen und -beschränkungen in Ihrem Pod, um sicherzustellen, dass der Planer GPU-Kapazität reserviert. Beispiel:

  resources:
    limits:
      [gpu-vendor].com/gpu: 1
  

• Verwenden Sie Validierungsrichtlinien oder Zugangscontroller, um zu erzwingen, dass GPU-Workloads die erforderlichen Tolerierungen und Ressourcenlimits enthalten.

Dieser Ansatz garantiert, dass nur GPU-fähige Workloads auf GPU-Knoten platziert werden und Zugriff auf die benötigten speziellen Computeressourcen haben.

In AKS Automatic sind Plattformschutzschienen standardmäßig vorkonfiguriert. Sie wenden weiterhin Platzierungssteuerelemente auf Workloadebene an, um strenges GPU-Planungsverhalten zu erzwingen.

Überprüfen der Installation und Laufzeitbereitschaft des GPU-Treibers

Überprüfen Sie vor der Bereitstellung von GPU-Workloads in der Produktion immer, ob Ihre GPU-Knotenpools:

• mit kompatiblen GPU-Treibern ausgestattet sind.
• einen fehlerfreien DaemonSet-Controller für Kubernetes-Geräte-Plug-Ins hosten.
• [gpu-vendor].com/gpu als planbare Ressource verfügbar machen.

Sie können die aktuelle Treiberversion, die auf Ihren GPU-Knotenpools ausgeführt wird, mit der Systemverwaltungsschnittstelle (SMI) des zugehörigen GPU-Anbieters bestätigen.

Der folgende Befehl führt nvidia-smi innerhalb Ihres Bereitstellungspods für das GPU-Geräte-Plug-In aus, um die Treiberinstallation und die Runtimebereitschaft für einen NVIDIA-GPU-fähigen Knotenpool zu überprüfen:

kubectl exec -it $"{GPU_DEVICE_PLUGIN_POD}" -n {GPU_NAMESPACE} -- nvidia-smi

Ihre Ausgabe sollte in etwa wie die folgende Beispielausgabe aussehen:

+-----------------------------------------------------------------------------+
|NVIDIA-SMI 570.xx.xx    Driver Version: 570.xx.xx    CUDA Version: 12.x|
...
...

Wiederholen Sie den kubectl exec Befehl für jeden GPU-Knotenpool, um die treiberversion zu bestätigen, die auf Ihren Knoten installiert ist.

Stellen Sie auf Ihren AMD-GPU-fähigen Knotenpools alternativ die AMD-GPU-Komponenten bereit und führen Sie den amd-smi-Befehl im ROCm-Geräte-Plug-In-Pod aus, um die installierte Treiberversion zu bestätigen.

Aktualisieren von GPU-fähigen Knoten auf das neueste Knotenbetriebssystem-Image

Um die Leistung, Sicherheit und Kompatibilität Ihrer GPU-Workloads in AKS sicherzustellen, sollten Sie Ihre GPU-Knotenpools stets mit den neuesten empfohlenen Knotenbetriebssystem-Images aktualisieren. Diese Updates sind wichtig, da sie:

• die neuesten GPU-Treiber für die Produktion enthalten und alle veralteten Versionen oder EOL-Versionen (End-of-Life) ersetzen.
• vollständig auf Kompatibilität mit Ihrer aktuellen Kubernetes-Version getestet wurden.
• bekannte Sicherheitsrisiken, die von GPU-Anbietern identifiziert wurden, adressieren.
• die neuesten Verbesserungen des Betriebssystems und der Containerruntime für verbesserte Stabilität und Effizienz enthalten.

Aktualisieren Sie Ihre GPU-Knotenpools auf das neueste empfohlene Knotenbetriebssystemimage, das von AKS veröffentlicht wird, entweder durch Festlegen des Autoupgrade-Kanals oder durch manuelles Upgrade. Sie können die neuesten Knotenimageversionen mithilfe des AKS-Release-Trackers überwachen und nachverfolgen.

Beginnen Sie für die meisten Produktionsszenarien mit AKS Automatic als Standardbasisplan. Wenn Sie AKS Standard verwenden, konfigurieren Sie Upgradekanäle und Wartungsfenster explizit.

Trennen von GPU-Workloads bei Verwendung freigegebener Cluster

Wenn ein einzelner AKS-Cluster mit GPU-Knotenpools unterschiedliche Typen von GPU-Workloads (z. B. Modelltraining, Echtzeitrückschluss oder Batchverarbeitung) ausführt, ist es wichtig, diese Workloads zu trennen, um Folgendes zu erreichen:

• Vermeiden von versehentlichen Interferenzen oder Ressourcenkonflikten zwischen den unterschiedlichen Workloadtypen
• Verbessern der Sicherheit und Einhalten von Compliancegrenzen
• Vereinfachen der Verwaltung und Überwachung der GPU-Ressourcennutzung nach Workloadkategorie

Sie können GPU-Workloads innerhalb eines einzelnen AKS-Clusters mithilfe von Namespaces und Netzwerkrichtlinien isolieren. Dies ermöglicht eine klarere Governance über workloadspezifische Kontingente, Limits und Protokollierungskonfigurationen.

Beispielszenario

Nehmen wir als Beispiel einen AKS-Cluster, der zwei verschiedene GPU-Workloadtypen hostet, die nicht miteinander kommunizieren müssen:

• Schulungsarbeitslasten: Ressourcenintensive KI-Modellschulungsaufträge.
• Inference-Workloads: Latenzsensitive Echtzeit-Ableitungsdienste.

Mit den folgenden Schritten können Sie die beiden Workloads trennen:

1. Erstellen Sie dedizierte Namespaces pro Workloadtyp mithilfe des kubectl create namespace-Befehls.

   kubectl create namespace gpu-training
   kubectl create namespace gpu-inference
   

2. Beschriften Sie GPU-Workload-Pods nach Typ, wie im folgenden Beispiel gezeigt:

   metadata:
     namespace: gpu-training
     labels:
       workload: training
   

3. Wenden Sie Netzwerkrichtlinien an, um den Datenverkehr zwischen den Workloadtypen zu isolieren. Das folgende Manifest blockiert den gesamten eingehenden und ausgehenden Datenverkehr für den gpu-training-Namespace (sofern nicht explizit zugelassen):

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: deny-cross-namespace
     namespace: gpu-training
   spec:
     podSelector: {}
     policyTypes:
     - Ingress
     - Egress
     ingress: []
     egress: []
   

Diese Richtlinie:

• gilt für alle Pods im gpu-training-Namespace.
• verweigert standardmäßig den gesamten eingehenden und ausgehenden Datenverkehr, wodurch eine klare Isolation unterstützt wird.

Dieses Modell verbessert Klarheit, Kontrolle und Sicherheit in freigegebenen GPU-Umgebungen, insbesondere wenn Workloadtypen unterschiedliche Runtimeprofile, Risikostufen oder Betriebssystemanforderungen aufweisen.

Optimieren der Ressourcennutzung auf GPU-Knoten mithilfe von MIG (GPU mit mehreren Instanzen)

Unterschiedliche GPU-Workloads weisen unterschiedliche Speicheranforderungen auf. Kleinere Bereitstellungen, z. B. NVIDIA A100 40 GB, benötigen möglicherweise keine gesamte GPU. Eine einzelne Workload belegt jedoch standardmäßig die gesamte GPU-Ressource selbst bei Unterauslastung.

AKS unterstützt die Ressourcenoptimierung auf GPU-Knoten, indem diese mithilfe von MIG (GPU mit mehreren Instanzen) in kleinere Segmente aufgeteilt werden, sodass Teams kleinere Aufträge effizienter planen können. Erfahren Sie mehr über die unterstützten GPU-Größen und die ersten Schritte mit GPUs mit mehreren Instanzen in AKS.

Verwenden von ephemeralen NVMe-Datenträgern als Hochleistungscache

Für KI-Workloads, die auf GPU-VMs in AKS ausgeführt werden, ist der schnelle und zuverlässige Zugriff auf temporären Speicher für die Maximierung der Schulungs- und Ableitungsleistung von entscheidender Bedeutung. Ephemere NVMe-Datenträger bieten hohen Durchsatz und geringe Latenz, da sie direkt an den VM-Host angeschlossen sind, was sie ideal für Szenarien wie das Zwischenspeichern von Datasets, das Speichern von Zwischenprüfpunkten und Modellgewichtungen oder die Bereitstellung von temporärem Speicherplatz für die Vorverarbeitung und Analyse von Daten macht.

Wenn Sie GPU-fähige Knotenpools für KI-Workloads bereitstellen, konfigurieren Sie ephemere NVMe-Datenträger als hochleistungsfähigen Cache oder Zwischenspeicher. Mit diesem Ansatz können E/A-Engpässe beseitigt, datenintensive Vorgänge beschleunigt und sichergestellt werden, dass Ihre GPU-Ressourcen beim Warten auf Daten nicht leer sind.

Azure unterstützt kurzlebige NVMe-Datenträger in einer Vielzahl von Azure GPU-VM-Familien. Je nach GPU-VM-Größe verfügt der virtuelle Computer über bis zu acht kurzlebige NVMe-Datenträger mit einer kombinierten Kapazität von bis zu 28 TiB. Ausführliche Konfigurationen auf VM-Größen finden Sie in der Dokumentation zur ND H100 v5-Serie oder in der Dokumentation zur VM-Größe für Ihre ausgewählte GPU-Familie.

Um die Bereitstellung und Verwaltung zu vereinfachen, verwenden Sie Azure Container Storage, der automatisch ephemerale NVMe-Datenträger für Ihre Kubernetes-Workloads erkennen und orchestrieren kann.

Empfohlene Szenarien umfassen:

• Zwischenspeichern großer Datasets und Modellprüfpunkte für KI-Schulungen und -Ableitungen.
• Cachen von Modellgewichten für die KI-Inferenz. Beispiel: KAITO-Hostingmodell als OCI-Artefakte auf lokalem NVMe.
• Bereitstellung eines schnellen temporären Speicherbereichs für Batchaufträge und Datenpipelines.

Weitere Anleitungen zu kurzlebigen NVMe-Datenträgern finden Sie unter Bewährte Methoden für kurzlebige NVMe-Datenträger in AKS.

Verwandte Inhalte

Weitere Informationen zu AKS- und GPU-Workloads finden Sie in den folgenden Artikeln:

• Einführung in Azure Kubernetes Service (AKS) Automatic
• Erstellen eines automatischen AKS-Clusters
• Erstellen eines GPU-fähigen Knotenpools auf Ihrem AKS-Cluster
• Überwachen von GPU-Workloads mit dem selbstverwalteten NVIDIA-DCGM-Exporter
• Autoskalierung Ihrer GPU-Workloads basierend auf häufigen GPU-Metriken mit dem KEDA- und DCGM-Exporter