**Ayude a mejorar esta página** Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página. # Implementación de una carga de trabajo acelerada En este tutorial, se muestra cómo el modo automático de Amazon EKS simplifica el lanzamiento de cargas de trabajo aceleradas por hardware. Con el modo automático, Amazon EKS simplifica las operaciones más allá del propio clúster al automatizar componentes clave de infraestructura, lo que permite contar desde el primer momento con funciones de computación, redes, equilibrio de carga, almacenamiento y administración de identidades y accesos. El modo automático de Amazon EKS incluye los controladores y los complementos de dispositivo necesarios para determinados tipos de instancias, como los controladores NVIDIA y AWS Neuron. No tiene que instalar ni actualizar estos componentes. El modo automático de EKS administra automáticamente los controladores de estos aceleradores: + [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/) + [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/) + [GPU NVIDIA en instancias aceleradas de Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html) **nota** El modo automático de EKS incluye el complemento de dispositivo de NVIDIA para Kubernetes. Este complemento se ejecuta automáticamente y no aparece como un conjunto de daemon en el clúster. Compatibilidad de red adicional: + [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/) Con el modo automático, Amazon EKS elimina el trabajo manual y repetitivo de administrar el controlador del acelerador y el complemento del dispositivo. También puede ahorrar costos al reducir la capacidad del clúster a cero. Puede habilitar el modo automático de EKS para que termine las instancias cuando no haya cargas de trabajo en ejecución. Esto es especialmente útil para cargas de trabajo de inferencia basadas en lotes. A continuación, se muestra un ejemplo de cómo lanzar cargas de trabajo aceleradas con el modo automático de Amazon EKS. ## Requisitos previos + Un clúster de Kubernetes con el modo automático de Amazon EKS configurado. + Una clase de nodo `default` de EKS, tal como se crea al habilitar los grupos de nodos administrados de `general-purpose` o del `system`. ## Paso 1: Implementación de una carga de trabajo de GPU Este ejemplo muestra cómo crear un NodePool para cargas de trabajo basadas en NVIDIA que requieren 45 GB de memoria de GPU. Con el modo automático de EKS, puede usar las restricciones de programación de Kubernetes para especificar los requisitos de instancia. Para implementar el `NodePool` de Amazon EKS en modo automático junto con la `workload` de ejemplo, revise las siguientes definiciones de NodePool y Pod, y guárdelas como `nodepool-gpu.yaml` y `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 ``` Tenga en cuenta que el selector `eks.amazonaws.com/compute-type: auto` requiere que la carga de trabajo se implemente en un nodo de modo automático de Amazon EKS. El NodePool también aplica un taint que solo permite la programación de pods con tolerancias para GPU de NVIDIA. Aplique el NodePool y la carga de trabajo al clúster. ``` kubectl apply -f nodepool-gpu.yaml kubectl apply -f pod.yaml ``` Debería ver los siguientes datos de salida: ``` nodepool.karpenter.sh/gpu configured created pod/nvidia-smi created ``` Espere unos segundos y verifique los nodos del clúster. Ahora debería poder ver un nuevo nodo aprovisionado en el clúster del modo automático de 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 ``` ## Paso 2: Validación Puede observar que el modo automático de Amazon EKS lanzó una instancia `g6e.2xlarge` en lugar de una `g6.2xlarge`, ya que la carga de trabajo requería una instancia con `GPU` l40s, conforme a las siguientes restricciones de programación de Kubernetes: ``` ... nodeSelector: eks.amazonaws.com/instance-gpu-name: l40s ... requests: memory: "30Gi" cpu: "3500m" nvidia.com/gpu: 1 limits: memory: "30Gi" nvidia.com/gpu: 1 ``` A continuación, consulte los registros de los contenedores con el siguiente comando: ``` kubectl logs nvidia-smi ``` Código de salida de ejemplo: ``` +---------------------------------------------------------------------------------------+ | 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 | +---------------------------------------------------------------------------------------+ ``` Puede ver que el contenedor detectó que se ejecuta en una instancia con GPU `NVIDIA` y que no necesitó instalar ningún controlador, ya que el modo automático de Amazon EKS se encarga de ello. ## Paso 3: Limpieza Para deshacerse de todos los objetos creados, utilice `kubectl` para eliminar la implementación de muestra y NodePool para que se termine el nodo: ``` kubectl delete -f nodepool-gpu.yaml kubectl delete -f pod.yaml ``` ## Ejemplo de referencia de NodePools ### Creación de un NodePool de NVIDIA El siguiente NodePool define: + Lance únicamente instancias de las familias `g6e` y `g6` + Consolide los nodos cuando estén vacíos durante 1 hora + El valor de 1 hora en `consolodateAfter` está diseñado para admitir cargas de trabajo con picos y reducir la rotación de nodos. Puede ajustar `consolidateAfter` en función de los requisitos de la carga de trabajo. **Ejemplo de NodePool con una familia de instancias con GPU y consolidación** ``` 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 ``` En lugar de configurar el `eks.amazonaws.com/instance-gpu-name`, puede utilizar `eks.amazonaws.com/instance-family` para especificar la familia de instancias. Para ver otras etiquetas conocidas que influyen en la revisión de la programación, consulte [Etiquetas compatibles con el modo automático de EKS](create-node-pool.md#auto-supported-labels). Cuando existan requisitos específicos de almacenamiento, es posible ajustar los `iops`, el `size` y el `throughput` del almacenamiento efímero de los nodos mediante la creación de una [NodeClass](create-node-class.md) propia, la cual puede ser referenciada desde el NodePool. Más información sobre las [opciones configurables de NodeClass](create-node-class.md). **Ejemplo de configuración de almacenamiento de NodeClass** ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: gpu spec: ephemeralStorage: iops: 3000 size: 80Gi throughput: 125 ``` ### Definición de un NodePool de AWS Trainium y AWS Inferentia El siguiente NodePool cuenta con un conjunto de `eks.amazonaws.com/instance-category` que indica: lanzar únicamente instancias de las familias Inferentia y Trainium. ``` - key: "eks.amazonaws.com/instance-category" operator: In values: - inf - trn ```