Dynamische Ressourcenzuweisung in GKE

Mit der dynamischen Ressourcenzuweisung (Dynamic Resource Allocation, DRA) können Sie GPUs Ihren Google Kubernetes Engine-Arbeitslasten (GKE) zuweisen. In diesem Dokument werden die Grundlagen von DRA, die Verwendung von DRA in GKE und die Vorteile der Verwendung von DRA erläutert.

Dieses Dokument richtet sich an die folgenden Rollen:

  • Plattformadministratoren die die Komplexität und den Aufwand bei der Einrichtung der Infrastruktur reduzieren möchten mit spezialisierten Hardwaregeräten.
  • App-Operatoren und Data Engineers die Arbeitslasten wie KI/ML oder Hochleistungs-Computing (HPC) ausführen.

Sie sollten bereits mit den folgenden Themen vertraut sein:

Einführung in DRA

DRA ist eine integrierte Kubernetes-Funktion, mit der Sie Hardware in Ihrem Cluster flexibel anfordern, zuweisen und zwischen Pods und Containern freigeben können. DRA verbessert die Zuweisung von angehängter Hardware wie Beschleunigern, indem Geräteanbieter und Plattformadministratoren Klassen von Geräten deklarieren können, die angefordert und zugewiesen werden können. App-Operatoren können bestimmte Gerätekonfigurationen innerhalb dieser Klassen anfordern und diese Konfigurationen dann in ihren Arbeitslasten anfordern. Kubernetes und GKE verwalten die Pod-Planung, Knotenzuweisungen und Gerätezuteilung basierend auf Arbeitslastanfragen.

Ein Plattformadministrator kann beispielsweise eine Geräteklasse definieren, die nur NVIDIA A100-GPUs enthält. App-Operatoren können die Geräte in dieser Geräteklasse dann anhand der Arbeitslastanforderungen filtern, z. B. nach mindestens 80 GB GPU-Speicher. Wenn der App-Operator eine Arbeitslast bereitstellt, die die gefilterte Konfiguration anfordert, platziert GKE die Pods auf Knoten, die die ausgewählten Kriterien erfüllen. In diesem Beispiel findet GKE Knoten mit verfügbaren A100-GPUs (80 GB). Der App-Operator muss im Arbeitslastmanifest keine bestimmten Knoten oder Gerätekonfigurationen auswählen.

Vorteile von DRA

Ohne DRA basiert die Zuweisung von Hardwaregeräten in Kubernetes auf Geräte-Plug-ins. Wenn Sie Hardware-Ressourcen mithilfe von Geräte-Plug-ins an Pods anhängen möchten, verwenden Sie Knotenlabels, um Pods auf bestimmten Knoten zu platzieren. Wenn Sie außerdem die Ressourcen eines gesamten Knotens einem einzelnen Pod zuweisen möchten, fordern Sie die genaue Anzahl der Geräte an, die an die Knoten angehängt sind.

