Dynamische Ressourcenzuweisung in GKE

Auf dieser Seite finden Sie Informationen zur dynamischen Ressourcenzuweisung (Dynamic Resource Allocation, DRA) in der Google Kubernetes Engine (GKE). Auf dieser Seite erfahren Sie mehr über die Grundlagen von DRA, wie es in GKE funktioniert und welche Vorteile die Zuweisung von Hardware wie GPUs und TPUs mit DRA bietet.

Diese Seite richtet sich an die folgenden Rollen:

  • Plattformadministratoren, die die Komplexität und den Overhead bei der Einrichtung der Infrastruktur mit speziellen Hardwaregeräten reduzieren möchten.
  • App-Betreiber und Datentechniker, die Arbeitslasten wie KI/ML oder Hochleistungs-Computing (HPC) ausführen.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Ressourcen vertraut:

Einführung in die dynamische Ressourcenzuweisung

Die dynamische Ressourcenanfrage ist eine integrierte Kubernetes-Funktion, mit der Sie Hardware in Ihrem Cluster flexibel anfordern, zuweisen und für Pods und Container freigeben können. DRA verbessert die Zuweisung von angeschlossener Hardware wie Beschleunigern, da Geräteanbieter und Plattformadministratoren Klassen von Geräten angeben können, die angefordert und zugewiesen werden können. App-Betreiber können bestimmte Gerätekonfigurationen innerhalb dieser Klassen anfordern und dann in ihren Arbeitslasten anfordern. Kubernetes und GKE verwalten die Pod-Planung, Knotenzuweisungen und Gerätezuweisungen basierend auf Arbeitslastanfragen.

Ein Plattformadministrator kann beispielsweise eine Geräteklasse definieren, die nur NVIDIA A100-GPUs hat. App-Betreiber 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-Betreiber 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-Betreiber muss keine bestimmten Knoten oder Gerätekonfigurationen im Arbeitslastmanifest auswählen.

Vorteile der dynamischen Ressourcenverwaltung

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

Bei der dynamischen Ressourcenzuweisung ä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. Mit der dynamischen Ressourcenzuweisung können Sie Geräte basierend auf Arbeitslast und Geschäftsanforderungen viel einfacher filtern. Der DRA-Ansatz, bei dem Ausdrücke und Vorlagen verwendet werden, um Hardware zu beanspruchen und Pods zu planen, bietet folgende Vorteile:

  • Deklarative Gerätezuweisung: Plattformadministratoren können Gerätekonfigurationen für bestimmte Arten von Arbeitslasten oder Teams definieren.
  • Reduzierte teamübergreifende Komplexität: Wenn Plattformadministratoren Knoten mit speziellen Hardwarekonfigurationen bereitstellen, müssen App-Betreiber nicht wissen, welche Knoten bestimmte Konfigurationen haben. Plattformadministratoren müssen keine Knoten kennzeichnen oder Betreibern Informationen zu bestimmten Knoten und Geräten mitteilen.
  • Weniger Komplexität für Entwickler: Kubernetes plant Pods basierend auf der referenzierten Gerätekonfiguration. App-Betreiber müssen keine bestimmten Knoten in ihren Arbeitslasten auswählen und müssen nicht dafür sorgen, dass jeder Pod genau die Anzahl der Geräte anfordert, die mit diesen Knoten verbunden sind.
  • Zentrales Infrastrukturmanagement: Plattformadministratoren können Hardwarekonfigurationen zentral definieren, die bestimmten Geschäftsanforderungen entsprechen. Ein Plattformadministrator kann beispielsweise eine Hochleistungskonfiguration mit H100-GPUs und eine kleine Inferenzkonfiguration mit Tesla T4-GPUs deklarieren.
  • Flexible Hardwareauswahl: Mit der dynamischen Ressourcenverwaltung können Sie mit CEL-Ausdrücken nach Geräten mit bestimmten Attributen filtern. Mithilfe von Ausdrücken können Sie flexibel nach Geräten filtern, die für bestimmte Arbeitslasten optimal geeignet sind.

Wann sollte DRA verwendet werden?

