Unterstützung für die Verbesserung dieser Seite beitragen

Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.

Einen beschleunigten Workload bereitstellen

Dieses Tutorial veranschaulicht, wie Amazon EKS Auto Mode die Ausführung beschleunigter Workloads vereinfacht. Amazon EKS Auto Mode optimiert den Betrieb über den Cluster hinaus. Dabei werden wichtige Infrastrukturkomponenten automatisiert und Funktionen für Rechenleistung, Netzwerke, Load Balancing, Speicher sowie Identitätszugriff und -verwaltung sofort bereitgestellt.

Amazon EKS Auto Mode umfasst die für bestimmte Instance-Typen erforderlichen Treiber und Geräte-Plugins, wie beispielsweise NVIDIA- und AWS-Neuron-Treiber. 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 einen NodePool für NVIDIA-basierte Workloads, der 45 GB GPU-Speicher erfordert. Mit EKS Auto Mode definieren Sie Ihre Instance-Anforderungen mithilfe von Kubernetes-Planungsbeschränkungen.

Um den NodePool von Amazon EKS Auto Mode und das Beispiel workload bereitzustellen, überprüfen Sie die folgenden NodePool- und Pod-Definitionen und speichern Sie diese als nodepool-gpu.yaml und pod.yaml ab:

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. Der NodePool setzt außerdem einen Taint, der nur die Planung von Pods mit Toleranzen für Nvidia-GPUs zulässt.

Wenden Sie den NodePool und die 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 ein g6e.2xlarge statt eines g6.2xlarge gestartet hat, da die Workload gemäß den folgenden Kubernetes-Planungsbeschränkungen eine Instance mit l40s GPU erforderte:

...
  nodeSelector:
    eks.amazonaws.com/instance-gpu-name: l40s
...
    requests:
        memory: "30Gi"
        cpu: "3500m"
        nvidia.com/gpu: 1
      limits:
        memory: "30Gi"
        nvidia.com/gpu: 1

Überprüfen Sie nun die Container-Protokolle, 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: Bereinigen

Um alle erstellten Objekte zu entfernen, löschen Sie mit kubectl die Beispielbereitstellung und den NodePool, sodass der Knoten beendet wird:

kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml

Beispiel für eine NodePools-Referenz

NVIDIA-Knoten-Pool erstellen

Der folgende NodePool definiert:

Beispiel für einen NodePool mit GPU-Instance-Familie 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 eks.amazonaws.com/instance-gpu-name festzulegen, können Sie eks.amazonaws.com/instance-family verwenden, um die Instance-Familie anzugeben. 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 flüchtigen Speicher iops, size und throughput der Knoten optimieren, indem Sie Ihre eigene NodeClass erstellen, auf die im NodePool verwiesen wird. Weitere Informationen zu den 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

Einen AWS-Trainium- und AWS-Inferentia-NodePool definieren

Der folgende NodePool verfügt über einen eks.amazonaws.com/instance-category-Satz, der angibt, dass nur Instances der Inferentia- und Trainium-Familie gestartet werden sollen:

        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values:
            - inf
            - trn