Mit DRA ähnelt die Zuweisung von Geräten zu Pods der Zuweisung von Volumes für den Speicher. Sie definieren Geräteklassen, fordern Geräte innerhalb dieser Klassen an und weisen diese angeforderten Geräte dann Arbeitslasten zu. DRA bietet eine deutlich erweiterbarere Oberfläche, um Geräte basierend auf Arbeitslast- und Geschäftsanforderungen zu filtern. Der DRA-Ansatz, Ausdrücke und Vorlagen zum Anfordern von Hardware und Planen von Pods zu verwenden, bietet folgende Vorteile:

  • Deklarative Gerätezuteilung: Plattformadministratoren können Geräte konfigurationen für bestimmte Arten von Arbeitslasten oder Teams definieren.
  • Weniger Komplexität teamübergreifend: Wenn Plattformadministratoren Knoten mit spezialisierten Hardwarekonfigurationen bereitstellen, müssen App-Operatoren nicht wissen, welche Knoten bestimmte Konfigurationen haben. Plattformadministratoren müssen Knoten nicht labeln oder Informationen zu bestimmten Knoten und Geräten an Operatoren weitergeben.
  • Weniger Komplexität für Entwickler: Kubernetes plant Pods basierend auf der referenzierten Gerätekonfiguration. App-Operatoren müssen in ihren Arbeitslasten keine bestimmten Knoten auswählen und nicht dafür sorgen, dass jeder Pod genau die Anzahl von Geräten anfordert, die an diese Knoten angehängt sind.
  • Zentrale Infrastrukturverwaltung: Plattformadministratoren können zentral Hardwarekonfigurationen definieren, die bestimmte Geschäftsanforderungen erfüllen. Ein Plattformadministrator könnte beispielsweise eine Hochleistungskonfiguration mit H100-GPUs und eine kleine Inferenzkonfiguration mit Tesla T4-GPUs deklarieren.
  • Flexible Hardwareauswahl: Sie können CEL-Ausdrücke verwenden, um nach Geräten mit bestimmten Attributen zu filtern. Mit Ausdrücken können Sie Geräte filtern, die für bestimmte Arbeitslasten optimal sind.

Wann sollte DRA verwendet werden?

Der Hauptgrund für die Verwendung von DRA in GKE ist die Flexibilität, mit der Sie Geräte für Arbeitslasten anfordern können. Sie können ein Manifest einmal schreiben und die Arbeitslast in verschiedenen Clustern mit unterschiedlichen Gerätetypen bereitstellen, ohne das Manifest ändern zu müssen. Diese Flexibilität ist ideal für Anwendungsfälle wie die folgenden:

  • GPU-Verfügbarkeit verbessern: Für Arbeitslasten, die Zugriff auf GPU Hardware benötigen, können Sie mit DRA jede verfügbare GPU im Cluster anfordern, anstatt ein GPU-Modell angeben zu müssen. Wenn für diese Arbeitslasten bestimmte Anforderungen an den GPU-Speicher (VRAM) gelten, können Sie jede GPU im Cluster anfordern, die eine Mindestspeichermenge hat. Diese Art von flexibler Anfrage erweitert die Anzahl der GPU-Knoten, auf denen eine Arbeitslast ausgeführt werden kann. Dadurch wird das Risiko verringert, dass die Arbeitslast aufgrund nicht verfügbarer Ressourcen nicht geplant wird.

  • Knotenverfügbarkeit während der Skalierung optimieren: Die Anzahl der Geräte, die für eine Arbeitslast erforderlich sind, kann je nach Faktoren wie Gerätetyp und Funktionen variieren. Mit GKE ComputeClasses können Sie beschleunigte Pods basierend auf der Geräte verfügbarkeit in bestimmten Knotenpools platzieren. Anschließend können Sie Ihre Pods so konfigurieren, dass sie die Geräte auf jedem Knoten anfordern, auf dem GKE die Pods platziert.

    Wenn Sie DRA mit ComputeClasses verwenden, können Sie das Risiko nicht geplanter Arbeitslasten minimieren und gleichzeitig Arbeitslasten auf optimierter Hardware ausführen.

Terminologie

Open-Source-Kubernetes und verwaltete Kubernetes-Anbieter wie GKE verwenden die folgenden DRA-API-Arten:

ResourceSlice
Eine ResourceSlice listet ein oder mehrere Hardwaregeräte im Cluster auf, auf die Knoten zugreifen können. In einem Knoten, der auf eine einzelne GPU zugreifen kann, listet die ResourceSlice beispielsweise die GPU und den Namen des Knotens auf. Die DRA-Gerätetreiber auf jedem Knoten erstellen ResourceSlices. Der Kubernetes-Planer verwendet ResourceSlices, um zu entscheiden, welche Geräte zugewiesen werden sollen, um Arbeitslastanfragen zu erfüllen.
DeviceClass
Eine DeviceClass definiert eine Kategorie von Geräten, z. B. GPUs, die für Arbeitslasten angefordert werden können. Einige Gerätetreiber bieten integrierte DeviceClasses, z. B. die DeviceClass gpu.nvidia.com für NVIDIA-GPUs. Plattformadministratoren können auch benutzerdefinierte DeviceClasses erstellen, die bestimmte Gerätekonfigurationen definieren.
ResourceClaim