Während der Vorabversion ist der Hauptgrund für die Verwendung von DRA in GKE 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 verschiedenen Gerätetypen bereitstellen, ohne das Manifest ändern zu müssen. Diese Flexibilität eignet sich ideal für folgende Anwendungsfälle:

  • Verbesserte Verfügbarkeit von GPUs: Bei Arbeitslasten, die Zugriff auf GPU-Hardware benötigen, können Sie mit der dynamischen Ressourcenanforderung eine beliebige verfügbare GPU im Cluster anfordern, anstatt ein GPU-Modell angeben zu müssen. Wenn diese Arbeitslasten bestimmte Anforderungen an den GPU-Speicher (VRAM) haben, können Sie eine beliebige GPU im Cluster anfordern, die eine bestimmte Mindestmenge an Speicher hat. Diese Art der flexiblen 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.
  • GPU-Knotenverfügbarkeit beim Skalieren optimieren: Die Anzahl der angeschlossenen GPUs, die für eine Arbeitslast erforderlich sind, kann sich je nach GPU-Typ ändern. Sie können eine Compute-Klasse von GKE verwenden, um Knoten basierend auf der GPU-Verfügbarkeit, dem Kontingent oder Kapazitätsreservierungen bereitzustellen. Sie können dann DRA in Ihren Arbeitslasten verwenden, um die Pods so zu konfigurieren, dass sie auf jedem Knoten ausgeführt werden, den GKE für die Compute-Klasse bereitstellt. Wenn Sie die dynamische Ressourcenanpassung mit Compute-Klassen verwenden, können Sie das Risiko unvorhergesehener Arbeitslasten minimieren und gleichzeitig dafür sorgen, dass die Arbeitslasten auf optimierter Hardware ausgeführt werden.

Terminologie

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

ResourceSlice
Ein ResourceSlice enthält ein oder mehrere Hardwaregeräte im Cluster, auf die Knoten zugreifen können. In einem Knoten, der auf eine einzelne GPU zugreifen kann, werden beispielsweise die GPU und der Name des Knotens im ResourceSlice aufgeführt. Die DRA-Gerätetreiber auf jedem Knoten erstellen ResourceSlices. Der Kubernetes-Planer verwendet ResourceSlices, um zu entscheiden, welche Geräte zur Erfüllung von Arbeitslastanfragen zugewiesen werden sollen.
DeviceClass
Mit DeviceClass wird eine Gerätekategorie wie GPUs definiert, die für Arbeitslasten angefordert werden kann. Einige Gerätetreiber bieten integrierte DeviceClasses, z. B. die gpu.nvidia.com DeviceClass für NVIDIA-GPUs. Plattformadministratoren können auch benutzerdefinierte DeviceClasses erstellen, die bestimmte Gerätekonfigurationen definieren.
ResourceClaim

Mit einem ResourceClaim kann ein Pod oder Nutzer Hardwareressourcen 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

Mit einer ResourceClaimTemplate wird eine Vorlage definiert, mit der Pods automatisch neue Pod-spezifische ResourceClaims erstellen können. ResourceClaimTemplates sind nützlich, wenn Sie mehrere Arbeitslasten haben, die Zugriff auf ähnliche Gerätekonfigurationen benötigen, insbesondere wenn Sie einen Workload-Controller wie Deployments oder StatefulSets verwenden.

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

Funktionsweise von DRA

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

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

In diesem Diagramm führen Clusteradministratoren und App-Betreiber folgende Aufgaben aus:

  1. Clusteradministratoren installieren Gerätetreiber, die DRA auf 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 Arbeitsspeicher. Einige Geräte enthalten möglicherweise auch integrierte DeviceClasses.
  3. Anwendungsoperatoren erstellen ResourceClaimTemplates oder ResourceClaims, die Gerätekonfigurationen anfordern. Die primären Anwendungsfälle für die einzelnen Anspruchstypen sind:
    • Mit einem ResourceClaim können mehrere Pods den Zugriff auf dasselbe Gerät teilen.
    • Mit einer ResourceClaimTemplate können mehrere Pods auf separate, ähnliche Geräte zugreifen, indem automatisch pro Pod ResourceClaims generiert werden.
  4. Anwendungsoperatoren fügen ihren Arbeitslastmanifesten die ResourceClaimTemplates oder ResourceClaims hinzu.
  5. Anwendungsoperatoren stellen die Arbeitslast bereit.

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

  1. Wenn die Arbeitslast auf eine ResourceClaimTemplate verweist, erstellt Kubernetes für jede Instanz der Arbeitslast ein neues ResourceClaim-Objekt (z. B. jedes Replikat in einer Bereitstellung).
  2. Der Kubernetes-Planer verwendet die ResourceSlices im Cluster, um dem ResourceClaim jedes Pods verfügbare, infrage kommende 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. Das kubelet auf dem Zielknoten ruft den On-Node-DRA-Treiber auf, um die zugewiesene Hardware an den Pod anzuhängen und so die Ressourcenanfrage zu erfüllen.

