EKS Auto Mode gegen Karpenter Allgemeine, AI/ML bekannte Bezeichnungen Planung von Labels für reservierte Kapazität Verhalten beim Ablauf der Reservierung Statische Kapazität NodePools Kapazitätsblöcke für ML On-Demand Kapazitätsreservierungen (ODCRs)On-Demand Spot-Instances

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 unter, der sich im rechten Bereich jeder Seite befindet.

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

Tipp

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

In diesem Abschnitt wird beschrieben, wie Sie beschleunigtes Rechnen (AWS Trainium, NVIDIA-GPUs) für KI-Trainings- und Inferenz-Workloads mithilfe des Amazon EKS-Automatikmodus oder des selbstverwalteten 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, wenn die Workloads im 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 den Workload-Anforderungen entsprechend zu skalieren.

EKS Auto Mode und Karpenter unterstützen alle vier Optionen zum Kauf von Kapazitäten (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 die gleiche NodePool API, unterscheiden sich jedoch in Bezug auf die Betriebsverantwortung, die Ressourcen-APIs, die Betriebssystemunterstützung, den Umgang mit punktuellen 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 Node-Lebenszyklus, AMIs, Betriebssystem-Tuning und Patching bevorzugen.
Operatives Modell	AWS stellt den Karpenter Controller, GPU/Trainium Treiber, Geräte-Plugins, Betriebssystem-Patches und den Umgang mit Spot-Unterbrechungen bereit und verwaltet sie.	Sie installieren und betreiben den Karpenter Controller in Ihrem Cluster und sind selbst für GPU/Trainium Treiber, Geräte-Plug-ins, den AMI-Lebenszyklus, das Patchen und die Behandlung von Spot-Unterbrechungen verantwortlich.
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`).
Node-Betriebssystem	Nur Bottlerocket. NVIDIA-GPU-, AWS Trainium- und EFA-Abhängigkeiten enthalten.	AL2023, Bottlerocket, Windows oder Ihr eigenes AMI.
Lebensdauer des Knotens	Maximale Lebensdauer des Knotens für Sicherheitspatches von 21 Tagen. Workloads müssen eine Knotenrotation tolerieren.	Sie definieren den Knotenlebenszyklus NodePool `expireAfter` und die Budgets für Unterbrechungen.
Behandlung von Unterbrechungen vor Ort	Einheimisch. Keine SQS-Warteschlange oder kein Node Termination Handler erforderlich.	Sie sind für die Konfiguration und Aktivierung verantwortlich.
Schnelles Ziehen des Containers	Paralleler SOCI-Pull ist in allen Instances der G-, P- und Trn-Familie enthalten	Sie sind für die Konfiguration und Aktivierung verantwortlich.
EC2-Praktizierungsgruppen	Cluster, Partition, Verteilung	Cluster, Partition, Ausbreitung
Konfiguration der Netzwerkschnittstelle	Konfiguration pro Schnittstelle für Typ `interface` oder `EFA-only`	Konfiguration pro Schnittstelle für Typ `interface` oder `EFA-only`
Reparatur des Knotens	Standardmäßig aktiviert, einschließlich des EKS-Knotenüberwachungsagenten	Der EKS-Knotenüberwachungsagent ist optional aktiviert und wird selbst verwaltet
Preisgestaltung	Die Verwaltungsgebühr für den EKS-Automatikmodus wird zusätzlich zu den Kosten der zugrunde liegenden EC2-Instance berechnet.	Open Source. Sie zahlen für die zugrunde liegenden EC2-Instances.

Allgemeine, AI/ML bekannte Bezeichnungen

EKS Auto Mode und Karpenter stellen Instanzbezeichnungen zur Verfügung, die Sie in einem NodePool requirements Pod nodeSelector oder für Target-Workloads verwenden können, ohne Instanztypen fest nodeAffinity zu codieren. Das Label-Präfix unterscheidet sich zwischen den beiden: EKS Auto Mode verwendet es, eks.amazonaws.com/ während das selbstverwaltete Karpenter es 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 dann für das Workload-Targeting weiter 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`	Generierungsnummer des Instanztyps innerhalb einer Kategorie.
`eks.amazonaws.com/instance-gpu-name`	`h100`	Name der GPU auf der Instance.
`eks.amazonaws.com/instance-gpu-manufacturer`	`nvidia`	Name des GPU-Herstellers.
`eks.amazonaws.com/instance-gpu-count`	`8`	Anzahl der GPUs auf der Instance.
`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`	Generierungsnummer des Instanztyps innerhalb einer Kategorie.
`karpenter.k8s.aws/instance-gpu-name`	`h100`	Name der GPU auf der Instance.
`karpenter.k8s.aws/instance-gpu-manufacturer`	`nvidia`	Name des GPU-Herstellers.
`karpenter.k8s.aws/instance-gpu-count`	`8`	Anzahl der GPUs auf der Instance.
`karpenter.sh/capacity-type`	`reserved`	Kapazitätstyp: `spoton-demand`, oder`reserved`.
`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 eine Reservierung aufnehmen, werden die folgenden Labels hinzugefügt. Verwenden Sie sie innodeSelector, Node-Affinität oder NodePool Anforderungen, um Workloads weiterzuleiten.

karpenter.sh/capacity-type: reservedon-demand, oderspot. Gibt die Kapazität an, die den Knoten unterstützt.
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 Kapazitätsblöcke.

Die folgenden Beispiele zeigen gängige Planungsmuster:

Einen Pod an eine bestimmte Reservierung anheften (kein Fallback):


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

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


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

Wählen Sie eine beliebige reservierte Kapazität (ODCR oder Capacity Block) als Ziel aus:


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

Bevorzugen Sie eine reservierte Option, 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 Kapazitätsblöcke verhalten sich unterschiedlich, wenn die Reservierung endet. Stellen Sie sicher, dass Ihre Planungs- und Checkpoint-Strategie der Art der Reservierung entspricht, die Ihren Arbeitsaufwand unterstützt.

ODCRs

Eine Instanz, die in ein ODCR gestartet wird, befindet sich nicht auf unbestimmte Zeit in diesem ODCR. Das ODCR kann ablaufen, storniert werden oder die Instanz kann manuell aus dem ODCR entfernt werden. Wenn einer dieser Fälle auftritt 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 werden weiterhin ohne Unterbrechung ausgeführt.

Anmerkung

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

Kapazitätsblöcke

Im Gegensatz zu ODCRs haben Kapazitätsblöcke immer eine Endzeit, und EC2 beendet Capacity Block-Instances 30 Minuten vor der Endzeit (60 Minuten für UltraServer Instance-Typen). Planen Sie Schulungen und Ableitungen so, dass der Status abgeschlossen ist, oder speichern Sie den Status, bevor das Reservierungsfenster geschlossen wird. Pods, bei denen ein Strict nodeSelector für einen bestimmten capacity-reservation-id Go verwendet wird, Pending sobald der Block abgelaufen ist, und werden nicht an anderer Stelle verschoben. Kombinieren Sie Checkpointing mit dem oben genannten flexiblen Affinitätsmuster, wenn Workloads während des Ablaufs des Kapazitätsblocks auf eine andere Kapazität verlagert werden müssen.

Sie können Reserved Instances bis 30 Minuten vor der Capacity Block-Endzeit für die meisten Instance-Typen oder 60 Minuten vor der Endzeit für UltraServer Instance-Typen verwenden.
EKS Auto Mode und Karpenter beginnen 10 Minuten vor der Beendigung von EC2 präventiv mit der Entleerung von Knoten in einem Kapazitätsblock, sodass Workloads Zeit haben, Checkpoints zu überprüfen und ordnungsgemäß herunterzufahren.

Statische Kapazität NodePools

EKS Auto Mode und Karpenter unterstützen statische Kapazitäten NodePools, wodurch unabhängig von der Arbeitslast 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 setzen. 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. Legen Sie diese limits.nodes Einstellung festreplicas, um eine vorübergehende Skalierung während einer Änderung oder eines Ablaufs des AMI zu ermöglichen.
Für eine vorhersehbare Verteilung der Availability Zone (AZ) sollten Sie eine statische Kapazität NodePool pro AZ erstellen, 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-Automatikmodus 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 verweist auf einen benutzerdefinierten EC2NodeClass Namen my-nodeclass und erstellt ein statisches Objekt NodePool mit 4 Knoten (replicas), das maximal 6 Knoten () sein 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, Trainium-Instances für ein definiertes zukünftiges Fenster zu reservieren P-family . Sie sind im Voraus bezahlt, sodass EKS Auto Mode und Karpenter sie als kostenlos betrachten und ihnen Vorrang vor Spot einräumen. On-Demand Kapazitätsblöcke für ML können eine Reservierungsdauer von 1 bis 14 Tagen oder ein Vielfaches von 7 Tagen haben, also bis zu 182 Tage (6 Monate).

Um Capacity Blocks for ML mit EKS Auto Mode oder Karpenter zu verwenden, konfigurieren Sie die Konfiguration capacityReservationSelectorTerms mit Ihrer Kapazitätsreservierungs-ID in Ihrem. NodeClass Sie können den Abgleich offener Reservierungen nicht mit Capacity Blocks for ML verwenden. Ein Begriff kann eine ID, eine Reihe von Stichwörtern oder Kriterien für die Zuordnung von Instanzen angeben, anhand derer Sie auswählen können. Bei der Angabe von Stichwörtern werden alle Kapazitätsreservierungen ausgewählt, auf die über das Konto mit den passenden Stichwörtern zugegriffen werden kann. Dies kann durch Angabe einer Inhaber-Konto-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 consolidateAfter: Never gesetzt, versucht Karpenter nicht, Knoten zu ersetzen, zusammenzuführen oder zu beenden, um Kosten zu reduzieren oder Workloads effizienter zu packen. Dies wird für Kapazitätsblöcke empfohlen, da die Kapazität bereits im Voraus bezahlt wurde.


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 eineEC2NodeClass, die zusätzlich AMI-, Subnetz- und Sicherheitsgruppen-Selektoren enthält, und erstellen Sie dann einecapacityReservationSelectorTerms, NodePool die diese verwendet.

Wenn consolidateAfter: Never gesetzt, versucht Karpenter nicht, Knoten zu ersetzen, zusammenzuführen oder zu beenden, um Kosten zu reduzieren oder Arbeitslasten effizienter zu packen. Dies wird für Kapazitätsblöcke empfohlen, da die Kapazität bereits im Voraus bezahlt wurde.


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 die Kapazität in einer bestimmten Availability Zone (AZ), ohne dass eine langfristige Bindung besteht. 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 Instances, die von Capacity Blocks for ML nicht unterstützt werden. ODCRs sind im Voraus bezahlt, daher modellieren EKS Auto Mode und Karpenter sie als kostenlos und priorisieren sie vor Spot. On-Demand

ODCRs verhalten sich am Ende der Reservierung anders als Capacity Blocks for ML. Wenn ein ODCR abläuft oder storniert wird, läuft die Instance 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 die Konfiguration capacityReservationSelectorTerms mit Ihren Kapazitätsreservierungsbedingungen in Ihrem. NodeClass Ein Begriff kann eine ID, eine Reihe von Stichwörtern oder Kriterien für die Auswahl einer Instanz angeben. Bei der Angabe von Stichwörtern werden alle Kapazitätsreservierungen ausgewählt, auf die über das Konto mit den passenden Stichwörtern zugegriffen werden kann. Bei der Angabe von Kriterien für die Zuordnung von Instances werden Reservierungen anhand ihres Zuordnungsverhaltens ausgewählt: offen (entspricht allen kompatiblen Instances) oder Targeted (entspricht nur explizit ausgewählten Instances). Dies kann durch Angabe einer Inhaber-Konto-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 Prioritäten setztreserved. 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 zusätzlich eine EC2NodeClass mit AMI-, Subnetz- und Sicherheitsgruppen-Selektoren und erstellen Sie capacityReservationSelectorTerms dann Folgendes: 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 Instances explizit anfordern, indem Sie Ihre einrichtenkarpenter.sh/capacity-type: on-demand. NodePool EKS Auto Mode und Karpenter wählen die Instance mit dem niedrigsten Preis aus, die die Ressourcenanforderungen des Pods erfüllt. Geeignet On-Demand für Entwicklung, Prototyping, unvorhersehbare Inferenzskalierung und für alle Workloads, die sofortige Verfügbarkeit ohne Unterbrechungsrisiko erfordern.

Spot-Instances

Spot bietet Einsparungen von bis zu 90% im Vergleich zur Nutzung On-Demand der EC2-Reservekapazität. AWS kann Spot-Instances mit einer zweiminütigen Unterbrechungsfrist zurückfordern. Maximieren Sie die Verfügbarkeit, indem Sie mehrere Instance-Familien auf der auflisten. NodePool Kombinieren Sie Spot-Workloads in regelmäßigen Abständen mit einem PodDisruptionBudget AND-Checkpoint auf einen dauerhaften Speicher (Amazon S3 oder Amazon EFS), damit die Pods ihren Status während des Ablauffensters speichern können.

Spot eignet sich gut für fehlertolerante, wiederaufladbare Schulungs- und Inferenz-Workloads, bei denen gelegentliche Unterbrechungen im Austausch für erhebliche Kosteneinsparungen akzeptabel sind.

Zu den häufigsten Kandidaten gehören:

Hyperparameter-Tuning und Sweeps: viele kurze, parallele Versuche, die bei einer Unterbrechung wiederholt werden können.
Verteiltes Training mit Checkpointing: Jobs mit langer Laufzeit, bei denen der Status regelmäßig in S3 oder FSx gespeichert wird und nach einem Knotenverlust am letzten Checkpoint wieder aufgenommen werden kann.
Batch- und Offline-Inferenz: groß angelegte Bewertungsaufträge anhand von Datensätzen, bei denen die End-to-End-Latenz in Stunden statt in Sekunden gemessen wird.
Datenvorverarbeitung und Feature-Engineering-Pipelines: parallele Transformationen über große Datensätze.
Modellevaluierung und Benchmarking: wiederholbare Aufgaben, die zu idempotenten Ergebnissen führen.
Entwicklung, Prototyping und Notizbücher: interaktive Experimente, bei denen Benutzer gelegentliche Neustarts tolerieren können.

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

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

EKS Auto Mode

Der EKS-Automatikmodus verarbeitet Spot-Unterbrechungen nativ. Es ist keine SQS-Warteschlange oder kein 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-Unterbrechungen und Rebalance-Empfehlungsereignisse empfängt. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/rebalance-recommendations.html 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 bootstrappeneksctl, geben Sie dies withSpotInterruptionQueue: true in Ihrer Cluster-Konfigurationsdatei ein. eksctlerstellt die SQS-Warteschlange und die EventBridge Regeln und konfiguriert den Karpenter-Controller so, dass er sie verwendet.


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

Sobald der Controller so eingerichtet ist, dass er Ihre Warteschlange verwendet, 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"

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Kapazitätsverwaltung

Verwaltete Knotengruppen und selbstverwaltete Knoten