Mit einem ResourceClaim kann ein Pod oder ein Nutzer Hardware-Ressourcen anfordern, indem er nach bestimmten Parametern innerhalb einer DeviceClass filtert. Wenn eine Arbeitslast auf einen ResourceClaim verweist, weist Kubernetes diesem ResourceClaim Geräte zu, die den angegebenen Parametern entsprechen.

Stellen Sie sich beispielsweise ein Szenario vor, in dem Sie einen ResourceClaim für eine A100-GPU (40 GB) erstellen und dann eine Arbeitslast bereitstellen, die diesen ResourceClaim auswählt. Kubernetes weist dem ResourceClaim eine verfügbare A100-GPU (40 GB) zu und plant Ihren Pod auf einem Knoten, der auf diese GPU zugreifen kann.

ResourceClaimTemplate

Ein ResourceClaimTemplate definiert eine Vorlage, mit der Pods automatisch neue ResourceClaims pro Pod erstellen können. ResourceClaimTemplates sind nützlich, wenn Sie mehrere Arbeitslasten haben, die Zugriff auf ähnliche Gerätekonfigurationen benötigen, insbesondere bei Verwendung eines Arbeitslast-Controllers wie Deployments oder StatefulSets.

App-Operatoren stellen ResourceClaimTemplates bereit und verweisen dann in Arbeitslasten auf die Vorlagen. Kubernetes erstellt ResourceClaims für jeden Pod basierend auf der angegebenen Vorlage, weist Geräte zu und plant die Pods. Wenn die Pods beendet werden, bereinigt Kubernetes die entsprechenden ResourceClaims.

Weitere Informationen zu DRA-API-Arten finden Sie unter DRA-Terminologie.

Funktionsweise von DRA

Die Verwendung von DRA in Ihren Clustern und Arbeitslasten ähnelt der Verwendung von StorageClasses, PersistentVolumeClaims und PersistentVolumes, um Volumes dynamisch für Pods bereitzustellen.

Das folgende Diagramm zeigt die Schritte, die Clusteradministratoren und App-Operatoren ausführen, um Geräte mit DRA zuzuweisen:

In diesem Diagramm führen Clusteradministratoren und App-Operatoren die folgenden Schritte aus:

  1. Clusteradministratoren installieren Gerätetreiber, die DRA in den Knoten unterstützen.
  2. Clusteradministratoren erstellen DeviceClasses, die nach Hardware filtern, die bestimmte Anforderungen erfüllt, z. B. alle GPUs mit mehr als 40 GB Speicher. Einige Geräte enthalten möglicherweise auch integrierte DeviceClasses.
  3. Anwendungsoperatoren erstellen ResourceClaimTemplates oder ResourceClaims, die Gerätekonfigurationen anfordern. Der primäre Anwendungsfall für jeden Anspruchstyp ist wie folgt:
    • Mit einem ResourceClaim können mehrere Pods gemeinsam auf dasselbe Gerät zugreifen.
    • Mit einem ResourceClaimTemplate können mehrere Pods auf separate, ähnliche Geräte zugreifen, indem automatisch ResourceClaims pro Pod generiert werden.
  4. Anwendungsoperatoren fügen die ResourceClaimTemplates oder ResourceClaims ihren Arbeitslastmanifesten hinzu.
  5. Anwendungsoperatoren stellen die Arbeitslast bereit.