Wann werden ResourceClaims und ResourceClaimTemplates verwendet?

Sowohl mit ResourceClaims als auch mit 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 der entsprechenden ResourceClaim API-Ressource auf dem Kubernetes API-Server Geräte zu. Diese Zuweisung erfolgt unabhängig davon, ob Sie den ResourceClaim erstellt haben oder Kubernetes den ResourceClaim aus einer 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. Dies kann beispielsweise passieren, wenn Sie in einem Bereitstellungsmanifest, das mehrere Repliken enthält, 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 zu unbeabsichtigtem Verhalten führen.

Mit einer ResourceClaimTemplate können Sie Vorlagen definieren, mit denen Kubernetes automatisch einzelne ResourceClaims für Pods erstellt. Wenn Sie beispielsweise in einem Deployment mit mehreren Replikaten auf eine ResourceClaimTemplate verweisen, erstellt Kubernetes für jeden replizierten Pod einen separaten ResourceClaim. So erhält jeder Pod ein eigenes 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 eine 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 über eine ResourceClaimTemplate beschrieben:

Manuell erstellte ResourceClaims Automatisch erstellte ResourceClaims
Von mir verwaltet Von Kubernetes verwaltet
Bietet Zugriff auf dieselben Geräte über mehrere Pods Ermöglicht den Zugriff auf Geräte über einen einzelnen Pod
Sie existieren im Cluster unabhängig von Pods. 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 erfordern

Vergleich der dynamischen Ressourcenzuweisung mit der manuellen Gerätezuweisung

Mit der dynamischen Ressourcenzuweisung können angehängte Geräte ähnlich wie PersistentVolumes dynamisch bereitgestellt werden. 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 gibt Informationen zu bestimmten Knoten und ihren angeschlossenen Geräten an die Arbeitslastoperatoren weiter.
  3. Ein Arbeitslastoperator fordert Geräte im Arbeitslastmanifest so an:
    • Wählen Sie mithilfe eines nodeSelector-Felds einen Knoten mit der erforderlichen Gerätekonfiguration aus, z. B. das GPU-Modell oder den TPU-Typ und die TPU-Topologie.
    • Geben Sie die genaue Anzahl der Geräte an, die die Container nutzen sollen, indem Sie das Feld resources in der Pod-Spezifikation verwenden.

Bei dieser manuellen Zuweisungsmethode müssen die Anwendungsoperatoren und Clusteradministratoren miteinander kommunizieren, welche Knoten oder Knotenpools bestimmte Gerätekonfigurationen haben. Sie müssen Arbeitslastanfragen so koordinieren, dass sie den Geräten auf den Knoten entsprechen, da die Bereitstellung sonst fehlschlägt. Im Vergleich dazu können Sie mit der dynamischen Ressourcenzuweisung Ausdrücke verwenden, um flexibel nach Geräten zu filtern, die bestimmte Attribute haben. Außerdem müssen die Arbeitslastbearbeiter nicht die genaue Konfiguration der Knoten im Cluster kennen.

In der folgenden Tabelle werden die dynamische Ressourcenzuweisung mit Geräte-Plug-ins verglichen:

DRA Manuelle Zuweisung
Flexible Geräteauswahl mit CEL-Ausdrücken Bestimmte Knotenauswahl mithilfe von Auswahlen und Ressourcenanfragen
Von Kubernetes getroffene Planungsentscheidungen Planung von Entscheidungen, die der Betreiber mithilfe von Knotenselektoren trifft
Gerätefilterung ist unabhängig von der Arbeitslasterstellung Die Gerätefilterung muss im Arbeitslastmanifest erfolgen.
Zentrale Gerätefilterung und bedarfsorientierte Kurse, die von Plattformadministratoren verwaltet werden Isolierte Gerätefilterung nach Anwendungsoperatoren
App-Betreiber müssen die Knotenkapazität, die Knotenlabelinformationen oder die angeschlossenen Gerätemodelle für jeden Knoten nicht kennen. App-Betreiber müssen wissen, an welchen Knoten bestimmte Modelle und eine bestimmte Anzahl bestimmter Geräte angeschlossen sind.

