Dynamische Ressourcenzuweisung in GKE

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

Diese Seite richtet sich an die folgenden Rollen:

  • Plattformadministratoren, die die Komplexität und den Aufwand für die Einrichtung von Infrastruktur mit speziellen Hardwaregeräten reduzieren möchten.
  • App-Betreiber und Data Engineers, 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 DRA

DRA ist eine integrierte Kubernetes-Funktion, mit der Sie Hardware in Ihrem Cluster flexibel für Pods und Container anfordern, zuweisen und freigeben können. DRA verbessert die Zuweisung von angeschlossener Hardware wie Beschleunigern, indem Geräteanbieter und Plattformadministratoren Geräteklassen 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ätezuweisung basierend auf Arbeitslastanforderungen.

Ein Plattformadministrator kann beispielsweise eine Geräteklasse definieren, die nur NVIDIA A100-GPUs enthält. App-Betreiber können die Geräte in dieser Geräteklasse dann nach 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 sucht GKE nach Knoten mit verfügbaren A100-GPUs (80 GB). Der App-Betreiber 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 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 die Speicherung. Sie definieren Geräteklassen, fordern Geräte innerhalb dieser Klassen an und weisen diese angeforderten Geräte dann Arbeitslasten zu. DRA bietet eine wesentlich erweiterbare Oberfläche zum Filtern von Geräten basierend auf Arbeitslast und geschäftlichen Anforderungen. 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.
  • Geringere teamübergreifende Komplexität: Wenn Plattformadministratoren Knoten mit speziellen Hardwarekonfigurationen bereitstellen, müssen App-Operatoren nicht wissen, welche Knoten bestimmte Konfigurationen haben. Plattformadministratoren müssen keine Knoten kennzeichnen oder Informationen zu bestimmten Knoten und Geräten an Bediener weitergeben.
  • Weniger Komplexität für Entwickler: Kubernetes plant Pods basierend auf der referenzierten Gerätekonfiguration. App-Betreiber müssen in ihren Arbeitslasten keine bestimmten Knoten auswählen und nicht dafür sorgen, dass jeder Pod genau die Anzahl der Geräte anfordert, die an diese Knoten angehängt sind.
  • Zentrales Infrastrukturmanagement: Plattformadministratoren können Hardwarekonfigurationen zentral definieren, die bestimmten Geschäftsanforderungen entsprechen. Ein Plattformadministrator könnte beispielsweise eine leistungsstarke Konfiguration mit H100-GPUs und eine kleine Inferenzkonfiguration mit Tesla T4-GPUs deklarieren.
  • Flexible Hardwareauswahl: Mit DRA können Sie CEL-Ausdrücke verwenden, um Geräte 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?

Während der Vorschau besteht der Hauptgrund für die Verwendung von DRA in GKE in der 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 diese Arbeitslasten bestimmte Anforderungen an den GPU-Speicher (VRAM) haben, können Sie eine beliebige GPU im Cluster anfordern, die über eine Mindestspeichermenge verfügt. Diese Art von flexibler Anfrage erweitert die Menge 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 angehängten GPUs, die für eine Arbeitslast erforderlich sind, kann sich je nach GPU-Typ ändern. Sie können eine GKE-Compute-Klasse verwenden, um Knoten basierend auf GPU-Verfügbarkeit, Kontingent oder Kapazitätsreservierungen bereitzustellen. Sie können dann DRA in Ihren Arbeitslasten verwenden, um die Pods so zu konfigurieren, dass sie auf einem beliebigen Knoten ausgeführt werden, den GKE für die Compute-Klasse bereitstellt. Wenn Sie DRA mit Compute-Klassen verwenden, können Sie das Risiko ungeplanter 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
In einem ResourceSlice werden ein oder mehrere Hardwaregeräte im Cluster aufgeführt, auf die Knoten zugreifen können. In einem Knoten, der auf eine einzelne GPU zugreifen kann, werden in „ResourceSlice“ beispielsweise die GPU und der Name des Knotens 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
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 gpu.nvidia.comDeviceClass für NVIDIA-GPUs. Plattformadministratoren können auch benutzerdefinierte DeviceClasses erstellen, in denen bestimmte Gerätekonfigurationen definiert werden.
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

Eine ResourceClaimTemplate definiert eine Vorlage, die Pods verwenden können, um automatisch neue ResourceClaims pro Pod zu erstellen. 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-Operatoren stellen ResourceClaimTemplates bereit und verweisen dann in Arbeitslasten auf die Vorlagen. Kubernetes erstellt für jeden Pod ResourceClaims basierend auf der angegebenen Vorlage, 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 StorageClasses, PersistentVolumeClaims und PersistentVolumes zum dynamischen Bereitstellen von Volumes für Pods.

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 die folgenden Schritte aus:

  1. Clusteradministratoren installieren Gerätetreiber, die DRA unterstützen, auf den Knoten.
  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, mit denen Gerätekonfigurationen angefordert werden. Der primäre Anwendungsfall für jede Art von Anspruch ist wie folgt:
    • Mit einem ResourceClaim können mehrere Pods 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 ihren Arbeitslastmanifesten die ResourceClaimTemplates oder ResourceClaims hinzu.
  5. Anwendungsoperatoren stellen die Arbeitslast bereit.

