View a markdown version of this page

Rechenleistung für AI/ML Workloads mit EKS Auto Mode und Karpenter verwalten - Amazon EKS

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.

Rechenleistung für AI/ML Workloads mit EKS Auto Mode und Karpenter verwalten

Tipp

Melden Sie sich für bevorstehende Amazon AI/ML EKS-Workshops an.

In diesem Abschnitt wird beschrieben, wie Sie beschleunigte Rechenleistung (AWS Trainium, NVIDIA-GPUs) für KI-Trainings- und Inferenz-Workloads mithilfe von Amazon EKS Auto Mode oder selbstverwaltetem Karpenter verwalten.

EKS Auto Mode und Karpenter unterstützen zwei Bereitstellungsmodi: dynamische Bereitstellung und statische Bereitstellung. Bei der dynamischen Bereitstellung stellen EKS Auto Mode und Karpenter beschleunigte Recheninstanzen bereit und skalieren sie, je nachdem, welche Workloads auf dem Cluster geplant sind. Bei der statischen Bereitstellung stellen EKS Auto Mode und Karpenter eine feste Anzahl von Knoten bereit und verwalten sie. Dynamisches und statisches Provisioning können im selben Cluster verwendet werden, um einen konstanten Basiskapazitätspool aufrechtzuerhalten und gleichzeitig mit den Workload-Anforderungen zu skalieren.

EKS Auto Mode und Karpenter unterstützen alle vier Kapazitätskaufoptionen (SpotOn-Demand, Capacity Blocks und ODCRs) und stellen immer zuerst reservierte Kapazität bereit, gefolgt von Spot oder. On-Demand

EKS Auto Mode gegen Karpenter

Beide Ansätze nutzen dieselbe NodePool API, unterscheiden sich jedoch in Bezug auf die betriebliche Eigentümerschaft, die Ressourcen-APIs, die Betriebssystemunterstützung, die Behandlung von Spot-Unterbrechungen und die Flexibilität bei der Konfiguration.

Feature EKS Auto Mode Self-managed Karpenter

Am besten geeignet für

Teams, die eine verwaltete Infrastruktur mit minimalem Betriebsaufwand bevorzugen

Teams, die die volle Kontrolle über den Knotenlebenszyklus, AMIs, Betriebssystem-Tuning und Patching bevorzugen.

Betriebsmodell

AWS stellt den Karpenter-Controller, die GPU/Trainium Treiber, Geräte-Plugins, das Betriebssystem-Patching und die Behandlung von Spot-Unterbrechungen bereit und verwaltet sie.

Sie installieren und betreiben den Karpenter-Controller in Ihrem Cluster und besitzen GPU/Trainium Treiber, Geräte-Plugins, den AMI-Lebenszyklus, das Patchen und die Behandlung von Spot-Unterbrechungen.

Rechenoptionen

On-Demand, Spot, ODCRs, Kapazitätsblöcke für ML

On-Demand, Spot, ODCRs, Kapazitätsblöcke für ML

Ressourcen-APIs

NodePool (karpenter.sh/v1), NodeClass (eks.amazonaws.com/v1).

NodePool (karpenter.sh/v1), EC2NodeClass (karpenter.k8s.aws/v1).

Betriebssystem des Knotens

Nur Bottlerocket. NVIDIA-GPU-, AWS Trainium- und EFA-Abhängigkeiten enthalten.

AL2023, Bottlerocket, Windows oder Ihr eigenes AMI.

Lebensdauer des Knotens

Maximale Knotenlebensdauer von 21 Tagen für Sicherheitspatches. Workloads müssen eine Rotation der Knoten tolerieren.

Sie definieren den Knotenlebenszyklus NodePool expireAfter und die Budgets für Unterbrechungen.

Behandlung von Unterbrechungen direkt vor Ort

Einheimisch. Keine SQS-Warteschlange oder kein Node Termination Handler erforderlich.

Sie sind für die Konfiguration und Aktivierung verantwortlich.

Schnelles Ziehen von Containern

SOCI-Parallel-Pull ist in allen Instances der G-, P- und Trn-Familie enthalten

Sie sind für die Konfiguration und Aktivierung verantwortlich.

EC2-Platzierungsgruppen

Cluster, Partition, Verteilung

Clustern, partitionieren, verteilen

Konfiguration der Netzwerkschnittstelle

Nicht unterstützt

