Freigeben über

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

Die Ausführung von GPU-Workloads auf einem AKS-Cluster erfordert eine ordnungsgemäße Einrichtung und kontinuierliche Von, um sicherzustellen, dass Computeressourcen zugänglich und sicher sind und optimal genutzt werden. In diesem Artikel werden bewährte Methoden für die Verwaltung von GPU-fähigen Knoten, die Überprüfung von Konfigurationen und die Reduzierung von Workloadunterbrechungen mithilfe von anbieterspezifischen Diagnosebefehlen beschrieben.

GPU-Workloads wie das Training von KI-Modellen, Echtzeitrückschlüsse, Simulationen und die Videoverarbeitung hängen häufig von den folgenden Konfigurationen ab:

  • 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-Planer Pods auf jedem verfügbaren Knoten mit ausreichend CPU- und Arbeitsspeicherkapazität. Ohne Anleitung kann dies zu einem der beiden folgenden Hauptprobleme führen:

  1. GPU-Workloads werden möglicherweise auf Knoten ohne GPUs geplant und können daher nicht gestartet werden.
  2. Universelle Workloads können GPU-Knoten belegen, wodurch teure Ressourcen verschwendet werden.

So erzwingen Sie die richtige Platzierung

  • Verfälschen Sie Ihre GPU-Knoten mit einem Schlüssel wie [gpu-vendor].com/gpu: NoSchedule (z. B. „nvidia.com/gpu: NoSchedule“). Dadurch wird verhindert, dass Nicht-GPU-Workloads auf diesen Knoten geplant 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 -limits 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.

Ü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 obigen Schritt 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 Knotenbetriebssystem-Image, das von AKS veröffentlicht wird, entweder über automatische Upgrades oder über manuelle Upgrades. Sie können die neuesten Knotenimageversionen mithilfe des AKS-Release-Trackers überwachen und nachverfolgen.

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:

  • Workloads für Training: ressourcenintensive Aufträge zum Training von KI-Modellen.
  • Workloads für Rückschlüsse: latenzempfindliche Dienste für Echtzeitrückschlüsse.

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 haben unterschiedliche Speicheranforderungen. Kleinere Bereitstellungen (z. B. NVIDIA A100 40 GB) benötigen möglicherweise nicht die gesamte GPU-Kapazität. 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.

Ephemerale NVMe-Datenträger werden in einer Vielzahl von Azure GPU-VM-Familien unterstützt. Je nach GPU-VM-Größe verfügt sie über bis zu 8 ephemere 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.

Von Bedeutung

Daten auf kurzlebigen NVMe-Datenträgern sind temporär und gehen verloren, wenn der virtuelle Computer umgeleitet oder erneut bereitgestellt wird. Verwenden Sie diese Datenträger nur für nicht kritische, vorübergehende Daten und speichern Sie wichtige Informationen zu beständigen Azure-Speicherlösungen.

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

Nächste Schritte

Weitere Informationen zur Bereitstellung und Verwaltung von GPU-Workloads in AKS finden Sie in den folgenden Artikeln:

  • Last updated on