Wenn Sie eine Arbeitslast bereitstellen, die auf ein ResourceClaimTemplate oder ein 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 (z. B. jedes Replikat in einer Bereitstellung) ein neues ResourceClaim-Objekt.
  2. Der Kubernetes-Planer verwendet die ResourceSlices im Cluster, um jedem ResourceClaim des Pods verfügbare, geeignete Geräte zuzuweisen.
  3. Der Scheduler 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 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?

Sowohl mit ResourceClaims als auch mit ResourceClaimTemplates können Sie Kubernetes mitteilen, dass Sie Geräte mit bestimmten Anforderungen benötigen. Wenn in einem Pod auf eine 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 oder Kubernetes den ResourceClaim aus einem ResourceClaimTemplate erstellt haben.

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 erfolgen, 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.

Mit einem ResourceClaimTemplate können Sie Vorlagen definieren, die Kubernetes verwendet, um automatisch einzelne ResourceClaims für Pods zu erstellen. 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 Geräte separat 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:

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 über einen einzelnen Pod
Ist unabhängig von Pods im Cluster vorhanden 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 mit manueller Gerätezuweisung

Mit DRA ist die Zuweisung angehängter Geräte ähnlich wie die dynamische 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 angeschlossenen Geräten mit.
  3. Ein Arbeitslastoperator fordert Geräte im Arbeitslastmanifest so an:
    • Wählen Sie einen Knoten mit der erforderlichen Gerätekonfiguration aus, z. B. das GPU-Modell oder den TPU-Typ und die TPU-Topologie, indem Sie ein nodeSelector-Feld verwenden.
    • Geben Sie die genaue Anzahl der Geräte an, die von den Containern verwendet werden sollen, indem Sie das Feld resources in der Pod-Spezifikation verwenden.

Bei dieser manuellen Zuweisungsmethode müssen sich die Anwendungsbetreiber und Clusteradministratoren darüber austauschen, welche bestimmten Knoten oder Knotenpools bestimmte Gerätekonfigurationen haben. Sie müssen Arbeitslastanfragen so koordinieren, dass sie mit den Geräten auf den Knoten übereinstimmen, da die Bereitstellung sonst fehlschlägt. Im Vergleich dazu können Sie mit DRA Ausdrücke verwenden, um Geräte flexibel nach Attributen zu filtern. Außerdem müssen Arbeitslastoperatoren die genaue Konfiguration von Knoten im Cluster nicht kennen.

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

DRA Manuelle Zuweisung
Flexible Geräteauswahl mit CEL-Ausdrücken Spezifische Knotenauswahl mit Selektoren und Ressourcenanfragen
Von Kubernetes getroffene Planungsentscheidungen Planungsentscheidungen des Operators mit Knotenselektoren treffen
Gerätefilterung ist unabhängig von der Arbeitslastgenerierung Die Gerätefilterung muss im Arbeitslastmanifest erfolgen.
Zentrale Gerätefilterung und bedarfsgerechte Klassen, die von Plattformadministratoren verwaltet werden Gerätefilterung nach Anwendungsoperatoren
App-Betreiber müssen die Knotenkapazität, Knotenlabelinformationen oder die angehängten Gerätemodelle für jeden Knoten nicht kennen. App-Betreiber müssen wissen, an welchen Knoten bestimmte Modelle und Mengen bestimmter Geräte angebracht sind.

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

Mit DRA können Sie GPUs oder TPUs für GKE-Arbeitslasten zuweisen. Sie können alle GPU- und TPU-Modelle zuweisen, die von GKE unterstützt werden. Weitere Informationen zu den von GKE unterstützten GPUs und TPUs finden Sie in den folgenden Ressourcen:

Einschränkungen von DRA in GKE

Für DRA gelten in GKE-Clustern 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 DRA verwenden möchten, um Geräte Arbeitslasten zuzuweisen. 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, sollten Sie die folgenden Hinweise beachten:

Knotenverfügbarkeit während der Skalierung verbessern

Mit ComputeClasses 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 beim Erstellen von Knoten zum Ausführen von Arbeitslasten verwendet. Anschließend können Sie DRA verwenden, um sicherzustellen, dass Ihre Arbeitslast auf jedem Knoten innerhalb der ComputeClass ausgeführt werden kann, ohne dass Sie Knoten manuell nach Label auswählen müssen.

Für eine optimale Ausführung einer Arbeitslast sind beispielsweise entweder zwei NVIDIA L4-GPUs oder eine NVIDIA A100-GPU (40 GB) erforderlich. Sie können eine ComputeClass erstellen, die die Erstellung von Knoten mit einer A100-GPU (40 GB) priorisiert, aber auf die Erstellung von Knoten mit zwei L4-GPUs pro Knoten zurückgreifen kann. Sie können dann mit DRA eine beliebige verfügbare GPU für Ihre Arbeitslast anfordern. Wenn Sie die Arbeitslast bereitstellen und diese Compute-Klasse auswählen, erstellt GKE Knoten mit einer der angegebenen GPU-Konfigurationen. Mit DRA kann GKE die Arbeitslast auf dem ersten verfügbaren Knoten platzieren, unabhängig von GPU-Modell, Knotenlabel oder GPU-Anzahl.

Weitere Informationen finden Sie auf den folgenden Seiten:

Nächste Schritte