Wenn Sie eine Arbeitslast bereitstellen, die auf ein ResourceClaimTemplate oder einen ResourceClaim verweist, führt Kubernetes die folgenden Planungsschritte aus:

  1. Wenn die Arbeitslast auf ein ResourceClaimTemplate verweist, erstellt Kubernetes für jede Instanz der Arbeitslast ein neues ResourceClaim-Objekt (z. B. jedes Replikat in einem Deployment).
  2. Der Kubernetes-Planer verwendet die ResourceSlices im Cluster, um jedem ResourceClaim des Pods verfügbare, geeignete Geräte zuzuweisen.
  3. Der Planer platziert jeden Pod auf einem Knoten, der Zugriff auf die Geräte hat, die dem ResourceClaim des Pods zugewiesen wurden.
  4. Der kubelet auf dem Zielknoten ruft den DRA-Treiber auf dem Knoten auf, um die zugewiesene Hardware an den Pod anzuhängen und so die Ressourcenanfrage zu erfüllen.

Wann sollten ResourceClaims und ResourceClaimTemplates verwendet werden?

Mit ResourceClaims oder ResourceClaimTemplates können Sie Kubernetes mitteilen, dass Sie Geräte benötigen, die bestimmte Anforderungen erfüllen. Wenn in einem Pod auf einen ResourceClaim verwiesen wird, weist Kubernetes Geräte der entsprechenden ResourceClaim-API-Ressource im Kubernetes API-Server zu. Diese Zuweisung erfolgt unabhängig davon, ob Sie den ResourceClaim erstellt haben oder ob Kubernetes den ResourceClaim aus einem ResourceClaimTemplate erstellt hat.

Wenn Sie einen ResourceClaim erstellen und dann in mehreren Pods darauf verweisen, können alle diese Pods auf die Geräte zugreifen, die Kubernetes für diesen ResourceClaim zuweist. Dieser gemeinsame Zugriff kann beispielsweise auftreten, wenn Sie in einem Deployment-Manifest mit mehreren Replikaten auf einen bestimmten ResourceClaim verweisen. Wenn die zugewiesenen Geräte jedoch nicht für die gemeinsame Nutzung durch mehrere Prozesse konfiguriert sind, kann dieser gemeinsame Gerätezugriff über Pods hinweg zu unerwartetem Verhalten führen.

Wenn Sie Pods separate Geräte zuweisen möchten, können Sie ein ResourceClaimTemplate verwenden. Das ist eine Vorlage, mit der Kubernetes automatisch einzelne ResourceClaims erstellt. Wenn Sie beispielsweise in einem Deployment mit mehreren Replikaten auf ein ResourceClaimTemplate verweisen, erstellt Kubernetes für jeden replizierten Pod einen separaten ResourceClaim. Dadurch erhält jeder Pod ein eigenes zugewiesenes Gerät, anstatt den Zugriff auf das Gerät mit anderen Pods zu teilen. Diese automatisch generierten ResourceClaims sind an die Lebensdauer des entsprechenden Pods gebunden und werden gelöscht, wenn der Pod beendet wird. Wenn Sie unabhängige Pods haben, die Zugriff auf ähnliche Gerätekonfigurationen benötigen, verwenden Sie ein ResourceClaimTemplate, um jedem Pod separat Geräte zuzuweisen.

In der folgenden Tabelle werden einige Unterschiede zwischen dem manuellen Erstellen von ResourceClaims und dem Erstellen von ResourceClaims durch Kubernetes aus einem ResourceClaimTemplate beschrieben:

Tabelle 1. Vergleich von ResourceClaims und ResourceClaimTemplates
Manuell erstellte ResourceClaims Automatisch erstellte ResourceClaims
Von mir verwaltet Von Kubernetes verwaltet
Ermöglicht den Zugriff auf dieselben Geräte von mehreren Pods aus Ermöglicht den Zugriff auf Geräte von einem einzelnen Pod aus
Ist unabhängig von Pods im Cluster vorhanden Ist an den Lebenszyklus des entsprechenden Pods gebunden
Ideal für mehrere Arbeitslasten, die ein bestimmtes Gerät gemeinsam nutzen müssen Ideal für mehrere Arbeitslasten, die unabhängigen Gerätezugriff benötigen

