Dynamische Ressourcenzuweisung im Vergleich zu Geräte-Plugins DRA-Treiber für Amazon EKS Geräte-Plug-ins für Amazon EKS Überlegungen DRA vs. ResourceClaim ResourceClaimTemplate Topics

Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten unter, der sich im rechten Bereich jeder Seite befindet.

Hardwaregeräte auf Amazon EKS verwalten

Amazon EKS unterstützt zwei Kubernetes-Mechanismen für die Verwaltung spezialisierter Hardwaregeräte in EKS-Clustern: Dynamic Resource Allocation (DRA) und Geräte-Plug-ins. Beide Mechanismen ermöglichen Workloads den Zugriff auf Hardwarebeschleuniger wie NVIDIA-GPUs und AWS Trainium-Chips sowie auf leistungsstarke Netzwerkgeräte wie Elastic Fabric Adapter (EFA).

Wir empfehlen die Verwendung von DRA-Treibern für neue Bereitstellungen mit Kubernetes-Versionen 1.34 und höher, wenn Sie die statische Kapazitätsbereitstellung in Karpenter, EKS-verwalteten Knotengruppen oder selbstverwalteten Knoten verwenden. DRA wird derzeit im EKS-Automatikmodus nicht unterstützt. DRA bietet eine umfassendere Geräteauswahl, topologieorientierte Planung und Funktionen zur gemeinsamen Nutzung von Geräten, die mit Geräte-Plug-ins nicht möglich sind.

Allgemeine Informationen zu diesen beiden Kubernetes-Funktionen finden Sie in der Kubernetes-Dokumentation für dynamische Ressourcenzuweisung und Geräte-Plugins.

Dynamische Ressourcenzuweisung im Vergleich zu Geräte-Plugins

Kubernetes-Geräte-Plugins waren der wichtigste Mechanismus, um spezielle Hardware Kubernetes-Workloads auszusetzen. Geräte-Plugins bewerben Geräte als erweiterte Ressourcen (z. B. nvidia.com/gpu oderaws.amazon.com/neuroncore), die Sie in Container-Ressourcenanforderungen und -limits anfordern. Geräte-Plugins werden zwar häufig unterstützt und verwendet, haben jedoch Einschränkungen:

Geräte werden als undurchsichtige Ganzzahlen ohne attributbasierte Filterung angefordert.
Keine Unterstützung für die gemeinsame Nutzung von Geräten zwischen Containern oder Pods.
Keine aussagekräftige topologieorientierte Zuordnung zwischen Gerätetypen.
Für eine intelligente Platzierung sind häufig benutzerdefinierte Scheduler-Erweiterungen erforderlich.

Dynamic Resource Allocation (DRA) ist eine Kubernetes-Funktion, die in Kubernetes Version 1.34 allgemein verfügbar ist und diese Einschränkungen behebt. Mit DRA veröffentlichen Gerätetreiber mithilfe von Objekten umfangreiche Geräteattribute für den Kubernetes-Scheduler. ResourceSlice Sie fordern Geräte mithilfe von ResourceClaim ResourceClaimTemplate Objekten an, die auf Kategorien verweisen. DeviceClass

DRA ermöglicht:

Attribute-based Geräteauswahl mithilfe von CEL-Ausdrücken (Common Expression Language).
Topology-aware Zuweisung, die sicherstellt, dass sich Geräte auf demselben PCIe-Switch oder derselben NUMA-Domäne befinden.
Gemeinsame Nutzung von Geräten zwischen mehreren Containern oder Pods durch gemeinsame Referenzen. ResourceClaim
Dynamische Partitionierung und gemeinsame Nutzung von NVIDIA-GPUs bei Verwendung von MIG oder Time-Slicing

DRA-Treiber für Amazon EKS

Die folgenden DRA-Treiber werden häufig für die Verwaltung spezialisierter Hardwaregeräte in Amazon EKS-Clustern verwendet.

