Unterstützung für die Verbesserung dieser Seite beitragen

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

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

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

EC2-On-Demand-Kapazitätsreservierungen (ODCRs)

EC2-Kapazitätsreservierungen ermöglichen Ihnen das Reservieren von Datenverarbeitungskapazität für Ihre Amazon-EC2-Instances in einer bestimmten Availability Zone für eine beliebige Dauer. 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.

In der Standardeinstellung startet EKS Auto Mode automatisch in offenen ODCRs. Durch die Konfiguration von capacityReservationSelectorTerms in einer NodeClass können Sie jedoch explizit steuern, welche ODCRs Ihre Workloads verwenden. Knoten, die mit konfigurierten ODCRs bereitgestellt werden, verfügen über karpenter.sh/capacity-type: reserved und werden gegenüber On-Demand- und Spot-Knoten priorisiert. Sobald dieses Feature aktiviert ist, verwendet EKS Auto Mode nicht mehr automatisch offene ODCRs – diese müssen explizit von einer NodeClass ausgewählt werden, sodass Sie die Nutzung der Kapazitätsreservierungen in Ihrem Cluster präzise steuern können.

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 einer NodeClass demonstriert zwei Ansätze zur Auswahl von ODCRs. Die erste Methode verweist direkt über die ID (cr-56fac701cc1951b03) auf einen bestimmten ODCR. Die zweite Methode verwendet eine tagbasierte Auswahl und zielt auf ODCRs mit dem Tag Name: "targeted-odcr" ab. Optional können Sie 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 gemeinsam genutzten Kapazitätsreservierungen.

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 automatisch nah beieinander in Amazon EC2 UltraClusters platziert, um ein nicht blockierendes, Petabit-fähiges Netzwerk mit geringer Latenz zu erhalten.

Weitere Informationen zu den unterstützten Plattformen und Instance-Typen finden Sie unter Kapazitätsblöcke für ML im EC2-Benutzerhandbuch.

Sie können eine EKS-Auto-Mode-NodeClass erstellen, die einen Kapazitätsblock für ML verwendet, ähnlich wie ein ODCR (wie zuvor beschrieben).

Die folgenden Beispieldefinitionen erstellen drei Ressourcen:

Beispiel NodeClass

Diese NodeClass verweist anhand ihrer Reservierungs-ID auf einen bestimmten Kapazitätsblock für ML. Sie können diese ID über die 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

Dieser NodePool verweist auf die gpu NodeClass und legt wichtige Konfigurationen fest:

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:

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.

Verwandte Ressourcen