**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.
# Déploiement d’une charge de travail accélérée
Ce didacticiel montre comment le mode automatique d'Amazon EKS simplifie le lancement de charges de travail accélérées par le matériel. Amazon EKS Auto Mode rationalise les opérations au-delà du cluster lui-même en automatisant les principaux composants de l'infrastructure en fournissant des fonctionnalités de calcul, de mise en réseau, d'équilibrage de charge, de stockage et d'Identity and Access Management prêtes à l'emploi.
Le mode automatique Amazon EKS inclut les pilotes et les plug-ins de périphérique requis pour certains types d'instances, tels que les pilotes NVIDIA et AWS Neuron. Vous n’avez pas à installer ni à mettre à jour ces composants.
Le mode automatique EKS gère automatiquement les pilotes pour les accélérateurs suivants :
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inférentie](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [GPU NVIDIA sur les instances accélérées Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**Note**
Le mode automatique EKS inclut le plug-in de périphérique NVIDIA pour Kubernetes. Ce plug-in s’exécute automatiquement et n’est pas visible comme un ensemble de démons dans votre cluster.
Prise en charge du réseautage supplémentaire :
+ [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/) — Pour plus d'informations sur la gestion des appareils EFA dans votre cluster EKS, consultez. [Gérez les appareils EFA sur Amazon EKS](device-management-efa.md)
Le mode automatique Amazon EKS élimine les tâches fastidieuses liées à la gestion des pilotes d’accélérateurs et des plug-ins de périphériques.
Vous pouvez également bénéficier d’économies, car le cluster peut être mis à l’échelle jusqu’à zéro. Il est possible de configurer le mode automatique EKS pour arrêter les instances lorsqu’aucune charge de travail n’est en cours d’exécution. Cela est utile pour les charges de travail d’inférence basées sur des lots.
La section suivante présente un exemple de lancement de charges de travail accélérées avec le mode automatique Amazon EKS.
## Conditions préalables
+ Un cluster Kubernetes avec le mode automatique Amazon EKS configuré.
+ Une classe de nœuds `default` EKS est créée lorsque les groupes de nœuds gérés `general-purpose` ou `system` sont activés.
## Étape 1 : déployer une charge de travail GPU
Dans cet exemple, vous allez créer un NodePool pour les charges de travail basées sur NVIDIA qui nécessitent 45 Go de mémoire GPU. Avec le mode automatique EKS, vous utilisez les contraintes de planification Kubernetes pour définir vos exigences d’instance.
Pour déployer le mode automatique Amazon EKS `NodePool` et l'exemple`workload`, consultez les informations suivantes NodePool et la définition du pod, puis enregistrez-les sous `nodepool-gpu.yaml` et `pod.yaml` :
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
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:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Notez que le sélecteur `eks.amazonaws.com/compute-type: auto` nécessite que la charge de travail soit déployée sur un nœud du mode automatique Amazon EKS. Cela crée NodePool également une impression qui n'autorise la planification que des pods avec des tolérances pour les GPU Nvidia.
Appliquez la charge de travail NodePool et à votre cluster.
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
Vous devriez voir la sortie suivante :
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
Attendez quelques secondes, puis vérifiez les nœuds de votre cluster. Vous devriez voir un nouveau nœud provisionné dans votre cluster du mode automatique Amazon EKS :
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## Étape 2 : valider
Vous pouvez constater qu'Amazon EKS Auto Mode a été lancé au `g6e.2xlarge` lieu d'un `g6.2xlarge` car la charge de travail nécessitait une instance avec des l40s`GPU`, conformément aux contraintes de planification Kubernetes suivantes :
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
Maintenant, examinez les journaux du conteneur en exécutant la commande suivante :
```
kubectl logs nvidia-smi
```
Exemple de sortie :
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
Vous pouvez constater que le conteneur a détecté qu’il s’exécute sur une instance dotée d’un GPU `NVIDIA` et que vous n’avez pas eu à installer de pilote de périphérique, car cela est géré par le mode automatique Amazon EKS.
## Étape 3 : Clean-up
Pour supprimer tous les objets créés, utilisez `kubectl` pour supprimer l'exemple de déploiement NodePool afin de mettre fin au nœud :
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## Exemple de NodePools référence
### Créez une carte NVIDIA NodePool
Les définitions suivantes sont NodePool les suivantes :
+ Lancement uniquement d’instances des familles `g6e` et `g6`
+ Consolidation des nœuds lorsqu’ils restent vides pendant 1 heure
+ La valeur d'une heure pour `consolidateAfter` prend en charge les charges de travail élevées et réduit le taux de désabonnement des nœuds. Vous pouvez ajuster `consolidateAfter` selon les exigences de votre charge de travail.
**Exemple NodePool de famille d'instances GPU et de consolidation**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
Au lieu de définir le, `eks.amazonaws.com/instance-gpu-name` vous pouvez l'utiliser `eks.amazonaws.com/instance-family` pour spécifier la famille d'instances. Pour consulter d’autres étiquettes courantes influençant la planification, consultez [Étiquettes prises en charge par le mode automatique EKS](create-node-pool.md#auto-supported-labels).
Si vous avez des besoins de stockage spécifiques, vous pouvez ajuster le stockage `iops` éphémère des nœuds `size` et `throughput` en créant le vôtre [NodeClass](create-node-class.md)à référencer dans le. NodePool En savoir plus sur les [ NodeClass options configurables](create-node-class.md).
**Exemple de configuration de stockage pour NodeClass**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### Définissez un AWS Trainium et AWS Inférentie NodePool
Ce qui suit NodePool contient un `eks.amazonaws.com/instance-category` ensemble qui indique de ne lancer que les instances de la famille Inferentia et Trainium :
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```