Pro Schnittstellenkonfiguration für Typ interface oder EFA-only

Reparatur von Knoten

Standardmäßig aktiviert, der EKS-Node-Monitoring-Agent ist enthalten

Optional aktiviert, der EKS-Node-Monitoring-Agent wird selbst verwaltet

Preisgestaltung

Die Verwaltungsgebühr für den automatischen Modus von EKS wird zusätzlich zu den Kosten der zugrunde liegenden EC2-Instance berechnet.

Open-Source-Software. Sie zahlen für die zugrunde liegenden EC2-Instances.

Gängige AI/ML bekannte Labels

EKS Auto Mode und Karpenter stellen Instanzbezeichnungen zur Verfügung, die Sie in NodePool requirements und Pod nodeSelector oder für Ziel-Workloads verwenden können, ohne Instanztypen fest nodeAffinity zu codieren. Das Label-Präfix unterscheidet sich zwischen den beiden: EKS Auto Mode verwendet, eks.amazonaws.com/ während Karpenter selbst verwaltet verwendet. karpenter.k8s.aws/

Die folgenden Tabellen zeigen relevante Labels, die in verwendet werden können. NodePools EKS Auto Mode und Karpenter wenden im Rahmen des Bereitstellungsprozesses auch die in der Karpenter-Dokumentation aufgeführten Bezeichnungen auf Knoten an, die anschließend für das Workload-Targeting verwendet werden können.

EKS Auto Mode

Die vollständige Liste finden Sie unter Von EKS Auto Mode unterstützte Labels.

Label (Bezeichnung) Beispielwert Description

eks.amazonaws.com/instance-family

p5

Instanztypen mit ähnlichen Eigenschaften, aber unterschiedlichen Ressourcenmengen.

eks.amazonaws.com/instance-category

p

Instanzkategorie, normalerweise der Buchstabe vor der Generationsnummer.

eks.amazonaws.com/instance-generation

5

Generationsnummer des Instanztyps innerhalb einer Kategorie.

eks.amazonaws.com/instance-gpu-name

h100

Name der GPU auf der Instanz.

eks.amazonaws.com/instance-gpu-manufacturer

nvidia

Name des GPU-Herstellers.

eks.amazonaws.com/instance-gpu-count

8

Anzahl der GPUs auf der Instanz.

eks.amazonaws.com/instance-gpu-memory

81920

Mebibyte Speicher pro GPU.

karpenter.sh/capacity-type

reserved

Kapazitätstyp:spot,on-demand, oder. reserved

topology.kubernetes.io/zone

us-east-1a

Verfügbarkeitszone.

Self-managed Karpenter

Die vollständige Liste finden Sie unter Karpenter Labels Well-Known .

Label (Bezeichnung) Beispielwert Description

karpenter.k8s.aws/instance-family

p5

Instanztypen mit ähnlichen Eigenschaften, aber unterschiedlichen Ressourcenmengen.

karpenter.k8s.aws/instance-category

p

Instanzkategorie, normalerweise der Buchstabe vor der Generationsnummer.

karpenter.k8s.aws/instance-generation

5

Generationsnummer des Instanztyps innerhalb einer Kategorie.

karpenter.k8s.aws/instance-gpu-name

h100

Name der GPU auf der Instanz.

karpenter.k8s.aws/instance-gpu-manufacturer

nvidia

Name des GPU-Herstellers.

karpenter.k8s.aws/instance-gpu-count

8

Anzahl der GPUs auf der Instanz.

karpenter.sh/capacity-type

reserved

Kapazitätstyp:spot,on-demand, oderreserved.

topology.kubernetes.io/zone

us-east-1a

Verfügbarkeitszone.

kubernetes.io/arch

amd64

CPU-Architektur.

Planung von Labels für reservierte Kapazität

Wenn EKS Auto Mode oder Karpenter einen Knoten in einer Reservierung starten, werden die folgenden Beschriftungen hinzugefügt. Verwenden Sie sie innodeSelector, in der Knotenaffinität oder in NodePool Anforderungen, um Workloads weiterzuleiten.

  • karpenter.sh/capacity-type:reserved, oderon-demand. spot Gibt die Kapazität an, die dem Knoten zugrunde liegt.

  • karpenter.k8s.aws/capacity-reservation-id: Die spezifische Reservierungs-ID, mit der der Knoten gestartet wurde.

  • karpenter.k8s.aws/capacity-reservation-type: default für ODCRs, capacity-block für Capacity Blocks.

