**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.
# Exécution d’exemples de charges de travail dans des clusters du mode automatique EKS
Ce chapitre fournit des exemples de déploiement de différents types de charges de travail sur des clusters Amazon EKS exécutés en mode automatique. Les exemples illustrent des modèles de charges de travail clés, notamment des exemples d’applications, des applications web avec équilibrage de charge, des charges de travail avec état utilisant du stockage persistant, et des charges de travail nécessitant un placement spécifique des nœuds. Chaque exemple inclut des manifestes complets et des instructions de step-by-step déploiement que vous pouvez utiliser comme modèles pour vos propres applications.
Avant de passer aux exemples, assurez-vous qu'un cluster EKS fonctionne en mode automatique et que vous avez installé la AWS CLI et kubectl. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md). Les exemples présupposent une connaissance de base des concepts Kubernetes et des commandes kubectl.
Vous pouvez utiliser ces exemples basés sur des cas d’utilisation pour exécuter des charges de travail dans des clusters du mode automatique EKS.
[Déploiement d’une charge de travail de gonflement dans un cluster du mode automatique Amazon EKS](automode-workload.md)
Montre comment déployer un exemple de charge de travail sur un cluster du mode automatique EKS à l’aide de commandes `kubectl`.
[Déploiement d’une charge de travail de l’équilibreur de charge en mode automatique EKS](auto-elb-example.md)
Montre comment déployer une version conteneurisée du jeu 2048 sur Amazon EKS.
[Déployer un exemple de charge de travail avec état dans le mode automatique EKS](sample-storage-workload.md)
Montre comment déployer un exemple d’application dynamique sur un cluster du mode automatique EKS.
[Déploiement d’une charge de travail accélérée](auto-accelerated.md)
Montre comment déployer des charges de travail accélérées par le matériel sur des nœuds gérés par le mode automatique EKS.
[Contrôle du déploiement d’une charge de travail sur les nœuds du mode automatique EKS](associate-workload.md)
Montre comment utiliser une annotation pour contrôler si une charge de travail est déployée sur des nœuds gérés par le mode automatique EKS.
# Déploiement d’une charge de travail de gonflement dans un cluster du mode automatique Amazon EKS
Ce tutoriel montre comment déployer une charge de travail d’exemple dans un cluster du mode automatique EKS et observer le provisionnement automatique des ressources de calcul nécessaires. Vous utiliserez des `kubectl` commandes pour observer le comportement du cluster et voir par vous-même comment le mode automatique simplifie les opérations de Kubernetes sur. AWSÀ la fin de ce tutoriel, vous comprendrez comment le mode automatique EKS réagit aux déploiements de charges de travail en gérant automatiquement les ressources de calcul sous-jacentes, sans configuration manuelle de groupes de nœuds.
## Conditions préalables
+ Un cluster du mode automatique Amazon EKS. Notez le nom et AWS la région du cluster.
+ Un principal IAM, tel qu’un utilisateur ou un rôle, disposant d’autorisations suffisantes pour gérer le réseau, le calcul et les ressources EKS.
+ Pour plus d’informations, consultez la section [Création de rôles et attribution de politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) dans le Guide de l’utilisateur IAM.
+ CLI `aws` installée et configurée avec une identité IAM.
+ CLI `kubectl` installée et connectée au cluster.
+ Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
## Étape 1 : consulter les ressources de calcul existantes (facultatif)
Tout d’abord, utilisez `kubectl` pour répertorier les groupes de nœuds de votre cluster.
```
kubectl get nodepools
```
Exemple de résultat :
```
general-purpose
```
Dans ce tutoriel, nous allons déployer une charge de travail configurée pour utiliser le groupe de nœuds `general-purpose`. Ce groupe de nœuds est intégré au mode automatique EKS et propose des valeurs par défaut raisonnables pour des charges générales, comme des microservices et des applications web. Vous pouvez créer votre propre groupe de nœuds. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
Ensuite, utilisez `kubectl` pour répertorier les nœuds connectés à votre cluster.
```
kubectl get nodes
```
Si vous venez de créer un cluster du mode automatique EKS, vous n’aurez aucun nœud.
Dans ce tutoriel, vous allez déployer un exemple de charge de travail. Si vous n’avez aucun nœud ou si la charge de travail ne peut pas être adaptée aux nœuds existants, le mode automatique EKS provisionnera un nouveau nœud.
## Étape 2 : déployer un exemple d’application sur votre cluster
Consultez le déploiement Kubernetes suivant et enregistrez-le sous `inflate.yaml`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
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.
Appliquez le déploiement à votre cluster.
```
kubectl apply -f inflate.yaml
```
## Étape 3 : surveiller les événements Kubernetes
Utilisez la commande suivante pour surveiller les événements Kubernetes, notamment la création d’un nouveau nœud. Utilisez `ctrl+c` pour arrêter la surveillance des événements.
```
kubectl get events -w --sort-by '.lastTimestamp'
```
Utilisez `kubectl` pour répertorier à nouveau les nœuds connectés à votre cluster. Notez le nœud nouvellement créé.
```
kubectl get nodes
```
## Étape 4 : Afficher les nœuds et les instances dans la AWS console
Vous pouvez afficher les nœuds du mode automatique EKS dans la console EKS et les EC2 instances associées dans la EC2 console.
EC2 Les instances déployées par le mode automatique d'EKS sont soumises à des restrictions. Vous ne pouvez pas exécuter de commandes arbitraires sur les nœuds du mode automatique EKS.
## Étape 5 : supprimer le déploiement
Utilisez `kubectl` pour supprimer l’exemple de déploiement
```
kubectl delete -f inflate.yaml
```
Si aucune autre charge de travail n’est déployée sur votre cluster, le nœud créé par le mode automatique EKS sera vide.
Dans la configuration par défaut, le mode automatique EKS détecte les nœuds vides depuis trente secondes et les arrête.
Utilisez `kubectl` la EC2 console pour confirmer que l'instance associée a été supprimée.
# Déploiement d’une charge de travail de l’équilibreur de charge en mode automatique EKS
Ce guide explique comment déployer une version conteneurisée du jeu 2048 sur Amazon EKS, avec équilibreur de charge et accès Internet.
## Prérequis
+ Un cluster du mode automatique EKS
+ `kubectl` configuré pour interagir avec votre cluster
+ Autorisations IAM nécessaires pour créer des ressources ALB
## Étape 1 : créer l’espace de noms
Créez d’abord un espace de noms dédié pour l’application de jeu 2048.
Créez un fichier nommé `01-namespace.yaml`:
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
Appliquez la configuration de l’espace de noms :
```
kubectl apply -f 01-namespace.yaml
```
## Étape 2 : déployer l’application
L’application exécute plusieurs réplicas du conteneur du jeu 2048.
Créez un fichier nommé `02-deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**Note**
Si vous recevez une erreur lors du chargement de l’image `public.ecr.aws/l6m2t8p7/docker-2048:latest`, vérifiez que votre rôle IAM de nœud possède les autorisations nécessaires pour extraire les images depuis ECR. Pour de plus amples informations, consultez [Rôle IAM de nœud](auto-learn-iam.md#auto-learn-node-iam-role). De plus, l’image `docker-2048` utilisée dans l’exemple est une image `x86_64` et ne fonctionnera pas sur d’autres architectures.
**Composants clés :**
+ Déploiement de 5 réplicas de l’application
+ Utilisation d’une image ECR publique
+ Demande de 0,5 cœur de processeur par pod
+ Exposition du port 80 pour le trafic HTTP
Appliquez le déploiement :
```
kubectl apply -f 02-deployment.yaml
```
## Étape 3 : créer le service
Le service expose le déploiement au réseau du cluster.
Créez un fichier nommé `03-service.yaml`:
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**Composants clés :**
+ Création d’un service NodePort
+ Mappage du port 80 vers le port 80 du conteneur
+ Utilisation d’un sélecteur d’étiquettes pour cibler les pods
Appliquez le service :
```
kubectl apply -f 03-service.yaml
```
## Étape 4 : configurer l’équilibrage de charge
Vous allez configurer un objet Ingress pour exposer l’application sur Internet.
Commencez par créer la `IngressClass`. Créez un fichier nommé `04-ingressclass.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**Note**
Le mode automatique EKS nécessite l’ajout de balises sur les sous-réseaux afin d’identifier les sous-réseaux publics et privés.
Si vous avez créé votre cluster avec `eksctl`, ces balises sont déjà présentes.
Découvrez comment [Baliser les sous-réseaux pour le mode automatique EKS](tag-subnets-auto.md).
Créez ensuite la ressource Ingress. Créez un fichier nommé `05-ingress.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**Composants clés :**
+ Création d’un ALB orienté Internet
+ Utilisation du type de cible IP pour un routage direct vers les pods
+ Routage de tout le trafic (/) vers le service du jeu
Appliquez les configurations Ingress :
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## Étape 5 : vérifier le déploiement
1. Vérifiez que tous les pods sont en cours d’exécution :
```
kubectl get pods -n game-2048
```
1. Vérifiez que le service a été créé :
```
kubectl get svc -n game-2048
```
1. Obtenez le point de terminaison de l’ALB :
```
kubectl get ingress -n game-2048
```
Le champ ADDRESS dans le résultat Ingress affiche le point de terminaison de votre ALB. Attendez 2 à 3 minutes pour que l’ALB soit entièrement provisionné et enregistre toutes les cibles.
## Étape 6 : accéder au jeu
Ouvrez votre navigateur web et accédez à l’URL du point de terminaison de l’ALB obtenue à l’étape précédente. L’interface du jeu 2048 devrait s’afficher.
## Étape 7 : nettoyage
Pour supprimer toutes les ressources créées dans ce tutoriel :
```
kubectl delete namespace game-2048
```
Cela supprimera toutes les ressources de l’espace de noms, y compris les ressources Déploiement, Service et Ingress.
## Ce qui se passe dans les coulisses
1. Le déploiement crée 5 pods exécutant le jeu 2048
1. Le service fournit un accès réseau stable à ces pods
1. Mode automatique EKS :
+ Crée un équilibreur de charge Application Load Balancer dans AWS
+ Configure les groupes cibles pour les pods
+ Définit les règles de routage pour transmettre le trafic au service
## Résolution des problèmes
Si le jeu ne se charge pas :
+ Assurez-vous que tous les pods sont en cours d’exécution : `kubectl get pods -n game-2048`
+ Vérifiez l’état de la ressource Ingress : `kubectl describe ingress -n game-2048`
+ Vérifiez la surveillance de l’état de l’ALB : consultez l’état du groupe cible dans la console AWS
# Déployer un exemple de charge de travail avec état dans le mode automatique EKS
Ce tutoriel vous guidera dans le déploiement d’un exemple d’application avec état dans votre cluster du mode automatique EKS. L’application écrit des horodatages dans un volume persistant, démontrant ainsi les capacités de provisionnement et de persistance automatiques des volumes EBS du mode automatique EKS.
## Prérequis
+ Un cluster du mode automatique EKS
+ L’interface AWS CLI configurée avec les autorisations appropriées
+ `kubectl` installé et configuré
+ Pour de plus amples informations, consultez [Configuration pour utiliser Amazon EKS](setting-up.md).
## Étape 1 : configurer votre environnement
1. Définissez vos variables d’environnement :
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. Mettez à jour votre kubeconfig :
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## Étape 2 : créer la classe de stockage
La `StorageClass` définit la manière dont le mode automatique EKS provisionnera les volumes EBS.
Le mode automatique EKS ne crée pas de `StorageClass` pour vous. Vous devez créer une `StorageClass` faisant référence à `ebs.csi.eks.amazonaws.com` pour utiliser les fonctionnalités de stockage du mode automatique EKS.
1. Créez un fichier nommé `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. Appliquez le `StorageClass` :
```
kubectl apply -f storage-class.yaml
```
**Composants clés :**
+ `provisioner: ebs.csi.eks.amazonaws.com` : utilise le mode automatique EKS
+ `volumeBindingMode: WaitForFirstConsumer` : retarde la création du volume jusqu’à ce qu’un pod en ait besoin
+ `type: gp3` : spécifie le type de volume EBS
+ `encrypted: "true"` : EBS utilisera la clé `aws/ebs` par défaut pour activer le chiffrement sur les volumes créés avec cette classe. Cette action est facultative, mais recommandée.
+ `storageclass.kubernetes.io/is-default-class: "true"` : Kubernetes utilisera cette classe de stockage par défaut, à moins que vous ne spécifiiez une autre classe de volume dans une demande de volume persistant. Soyez prudent lorsque vous définissez cette valeur si vous migrez depuis un autre contrôleur de stockage. (facultatif)
## Étape 3 : créer la revendication de volume persistant
La PVC demande du stockage à la `StorageClass`.
1. Créez un fichier nommé `pvc.yaml`:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. Appliquez le PVC :
```
kubectl apply -f pvc.yaml
```
**Composants clés :**
+ `accessModes: ReadWriteOnce` : le volume peut être monté par un nœud à la fois
+ `storage: 8Gi` : demande un volume de 8 Gio
+ `storageClassName: auto-ebs-sc` : fait référence à la `StorageClass` que nous avons créée
## Étape 4 : déployer l’application
Le déploiement exécute un conteneur qui écrit des horodatages sur le volume persistant.
1. Créez un fichier nommé `deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. Appliquez le déploiement :
```
kubectl apply -f deployment.yaml
```
**Composants clés :**
+ Conteneur bash simple qui écrit des horodatages dans un fichier
+ Monte le PVC à `/data`
+ Demande 1 cœur de processeur
+ Utilise le sélecteur de nœuds pour les nœuds gérés par EKS
## Étape 5 : vérifier la configuration
1. Vérifiez que le pod est en cours d’exécution :
```
kubectl get pods -l app=inflate-stateful
```
1. Vérifiez que le PVC est lié :
```
kubectl get pvc auto-ebs-claim
```
1. Vérifiez le volume EBS :
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. Vérifiez que les données sont écrites :
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## Étape 6 : nettoyage
Exécutez la commande suivante pour supprimer toutes les ressources créées dans ce tutoriel :
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## Ce qui se passe dans les coulisses
1. Le PVC demande du stockage à la `StorageClass`
1. Lorsque le pod est planifié :
1. Le mode automatique EKS provisionne un volume EBS
1. Crée un PersistentVolume
1. Attache le volume au nœud
1. Le pod monte le volume et commence à écrire les horodatages
## Contrôleur d’instantané
Le mode automatique EKS est compatible avec le Kubernetes CSI Snapshotter, également appelé contrôleur d’instantané. Cependant, le mode automatique EKS n’inclut pas le contrôleur d’instantané. Vous êtes responsable de l’installation et de la configuration du contrôleur d’instantané. Pour de plus amples informations, consultez [Activer la fonctionnalité d’instantané pour les volumes CSI](csi-snapshot-controller.md).
Veuillez consulter la classe `VolumeSnapshotClass` suivante qui fait référence à la capacité de stockage du mode automatique EKS.
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[En savoir plus sur le contrôleur de snapshots CSI Kubernetes.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# 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
```