**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. # Ausführung von Beispiel-Workloads in Clustern in EKS Auto Mode Dieses Kapitel enthält Beispiele dafür, wie verschiedene Arten von Workloads in Amazon-EKS-Clustern bereitgestellt werden können, die im Automatikmodus ausgeführt werden. Die Beispiele veranschaulichen wichtige Workload-Muster, darunter Beispielanwendungen, Web-Anwendungen mit Lastenausgleich, zustandsbehaftete Workloads mit persistenter Speicherung und Workloads mit spezifischen Anforderungen an die Knoten-Platzierung. Jedes Beispiel enthält vollständige Manifeste und step-by-step Bereitstellungsanweisungen, die Sie als Vorlagen für Ihre eigenen Anwendungen verwenden können. Bevor Sie mit den Beispielen fortfahren, stellen Sie sicher, dass ein EKS-Cluster im Auto-Modus läuft und dass Sie AWS CLI und kubectl installiert haben. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md). Die Beispiele setzen grundlegende Kenntnisse der Kubernetes-Konzepte und kubectl-Befehle voraus. Sie können diese auf Anwendungsfällen basierenden Beispiele verwenden, um Workloads in Clustern in EKS Auto Mode auszuführen. [Bereitstellung einer erhöhten Beispiel-Workload in einem Cluster in Amazon EKS Auto Mode](automode-workload.md) Zeigt, wie Sie mithilfe von `kubectl`-Befehlen einen Beispiel-Workload in einem Cluster in EKS Auto Mode bereitstellen. [Bereitstellung einer Beispiel-Workload für Load Balancer in EKS Auto Mode](auto-elb-example.md) Zeigt, wie Sie eine containerisierte Version des Spiels 2048 in Amazon EKS bereitstellen. [Bereitstellung einer Beispiel-Workload mit Statusverwaltung in EKS Auto Mode](sample-storage-workload.md) Zeigt, wie Sie eine Beispielanwendung mit Status in einem Cluster in EKS Auto Mode bereitstellen. [Einen beschleunigten Workload bereitstellen](auto-accelerated.md) Zeigt, wie hardwarebeschleunigte Workloads auf Knoten bereitgestellt werden, die vom EKS Auto Mode verwaltet werden. [Überprüfen, ob eine Workload in Knoten von EKS Auto Mode bereitgestellt wird](associate-workload.md) Zeigt, wie Sie mithilfe einer Annotation steuern, ob eine Workload auf Knoten bereitgestellt wird, die von EKS Auto Mode verwaltet werden. # Bereitstellung einer erhöhten Beispiel-Workload in einem Cluster in Amazon EKS Auto Mode In diesem Tutorial erfahren Sie, wie Sie eine Beispiel-Workload in einem EKS-Auto-Mode-Cluster bereitstellen und beobachten, wie dieser automatisch die erforderlichen Rechenressourcen bereitstellt. Sie werden `kubectl` Befehle verwenden, um das Verhalten des Clusters zu beobachten und aus erster Hand zu erfahren, wie der Auto Mode den Kubernetes-Betrieb vereinfacht. AWS Am Ende dieses Tutorials werden Sie verstehen, wie EKS Auto Mode auf Workload-Bereitstellungen reagiert, indem er die zugrunde liegenden Rechenressourcen automatisch verwaltet, ohne dass eine manuelle Konfiguration der Knotengruppe erforderlich ist. ## Voraussetzungen + Ein Cluster in Amazon EKS Auto Mode. Notieren Sie sich den Namen und die AWS Region des Clusters. + Ein IAM-Prinzipal, beispielsweise ein Benutzer oder eine Rolle, mit ausreichenden Berechtigungen zur Verwaltung von Netzwerk-, Rechen- und EKS-Ressourcen. + Weitere Informationen finden Sie unter [Erstellung von Rollen und Hinzufügen von Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) im IAM-Benutzerhandbuch. + `aws`-CLI installiert und mit einer IAM-Identität konfiguriert. + `kubectl`-CLI installiert und mit dem Cluster verbunden. + Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md). ## Schritt 1: Vorhandene Rechenressourcen überprüfen (optional) Verwenden Sie zunächst `kubectl`, um die Knoten-Pools in Ihrem Cluster aufzulisten. ``` kubectl get nodepools ``` Beispiel-Ausgabe: ``` general-purpose ``` In diesem Tutorial werden wir eine Workload bereitstellen, die für die Verwendung des `general-purpose`-Knoten-Pools konfiguriert ist. Dieser Knoten-Pool ist in EKS Auto Mode integriert und enthält sinnvolle Standardeinstellungen für allgemeine Workloads wie Microservices und Web-Anwendungen. Sie können Ihren eigenen Knoten-Pool erstellen. Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md). Verwenden Sie anschließend `kubectl`, um die mit Ihrem Cluster verbundenen Knoten aufzulisten. ``` kubectl get nodes ``` Wenn Sie gerade einen EKS-Auto-Mode-Cluster erstellt haben, werden keine Knoten angezeigt. In diesem Tutorial werden Sie eine Beispiel-Workload bereitstellen. Wenn keine Knoten vorhanden sind oder die Workload nicht auf die vorhandenen Knoten passt, wird der EKS-Auto-Mode-Cluster einen neuen Knoten bereitstellen ## Schritt 2: Beispielanwendung im Cluster bereitstellen Überprüfen Sie die folgende Kubernetes-Bereitstellung und speichern Sie sie als `inflate.yaml` ``` apiVersion: apps/v1 kind: Deployment metadata: name: inflate spec: replicas: 1 selector: matchLabels: app: inflate template: metadata: labels: app: inflate spec: terminationGracePeriodSeconds: 0 nodeSelector: eks.amazonaws.com/compute-type: auto securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 containers: - name: inflate image: public.ecr.aws/eks-distro/kubernetes/pause:3.7 resources: requests: cpu: 1 securityContext: allowPrivilegeEscalation: false ``` 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. Wenden Sie die Bereitstellung auf Ihren Cluster an. ``` kubectl apply -f inflate.yaml ``` ## Schritt 3: Kubernetes-Ereignisse beobachten Verwenden Sie den folgenden Befehl, um Kubernetes-Ereignisse zu überwachen, einschließlich der Erstellung eines neuen Knotens. Verwenden Sie `ctrl+c`, um die Überwachung von Ereignissen zu beenden. ``` kubectl get events -w --sort-by '.lastTimestamp' ``` Verwenden Sie `kubectl`, um die mit Ihrem Cluster verbundenen Knoten erneut aufzulisten. Notieren Sie sich den neu erstellten Knoten. ``` kubectl get nodes ``` ## Schritt 4: Knoten und Instanzen in der AWS Konsole anzeigen Sie können die EKS-Automodus-Knoten in der EKS-Konsole und die zugehörigen EC2 Instanzen in der EC2 Konsole anzeigen. EC2 Instances, die im automatischen Modus von EKS bereitgestellt werden, sind eingeschränkt. Sie können in EKS-Auto-Mode-Knoten keine beliebigen Befehle ausführen. ## Schritt 5: Bereitstellung löschen Verwenden Sie `kubectl`, um die Beispielbereitstellung zu löschen ``` kubectl delete -f inflate.yaml ``` Wenn keine weiteren Workloads in Ihrem Cluster bereitgestellt sind, bleibt der vom EKS Auto Mode erstellte Knoten leer. In der Standardkonfiguration erkennt EKS Auto Mode Knoten, die seit 30 Sekunden leer sind, und beendet sie. Verwenden Sie `kubectl` oder die EC2 Konsole, um zu bestätigen, dass die zugehörige Instanz gelöscht wurde. # Bereitstellung einer Beispiel-Workload für Load Balancer in EKS Auto Mode Dieser Leitfaden führt Sie durch die Bereitstellung einer containerisierten Version des Spiels 2048 in Amazon EKS, einschließlich Load Balancing und Internetzugänglichkeit. ## Voraussetzungen + Ein EKS-Auto-Mode-Cluster + `kubectl` für die Interaktion mit Ihrem Cluster konfiguriert + Geeignete IAM-Berechtigungen für die Erstellung von ALB-Ressourcen ## Schritt 1: Namespace erstellen Erstellen Sie zunächst einen dedizierten Namespace für die 2048-Spiel-Anwendung. Erstellen Sie eine Datei namens `01-namespace.yaml`: ``` apiVersion: v1 kind: Namespace metadata: name: game-2048 ``` Wenden Sie die Namespace-Konfiguration an: ``` kubectl apply -f 01-namespace.yaml ``` ## Schritt 2: Anwendung bereitstellen Die Anwendung führt mehrere Replikate des 2048-Spiel-Containers aus. Erstellen Sie eine Datei namens `02-deployment.yaml`: ``` apiVersion: apps/v1 kind: Deployment metadata: namespace: game-2048 name: deployment-2048 spec: selector: matchLabels: app.kubernetes.io/name: app-2048 replicas: 5 template: metadata: labels: app.kubernetes.io/name: app-2048 spec: containers: - image: public.ecr.aws/l6m2t8p7/docker-2048:latest imagePullPolicy: Always name: app-2048 ports: - containerPort: 80 resources: requests: cpu: "0.5" ``` **Anmerkung** Sollten beim Laden des Images `public.ecr.aws/l6m2t8p7/docker-2048:latest` Fehler auftreten, überprüfen Sie, ob Ihre Knoten-IAM-Rolle über ausreichende Berechtigungen verfügt, um Images aus ECR abzurufen. Weitere Informationen finden Sie unter [Knoten-IAM-Rolle](auto-learn-iam.md#auto-learn-node-iam-role). Beachten Sie, dass es sich bei dem `docker-2048`-Image im Beispiel um ein `x86_64`-Image handelt, das in anderen Architekturen nicht ausgeführt werden kann. **Zentrale Komponenten:** + Stellt 5 Replikate der Anwendung bereit + Verwendet ein öffentliches ECR-Image + Erfordert 0,5 CPU-Kerne pro Pod + Stellt Port 80 für HTTP-Datenverkehr bereit Bereitstellung durchführen: ``` kubectl apply -f 02-deployment.yaml ``` ## Schritt 3: Service erstellen Der Service macht die Bereitstellung für das Cluster-Netzwerk sichtbar. Erstellen Sie eine Datei namens `03-service.yaml`: ``` apiVersion: v1 kind: Service metadata: namespace: game-2048 name: service-2048 spec: ports: - port: 80 targetPort: 80 protocol: TCP selector: app.kubernetes.io/name: app-2048 ``` **Zentrale Komponenten:** + Erstellt einen NodePort-Service + Ordnet Port 80 dem Port 80 des Containers zu + Verwendet den Label-Selektor, um Pods zu finden Wenden Sie den Service an: ``` kubectl apply -f 03-service.yaml ``` ## Schritt 4: Load Balancing konfigurieren Sie richten einen Ingress ein, um die Anwendung im Internet verfügbar zu machen. Erstellen Sie zunächst die `IngressClass`. Erstellen Sie eine Datei namens `04-ingressclass.yaml`: ``` apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: labels: app.kubernetes.io/name: LoadBalancerController name: alb spec: controller: eks.amazonaws.com/alb ``` **Anmerkung** EKS Auto Mode erfordert Subnetz-Tags zur Identifizierung öffentlicher und privater Subnetze. Wenn Sie Ihren Cluster mit `eksctl` erstellt haben, verfügen Sie bereits über diese Tags. Weitere Informationen erhalten Sie unter [Kennzeichnung von Subnetzen für EKS Auto Mode](tag-subnets-auto.md). Erstellen Sie anschließend die Ingress-Ressource. Erstellen Sie eine Datei namens `05-ingress.yaml`: ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: namespace: game-2048 name: ingress-2048 annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip spec: ingressClassName: alb rules: - http: paths: - path: / pathType: Prefix backend: service: name: service-2048 port: number: 80 ``` **Zentrale Komponenten:** + Erstellt ein internetbasiertes ALB + Verwendet den IP-Zieltyp für die direkte Pod-Weiterleitung + Leitet den gesamten Datenverkehr (/) an den Spiele-Service weiter Wenden Sie die Ingress-Konfigurationen an: ``` kubectl apply -f 04-ingressclass.yaml kubectl apply -f 05-ingress.yaml ``` ## Schritt 5: Bereitstellung überprüfen 1. Vergewissern Sie sich, dass alle Pods ausgeführt werden: ``` kubectl get pods -n game-2048 ``` 1. Überprüfen Sie, ob der Service erstellt wurde: ``` kubectl get svc -n game-2048 ``` 1. Rufen Sie den ALB-Endpunkt ab: ``` kubectl get ingress -n game-2048 ``` Das Feld ADDRESS in der Ingress-Ausgabe zeigt Ihren ALB-Endpunkt an. Warten Sie 2–3 Minuten, bis der ALB alle Ziele bereitgestellt und registriert hat. ## Schritt 6: Auf das Spiel zugreifen Öffnen Sie Ihren Web-Browser und navigieren Sie zur ALB-Endpunkt-URL aus dem vorherigen Schritt. Sie sollten nun die 2048-Spieloberfläche sehen. ## Schritt 7: Bereinigen So entfernen Sie alle in diesem Tutorial erstellten Ressourcen: ``` kubectl delete namespace game-2048 ``` Dadurch werden alle Ressourcen im Namespace gelöscht, einschließlich der Bereitstellungs-, Service- und Ingress-Ressourcen. ## Was hinter den Kulissen passiert 1. Die Bereitstellung erstellt fünf Pods, in denen das Spiel 2048 ausgeführt wird 1. Der Service bietet einen stabilen Netzwerkzugang zu diesen Pods 1. EKS Auto Mode: + Erstellt einen Application Load Balancer in AWS + Konfiguriert Zielgruppen für die Pods + Richtet Routing-Regeln ein, um den Datenverkehr zum Service zu leiten ## Fehlersuche Falls das Spiel nicht geladen wird: + Stellen Sie sicher, dass alle Pods ausgeführt werden: `kubectl get pods -n game-2048` + Überprüfen Sie den Ingress-Status: `kubectl describe ingress -n game-2048` + Überprüfen Sie die ALB-Zustandsprüfungen: Zustand der Zielgruppe in der AWS-Konsole überprüfen # Bereitstellung einer Beispiel-Workload mit Statusverwaltung in EKS Auto Mode Dieses Tutorial führt Sie durch die Bereitstellung einer Beispielanwendung mit Statusverwaltung in Ihrem Cluster von EKS Auto Mode. Die Anwendung schreibt Zeitstempel in ein persistentes Volume und demonstriert damit die automatische EBS-Volume-Bereitstellung und die Persistenzfunktionen von EKS Auto Mode. ## Voraussetzungen + Ein EKS-Auto-Mode-Cluster + Die AWS CLI ist mit entsprechenden Berechtigungen konfiguriert + `kubectl` installiert und konfiguriert + Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md). ## Schritt 1: Umgebung konfigurieren 1. Legen Sie Ihre Umgebungsvariablen fest: ``` export CLUSTER_NAME=my-auto-cluster export AWS_REGION="us-west-2" ``` 1. Aktualisieren Sie Ihre kubeconfig: ``` aws eks update-kubeconfig --name "${CLUSTER_NAME}" ``` ## Schritt 2: Speicherklasse erstellen `StorageClass` definiert, wie der EKS Auto Mode EBS-Volumes bereitstellt. EKS Auto Mode erstellt keine `StorageClass` für Sie. Sie müssen eine `StorageClass`-Referenzierung `ebs.csi.eks.amazonaws.com` erstellen, um die Speicherfunktion von EKS Auto Mode zu nutzen. 1. Erstellen Sie eine Datei namens `storage-class.yaml`: ``` apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: auto-ebs-sc annotations: storageclass.kubernetes.io/is-default-class: "true" provisioner: ebs.csi.eks.amazonaws.com volumeBindingMode: WaitForFirstConsumer parameters: type: gp3 encrypted: "true" ``` 1. Wenden Sie `StorageClass` an: ``` kubectl apply -f storage-class.yaml ``` **Zentrale Komponenten:** + `provisioner: ebs.csi.eks.amazonaws.com` – Verwendet EKS Auto Mode + `volumeBindingMode: WaitForFirstConsumer` – Verzögert die Volume-Erstellung, bis ein Pod sie benötigt + `type: gp3` – Gibt den EBS-Volume-Typ an + `encrypted: "true"` – EBS verwendet den Standardschlüssel `aws/ebs` zum Verschlüsseln von Volumes, die mit dieser Klasse erstellt wurden. Dies ist zwar optional, wird aber empfohlen. + `storageclass.kubernetes.io/is-default-class: "true"` – Kubernetes verwendet standardmäßig diese Speicherklasse, sofern Sie nicht für einen persistenten Volume-Anspruch eine andere Volume-Klasse angeben. Seien Sie beim Festlegen dieses Werts vorsichtig, wenn Sie von einem anderen Speicher-Controller migrieren. (optional) ## Schritt 3: Persistenten Volume-Anspruch erstellen Der PVC fordert Speicher von der `StorageClass` an. 1. Erstellen Sie eine Datei namens `pvc.yaml`: ``` apiVersion: v1 kind: PersistentVolumeClaim metadata: name: auto-ebs-claim spec: accessModes: - ReadWriteOnce storageClassName: auto-ebs-sc resources: requests: storage: 8Gi ``` 1. Wenden Sie den PVC an: ``` kubectl apply -f pvc.yaml ``` **Zentrale Komponenten:** + `accessModes: ReadWriteOnce` – Das Volume kann jeweils von einem Knoten eingebunden werden + `storage: 8Gi` – Fordert ein Volumen von 8 GiB an + `storageClassName: auto-ebs-sc` – Verweist auf die von uns erstellte `StorageClass` ## Schritt 4: Anwendung bereitstellen Die Bereitstellung führt einen Container aus, der Zeitstempel in das persistente Volume schreibt. 1. Erstellen Sie eine Datei namens `deployment.yaml`: ``` apiVersion: apps/v1 kind: Deployment metadata: name: inflate-stateful spec: replicas: 1 selector: matchLabels: app: inflate-stateful template: metadata: labels: app: inflate-stateful spec: terminationGracePeriodSeconds: 0 nodeSelector: eks.amazonaws.com/compute-type: auto containers: - name: bash image: public.ecr.aws/docker/library/bash:4.4 command: ["/usr/local/bin/bash"] args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"] resources: requests: cpu: "1" volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim: claimName: auto-ebs-claim ``` 1. Bereitstellung durchführen: ``` kubectl apply -f deployment.yaml ``` **Zentrale Komponenten:** + Einfacher Bash-Container, der Zeitstempel in eine Datei schreibt + Bindet den PVC bei `/data` ein + Fordert 1 CPU-Kern an + Verwendet Knotenselektor für EKS-verwaltete Knoten ## Schritt 5: Einrichtung überprüfen 1. Überprüfen Sie, ob der Pod ausgeführt wird: ``` kubectl get pods -l app=inflate-stateful ``` 1. Überprüfen Sie, ob der PVC eingebunden ist: ``` kubectl get pvc auto-ebs-claim ``` 1. Überprüfen Sie das EBS-Volume: ``` # Get the PV name PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}') # Describe the EBS volume aws ec2 describe-volumes \ --filters Name=tag:CSIVolumeName,Values=${PV_NAME} ``` 1. Überprüfen Sie, ob Daten geschrieben werden: ``` kubectl exec "$(kubectl get pods -l app=inflate-stateful \ -o=jsonpath='{.items[0].metadata.name}')" -- \ cat /data/out.txt ``` ## Schritt 6: Bereinigen Führen Sie den folgenden Befehl aus, um alle in diesem Tutorial erstellten Ressourcen zu entfernen: ``` # Delete all resources in one command kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc ``` ## Was hinter den Kulissen passiert 1. Der PVC fordert Speicher von der `StorageClass` an 1. Wenn der Pod geplant ist: 1. EKS Auto Mode stellt ein EBS-Volume bereit 1. Erstellt ein PersistentVolume 1. Fügt das Volume zum Knoten hinzu 1. Der Pod bindet das Volume ein und beginnt mit dem Schreiben von Zeitstempeln ## Snapshot-Controller EKS Auto Mode ist mit dem Kubernetes CSI Snapshotter, auch bekannt als Snapshot-Controller, kompatibel. EKS Auto Mode umfasst jedoch keinen Snapshot-Controller. Sie sind für die Installation und Konfiguration des Snapshot-Controllers verantwortlich. Weitere Informationen finden Sie unter [Snapshot-Funktion für CSI-Volumes aktivieren](csi-snapshot-controller.md). Überprüfen Sie die folgenden `VolumeSnapshotClass`, die sich auf die Speicherkapazität von EKS Auto Mode beziehen. ``` apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotClass metadata: name: auto-ebs-vsclass driver: ebs.csi.eks.amazonaws.com deletionPolicy: Delete ``` [Weitere Informationen zum Kubernetes CSI Snapshotter.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage) # Einen beschleunigten Workload bereitstellen Dieses Tutorial zeigt, wie Amazon EKS Auto Mode das Starten hardwarebeschleunigter 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 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/) + [ EC2 Beschleunigte Instances von NVIDIA GPUs auf Amazon](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/) 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 stellt NodePool auch einen Makel dar, der es erlaubt, nur Pods mit Toleranzen für Nvidia GPUs zu planen. 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 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, 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 `consolodateAfter` unterstützt spitzenlastige Workloads und reduziert die Fluktuation der 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 `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](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 Speicher erstellen`iops`, auf den Sie [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 Inferentia AWS NodePool Im Folgenden NodePool ist `eks.amazonaws.com/instance-category` festgelegt, dass nur Instanzen der Inferentia- und Trainium-Familie gestartet werden sollen: ``` - key: "eks.amazonaws.com/instance-category" operator: In values: - inf - trn ```