Die folgenden Beispiele zeigen gängige Planungsmuster:

Verbinde einen Pod mit einer bestimmten Reservierung (kein Fallback):

spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"

Nur ODCR-Zielknoten (alle ODCR-Knoten, keine Kapazitätsblöcke):

spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-type: default

Auf jede reservierte Kapazität (ODCR oder Kapazitätsblock) abzielen:

spec: nodeSelector: karpenter.sh/capacity-type: reserved

Bevorzugen Sie reserviert, greifen Sie aber auf Spot zurück oder On-Demand falls nicht verfügbar:

spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: karpenter.sh/capacity-type operator: In values: ["reserved"]

Verhalten beim Ablauf der Reservierung

ODCRs und Capacity Blocks verhalten sich unterschiedlich, wenn die Reservierung endet. Vergewissern Sie sich, dass Ihre Terminplanung und Checkpoint-Strategie der Art der Reservierung entspricht, die Ihren Arbeitsaufwand unterstützt.

Dokumente

Eine in einem ODCR gestartete Instanz befindet sich nicht auf unbestimmte Zeit in diesem ODCR. Das ODCR kann ablaufen, gekündigt werden oder die Instanz kann manuell aus dem ODCR entfernt werden. Wenn einer dieser Fälle eintritt und EKS Auto Mode//Karpenter feststellt, dass die Instanz nicht mehr zu einem ODCR gehört, aktualisiert es die Bezeichnung des Knotens von bis. karpenter.sh/capacity-type reserved on-demand Die Instanz wird weiterhin mit On-Demand Standardkapazität ausgeführt, und bestehende Pods laufen ohne Unterbrechung weiter.

Anmerkung

Jeder Pod, der mit einem Strict-Wert geplant ist, nodeSelector: karpenter.sh/capacity-type: reserved wird nicht auf den Knoten eingeplant, wenn er neu beschriftet wurde. Damit Workloads einen Ablauf oder eine Kündigung von ODCR überstehen, verwenden Sie das oben gezeigte preferredDuringSchedulingIgnoredDuringExecution Muster anstelle von a. nodeSelector

Kapazitätsblöcke

Im Gegensatz zu ODCRs haben Capacity-Blöcke immer eine Endzeit, und EC2 beendet Capacity Block-Instances 30 Minuten vor der Endzeit (60 Minuten für UltraServer Instance-Typen). Planen Sie Schulungs- und Inferenzaufgaben so, dass sie abgeschlossen sind, oder speichern Sie den Status, bevor das Reservierungsfenster geschlossen wird. Pods, die capacity-reservation-id nach Pending Ablauf der Sperre einen Strict nodeSelector für eine bestimmte Ausführung verwenden und nicht an anderer Stelle verschoben werden können. Kombinieren Sie Checkpointing mit dem oben genannten flexiblen Affinitätsmuster, wenn Sie Workloads während des Ablaufs des Capacity-Blocks auf eine andere Kapazität verschieben müssen.

  • Sie können Reserved Instances für die meisten Instance-Typen bis 30 Minuten vor der Endzeit des Kapazitätsblocks oder bis 60 Minuten vor der Endzeit für UltraServer Instance-Typen verwenden.

  • EKS Auto Mode und Karpenter beginnen 10 Minuten vor der Terminierung von EC2 präventiv mit der Entleerung von Knoten in einem Kapazitätsblock, sodass Workloads Zeit haben, Checkpoints durchzuführen und ordnungsgemäß herunterzufahren.

Statische Kapazität NodePools

EKS Auto Mode und Karpenter unterstützen statische Kapazität NodePools, wodurch unabhängig vom Workload-Bedarf eine feste Anzahl von Knoten aufrechterhalten wird. Statische Pools verhindern Kaltstartverzögerungen für latenzempfindliche Inferenzen und ermöglichen es Ihnen, einen minimalen Infrastrukturbedarf für Ihren Cluster zu reservieren.

Die statische Kapazität wird konfiguriert, indem Sie das Feld auf dem festlegen. replicas NodePool

