**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.
# Ejecución de cargas de trabajo de muestra en clústeres del modo automático de EKS
En este capítulo se ofrecen ejemplos de cómo implementar diferentes tipos de cargas de trabajo en clústeres de Amazon EKS que se ejecutan en modo automático. Los ejemplos muestran patrones clave de cargas de trabajo, como aplicaciones de muestra, aplicaciones web con equilibrio de carga, cargas de trabajo con estado que utilizan almacenamiento persistente y cargas de trabajo con requisitos específicos de ubicación de nodos. Cada ejemplo incluye manifiestos completos e instrucciones de implementación paso a paso que se pueden utilizar como plantillas para aplicaciones propias.
Antes de continuar con los ejemplos, asegúrese de que tiene un clúster de EKS en ejecución en modo automático y que ha instalado AWS CLI y kubectl. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md). Los ejemplos presuponen cierta familiaridad con los conceptos de Kubernetes y los comandos kubectl.
Puede utilizar estas muestras basadas en casos de uso para ejecutar cargas de trabajo en clústeres del modo automático de EKS.
[Implementación de una carga de trabajo de expansión de muestra en un clúster del modo automático de Amazon EKS](automode-workload.md)
Muestra cómo implementar una carga de trabajo de muestra en un clúster de modo automático de EKS mediante comandos `kubectl`.
[Implementación de una carga de trabajo de equilibrador de carga de muestra en el modo automático de EKS](auto-elb-example.md)
Muestra cómo implementar una versión en contenedores del videojuego 2048 en Amazon EKS.
[Implementación de una carga de trabajo con estado de ejemplo en el modo automático de EKS](sample-storage-workload.md)
Muestra cómo implementar una aplicación con estado de muestra en un clúster del modo automático de EKS.
[Implementación de una carga de trabajo acelerada](auto-accelerated.md)
Muestra cómo implementar cargas de trabajo aceleradas por hardware en nodos administrados por el modo automático de EKS.
[Cómo controlar si una carga de trabajo se implementa en nodos del modo automático de EKS](associate-workload.md)
Muestra cómo utilizar una anotación para controlar si una carga de trabajo se implementa en nodos administrados por el modo automático de EKS.
# Implementación de una carga de trabajo de expansión de muestra en un clúster del modo automático de Amazon EKS
En este tutorial, aprenderá a implementar una carga de trabajo de muestra en un clúster del modo automático de EKS y observará cómo se aprovisionan automáticamente los recursos de computación necesarios. Utilizará comandos `kubectl` para observar el comportamiento del clúster y comprobar de primera mano la forma en que el modo automático simplifica las operaciones de Kubernetes en AWS. Al final de este tutorial, comprenderá la forma en que el modo automático de EKS responde a las implementaciones de cargas de trabajo mediante la administración automática de los recursos de computación subyacentes, sin necesidad de configurar manualmente los grupos de nodos.
## Requisitos previos
+ Un clúster del modo automático de Amazon EKS. Anote el nombre y la región de AWS del clúster.
+ Una entidad principal de IAM, como un usuario o rol, con permisos suficientes para administrar recursos de red, computación y EKS.
+ Para obtener más información, consulte [Cómo crear roles y asociar políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) en la Guía del usuario de IAM.
+ `aws` CLI instalada y configurada con una identidad de IAM.
+ `kubectl` CLI instalada y conectada al clúster.
+ Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
## Paso 1: Revisión de los recursos de computación existentes (opcional)
En primer lugar, utilice `kubectl` para enumerar los grupos de nodos en el clúster.
```
kubectl get nodepools
```
Resultado de ejemplo:
```
general-purpose
```
En este tutorial, implementaremos una carga de trabajo configurada para utilizar el grupo de nodos `general-purpose`. Este grupo de nodos está integrado en el modo automático de EKS e incluye valores predeterminados razonables para cargas de trabajo generales, como microservicios y aplicaciones web. Puede crear un grupo de nodos propio. Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
En segundo lugar, utilice `kubectl` para enumerar los nodos conectados al clúster.
```
kubectl get nodes
```
Si acaba de crear un clúster de modo automático de EKS, no tendrá nodos.
En este tutorial, implementará una carga de trabajo de ejemplo. Si no tiene nodos, o la carga de trabajo no cabe en los nodos existentes, el modo automático de EKS aprovisionará un nuevo nodo.
## Paso 2: Implementación de una aplicación de ejemplo en el clúster
Revise la siguiente implementación de Kubernetes y guárdela como `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
```
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.
Aplique la implementación al clúster.
```
kubectl apply -f inflate.yaml
```
## Paso 3: Visualización de los eventos de Kubernetes
Utilice el siguiente comando para ver los eventos de Kubernetes, incluida la creación de un nuevo nodo. Utilice `ctrl+c` para dejar de ver los eventos.
```
kubectl get events -w --sort-by '.lastTimestamp'
```
Utilice `kubectl` para enumerar los nodos conectados al clúster nuevamente. Tenga en cuenta el nodo recién creado.
```
kubectl get nodes
```
## Paso 4: Visualización de nodos e instancias en la consola de AWS
Puede ver los nodos de modo automático de EKS en la consola de EKS, y las instancias de EC2 asociadas en la consola de EC2.
Las instancias de EC2 implementadas por el modo automático de EKS están restringidas. No se pueden ejecutar comandos arbitrarios en los nodos del modo automático de EKS.
## Paso 5: Eliminación de la implementación
Utilice `kubectl` para eliminar la implementación de muestra
```
kubectl delete -f inflate.yaml
```
Si no tiene otras cargas de trabajo implementadas en el clúster, el nodo creado por el modo automático de EKS estará vacío.
En la configuración predeterminada, el modo automático de EKS detecta los nodos que han estado vacíos durante treinta segundos y los termina.
Utilice `kubectl` o la consola de EC2 para confirmar que la instancia asociada se ha eliminado.
# Implementación de una carga de trabajo de equilibrador de carga de muestra en el modo automático de EKS
En esta guía se explica cómo implementar una versión en contenedores del videojuego 2048 en Amazon EKS, con equilibrio de carga y accesibilidad a Internet.
## Requisitos previos
+ Un clúster de modo automático de EKS
+ `kubectl` configurado para interactuar con el clúster
+ Permisos de IAM adecuados para crear recursos del equilibrador de carga de aplicaciones
## Paso 1: Creación del espacio de nombres
En primer lugar, cree un espacio de nombres dedicado para la aplicación del videojuego 2048.
Cree un archivo denominado `01-namespace.yaml`:
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
Aplique la configuración del espacio de nombres:
```
kubectl apply -f 01-namespace.yaml
```
## Paso 2: Implementación de la aplicación
La aplicación ejecuta varias réplicas del contenedor del videojuego 2048.
Cree un archivo denominado `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"
```
**nota**
Si obtiene un error al cargar la imagen `public.ecr.aws/l6m2t8p7/docker-2048:latest`, confirme que el rol de IAM del nodo tenga los permisos suficientes para extraer imágenes de ECR. Para obtener más información, consulte [Rol de IAM de nodo](auto-learn-iam.md#auto-learn-node-iam-role). Además, la imagen `docker-2048` del ejemplo es una imagen `x86_64` y no se ejecutará en otras arquitecturas.
**Componentes principales:**
+ Implementa 5 réplicas de la aplicación
+ Utiliza una imagen de ECR pública
+ Solicita 0,5 núcleos de CPU por pod
+ Expone el puerto 80 para el tráfico HTTP
Aplique la implementación:
```
kubectl apply -f 02-deployment.yaml
```
## Paso 3: Creación del servicio
El servicio expone la implementación a la red del clúster.
Cree un archivo denominado `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
```
**Componentes principales:**
+ Crea un servicio NodePort
+ Asigna el puerto 80 al puerto 80 del contenedor
+ Utiliza el selector de etiquetas para encontrar pods
Aplique el servicio:
```
kubectl apply -f 03-service.yaml
```
## Paso 4: Configuración del equilibrio de carga
Configurará un ingreso para exponer la aplicación a Internet.
Primero, cree la `IngressClass`. Cree un archivo denominado `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
```
**nota**
El modo automático de EKS requiere etiquetas de subred para identificar las subredes públicas y privadas.
Si creó el clúster con `eksctl`, ya dispone de estas etiquetas.
Aprenda cómo [Etiquetado de subredes para el modo automático de EKS](tag-subnets-auto.md).
A continuación, cree el recurso de ingreso. Cree un archivo denominado `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
```
**Componentes principales:**
+ Creación de un equilibrador de carga de aplicaciones expuesto a Internet
+ Utiliza el tipo de destino de IP para el enrutamiento directo de pods
+ Dirige todo el tráfico (/) al servicio del videojuego
Aplique las configuraciones de ingreso:
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## Paso 5: Verificación de la implementación
1. Compruebe que todos los pods estén en ejecución:
```
kubectl get pods -n game-2048
```
1. Compruebe que el servicio se haya creado:
```
kubectl get svc -n game-2048
```
1. Obtenga el punto de conexión del equilibrador de carga de aplicaciones:
```
kubectl get ingress -n game-2048
```
El campo ADDRESS en la salida del ingreso mostrará el punto de conexión del equilibrador de carga de aplicaciones. Espere de 2 a 3 minutos para que el equilibrador de carga de aplicaciones aprovisione y registre todos los destinos.
## Paso 6: Acceso al videojuego
Abra el navegador web y vaya a la URL del punto de conexión del equilibrador de carga de aplicaciones del paso anterior. Aparecerá la interfaz del videojuego 2048.
## Paso 7: Efectúe una limpieza
Para eliminar todos los recursos creados en este tutorial:
```
kubectl delete namespace game-2048
```
Esto eliminará todos los recursos del espacio de nombres, incluidos los recursos de implementación, servicio e ingreso.
## Lo que ocurre detrás de las cámaras
1. La implementación crea 5 pods que ejecutan el videojuego 2048
1. El servicio proporciona un acceso de red estable a estos pods
1. Modo automático de EKS:
+ Crea un equilibrador de carga de aplicación en AWS
+ Configura grupos de destino para los pods
+ Establece reglas de enrutamiento para dirigir el tráfico al servicio
## Solución de problemas
Si el videojuego no se carga
+ Asegúrese de que todos los pods se ejecutan: `kubectl get pods -n game-2048`
+ Compruebe el estado del ingreso: `kubectl describe ingress -n game-2048`
+ Verifique las comprobaciones de estado del equilibrador de carga de aplicación: compruebe el estado del grupo de destino en la Consola de AWS
# Implementación de una carga de trabajo con estado de ejemplo en el modo automático de EKS
En este tutorial se explica cómo implementar una aplicación con estado de ejemplo en el clúster de modo automático de EKS. La aplicación escribe marcas de tiempo en un volumen persistente, lo que demuestra las capacidades automáticas de persistencia y aprovisionamiento de volúmenes de EBS del modo automático de EKS.
## Requisitos previos
+ Un clúster de modo automático de EKS
+ AWS CLI configurada con los permisos adecuados
+ `kubectl` instalado y configurado
+ Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
## Paso 1: Configuración del entorno
1. Configure las variables de entorno:
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. Actualice la kubeconfig:
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## Paso 2: Creación de la clase de almacenamiento
La `StorageClass` define cómo el modo automático de EKS aprovisionará los volúmenes de EBS.
El modo automático de EKS no crea una `StorageClass` en su nombre. Debe crear una `StorageClass` que haga referencia a `ebs.csi.eks.amazonaws.com` para utilizar la capacidad de almacenamiento del modo automático de EKS.
1. Cree un archivo denominado `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. Aplicación de `StorageClass`:
```
kubectl apply -f storage-class.yaml
```
**Componentes principales:**
+ `provisioner: ebs.csi.eks.amazonaws.com`: utiliza el modo automático de EKS
+ `volumeBindingMode: WaitForFirstConsumer`: retrasa la creación del volumen hasta que un pod lo necesite
+ `type: gp3`: especifica el tipo de volumen de EBS
+ `encrypted: "true"`: EBS utilizará la clave de `aws/ebs` predeterminada para cifrar los volúmenes creados con esta clase. Esto es opcional, pero recomendable.
+ `storageclass.kubernetes.io/is-default-class: "true"`: Kubernetes utilizará esta clase de almacenamiento de forma predeterminada, a menos que se especifique una clase de volumen diferente en una reclamación de volumen persistente. Tenga cuidado al establecer este valor si va a migrar desde otro controlador de almacenamiento. (opcional)
## Paso 3: Creación de la reclamación de volumen persistente
La reclamación de volumen persistente solicita almacenamiento a la `StorageClass`.
1. Cree un archivo denominado `pvc.yaml`:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. Aplicación de la reclamación de volumen persistente:
```
kubectl apply -f pvc.yaml
```
**Componentes principales:**
+ `accessModes: ReadWriteOnce`: el volumen se puede montar con un nodo a la vez
+ `storage: 8Gi`: solicita un volumen de 8 GiB
+ `storageClassName: auto-ebs-sc`: hace referencia a la `StorageClass` que creamos
## Paso 4: Implementación de la aplicación
La implementación ejecuta un contenedor que escribe marcas de tiempo en el volumen persistente.
1. Cree un archivo denominado `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. Aplique la implementación:
```
kubectl apply -f deployment.yaml
```
**Componentes principales:**
+ Contenedor bash simple que escribe marcas de tiempo en un archivo
+ Monta la reclamación de volumen persistente en `/data`
+ Solicita 1 núcleo de CPU
+ Utiliza el selector de nodos para los nodos administrados por EKS
## Paso 5: Verificación del modo en que quedó establecido
1. Compruebe que el pod se ejecuta:
```
kubectl get pods -l app=inflate-stateful
```
1. Compruebe que la reclamación de volumen persistente está vinculada:
```
kubectl get pvc auto-ebs-claim
```
1. Compruebe el volumen de 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. Verifique que los datos se escriben:
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## Paso 6: Efectúe una limpieza
Ejecute el siguiente comando para eliminar todos los recursos creados en este tutorial:
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## Lo que ocurre detrás de las cámaras
1. La reclamación de volumen persistente solicita almacenamiento a la `StorageClass`.
1. Cuando el pod se ha programado:
1. El modo automático de EKS aprovisiona un volumen de EBS
1. Crea un PersistentVolume
1. Asocia el volumen al nodo
1. El pod monta el volumen y comienza a escribir las marcas de tiempo
## Controlador de instantáneas
El modo automático de EKS es compatible con Kubernetes CSI Snapshotter, también conocido como controlador de instantáneas. Sin embargo, el modo automático de EKS no incluye el controlador de instantáneas. Usted es responsable de instalar y configurar el controlador de instantáneas. Para obtener más información, consulte [Habilitación de la funcionalidad de instantáneas para volúmenes de CSI](csi-snapshot-controller.md).
Revise la siguiente `VolumeSnapshotClass` que hace referencia a la capacidad de almacenamiento del modo automático de EKS.
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[Más información sobre Kubernetes CSI Snapshotter.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# 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
```