NVIDIA DRA-Treiber: Der NVIDIA DRA-Treiber für GPUs GitHub aktiviert die flexible Zuweisung und dynamische Konfiguration von NVIDIA-GPUs. Informationen Verwenden Sie den NVIDIA DRA-Treiber oder das Geräte-Plugin auf Amazon EKS zur Verwaltung von GPUs mit dem NVIDIA DRA-Treiber und Informationen P6e-GB200 UltraServers Mit Amazon EKS verwenden zur Verwendung ComputeDomains für Multi-Node NVLink (MNNVL) -Workloads mit EC2-Instances finden Sie unter. Grace-Blackwell
EFA-DRA-Treiber: Der EFA-DRA-Treiber (DRANET aktiviert GitHub) verwaltet die Gerätezuweisung des Elastic Fabric Adapters (EFA) mit topologieorientierter Planung, die EFA-Schnittstellen mit ihren topologisch lokalen GPUs oder Neuron-Geräten verbindet und die gemeinsame Nutzung von Geräten zwischen Pods unterstützt. Weitere Informationen finden Sie unter EFA-Geräte auf Amazon EKS verwalten.
Neuron-DRA-Treiber: Der Neuron DRA-Treiber verwaltet die AWS Trainium- und AWS Inferentia2-Gerätezuweisung mit topologieorientierter Planung, Zuweisung von Teilmengen verbundener Geräte und logischer NeuronCore (LNC) -Konfiguration, ohne dass benutzerdefinierte Scheduler-Erweiterungen erforderlich sind. Weitere Informationen finden Sie unter Neuron-Geräte auf Amazon EKS verwalten.

Geräte-Plug-ins für Amazon EKS

Die folgenden Geräte-Plugins werden häufig für die Verwaltung spezialisierter Hardwaregeräte in Amazon EKS-Clustern verwendet.

NVIDIA-Geräte-Plugin: Das NVIDIA-Geräte-Plug-In GitHub bewirbt NVIDIA-GPUs als nvidia.com/gpu erweiterte Ressourcen und überwacht den Zustand der GPUs.
EFA-Geräte-Plugin: Das EFA-Geräte-Plugin erkennt alle verfügbaren EFA-Geräte auf jedem Knoten und kündigt EFA-Geräte als erweiterte Ressourcen an. vpc.amazonaws.com/efa
Neuron-Geräte-Plugin: Das Neuron-Geräte-Plugin stellt Neuron-Hardware als aws.amazon.com/neuroncore erweiterte Ressourcen zur Verfügung. aws.amazon.com/neuron Es erkennt verfügbare Neuron-Geräte auf jedem Knoten, bewirbt sie als zuweisbare Ressourcen und verwaltet ihren Lebenszyklus.

Überlegungen

Bevor Sie DRA-Treiber auf Amazon EKS verwenden, sollten Sie die folgenden Überlegungen beachten:

DRA ist auf Amazon EKS mit Kubernetes-Version 1.33 und höher verfügbar. Aufgrund eines Upstream-Kubernetes-Problems wird es jedoch für Kubernetes-Versionen 1.34 und höher empfohlen. https://github.com/kubernetes/kubernetes/issues/133920 GitHub Auf Ihrer Cluster-Steuerungsebene und Ihren Knoten muss eine Kubernetes-Version ausgeführt werden, die DRA unterstützt.
DRA ist derzeit nicht mit dem EKS-Automatikmodus kompatibel.
DRA ist derzeit nicht mit Karpenter kompatibel, wenn dynamisch bereitgestellte Kapazität verwendet wird. Sie müssen die statische Kapazitätsbereitstellung in Karpenter oder von EKS verwaltete Knotengruppen oder selbstverwaltete Knoten mit DRA-Treibern verwenden.
DRA-Treiber und Geräte-Plug-ins für denselben Gerätetyp dürfen nicht gleichzeitig auf demselben Knoten ausgeführt werden. Deinstallieren Sie das Geräte-Plug-In, bevor Sie den entsprechenden DRA-Treiber installieren, oder stellen Sie sie auf separaten Knoten bereit. Wenn sowohl der DRA-Treiber als auch das Geräte-Plug-In für dasselbe Gerät auf demselben Knoten ausgeführt werden, kann dies zu einer unbemerkten Überbelegung der zugrunde liegenden Hardwaregeräte führen.
DRA verwendet andere Kubernetes-API-Ressourcen (ResourceClaim,ResourceClaimTemplate,DeviceClass) als Geräte-Plugins (resource.limits,). resource.requests Sie können DRA verwenden, um die erweiterten Ressourcen des Geräte-Plug-ins zu verwalten, ohne Ihre Workload-Spezifikationen zu ändern. Weitere Informationen zu erweiterten Ressourcen in DRA finden Sie in der Kubernetes-Dokumentation auf der Kubernetes-Website.
Die DRA-Treiber für NVIDIA, EFA und Neuron sind sowohl mit den EKS-optimized AL2023-AMIs als auch mit den Bottlerocket-AMIs kompatibel. Wenn Sie den NVIDIA DRA-Treiber mit Bottlerocket verwenden, deaktivieren Sie das NVIDIA-Geräte-Plug-In, das in den Bottlerocket-NVIDIA-Varianten enthalten ist.
Geräte-Plugins werden weiterhin für alle Kubernetes-Versionen vollständig unterstützt.