Überlegungen

  • Sobald replicas es auf a gesetzt ist NodePool, können Sie es nicht mehr entfernen. Eine einzelne Person NodePool kann nicht zwischen statischer und dynamischer Kapazitätsbereitstellung wechseln.

  • Statische Kapazitäten NodePools werden bei der Konsolidierung nicht berücksichtigt. Wird limits.nodes oben festgelegtreplicas, um eine temporäre Skalierung während der AMI-Drift oder -Ablaufzeit zu ermöglichen.

  • Für eine vorhersehbare Verteilung der Availability Zone (AZ) sollten Sie eine statische Kapazität NodePool pro AZ einrichten, anstatt sich über mehrere Zonen in einem einzigen Pool zu erstrecken.

EKS Auto Mode

Das folgende Beispiel zeigt eine statische Kapazität NodePool , die den standardmäßigen EKS-Automodus verwendet NodeClass und eine statische Kapazität NodePool mit 4 Knoten (replicas) erstellt, die maximal 6 Knoten (limits.nodes) sein können.

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-static-inference spec: replicas: 4 template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: nodes: 6 # Allow temporary headroom during node replacement
Self-managed Karpenter

Bei selbstverwaltetem Karpenter wird die statische Kapazität durch die StaticCapacity Alpha-Funktion (eingeführt in Karpenter-Version v1.8) begrenzt, die in den Helm-Werten aktiviert werden muss:

settings: featureGates: staticCapacity: true

Das NodePool referenziert einen benutzerdefinierten EC2NodeClass Namen my-nodeclass und erstellt ein statisches Objekt NodePool mit 4 Knoten (replicas), bei denen es sich um maximal 6 Knoten () handeln kann. limits.nodes

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-static-inference spec: replicas: 4 template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: my-nodeclass requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: nodes: 6 # Allow temporary headroom during node replacement

Kapazitätsblöcke für ML

Capacity Blocks for ML ermöglichen es Ihnen, Instances für ein definiertes future Fenster zu reservieren P-family und zu trainieren. Sie sind im Voraus bezahlt, weshalb EKS Auto Mode und Karpenter sie als kostenlos abbilden und ihnen Vorrang vor Spot einräumen. On-Demand Kapazitätsblöcke für ML können eine Reservierungsdauer von 1—14 Tagen oder einem Vielfachen von 7 Tagen bis zu 182 Tagen (6 Monaten) haben.

Um Capacity Blocks for ML mit EKS Auto Mode oder Karpenter zu verwenden, konfigurieren Sie es capacityReservationSelectorTerms mit Ihrer Kapazitätsreservierungs-ID in Ihrem. NodeClass Sie können den offenen Reservierungsabgleich nicht mit Capacity Blocks for ML verwenden. Ein Begriff kann eine ID, eine Reihe von Tags oder Kriterien für die Instanzübereinstimmung angeben, anhand derer ausgewählt werden soll. Bei der Angabe von Stichwörtern werden alle Kapazitätsreservierungen ausgewählt, auf die über das Konto zugegriffen werden kann, mit passenden Stichwörtern. Dies kann durch Angabe einer Eigentümerkonto-ID weiter eingeschränkt werden.

Weitere Beispiele finden Sie in der Karpenter-Dokumentation.

EKS Auto Mode

Erstellen Sie eineNodeClass, die auf Ihre Kapazitätsblock-Reservierung verweist, und erstellen Sie dann eine, NodePool die sie verwendet.

Wenn diese consolidateAfter: Never Option aktiviert ist, versucht Karpenter nicht, Knoten zu ersetzen, zusammenzuführen oder zu beenden, um Kosten zu reduzieren oder Workloads effizienter zu bündeln. Dies wird für Kapazitätsblöcke empfohlen, da die Kapazität bereits im Voraus bezahlt ist.

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: capacity-block-gpu spec: capacityReservationSelectorTerms: - id: "cr-0123456789abcdef0" # Your Capacity Block reservation ID # Alternative: select by tags # - tags: # role: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-capacity-block spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: capacity-block-gpu requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "p5e", "p5en", "p4d"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule
Self-managed Karpenter

Erstellen Sie eine, EC2NodeClass die zusätzlich AMI-, Subnetz- und Sicherheitsgruppenselektoren enthält, und erstellen Sie dann einecapacityReservationSelectorTerms, NodePool die sie verwendet.

Wenn diese consolidateAfter: Never Option aktiviert ist, versucht Karpenter nicht, Knoten zu ersetzen, zusammenzuführen oder zu beenden, um Kosten zu senken oder Workloads effizienter zu verpacken. Dies wird für Kapazitätsblöcke empfohlen, da die Kapazität bereits im Voraus bezahlt ist.

apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: capacity-block-gpu spec: amiSelectorTerms: - alias: al2023@latest subnetSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster securityGroupSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster capacityReservationSelectorTerms: - id: "cr-0123456789abcdef0" # Your Capacity Block reservation ID # Alternative: select by tags # - tags: # role: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-capacity-block spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: capacity-block-gpu requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "p5e", "p5en", "p4d"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule

On-Demand Kapazitätsreservierungen (ODCRs)

ODCRs garantieren Kapazität in einer bestimmten Availability Zone (AZ) ohne langfristige Verpflichtung. Ihnen werden On-Demand Standardtarife in Rechnung gestellt, unabhängig davon, ob die Kapazität genutzt wird oder nicht. ODCRs unterstützen alle NVIDIA-GPU-Familien, einschließlich G-family Instanzen, die von Capacity Blocks for ML nicht unterstützt werden. ODCRs sind im Voraus bezahlt, sodass sie von EKS Auto Mode und Karpenter als kostenlos angeboten werden und ihnen Vorrang vor Spot eingeräumt werden. On-Demand

ODCRs verhalten sich am Ende der Reservierung anders als Capacity Blocks für ML. Wenn ein ODCR abläuft oder storniert wird, läuft die Instanz standardmäßig weiter. On-Demand Details dazu finden Sie unter Verhalten beim Ablauf der Reservierung.

Um ODCRs mit EKS Auto Mode oder Karpenter zu verwenden, konfigurieren Sie es capacityReservationSelectorTerms mit Ihren Kapazitätsreservierungsbedingungen in Ihrem. NodeClass Ein Begriff kann eine ID, eine Reihe von Tags oder Instance-Übereinstimmungskriterien angeben, anhand derer ausgewählt werden soll. Bei der Angabe von Stichwörtern werden alle Kapazitätsreservierungen ausgewählt, auf die über das Konto zugegriffen werden kann, mit passenden Stichwörtern. Bei der Angabe von Kriterien für die Zuordnung von Instanzen werden Reservierungen anhand ihres Abgleichverhaltens ausgewählt: offen (entspricht allen kompatiblen Instances) oder zielgerichtet (entspricht nur explizit ausgewählten Instances). Dies kann durch Angabe einer Besitzerkonto-ID weiter eingeschränkt werden.

Weitere Beispiele finden Sie in der Karpenter-Dokumentation.

EKS Auto Mode

Erstellen Sie ein NodeClass mit capacityReservationSelectorTerms und ein NodePool , das mit Fallback priorisiert reserved wird. on-demand An topology.kubernetes.io/zone die AZ des ODCR anheften:

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: odcr-gpu-production spec: capacityReservationSelectorTerms: - id: "cr-0987654321fedcba0" # Alternative: select by tags # - tags: # Purpose: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-reserved-production spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: odcr-gpu-production requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved", "on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule
Self-managed Karpenter

Erstellen Sie eine EC2NodeClass mit zusätzlich AMI-, Subnetz- und Sicherheitsgruppenselektoren und erstellen Sie capacityReservationSelectorTerms dann die: NodePool

apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: odcr-gpu-production spec: amiSelectorTerms: - alias: al2023@latest subnetSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster securityGroupSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster capacityReservationSelectorTerms: - id: "cr-0987654321fedcba0" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-reserved-production spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: odcr-gpu-production requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved", "on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule

On-Demand

On-Demand ist der Standardkapazitätstyp und kann mit statischer oder dynamischer Bereitstellung in EKS Auto Mode und Karpenter verwendet werden. Sie können On-Demand Instanzen explizit anfordern, indem Sie Ihre einrichtenkarpenter.sh/capacity-type: on-demand. NodePool EKS Auto Mode und Karpenter wählen die Instanz mit dem niedrigsten Preis aus, die die Ressourcenanforderungen des Pods erfüllt. Wird On-Demand für Entwicklung, Prototyping, unvorhersehbare Skalierung von Inferenzen und für alle Workloads verwendet, die sofortige Verfügbarkeit ohne Unterbrechungsrisiko erfordern.

EKS Auto Mode
apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-ondemand spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule
Self-managed Karpenter
apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-ondemand spec: template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule

