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:

Zusätzliche Netzwerkunterstützung:

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

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 bereitzustellenworkload, überprüfen Sie Folgendes NodePool und die Pod-Definition und speichern Sie unter nodepool-gpu.yaml undpod.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 warGPU, 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:

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.

Wenn Sie spezielle Speicheranforderungen haben, können Sie den kurzlebigen Speicher der Knoten anpassen size und throughput Ihren eigenen erstelleniops, auf den Sie in der NodeClassverweisen können. NodePool Erfahren Sie mehr über die konfigurierbaren NodeClass 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