**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. Le mode automatique Amazon EKS simplifie les opérations au-delà du cluster lui-même en automatisant les composants clés de l’infrastructure qui fournissent des capacités de calcul, de mise en réseau, d’équilibrage de charge, de stockage et de gestion des identités et des accès dès leur installation.
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/)
+ [Instances EC2 accélérées NVIDIA GPUs sur Amazon](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/)
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 odeur qui permet uniquement de planifier des pods avec des tolérances GPUs pour 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 que le mode automatique Amazon EKS a lancé un `g6e.2xlarge` plutôt qu’un `g6.2xlarge` autonome, car la charge de travail nécessitait une instance avec un `GPU` L40S, 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, consultez les journaux des conteneurs 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 : nettoyer
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 un 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 de 1 heure pour `consolodateAfter` prend en charge des charges de travail irrégulières et réduit le roulement 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 directement le paramètre `eks.amazonaws.com/instance-gpu-name`, vous pouvez 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éfinition d'un AWS trainium et AWS d'une inférence 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
```