Spot-Instances

Spot bietet Einsparungen von bis zu 90% gegenüber der Verwendung On-Demand von EC2-Reservekapazitäten. AWS kann Spot-Instances mit einer Unterbrechungsbenachrichtigung von 2 Minuten zurückfordern. Maximieren Sie die Verfügbarkeit, indem Sie mehrere Instance-Familien auf dem NodePool auflisten. Kombinieren Sie Spot-Workloads in regelmäßigen Abständen mit einem PodDisruptionBudget und einem Checkpoint zu einem dauerhaften Speicher (Amazon S3 oder Amazon EFS), sodass Pods den Status speichern können, während das Fenster leer ist.

Spot-Workloads eignen sich hervorragend für fehlertolerante, wiederaufnehmbare Trainings- und Inferenz-Workloads, bei denen gelegentliche Unterbrechungen als Gegenleistung für erhebliche Kosteneinsparungen akzeptabel sind.

Zu den gängigen Kandidaten gehören:

  • Hyperparameter-Tuning und Sweeps: viele kurze, parallel Versuche, die wiederholt werden können, wenn sie unterbrochen werden.

  • Verteiltes Training mit Checkpointing: lang andauernde Jobs, die den Status regelmäßig in S3 oder FSx speichern und nach einem Knotenverlust ab dem letzten Checkpoint wieder aufgenommen werden können.

  • Batch- und Offline-Inferenz: groß angelegte Scoring-Jobs anhand von Datensätzen, bei denen die End-to-End-Latenz in Stunden statt in Sekunden gemessen wird.

  • Datenvorverarbeitungs- und Feature-Engineering-Pipelines: parallel Transformationen über große Datensätze.

  • Modellevaluierung und Benchmarking: wiederholbare Aufgaben, die zu idempotenten Ergebnissen führen.

  • Entwicklung, Prototyping und Notebooks: interaktives Experimentieren, bei dem Benutzer gelegentliche Neustarts tolerieren können.

Vermeiden Sie Spot für latenzempfindliche Echtzeit-Inferenzen, SLA-bound Produktionsendpunkte und Workloads, die keine Checkpoints ausführen oder Neustarts nicht tolerieren können.

Sie können Spot-Instances explizit anfordern, indem Sie Ihre einrichten. karpenter.sh/capacity-type: spot NodePool

EKS Auto Mode

Der automatische Modus von EKS verarbeitet Spot-Unterbrechungen nativ. Es ist weder eine SQS-Warteschlange noch ein Node Termination Handler erforderlich.

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-spot spec: disruption: budgets: - nodes: 10% consolidationPolicy: WhenEmpty consolidateAfter: 1h template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["spot"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: resources: nvidia.com/gpu: "64"
Self-managed Karpenter

Self-managed Karpenter verlangt, dass Sie die systemeigene Unterbrechungsbehandlung auf dem Karpenter-Controller (nicht auf dem NodePool) aktivieren, indem Sie eine Unterbrechungswarteschlange konfigurieren: eine SQS-Warteschlange, die EC2-Spot-Interruptions- und Rebalance-Recommendation-Ereignisse empfängt. Sie konfigurieren dies einmal bei der Installation.

Wenn Sie Karpenter direkt mit Helm installieren, geben Sie Folgendes einsettings.interruptionQueue: values.yaml

# karpenter values.yaml (Helm) settings: clusterName: my-cluster interruptionQueue: my-queue # Name of the SQS queue receiving Spot events

Wenn Sie Karpenter mit booten, legen Sie das withSpotInterruptionQueue: true in Ihrer eksctl Cluster-Konfigurationsdatei fest. eksctlerstellt die SQS-Warteschlange und die EventBridge Regeln und konfiguriert den Karpenter-Controller für deren Verwendung.

# eksctl ClusterConfig karpenter: version: "${KARPENTER_VERSION}" withSpotInterruptionQueue: true

Sobald der Controller für die Verwendung Ihrer Warteschlange eingerichtet ist, ist keine zusätzliche Konfiguration für einzelne Ressourcen erforderlich. NodePool Die Behandlung von Unterbrechungen gilt für den gesamten Cluster.

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-spot spec: disruption: budgets: - nodes: 10% consolidationPolicy: WhenEmpty consolidateAfter: 1h template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["spot"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: resources: nvidia.com/gpu: "64"