Vergleich von DRA und manueller Gerätezuteilung

Mit DRA ähnelt die Zuweisung von angehängten Geräten der dynamischen Bereitstellung von PersistentVolumes. Kubernetes unterstützt auch die Zuweisung von Geräten mithilfe von Geräte-Plug-ins. Diese Methode umfasst die folgenden Schritte:

  1. Ein Clusteradministrator erstellt Knoten mit angehängten Geräten wie GPUs.
  2. Der Clusteradministrator teilt den Arbeitslastoperatoren Informationen zu bestimmten Knoten und den daran angehängten Geräten mit.
  3. Ein Arbeitslastoperator fordert Geräte im Arbeitslastmanifest wie folgt an:
    • Wählen Sie mit einem nodeSelector-Feld einen Knoten mit der erforderlichen Gerätekonfiguration aus, z. B. das GPU-Modell.
    • Geben Sie mit dem Feld resources in der Pod-Spezifikation die genaue Anzahl der Geräte an, die von den Containern verwendet werden sollen.

Bei dieser manuellen Zuweisungsmethode müssen die Anwendungsoperatoren und Clusteradministratoren kommunizieren, welche bestimmten Knoten oder Knotenpools bestimmte Gerätekonfigurationen haben. Sie müssen Arbeitslastanfragen koordinieren, damit sie mit den Geräten auf den Knoten übereinstimmen, andernfalls schlägt die Bereitstellung fehl. Mit DRA können Sie dagegen Ausdrücke verwenden, um Geräte flexibel nach Attributen zu filtern. Arbeitslastoperatoren müssen die genaue Konfiguration der Knoten im Cluster nicht kennen.

In der folgenden Tabelle wird DRA mit Geräte-Plug-ins verglichen:

Tabelle 2. Vergleich von DRA und manueller Gerätezuteilung
DRA Manuelle Zuweisung
Flexible Geräteauswahl mit CEL-Ausdrücken Spezifische Knotenauswahl mit Selektoren und Ressourcenanfragen
Planungsentscheidungen werden von Kubernetes getroffen Planungsentscheidungen werden vom Operator mit Knotenselektoren getroffen
Die Gerätefilterung ist von der Arbeitslasterstellung getrennt Die Gerätefilterung muss im Arbeitslastmanifest erfolgen
Zentrale Gerätefilterung und bedarfsgerechte Klassen, verwaltet von Plattformadministratoren Isolierte Gerätefilterung durch Anwendungsoperatoren
App-Operatoren müssen die Knotenkapazität, Knotenlabelinformationen, oder die angehängten Gerätemodelle für jeden Knoten nicht kennen App-Operatoren müssen wissen, welche Knoten bestimmte Modelle und Mengen bestimmter angehängter Geräte haben.

DRA und Infrastruktur-Autoscaling

Wenn Sie die Anzahl der Knoten in einem Knotenpool im Standardmodus automatisch anpassen möchten, verwenden Sie das Cluster-Autoscaling. Sie können das Cluster-Autoscaling in allen manuell erstellten Knotenpools aktivieren, einschließlich Knotenpools mit DRA-Treibern.

Bei Knotenpools, die DRA verwenden, wirkt sich die Gerätenutzung darauf aus, wie das Cluster-Autoscaling Knoten in einem Knotenpool hinzufügt und entfernt. Um die Gerätenutzung in einem Knotenpool zu berechnen, berücksichtigt das Cluster-Autoscaling die folgenden Faktoren:

  • Alle Geräte in einem Ressourcenpool müssen sich lokal auf einem bestimmten Knoten befinden. Wenn eine ResourceSlice einen Pool von Geräten enthält, die an mehrere Knoten angehängt sind, ignoriert das Cluster-Autoscaling diese Geräte.
  • Alle Geräte im Knotenpool sind gleich wichtig und identisch.
  • DRA-Geräte haben eine höhere Priorität als CPU oder Arbeitsspeicher. In DRA-Knotenpools ignoriert das Cluster-Autoscaling die CPU- und Speichernutzung.