DRA vs. ResourceClaim ResourceClaimTemplate

Wenn Sie DRA verwenden, fordern Sie Geräte über ResourceClaim unsere ResourceClaimTemplate Objekte an. Diese beiden Ressourcentypen dienen unterschiedlichen Zwecken und haben ein unterschiedliches Lebenszyklusverhalten.

ResourceClaim

A ResourceClaim ist ein benanntes Kubernetes-Objekt, das Sie unabhängig von einem Pod erstellen. Sie referenzieren es in einer Pod-Spezifikation anhand des Namens mithilfe des resourceClaimName Felds. A ResourceClaim hat die folgenden Eigenschaften:

Es muss im Cluster existieren, bevor ein Pod, das darauf verweist, erstellt wird. Wenn der Anspruch nicht besteht, verbleibt der Pod im Status „Ausstehend“.
Er bleibt bestehen, bis Sie ihn explizit löschen, unabhängig davon, ob Pods darauf verweisen.
Mehrere Pods können auf dasselbe verweisenResourceClaim, wodurch die gemeinsame Nutzung von Geräten ermöglicht wird. Alle Pods, die auf denselben Anspruch verweisen, teilen sich den Zugriff auf dieselben zugewiesenen Geräte und sind für denselben Knoten geplant.

Verwenden Sie aResourceClaim, wenn Sie mehrere Pods benötigen, um gemeinsam auf dieselben Geräte zuzugreifen, oder wenn ein Anspruch über die Lebensdauer eines einzelnen Pods hinaus bestehen soll.

ResourceClaimTemplate

A ResourceClaimTemplate definiert eine Vorlage, die Kubernetes verwendet, um automatisch eine Vorlage ResourceClaim für jeden Pod zu generieren. Sie verweisen in einer Pod-Spezifikation mithilfe des resourceClaimTemplateName Felds darauf. Die Vorlage ResourceClaimTemplate selbst ist nicht an einen Pod gebunden — sie ist eine wiederverwendbare Vorlage, die unabhängig voneinander bestehen bleibt. A ResourceClaimTemplate hat die folgenden Eigenschaften:

Kubernetes erstellt ResourceClaim für jeden Pod, der auf die Vorlage verweist, einen neuen. Jeder Pod erhält seinen eigenen Satz von Geräten.
Jeder generierte Pod ResourceClaim ist an den Lebenszyklus des Pods gebunden, der seine Erstellung ausgelöst hat. Wenn der Pod gelöscht wird, ResourceClaim wird auch der zugehörige generierte Pod gelöscht. Der ResourceClaimTemplate Pod selbst ist davon nicht betroffen und generiert weiterhin neue Ansprüche für zukünftige Pods.

Verwenden Sie aResourceClaimTemplate, wenn jeder Pod in einem Workload seine eigenen dedizierten Geräte mit ähnlichen Konfigurationen benötigt. Verwenden Sie beispielsweise a ResourceClaimTemplate für Pods in einem Job, der eine parallele Ausführung verwendet, bei der jeder Pod seine eigenen GPU- oder EFA-Geräte benötigt.

Die folgende Tabelle fasst die Unterschiede zwischen und ResourceClaim zusammen. ResourceClaimTemplate

Behavior	ResourceClaim	ResourceClaimTemplate
Erstellung	Sie erstellen es manuell, bevor Pods darauf verweisen	Kubernetes generiert automatisch einen Anspruch pro Pod
Lebenszyklus	Bleibt bestehen, bis du ihn löschst	Die Vorlage bleibt bestehen, bis Sie sie löschen. Jeder generierte Pod `ResourceClaim` ist an den Pod gebunden, der seine Erstellung ausgelöst hat.
Gemeinsame Nutzung von Geräten über mehrere Pods hinweg	Unterstützt. Mehrere Pods können auf dieselbe Behauptung verweisen.	Nicht unterstützt Für jeden Pod wird ein eigener Anspruch geltend gemacht.
Feld für die Pod-Spezifikation	`resourceClaimName`	`resourceClaimTemplateName`

Beispiele für die Verwendung von ResourceClaim Objekten zur gemeinsamen Nutzung von EFA-Geräten zwischen Pods finden Sie unterTeilen Sie EFA-Geräte mit mehreren Pods. Beispiele für die Verwendung von ResourceClaimTemplate Objekten mit topologieorientierter Zuordnung finden Sie unter. Topology-aware EFA und Gerätezuweisung GPU/Neuron

Topics

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

P6e-GB200 Mit EKS verwenden

EFA-Geräte