**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.
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.
# Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.
Sie können die Bereitstellung von Workloads in [Kapazitätsreservierungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html) steuern. Der automatische EKS-Modus unterstützt On-Demand EC2-Kapazitätsreservierungen (ODCRs), EC2-Kapazitätsblöcke für ML und Unterbrechungsfreie Kapazitätsreservierungen (IODCRs).
**Tipp**
Standardmäßig kann der automatische EKS-Modus offene ODCRs durch Open-Matching aufrufen, priorisiert sie jedoch nicht. Instances, die durch Open-Matching gestartet werden, sind gekennzeichnet, nicht. `karpenter.sh/capacity-type: on-demand` `reserved` Um der ODCR-Nutzung Priorität einzuräumen und Instanzen beschriften zu lassen`karpenter.sh/capacity-type: reserved`, konfigurieren Sie dies `capacityReservationSelectorTerms` in der Definition. NodeClass Kapazitätsblöcke für ML sind immer erforderlich `capacityReservationSelectorTerms` und werden nicht automatisch verwendet.
## On-Demand EC2-Kapazitätsreservierungen (ODCRs)
Mit EC2 On-Demand Capacity Reservations (ODCRs) können Sie Rechenkapazität für Ihre Amazon EC2 EC2-Instances in einer bestimmten Availability Zone für einen beliebigen Zeitraum 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.
In der Standardeinstellung startet EKS Auto Mode automatisch in offenen ODCRs. Durch die Konfiguration `capacityReservationSelectorTerms` auf a können Sie jedoch explizit steuern NodeClass, 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 diese Funktion aktiviert ist, verwendet der automatische EKS-Modus nicht mehr automatisch offene ODCRs. Sie müssen explizit von a ausgewählt werden NodeClass, sodass Sie die Kapazitätsreservierungsnutzung in Ihrem gesamten Cluster genau steuern können.
**Warnung**
*Wenn Sie NodeClass in einem Cluster eine Konfiguration `capacityReservationSelectorTerms` vornehmen, verwendet der automatische EKS-Modus nicht mehr automatisch offene ODCRs für alle ODCRs im Cluster.* NodeClass
### 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 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. 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 gemeinsam genutzte Kapazitäten.
## Bezeichnungen für die Planung von Kapazitätsreservierungen
Wenn Sie `capacityReservationSelectorTerms` auf a konfigurieren, werden Knoten NodeClass, die über Kapazitätsreservierungen bereitgestellt wurden, mit zusätzlichen Bezeichnungen für die Terminplanung gekennzeichnet. Sie können diese Bezeichnungen als NodePool Anforderungen oder als Einschränkungen für die Pod-Planung (z. B. die Knotenaffinität) verwenden, um die Verteilung der Workloads zu steuern.
| Label (Bezeichnung) | Beispiel | Description |
| --- | --- | --- |
| `eks.amazonaws.com/capacity-reservation-id` | `cr-56fac701cc1951b03` | Die ID der Kapazitätsreservierung |
| `eks.amazonaws.com/capacity-reservation-type` | `default` oder `capacity-block` | Die Art der Kapazitätsreservierung |
| `eks.amazonaws.com/capacity-reservation-interruptible` | `true` oder `false` | Ob die Kapazitätsreservierung unterbrechbar ist |
Diese Beschriftungen sind nur auf Knoten mit `karpenter.sh/capacity-type: reserved` vorhanden.
## Reservierungen für unterbrechbare Kapazitäten (IODCRs)
[Unterbrechungsfreie Kapazitätsreservierungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interruptible-capacity-reservations.html) ermöglichen es Ihnen, ungenutzte On-Demand Kapazitätsreservierungskapazitäten mit anderen Workloads innerhalb Ihres Unternehmens zu teilen. Durch die Wiederverwendung ungenutzter Kapazitäten als unterbrechbare ODCRs können Workloads, die für flexible, fehlertolerante Operationen wie Stapelverarbeitung und Datenanalyse geeignet sind, von vorübergehend verfügbarer Kapazität profitieren. Reservierungsbesitzer können ihre Kapazität jederzeit zurückfordern, wohingegen Nutzer von unterbrechbaren ODCRs vor der Kündigung eine Benachrichtigung über die Unterbrechung erhalten, damit der Knoten ordnungsgemäß heruntergefahren oder überprüft werden kann, bevor der Knoten geschlossen wird.
Sie wählen Reservierungen für unterbrechbare Kapazitäten genauso aus wie bei einem `capacityReservationSelectorTerms` Standard-ODCR — nach ID oder nach Tags. Verwenden Sie die Bezeichnung Scheduling, um zu kontrollieren, ob Workloads für unterbrechbare oder für unterbrechungsfreie reservierte Kapazität geplant werden. `eks.amazonaws.com/capacity-reservation-interruptible`
Wenn Kapazität zurückgewonnen wird, erhalten laufende Instances aufgrund von Ereignissen eine zweiminütige Unterbrechungswarnung. EventBridge Nach Ablauf der Kündigungsfrist werden die laufenden Instances in der zurückgewonnenen Kapazität heruntergefahren und beendet. Der automatische EKS-Modus beginnt automatisch mit dem Entladen von Knoten, die aus Reservationen mit unterbrechbarer Kapazität gestartet wurden, sobald die zweiminütige Unterbrechungswarnung eingeht, sodass Ihre Workloads ordnungsgemäß beendet werden können, bevor der Knoten zurückerobert wird.
## EC2-Kapazitätsblöcke für ML
Kapazitätsblöcke für ML reservieren GPU-based beschleunigte Recheninstanzen zu einem future Zeitpunkt, um Ihre kurzfristigen Machine-Learning-Workloads (ML) zu unterstützen. Instances, die innerhalb eines Kapazitätsblocks ausgeführt werden, werden in Amazon EC2 automatisch nahe beieinander platziert 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 [Kapazitätsblöcke für ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) im EC2-Benutzerhandbuch.
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:
1. A NodeClass , das auf Ihre Kapazitätsblock-Reservierung verweist
1. Eine NodePool , die den NodeClass und verwendet, verleiht ihm einen Makel
1. Eine Pod-Spezifikation, die den Taint toleriert und GPU-Ressourcen anfordert
### Ein Beispiel NodeClass
Dies NodeClass verweist anhand seiner 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](create-node-class.md).
### 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 [Erstellen eines Knotenpools für EKS Auto Mode](create-node-pool.md).
### 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 bestimmte GPU-Typen anzusprechen (in diesem Fall H200-GPUs).
+ Es beinhaltet eine **Toleranz** für den `nvidia.com/gpu` Makel, der durch 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](https://kubernetes.io/docs/concepts/workloads/pods/) in der Kubernetes-Dokumentation.
### Verwandte Ressourcen
+ [Kapazitätsblöcke für ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) im Benutzerhandbuch für Amazon-EC2
+ [Kapazitätsblöcke suchen und erwerben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) im Benutzerhandbuch für Amazon-EC2
+ [Reservierungen für unterbrechbare Kapazitäten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interruptible-capacity-reservations.html) im Amazon EC2 EC2-Benutzerhandbuch
+ [Rechenressourcen für AI/ML Workloads auf Amazon EKS verwalten](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [GPU-Ressourcenoptimierung und Kostenmanagement](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) im EKS-Leitfaden für bewährte Verfahren