Diese Faktoren können dazu führen, dass Sie in DRA-Knotenpools ein anderes Verhalten beim Herunterskalieren als in anderen Knotenpools beobachten.

Unterstützte GKE-Geräte für DRA

In der folgenden Tabelle werden die Geräte beschrieben, die Sie Arbeitslasten mit DRA in GKE zuweisen können:

Tabelle 3. Unterstützte Geräte für DRA in GKE
Unterstützte Geräte für DRA
GPUs Jeder GPU-Typ, der an Ihrem Standort verfügbar ist. Weitere Informationen finden Sie unter GPU-Standorte.
Netzwerkschnittstellen Mehrere Arten von Netzwerkschnittstellen, z. B. RDMA-fähige Schnittstellen, durch Installation des verwalteten DRANET-Treibers. Weitere Informationen finden Sie unter Netzwerkressourcen mit verwaltetem DRANET von GKE zuweisen.

Beschränkungen

Bei der Verwendung von DRA gelten die folgenden Einschränkungen:

  • Betriebsmodus: DRA ist nur in Clustern im Standardmodus verfügbar.

  • Beschleunigertyp: Während der Vorschau unterstützt DRA in GKE nur GPUs.

  • GPUs:

  • Netzwerkschnittstellen (Vorschau): Informationen zu Einschränkungen finden Sie unter "Netzwerkressourcen mit verwaltetem DRANET von GKE zuweisen".

  • Autoscaling:

    • Bei DRA-Treibern von Drittanbietern, die Sie installieren, muss Ihr Knotenpool mindestens einen Knoten haben. Damit Knotenpools, die Treiber von Drittanbietern verwenden, nicht auf null Knoten skaliert werden, legen Sie die Mindestanzahl der Knoten auf mindestens 1 fest.
    • Das Cluster-Autoscaling funktioniert möglicherweise nicht richtig mit DRA-Treibern von Drittanbietern. Wenn Sie Treiber von Drittanbietern verwenden, prüfen Sie, ob die Treiber Informationen nur für Geräte veröffentlichen, die sich lokal auf bestimmten Knoten befinden.
    • Bei DaemonSets in automatisch skalierten Knotenpools, die einen statischen ResourceClaim verwenden, um den Gerätezugriff zwischen Pods freizugeben, unterstützt das Autoscaling bis zu 128 DaemonSet-Pods. Um diese Einschränkung zu vermeiden, haben Sie folgende Möglichkeiten:
    • Wenn Ihre Pods auf ResourceClaims verweisen und eine PriorityClass haben, die die Richtlinie zur vorzeitigen Beendigung auf PreemptLowerPriority festlegt, kann sich die Autoscaling-Latenz erhöhen. PreemptLowerPriority ist die Standardrichtlinie zur vorzeitigen Beendigung für PriorityClass. Legen Sie daher in Ihren PriorityClasses das Feld preemptionPolicy explizit auf Never fest. Weitere Informationen finden Sie unter Non-preempting PriorityClass.

In diesem Abschnitt finden Sie Empfehlungen für Plattformadministratoren oder App-Operatoren, die mit DRA Geräte für Arbeitslasten zuweisen möchten. DRA ändert die Methode, mit der Sie angehängte Geräte anfordern, sowohl in GKE als auch in Kubernetes erheblich. Wenn Sie erweiterte Anwendungsfälle wie geräteübergreifendes Fallback oder detaillierte Gerätefilterung und -auswahl nutzen möchten, beachten Sie die folgenden Empfehlungen:

Nächste Schritte