Déploiement d’une charge de travail accélérée - Amazon EKS
PrérequisÉtape 1 : déployer une charge de travail GPUÉtape 2 : validerÉtape 3 : nettoyerExemple de référence NodePools

Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.

Déploiement d’une charge de travail accélérée

Ce tutoriel présente comment le mode automatique Amazon EKS simplifie le lancement de charges de travail accélérées. 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ériques 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 :

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 :

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.

Prérequis

  • 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 des charges de travail basées sur NVIDIA, nécessitant 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 NodePool en mode automatique Amazon EKS et l’exemple de workload, consultez les définitions suivantes et 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. Le NodePool définit également un rejet qui permet uniquement aux pods ayant des tolérances pour les GPU NVIDIA d’être planifiés.

Appliquez le NodePool et la charge de travail à 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 afin de supprimer le déploiement exemple et le NodePool, ce qui entraînera l’arrêt du nœud :

kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml

Exemple de référence NodePools

Création d’un NodePool NVIDIA

Le NodePool ci-dessous définit les paramètres suivants :

  • 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 de NodePool avec famille d’instances GPU et 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.

Si vous avez des exigences de stockage spécifiques, vous pouvez ajuster la capacité de stockage éphémère des nœuds iops, size et throughput en créant votre propre NodeClass à référencer dans le NodePool. Pour en savoir plus, consultez les options configurables de NodeClass.

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 NodePool AWS Trainium et AWS Inferentia

Le NodePool suivant contient un paramètre eks.amazonaws.com/instance-category indiquant de lancer uniquement des instances des familles Inferentia et Trainium :

        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values:
            - inf
            - trn