**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 con estado de ejemplo en el modo automático de EKS
<a name="sample-storage-workload"></a>

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
<a name="_prerequisites"></a>
+ 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
<a name="_step_1_configure_your_environment"></a>

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
<a name="_step_2_create_the_storage_class"></a>

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
<a name="_step_3_create_the_persistent_volume_claim"></a>

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
<a name="_step_4_deploy_the_application"></a>

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
<a name="_step_5_verify_the_setup"></a>

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
<a name="_step_6_cleanup"></a>

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
<a name="_whats_happening_behind_the_scenes"></a>

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
<a name="_snapshot_controller"></a>

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)