**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 auf**, der sich im rechten Bereich jeder Seite befindet. 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. # Einen beschleunigten Workload bereitstellen Dieses Tutorial zeigt, wie Amazon EKS Auto Mode das Starten hardwarebeschleunigter Workloads vereinfacht. Amazon EKS Auto Mode optimiert Abläufe, die über den Cluster selbst hinausgehen, indem wichtige Infrastrukturkomponenten automatisiert werden und sofort einsatzbereite Rechen-, Netzwerk-, Lastausgleichs-, Speicher- sowie Identity and Access Management Zugriffsmanagementfunktionen bereitgestellt werden. Amazon EKS Auto Mode umfasst die Treiber und Geräte-Plug-ins, die für bestimmte Instance-Typen wie NVIDIA- und AWS Neuron-Treiber erforderlich sind. Sie müssen diese Komponenten nicht installieren oder aktualisieren. EKS Auto Mode verwaltet automatisch die Treiber für folgende Beschleuniger: + [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/) + [AWS Inferenz](https://aws.amazon.com/ai/machine-learning/inferentia/) + [NVIDIA-GPUs in beschleunigten Amazon-EC2-Instances](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html) **Anmerkung** EKS Auto Mode beinhaltet das NVIDIA-Geräte-Plugin für Kubernetes. Dieses Plugin wird automatisch ausgeführt und ist in Ihrem Cluster nicht als Daemon-Set sichtbar. Zusätzliche Netzwerkunterstützung: + [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/) — Informationen zur Verwaltung von EFA-Geräten in Ihrem EKS-Cluster finden Sie unter. [EFA-Geräte auf Amazon EKS verwalten](device-management-efa.md) Amazon EKS Auto Mode macht die aufwändige Verwaltung von Beschleunigertreibern und Geräte-Plugins überflüssig. Sie können außerdem von Kosteneinsparungen profitieren, indem Sie den Cluster auf Null skalieren. Sie können EKS Auto Mode so konfigurieren, dass Instances beendet werden, wenn keine Workloads ausgeführt werden. Dies ist nützlich für Batch-basierte Inferenz-Workloads. Nachfolgend finden Sie ein Beispiel für das Starten beschleunigter Workloads mit Amazon EKS Auto Mode. ## Voraussetzungen + Ein Kubernetes-Cluster mit konfiguriertem Amazon EKS Auto Mode. + Eine `default`-EKS-Knotenklasse wird erstellt, wenn die verwalteten Knoten-Pools `general-purpose` oder `system` aktiviert sind. ## Schritt 1: GPU-Workload bereitstellen In diesem Beispiel erstellen Sie eine NodePool für NVIDIA-basierte Workloads, die 45 GB GPU-Speicher benötigen. Mit EKS Auto Mode definieren Sie Ihre Instance-Anforderungen mithilfe von Kubernetes-Planungsbeschränkungen. Um den Amazon EKS Auto Mode `NodePool` und das Beispiel bereitzustellen`workload`, überprüfen Sie Folgendes NodePool und die Pod-Definition und speichern Sie unter `nodepool-gpu.yaml` und`pod.yaml`: **nodepool-gpu.yaml** ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu spec: disruption: budgets: - nodes: 10% consolidateAfter: 1h consolidationPolicy: WhenEmpty template: metadata: {} spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "kubernetes.io/arch" operator: In values: ["amd64"] - key: "eks.amazonaws.com/instance-family" operator: In values: - g6e - g6 taints: - key: nvidia.com/gpu effect: NoSchedule terminationGracePeriod: 24h0m0s ``` **pod.yaml** ``` apiVersion: v1 kind: Pod metadata: name: nvidia-smi spec: nodeSelector: eks.amazonaws.com/compute-type: auto restartPolicy: OnFailure containers: - name: nvidia-smi image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal args: - "nvidia-smi" resources: requests: memory: "30Gi" cpu: "3500m" nvidia.com/gpu: 1 limits: memory: "30Gi" nvidia.com/gpu: 1 tolerations: - key: nvidia.com/gpu effect: NoSchedule operator: Exists ``` Beachten Sie, dass für den `eks.amazonaws.com/compute-type: auto`-Selektor die Bereitstellung des Workloads in einem Knoten von Amazon EKS Auto Mode erforderlich ist. Das ist NodePool auch ein Makel, dass nur Pods mit Toleranzen für Nvidia-GPUs geplant werden können. Wenden Sie die Arbeitslast NodePool und den Workload auf Ihren Cluster an. ``` kubectl apply -f nodepool-gpu.yaml kubectl apply -f pod.yaml ``` Die Ausgabe sollte folgendermaßen aussehen: ``` nodepool.karpenter.sh/gpu configured created pod/nvidia-smi created ``` Warten Sie einige Sekunden und überprüfen Sie die Knoten in Ihrem Cluster. Sie sollten nun einen neuen Knoten in Ihrem Cluster von Amazon EKS Auto Mode sehen: ``` > kubectl get nodes NAME TYPE CAPACITY ZONE NODE READY AGE gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s ``` ## Schritt 2: Validieren Sie können sehen, dass Amazon EKS Auto Mode `g6e.2xlarge` statt a gestartet hat, `g6.2xlarge` da für die Arbeitslast eine Instance mit l40s erforderlich war`GPU`, und zwar gemäß den folgenden Kubernetes-Scheduling-Einschränkungen: ``` ... nodeSelector: eks.amazonaws.com/instance-gpu-name: l40s ... requests: memory: "30Gi" cpu: "3500m" nvidia.com/gpu: 1 limits: memory: "30Gi" nvidia.com/gpu: 1 ``` Sehen Sie sich nun die Protokolle des Containers an, indem Sie den folgenden Befehl ausführen: ``` kubectl logs nvidia-smi ``` Beispielausgabe: ``` +---------------------------------------------------------------------------------------+ | NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 | |-----------------------------------------+----------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+======================+======================| | 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 | | N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default | | | | N/A | +-----------------------------------------+----------------------+----------------------+ +---------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=======================================================================================| | No running processes found | +---------------------------------------------------------------------------------------+ ``` Sehen Sie sich nun die Container-Protokolle an, indem Sie den folgenden Befehl ausführen: Sie können sehen, dass der Container erkannt hat, dass er in einer Instance mit einer `NVIDIA` GPU ausgeführt wird, und dass Sie keine Gerätetreiber installieren mussten, da dies von Amazon EKS Auto Mode verwaltet wird. ## Schritt 3: Clean-up Um alle erstellten Objekte zu entfernen, verwenden Sie, `kubectl` um die Beispielbereitstellung zu löschen, NodePool sodass der Knoten beendet wird: ``` kubectl delete -f nodepool-gpu.yaml kubectl delete -f pod.yaml ``` ## NodePools Beispielreferenz ### Erstellen Sie eine NVIDIA NodePool Im Folgenden wird Folgendes NodePool definiert: + Nur Instances der `g6e`- und `g6`-Familie starten + Knoten konsolidieren, wenn sie 1 Stunde lang leer sind + Der Wert von 1 Stunde für `consolidateAfter` unterstützt hohe Arbeitslasten und reduziert die Abwanderung von Knoten. Sie können `consolidateAfter` basierend auf Ihren Workload-Anforderungen optimieren. **Beispiel NodePool mit GPU-Instanzfamilie und Konsolidierung** ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu spec: disruption: budgets: - nodes: 10% consolidateAfter: 1h consolidationPolicy: WhenEmpty template: metadata: {} spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "kubernetes.io/arch" operator: In values: ["amd64"] - key: "eks.amazonaws.com/instance-family" operator: In values: - g6e - g6 terminationGracePeriod: 24h0m0s ``` Anstatt das festzulegen, können `eks.amazonaws.com/instance-gpu-name` Sie `eks.amazonaws.com/instance-family` die Instanzfamilie angeben. Weitere bekannte Labels, welche die Überprüfung der Zeitplanung beeinflussen, finden Sie unter [Unterstützte Labels für EKS Auto Mode](create-node-pool.md#auto-supported-labels). Wenn Sie spezielle Speicheranforderungen haben, können Sie den kurzlebigen Speicher der Knoten anpassen `size` und `throughput` Ihren eigenen erstellen`iops`, auf den Sie in der [NodeClass](create-node-class.md)verweisen können. NodePool Erfahren Sie mehr über die [konfigurierbaren NodeClass ](create-node-class.md) Optionen. **Beispiel für eine Speicherkonfiguration für NodeClass** ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: gpu spec: ephemeralStorage: iops: 3000 size: 80Gi throughput: 125 ``` ### Definieren Sie ein AWS Trainium und AWS Inferenz NodePool Im Folgenden NodePool steht, dass nur Instances der Inferentia- und Trainium-Familie gestartet werden `eks.amazonaws.com/instance-category` sollen: ``` - key: "eks.amazonaws.com/instance-category" operator: In values: - inf - trn ```