EC2 Kapazitätsreservierungen auf Abruf (ODCRs)EC2 Kapazitätsblöcke für ML

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.

Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.

Sie können die Bereitstellung von Workloads in Kapazitätsreservierungen steuern. Der automatische EKS-Modus unterstützt EC2 On-Demand-Kapazitätsreservierungen (ODCRs) und EC2 Kapazitätsblöcke für ML.

Tipp

Standardmäßig startet der automatische EKS-Modus automatisch offene Blöcke ODCRs und ML-Kapazitätsblöcke. Bei Verwendung capacityReservationSelectorTerms in der NodeClass Definition verwendet der automatische EKS-Modus nicht mehr automatisch offene Kapazitätsreservierungen.

EC2 Kapazitätsreservierungen auf Abruf (ODCRs)

EC2 Kapazitätsreservierungen auf Abruf (ODCRs) ermöglichen es Ihnen, Rechenkapazität für Ihre EC2 Amazon-Instances in einer bestimmten Availability Zone für einen beliebigen Zeitraum zu reservieren. Bei Verwendung von EKS Auto Mode möchten Sie möglicherweise steuern, ob Ihre Kubernetes-Workloads in diesen reservierten Instances bereitgestellt werden, um die Auslastung der im Voraus erworbenen Kapazität zu maximieren oder um sicherzustellen, dass wichtige Workloads Zugriff auf garantierte Ressourcen haben.

Standardmäßig wird der automatische EKS-Modus automatisch geöffnet ODCRs. Durch die Konfiguration capacityReservationSelectorTerms auf a können Sie NodeClass jedoch explizit steuern, welche ODCRs Workloads verwendet werden. Knoten, die mithilfe von configured bereitgestellt wurden, haben ODCRs Vorrang vor On-Demand-Nodes karpenter.sh/capacity-type: reserved und Spot-Nodes und haben auch weiterhin Priorität. Sobald diese Funktion aktiviert ist, verwendet der automatische EKS-Modus nicht mehr automatisch die Option „Öffnen“ ODCRs. Sie müssen explizit durch ein ausgewählt werden NodeClass, sodass Sie die Kapazitätsreservierungsnutzung in Ihrem gesamten Cluster genau steuern können.

Warnung

Wenn Sie NodeClass in capacityReservationSelectorTerms einem Cluster eine Konfiguration vornehmen, verwendet EKS Auto Mode nicht mehr automatisch open ODCRs für alle NodeClass im Cluster.

Beispiel NodeClass


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
  # Optional: Selects upon on-demand capacity reservations and capacity blocks
  # for EKS Auto Mode to prioritize.
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03
    # Alternative Approaches
    - tags:
        app: "my-app"
      # Optional owning account ID filter
      owner: "012345678901"

Dieses Beispiel NodeClass zeigt zwei Ansätze für die Auswahl ODCRs. Die erste Methode verweist direkt über die ID (cr-56fac701cc1951b03) auf einen bestimmten ODCR. Die zweite Methode verwendet eine Tag-basierte Auswahl, ODCRs wobei das Targeting anhand des Tags Name: "targeted-odcr" erfolgt. Sie können optional auch nach dem AWS Konto filtern, dem die Reservierung gehört. Dies ist besonders nützlich in kontoübergreifenden Szenarien oder bei der Arbeit mit Reservierungen für gemeinsame Kapazitäten.

EC2 Kapazitätsblöcke für ML

Kapazitätsblöcke für ML reservieren GPU-basierte beschleunigte Rechen-Instances für einen zukünftigen Zeitpunkt, um Ihre kurzfristigen Machine-Learning-Workloads (ML) zu unterstützen. Instances, die innerhalb eines Kapazitätsblocks ausgeführt werden, werden innerhalb von Amazon automatisch nahe beieinander platziert EC2 UltraClusters, um blockierungsfreie Netzwerke im Petabit-Bereich mit niedriger Latenz zu gewährleisten.

Weitere Informationen zu den unterstützten Plattformen und Instance-Typen finden Sie unter Capacity Blocks for ML im Benutzerhandbuch. EC2

Sie können einen automatischen EKS-Modus erstellen NodeClass , der einen Kapazitätsblock für ML verwendet, ähnlich einem ODCR (weiter oben beschrieben).

Die folgenden Beispieldefinitionen erstellen drei Ressourcen:

A NodeClass , das auf Ihre Kapazitätsblock-Reservierung verweist
Eine NodePool , die den NodeClass und verwendet, verleiht ihm einen Makel
Eine Pod-Spezifikation, die den Taint toleriert und GPU-Ressourcen anfordert

Beispiel NodeClass

Dies NodeClass verweist anhand seiner Reservierungs-ID auf einen bestimmten Kapazitätsblock für ML. Sie können diese ID von der EC2 Konsole abrufen.


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: gpu
spec:
  # Specify your Capacity Block reservation ID
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03

Weitere Informationen finden Sie unter Knotenklasse für Amazon EKS erstellen.

Beispiel NodePool

Dies NodePool verweist auf die gpu NodeClass und spezifiziert eine wichtige Konfiguration:

Er nutzt auschliesslich reservierte Kapazität, indem er karpenter.sh/capacity-type: reserved festlegt
Es werden bestimmte GPU-Instance-Familien angefordert, die für ML-Workloads geeignet sind
Es wird ein nvidia.com/gpu Taint angewendet, um sicherzustellen, dass nur GPU-Workloads auf diesen Knoten geplant werden


apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: gpu
      requirements:
        - key: eks.amazonaws.com/instance-family
          operator: In
          values:
            - g6
            - p4d
            - p4de
            - p5
            - p5e
            - p5en
            - p6
            - p6-b200
        - key: karpenter.sh/capacity-type
          operator: In
          values:
            - reserved
            # Enable other capacity types
            # - on-demand
            # - spot
      taints:
        - effect: NoSchedule
          key: nvidia.com/gpu

Weitere Informationen finden Sie unter Einen Knotenpool für EKS Auto Mode erstellen.

Beispiel Pod

Dieses Beispiel-Pod veranschaulicht, wie Sie eine Workload für die Ausführung in Ihren Kapazitätsblock-Knoten konfigurieren:

Es verwendet einen NodeSelector, um auf bestimmte GPU-Typen abzuzielen (in diesem Fall H200) GPUs
Es beinhaltet eine Toleranz für den Makel, der durch den nvidia.com/gpu NodePool
Es fordert explizit GPU-Ressourcen unter Verwendung des nvidia.com/gpu-Ressourcentyps an


apiVersion: v1
kind: Pod
metadata:
  name: nvidia-smi
spec:
  nodeSelector:
    # Select specific GPU type - uncomment as needed
    # eks.amazonaws.com/instance-gpu-name: l4
    # eks.amazonaws.com/instance-gpu-name: a100
    eks.amazonaws.com/instance-gpu-name: h200
    # eks.amazonaws.com/instance-gpu-name: b200
    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:
        # Uncomment if needed
        # memory: "30Gi"
        # cpu: "3500m"
        nvidia.com/gpu: 1
      limits:
        # Uncomment if needed
        # memory: "30Gi"
        nvidia.com/gpu: 1
  tolerations:
  - key: nvidia.com/gpu
    effect: NoSchedule
    operator: Exists

Weitere Informationen finden Sie unter Dry run in der Kubernetes-Dokumentation.

Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.

Tipp

EC2 Kapazitätsreservierungen auf Abruf (ODCRs)

Warnung

Beispiel NodeClass

EC2 Kapazitätsblöcke für ML

Beispiel NodeClass

Beispiel NodePool

Beispiel Pod

Verwandte Ressourcen