**Aidez à améliorer cette page**
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Contrôle du déploiement des charges de travail dans les réserves de capacité avec le mode automatique EKS
Vous pouvez contrôler le déploiement des charges de travail dans des [réserves de capacité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). Le mode automatique EKS prend en charge les réserves de capacité à la demande (On-Demand Capacity Reservation, ODCR) EC2 ainsi que les blocs de capacité EC2 pour le ML.
**Astuce**
Par défaut, le mode automatique d'EKS peut être lancé en mode ouvert ODCRs par le biais d'une correspondance ouverte, mais il ne les priorise pas. Les instances lancées par le biais d'une correspondance ouverte sont étiquetées`karpenter.sh/capacity-type: on-demand`, non`reserved`. Pour hiérarchiser l'utilisation de l'ODCR et étiqueter les instances`karpenter.sh/capacity-type: reserved`, configurez `capacityReservationSelectorTerms` dans la NodeClass définition. Les blocs de capacité pour le ML nécessitent toujours `capacityReservationSelectorTerms` et ne sont pas utilisés automatiquement.
## Réservations de capacité à la demande EC2 () ODCRs
Les réserves de capacité à la demande (ODCR) EC2 permettent de réserver de la capacité de calcul pour vos instances Amazon EC2 dans une zone de disponibilité spécifique, pour toute durée souhaitée. Lorsque vous utilisez le mode automatique EKS, vous pouvez vouloir contrôler le déploiement de vos charges de travail Kubernetes sur ces instances réservées afin de maximiser l’utilisation de la capacité préachetée ou garantir l’accès des charges de travail critiques à des ressources dédiées.
Par défaut, le mode automatique EKS démarre automatiquement en mode ouvert ODCRs. Cependant, en configurant `capacityReservationSelectorTerms` sur un NodeClass, vous pouvez contrôler explicitement les charges de travail utilisées par ODCRs vos charges de travail. Les nœuds approvisionnés à l'aide de la configuration ODCRs auront `karpenter.sh/capacity-type: reserved` et seront priorisés par rapport à la demande et au spot. Une fois cette fonctionnalité activée, le mode automatique d'EKS n'utilisera plus automatiquement les options ouvertes. ODCRs Elles doivent être explicitement sélectionnées par un NodeClass, ce qui vous permet de contrôler précisément l'utilisation des réservations de capacité au sein de votre cluster.
**Avertissement**
Si vous effectuez une configuration `capacityReservationSelectorTerms` NodeClass dans un cluster, le mode automatique d'EKS n'utilisera plus automatiquement l'option open ODCRs pour *aucun* NodeClass élément du cluster.
### Exemple 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"
```
Cet exemple NodeClass illustre deux approches de sélection ODCRs. La première méthode fait référence directement à une ODCR spécifique à l’aide de son ID (`cr-56fac701cc1951b03`). La seconde méthode utilise la sélection basée sur les balises, le ciblage à l' ODCRs aide de la balise`Name: "targeted-odcr"`. Vous pouvez également éventuellement filtrer en fonction du AWS compte propriétaire de la réservation, ce qui est particulièrement utile dans les scénarios entre comptes ou lorsque vous travaillez avec des réservations à capacité partagée.
## Blocs de capacité EC2 pour ML
Les blocs de capacité pour ML vous permettent de réserver à l’avance des instances de calcul accéléré basées sur GPU pour exécuter des charges de travail de machine learning (ML) de courte durée. Les instances qui s'exécutent au sein d'un bloc de capacité sont automatiquement placées à proximité les unes des autres dans Amazon EC2 UltraClusters, pour une mise en réseau non bloquante à faible latence, à l'échelle du pétabit.
Pour plus d’informations sur les plateformes et les types d’instances pris en charge, consultez [Blocs de capacité ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) dans le Guide de l’utilisateur EC2.
Vous pouvez créer un mode automatique EKS NodeClass qui utilise un bloc de capacité pour le ML, similaire à un ODCR (décrit précédemment).
Les exemples de définitions suivants créent trois ressources :
1. A NodeClass qui fait référence à votre réservation Capacity Block
1. Un NodePool qui utilise le NodeClass et applique une teinte
1. Une spécification de pod tolérant cette balise de rejet et demandant des ressources GPU
### Exemple NodeClass
Cela NodeClass fait référence à un bloc de capacité spécifique pour ML par son ID de réservation. Vous pouvez obtenir cet ID dans la console EC2.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Pour de plus amples informations, veuillez consulter [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
### Exemple NodePool
Cela NodePool fait référence à la configuration importante `gpu` NodeClass et précise :
+ Il utilise **uniquement** la capacité réservée en définissant `karpenter.sh/capacity-type: reserved`
+ Il demande des familles d’instances GPU spécifiques adaptées aux charges de travail ML
+ Il applique une balise de rejet `nvidia.com/gpu` pour s’assurer que seules les charges de travail GPU sont planifiées sur ces nœuds
```
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
```
Pour de plus amples informations, veuillez consulter [Création d’un pool de nœuds pour le mode automatique EKS](create-node-pool.md).
### Exemple de pod
Cet exemple de pod montre comment configurer une charge de travail afin qu’elle s’exécute sur vos nœuds de bloc de capacité :
+ Il utilise un **NodeSelector** pour cibler des types de GPU spécifiques (dans ce cas, le H200) GPUs
+ Il inclut une **tolérance à l'égard de** la `nvidia.com/gpu` souillure appliquée par le NodePool
+ Il **demande explicitement des ressources GPU** en utilisant le type de ressource `nvidia.com/gpu`
```
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
```
Pour plus d'informations, consultez [pods](https://kubernetes.io/docs/concepts/workloads/pods/) dans la documentation Kubernetes.
### Ressources connexes
+ [Blocs de capacité pour ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) dans le Guide de l’utilisateur Amazon EC2
+ [Trouver et acheter des blocs de capacité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) dans le Guide de l’utilisateur Amazon EC2
+ [Gérez les ressources informatiques pour les AI/ML charges de travail sur Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [Optimisation et gestion des coûts des ressources GPU](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) dans le Guide des bonnes pratiques EKS