Unterstützte GKE-Geräte für die direkte Remotezugriffsverwaltung

Mit DRA können Sie GKE-Arbeitslasten GPUs oder TPUs zuweisen. Sie können eines der von GKE unterstützten GPU- und TPU-Modelle zuweisen. Weitere Informationen zu den von GKE unterstützten GPUs und TPUs finden Sie in den folgenden Ressourcen:

Einschränkungen der datenressourcenorientierten Zugriffsverwaltung in GKE

Für die dynamische Ressourcenverwaltung in GKE-Clustern gelten die folgenden Einschränkungen:

  • Sie können DRA nicht mit der automatischen Knotenbereitstellung verwenden.
  • Sie können DRA nicht mit den folgenden GPU-Freigabefunktionen verwenden:
    • GPUs mit Zeitfreigabe
    • GPUs mit mehreren Instanzen
    • Multi-Process Service (MPS)
  • Sie können DRA nicht in Autopilot-Clustern verwenden.
  • Sie müssen mindestens die GKE-Version 1.32.1-gke.1489001 verwenden.

Dieser Abschnitt enthält Empfehlungen für Plattformadministratoren oder App-Betreiber, die mithilfe von DRA Geräte Arbeitslasten zuweisen möchten. Durch DRA ändert sich die Methode, mit der Sie angeschlossene Geräte anfordern, sowohl in GKE als auch in Kubernetes. Wenn Sie erweiterte Anwendungsfälle wie den geräteübergreifenden Fallback oder die detaillierte Gerätefilterung und -auswahl nutzen möchten, beachten Sie die folgenden Hinweise:

  • CEL kennenlernen: Mit der dynamischen Ressourcenzuweisung können Sie mit CEL-Ausdrücken eine detaillierte Gerätefilterung in Ihren Anfragen zur Ressourcenzuweisung und DeviceClasses durchführen. Die folgenden Ressourcen können Ihnen beim Erlernen von CEL helfen:
  • ComputeClasses in GKE: Mit ComputeClasses können Sie prioritätsbasierte Fallback-Knotenkonfigurationen für GKE definieren, die beim Skalieren eines Clusters verwendet werden. Sie können ComputeClasses mit der dynamischen Ressourcenverwaltung verwenden, um Geschäftsanforderungen zu erfüllen, z. B. die Bereitstellung von Spot-VMs zum Ausführen von Inferenzarbeitslasten, für die kosteneffiziente GPUs erforderlich sind. In den folgenden Ressourcen finden Sie weitere Informationen zu ComputeClasses:

Knotteverfügbarkeit während der Skalierung verbessern

Mit Compute-Klassen in GKE können Sie ein prioritätsbasiertes Fallback-Verhalten definieren, das GKE beim Erstellen neuer Knoten in Clustern befolgt. Mit ComputeClasses können Sie eine priorisierte Reihe von Knoten- und Gerätekonfigurationen konfigurieren, die GKE verwendet, wenn es Knoten zum Ausführen von Arbeitslasten erstellt. Mit der dynamischen Ressourcenzuweisung können Sie dann dafür sorgen, dass Ihre Arbeitslast auf jedem Knoten innerhalb der Compute-Klasse ausgeführt werden kann, ohne dass Sie Knoten manuell nach Label auswählen müssen.

Für eine Arbeitslast sind beispielsweise entweder zwei NVIDIA L4-GPUs oder eine NVIDIA A100-GPU (40 GB) erforderlich, um sie optimal auszuführen. Sie können eine ComputeClass erstellen, bei der Knoten mit einer A100-GPU (40 GB) priorisiert werden, aber auch Knoten mit zwei L4-GPUs pro Knoten erstellt werden können. Sie können dann mit der dynamischen Ressourcenanforderung eine beliebige verfügbare GPU für Ihre Arbeitslast anfordern. Wenn Sie die Arbeitslast bereitstellen und diese ComputeClass auswählen, erstellt GKE Knoten mit einer der angegebenen GPU-Konfigurationen. Mit der dynamischen Ressourcenzuweisung kann GKE die Arbeitslast unabhängig vom GPU-Modell, vom Knotenlabel oder von der Anzahl der GPUs auf den ersten verfügbaren Knoten platzieren.

Weitere Informationen finden Sie auf den folgenden Seiten:

Nächste Schritte