Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Ejecución de trabajos de Spark con Amazon EMR en EKS
<a name="job-runs-main"></a>

Una *ejecución de trabajo* es una unidad de trabajo, como un jar de Spark, un PySpark script o una consulta de SparkSQL, que se envía a Amazon EMR en EKS. En este tema se proporciona información general sobre la administración de ejecuciones de tareas mediante la consola Amazon EMR AWS CLI, la visualización de las ejecuciones de tareas mediante la consola Amazon EMR y la solución de errores comunes de ejecución de tareas.

Ten en cuenta que no puedes ejecutar trabajos de IPv6 Spark en Amazon EMR en EKS

**nota**  
Antes de enviar una ejecución de trabajo con Amazon EMR en EKS, debe completar los pasos que se indican en [Configuración de Amazon EMR en EKS](setting-up.md).

**Topics**
+ [Ejecución de trabajos de Spark con `StartJobRun`](job-runs.md)
+ [Ejecución de trabajos de Spark con el operador de Spark](spark-operator.md)
+ [Ejecución de trabajos de Spark con spark-submit](spark-submit.md)
+ [Uso de Apache Livy con Amazon EMR en EKS](job-runs-apache-livy.md)
+ [Administración de las ejecuciones de trabajos de Amazon EMR en EKS](emr-eks-jobs-manage.md)
+ [Uso de plantillas de trabajos](job-templates.md)
+ [Uso de plantillas de pods](pod-templates.md)
+ [Uso de políticas de reintento de trabajos](jobruns-using-retry-policies.md)
+ [Uso de la rotación del registro de eventos de Spark](emr-eks-log-rotation.md)
+ [Uso de la rotación de los registros de contenedores de Spark](emr-eks-log-rotation-container.md)
+ [Uso del escalado automático vertical con trabajos de Spark de Amazon EMR](jobruns-vas.md)

# Ejecución de trabajos de Spark con `StartJobRun`
<a name="job-runs"></a>

Esta sección incluye pasos de configuración detallados para preparar tu entorno para ejecutar trabajos de Spark y, a continuación, proporciona step-by-step instrucciones para enviar una ejecución de trabajo con parámetros específicos.

**Topics**
+ [Configuración de Amazon EMR en EKS](setting-up.md)
+ [Enviar una ejecución de trabajo con `StartJobRun`](emr-eks-jobs-submit.md)
+ [Uso de la clasificación de remitentes de trabajos](emr-eks-job-submitter.md)
+ [Uso de la clasificación de valores predeterminados de contenedores de Amazon EMR](emr-eks-job-submitter-container-defaults.md)

# Configuración de Amazon EMR en EKS
<a name="setting-up"></a>

Complete las siguientes tareas para la configuración de Amazon EMR en EKS. Si ya se ha registrado en Amazon Web Services (AWS) y ha estado usando Amazon EKS, ya lo tiene todo casi listo para usar Amazon EMR en EKS. Omita cualquier tarea que ya haya completado.

**nota**  
También puede seguir el [Taller de Amazon EMR en EKS](https://emr-on-eks.workshop.aws/amazon-emr-eks-workshop.html) para configurar todos los recursos necesarios y ejecutar trabajos de Spark en Amazon EMR en EKS. El taller también proporciona automatización mediante el uso de CloudFormation plantillas para crear los recursos necesarios para empezar. Para ver otras plantillas y prácticas recomendadas, consulte nuestra [Guía de mejores prácticas para contenedores EMR](https://aws.github.io/aws-emr-containers-best-practices/) en. GitHub

1. [Instale o actualice a la última versión de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)

1. [Configuración de kubectl y eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)

1. [Introducción a Amazon EKS: ekstcl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)

1. [Habilite el acceso al clúster para Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html)

1. [Habilitar los roles de IAM para el clúster de EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM-roles.html)

1. [Otorgar a los usuarios acceso a Amazon EMR en EKS](setting-up-iam.md)

1. [Registrar el clúster de Amazon EKS con Amazon EMR](setting-up-registration.md)

# Habilitar el acceso a clústeres de Amazon EMR en EKS
<a name="setting-up-cluster-access"></a>

Las siguientes secciones muestran un par de formas de habilitar el acceso a los clústeres. La primera es mediante la administración de acceso a clústeres (CAM) de Amazon EKS y la segunda muestra cómo tomar medidas manuales para habilitar el acceso a los clústeres.

## Habilitación del acceso al clúster mediante EKS Access Entry (recomendado)
<a name="setting-up-cluster-access-cam-integration"></a>

**nota**  
`aws-auth` ConfigMap se ha quedado obsoleto. [El método recomendado para administrar el acceso a Kubernetes APIs son las entradas de acceso.](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)

Amazon EMR está integrado con la [administración de acceso a clústeres (CAM) de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html), por lo que puede automatizar la configuración de las políticas AuthN y AuthZ necesarias para ejecutar trabajos de Amazon EMR Spark en los espacios de nombres de los clústeres de Amazon EKS. Cuando crea un clúster virtual a partir de un espacio de nombres de clústeres de Amazon EKS, Amazon EMR configura automáticamente todos los permisos necesarios, por lo que no necesita añadir ningún paso adicional a sus flujos de trabajo actuales.

**nota**  
La integración de Amazon EMR con Amazon EKS CAM solo es compatible con los nuevos clústeres virtuales de Amazon EMR en EKS. No puede migrar los clústeres virtuales existentes para utilizar esta integración.

### Requisitos previos
<a name="setting-up-cluster-access-cam-integration-prereqs"></a>
+ Asegúrese de que está ejecutando la versión 2.15.3 o superior del AWS CLI
+ El clúster de Amazon EKS debe estar en la versión 1.23 o posteriores.

### Configuración
<a name="setting-up-cluster-access-cam-integration-setup"></a>

Para configurar la integración entre Amazon EMR y las operaciones de AccessEntry API de Amazon EKS, asegúrese de haber completado los siguientes pasos:
+ Asegúrese de que `authenticationMode` de su clúster de Amazon EKS esté establecido en `API_AND_CONFIG_MAP`.

  ```
  aws eks describe-cluster --name <eks-cluster-name>
  ```

  Si aún no lo está, establezca `authenticationMode` en `API_AND_CONFIG_MAP`.

  ```
  aws eks update-cluster-config 
      --name <eks-cluster-name> 
      --access-config authenticationMode=API_AND_CONFIG_MAP
  ```

  Para obtener más información acerca de los modos de autenticación, consulte [Modos de autenticación de clústeres](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html#authentication-modes).
+ Asegúrese de que el [rol de IAM](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html) que está utilizando para ejecutar las operaciones de la API `CreateVirtualCluster` y `DeleteVirtualCluster` también tenga los siguientes permisos:

  ```
  {
    "Effect": "Allow",
    "Action": [
      "eks:CreateAccessEntry"
    ],
    "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:cluster/<EKS_CLUSTER_NAME>"
  }, 
  {
    "Effect": "Allow",
    "Action": [
      "eks:DescribeAccessEntry",
      "eks:DeleteAccessEntry",
      "eks:ListAssociatedAccessPolicies",
      "eks:AssociateAccessPolicy",
      "eks:DisassociateAccessPolicy"
    ],
    "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:access-entry/<EKS_CLUSTER_NAME>/role/<AWS_ACCOUNT_ID>/AWSServiceRoleForAmazonEMRContainers/*"
  }
  ```

### Conceptos y terminología
<a name="setting-up-cluster-access-cam-integration-concepts"></a>

La siguiente es una lista de terminologías y conceptos relacionados con Amazon EKS CAM.
+ Clúster virtual (VC): representación lógica del espacio de nombres creado en Amazon EKS. Es un enlace 1:1 a un espacio de nombres de un clúster de Amazon EKS. Puede usarlo para ejecutar cargas de trabajo de Amazon EMR en un clúster de Amazon EKS dentro del espacio de nombres especificado.
+ Espacio de nombres: mecanismo para aislar grupos de recursos dentro de un único clúster de EKS.
+ Política de acceso: permisos que otorgan acceso y acciones a un rol de IAM dentro de un clúster de EKS.
+ Entrada de acceso: una entrada creada con un ARN de rol. Puede vincular la entrada de acceso a una política de acceso para asignar permisos específicos en el clúster de Amazon EKS.
+ Clúster virtual integrado de entrada de acceso EKS: el clúster virtual creado mediante las [operaciones de la API de entrada de acceso](https://docs.aws.amazon.com/eks/latest/APIReference/API_Operations_Amazon_Elastic_Kubernetes_Service.html) desde Amazon EKS.

## Habilitación del acceso al clúster mediante `aws-auth`
<a name="setting-up-cluster-access-aws-auth"></a>

Debe permitir que Amazon EMR en EKS acceda a un espacio de nombres específico de su clúster mediante las siguientes acciones: crear un rol de Kubernetes, vincular el rol a un usuario de Kubernetes y asignar el usuario de Kubernetes con el rol [https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html) vinculado al servicio. Estas acciones se automatizan en `eksctl` cuando se utiliza el comando de asignación de identidades de IAM con `emr-containers` como nombre del servicio. Puede llevar a cabo estas operaciones fácilmente con el siguiente comando.

```
eksctl create iamidentitymapping \
    --cluster my_eks_cluster \
    --namespace kubernetes_namespace \
    --service-name "emr-containers"
```

*my\$1eks\$1cluster*Sustitúyalo por el nombre del clúster de Amazon EKS y sustitúyalo por *kubernetes\$1namespace* el espacio de nombres de Kubernetes creado para ejecutar las cargas de trabajo de Amazon EMR. 

**importante**  
Para descargar la versión más reciente de eksctl, siga el paso anterior [Configuración de kubectl y eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) para utilizar esta funcionalidad. 

### Pasos manuales para habilitar el acceso a clústeres de Amazon EMR en EKS
<a name="setting-up-cluster-access-manual"></a>

También puede utilizar los siguientes pasos manuales para habilitar el acceso al clúster de Amazon EMR en EKS.

1. **Crear un rol de Kubernetes en un espacio de nombres específico**

------
#### [ Amazon EKS 1.22 - 1.29 ]

   Con las versiones de Amazon EKS de 1.22 a 1.29, ejecute el siguiente comando para crear un rol de Kubernetes en un espacio de nombres específico. Este rol concede los permisos de RBAC necesarios a Amazon EMR en EKS.

   ```
   namespace=my-namespace
   cat - >>EOF | kubectl apply -f - >>namespace "${namespace}"
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: emr-containers
     namespace: ${namespace}
   rules:
     - apiGroups: [""]
       resources: ["namespaces"]
       verbs: ["get"]
     - apiGroups: [""]
       resources: ["serviceaccounts", "services", "configmaps", "events", "pods", "pods/log"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["secrets"]
       verbs: ["create", "patch", "delete", "watch"]
     - apiGroups: ["apps"]
       resources: ["statefulsets", "deployments"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["batch"]
       resources: ["jobs"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["extensions", "networking.k8s.io"]
       resources: ["ingresses"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["rbac.authorization.k8s.io"]
       resources: ["roles", "rolebindings"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["persistentvolumeclaims"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete",  "deletecollection", "annotate", "patch", "label"]
   EOF
   ```

------
#### [ Amazon EKS 1.21 and below ]

   Con Amazon EKS 1.21 y versiones anteriores, ejecute el siguiente comando para crear un rol de Kubernetes en un espacio de nombres específico. Este rol concede los permisos de RBAC necesarios a Amazon EMR en EKS.

   ```
   namespace=my-namespace
   cat - >>EOF | kubectl apply -f - >>namespace "${namespace}"
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: emr-containers
     namespace: ${namespace}
   rules:
     - apiGroups: [""]
       resources: ["namespaces"]
       verbs: ["get"]
     - apiGroups: [""]
       resources: ["serviceaccounts", "services", "configmaps", "events", "pods", "pods/log"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["secrets"]
       verbs: ["create", "patch", "delete", "watch"]
     - apiGroups: ["apps"]
       resources: ["statefulsets", "deployments"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["batch"]
       resources: ["jobs"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["extensions"]
       resources: ["ingresses"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["rbac.authorization.k8s.io"]
       resources: ["roles", "rolebindings"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["persistentvolumeclaims"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
   EOF
   ```

------

1. **Crear una vinculación de roles de Kubernetes limitada al espacio de nombres**

   Ejecute el siguiente comando para crear una vinculación de roles de Kubernetes en el espacio de nombres dado. Esta vinculación de roles otorga los permisos definidos en el rol creado en el paso anterior a un usuario nombrado `emr-containers`. Este usuario identifica los [roles vinculadas al servicio de Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html) y, por lo tanto, permite que Amazon EMR en EKS lleve a cabo las acciones definidas por el rol que creó.

   ```
   namespace=my-namespace
   
   cat - <<EOF | kubectl apply -f - --namespace "${namespace}"
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: emr-containers
     namespace: ${namespace}
   subjects:
   - kind: User
     name: emr-containers
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: Role
     name: emr-containers
     apiGroup: rbac.authorization.k8s.io
   EOF
   ```

1. **Actualizar el mapa de configuración `aws-auth` de Kubernetes**

   Puede utilizar una de las siguientes opciones para asignar el rol vinculado al servicio de Amazon EMR en EKS con el usuario de `emr-containers` que estaba vinculado con el rol de Kubernetes en el paso anterior.

   **Opción 1: con `eksctl`**

   Ejecute el siguiente comando `eksctl` para asignar el rol vinculado al servicio de Amazon EMR en EKS con el usuario `emr-containers`.

   ```
   eksctl create iamidentitymapping \
       --cluster my-cluster-name \
       --arn "arn:aws:iam::my-account-id:role/AWSServiceRoleForAmazonEMRContainers" \
       --username emr-containers
   ```

   **Opción 2: sin usar eksctl**

   1. Ejecute el siguiente comando para abrir el mapa de configuración `aws-auth` en el editor de texto. 

      ```
      kubectl edit -n kube-system configmap/aws-auth
      ```
**nota**  
Si recibe un mensaje de error al respecto`Error from server (NotFound): configmaps "aws-auth" not found`, consulte los pasos de [Añadir funciones de usuario](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) en la Guía del usuario de Amazon EKS para aplicar el stock ConfigMap. 

   1. Agregue los detalles del rol vinculado al servicio Amazon EMR en EKS en la sección `mapRoles` de `ConfigMap`, en `data`. Agregue esta sección si no existe todavía en el archivo. La sección `mapRoles` actualizada en datos es similar al siguiente ejemplo.

      ```
      apiVersion: v1
      data:
        mapRoles: |
          - rolearn: arn:aws:iam::<your-account-id>:role/AWSServiceRoleForAmazonEMRContainers
            username: emr-containers
          - ... <other previously existing role entries, if there's any>.
      ```

   1. Guarde el archivo y salga del editor de texto.

# Habilitar los roles de IAM para el clúster de EKS
<a name="setting-up-enable-IAM-roles"></a>

En los siguientes temas se detallan las opciones para habilitar los roles de IAM.

**Topics**
+ [Opción 1: habilitar Pod Identity de EKS en el clúster de EKS](setting-up-enable-IAM.md)
+ [Opción 2: habilite los roles de IAM para las cuentas de servicio (IRSA) en el clúster de EKS](setting-up-enable-IAM-service-accounts.md)

# Opción 1: habilitar Pod Identity de EKS en el clúster de EKS
<a name="setting-up-enable-IAM"></a>

Las asociaciones de Pod Identity de Amazon EKS ofrecen la posibilidad de administrar las credenciales para las aplicaciones, de un modo similar a cómo los perfiles de instancia de Amazon EC2 proporcionan credenciales a instancias de Amazon EC2. Pod Identity de Amazon EKS proporciona credenciales a sus cargas de trabajo con una API de autenticación de EKS adicional y un pod de agente que se ejecuta en cada nodo.

Amazon EMR en EKS comienza a admitir la identidad de pod de EKS desde la versión emr-7.3.0 para el modelo de envío. StartJobRun 

Para obtener más información sobre Pod Identity de EKS, consulte [Understand how EKS Pod Identity works](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html).

## ¿Por qué Pod Identities de EKS?
<a name="setting-up-enable-IAM-pod-identity-why"></a>

Como parte de la configuración de EMR, la función de ejecución de trabajos debe establecer límites de confianza entre un rol de IAM y las cuentas de servicio en un espacio de nombres específico (de clústeres virtuales de EMR). Con IRSA, esto se logró mediante la actualización de la política de confianza del rol de ejecución de trabajos de EMR. Sin embargo, debido al límite estricto de 4096 caracteres en la longitud de la política de confianza de IAM, existía la restricción de compartir un único rol de IAM de ejecución de trabajos en un máximo de doce (12) clústeres de EKS.

Gracias a la compatibilidad de EMR con las identidades de pod, el equipo de EKS gestiona ahora el límite de confianza entre las funciones de IAM y las cuentas de servicio mediante la asociación entre las funciones de IAM y las cuentas de servicio. APIs

**nota**  
El límite de seguridad de Pod Identity de EKS sigue estando en el nivel de la cuenta de servicio, no en el nivel del pod.

## Consideraciones sobre Pod Identity
<a name="setting-up-enable-IAM-pod-identity-consider"></a>

Para obtener información sobre las limitaciones de Pod Identity, consulte las [consideraciones sobre Pod Identity de EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations).

## Prepare Pod Identity de EKS en el clúster EKS
<a name="setting-up-enable-IAM-pod-eks-cluster"></a>

### Comprueba si el permiso necesario existe en NodeInstanceRole
<a name="setting-up-enable-IAM-pod-eks-cluster-permission"></a>

El rol de nodo `NodeInstanceRole` necesita un permiso para que el agente realice la acción `AssumeRoleForPodIdentity` en la API de autenticación de EKS. Puede añadir lo siguiente a [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy), tal como se define en la Guía del usuario de Amazon EKS, o utilizar una política personalizada.

Si su clúster de EKS se creó con una versión eksctl superior a la **0.181.0,** Amazon EKSWorkerNodePolicy, incluido el `AssumeRoleForPodIdentity` permiso requerido, se asociará automáticamente al rol de nodo. Si el permiso no está presente, añade manualmente el siguiente permiso a Amazon EKSWorker NodePolicy que te permita asumir un rol para la identidad del pod. El agente de Pod Identity de EKS necesita este permiso para recuperar las credenciales de los pods.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks-auth:AssumeRoleForPodIdentity"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEKSAUTHAssumeroleforpodidentity"
    }
  ]
}
```

------

### Crear un complemento agente de Pod Identity de EKS
<a name="setting-up-enable-IAM-pod-eks-cluster-agent"></a>

Utilice el comando siguiente para crear el complemento agente de Pod Identity de EKS con la versión más reciente:

```
aws eks create-addon --cluster-name cluster-name --addon-name eks-pod-identity-agent

kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```

Siga estos pasos para crear el complemento agente de Pod Identity de EKS desde la consola de Amazon EKS:

1. Abra la consola de Amazon EK: [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. En el panel de navegación izquierdo, seleccione **Clústeres** y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento de agente de Pod Identity de EKS.

1. Elija la pestaña **Complementos**.

1. Escoja **Obtener más complementos**.

1. Seleccione la casilla situada en la parte superior derecha del cuadro de complementos para el agente de Pod Identity de EKS y, a continuación, elija **Siguiente**.

1. En la página **Configurar las opciones de complementos seleccionados**, seleccione cualquier versión de la lista desplegable **Versión**.

1. (Opcional) Expanda **Valores de configuración opcionales** para introducir una configuración adicional. Por ejemplo, puede proporcionar una ubicación de imagen de contenedor alternativa e `ImagePullSecrets`. El esquema JSON con las claves aceptadas se muestra en **Esquema de configuración de complementos**.

   Introduzca las claves y los valores de configuración en **Valores de configuración**.

1. Elija **Siguiente**.

1. Confirme que los pods agente se estén ejecutando en su clúster mediante la CLI.

   `kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'`

Un ejemplo de salida sería el siguiente:

```
NAME                              READY   STATUS    RESTARTS      AGE
eks-pod-identity-agent-gmqp7      1/1     Running   1 (24h ago)   24h
eks-pod-identity-agent-prnsh      1/1     Running   1 (24h ago)   24h
```

Esto configura un nuevo DaemonSet en el espacio de `kube-system` nombres. El agente de identidad del pod de Amazon EKS, que se ejecuta en cada nodo de EKS, utiliza la [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)acción para recuperar las credenciales temporales de la API de autenticación de EKS. Luego, estas credenciales están disponibles para las AWS SDKs que ejecute dentro de sus contenedores.

Para obtener más información, consulte el requisito previo del documento público: [Configuración del agente de Pod Identity de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html).

## Crear un rol de ejecución de trabajos
<a name="setting-up-enable-IAM-pod-create-job-role"></a>

### Cree o actualice el rol de ejecución de trabajo que admite Pod Identity de EKS
<a name="setting-up-enable-IAM-pod-create-job-role-update"></a>

Para ejecutar cargas de trabajo en Amazon EMR en EKS, debe crear un rol de IAM. En esta documentación, nos referimos a este rol como rol de ejecución de trabajos. Para obtener más información acerca de cómo crear el rol de IAM, consulte [Creación de roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) en la Guía del usuario.

Además, debe crear una política de IAM que especifique los permisos necesarios para el rol de ejecución de trabajos y, a continuación, adjuntar esta política a dicho rol para habilitar Pod Identity de EKS.

Por ejemplo, tiene el siguiente rol de ejecución de trabajos. Para obtener más información, consulte [Create a job execution role](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html).

```
arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole
```

**importante**  
Amazon EMR en EKS crea automáticamente cuentas de servicio de Kubernetes en función del nombre de su rol de ejecución de trabajos. Asegúrese de que el nombre del rol no sea demasiado largo, ya que su trabajo podría fallar si la combinación de `cluster_name`, `pod_name` y `service_account_name` supera el límite de longitud.

**Configuración del rol de ejecución de trabajos**: asegúrese de que el rol de ejecución de trabajos se haya creado con el siguiente permiso de confianza para Pod Identity de EKS. Para actualizar un rol de ejecución de trabajos existente, configúrelo para que confíe en la siguiente entidad principal de servicio de EKS como permiso adicional de la política de confianza. Este permiso de confianza puede coexistir con las políticas de confianza de IRSA existentes.

```
cat >trust-relationship.json <<EOF
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}
EOF
```

**Permiso de usuario**: los usuarios necesitan el permiso `iam:PassRole` para ejecutar llamadas a la API `StartJobRun` o enviar trabajos. Este permiso permite a los usuarios transferir el rol de ejecución de trabajos a EMR en EKS. Los administradores de trabajos deberían tener el permiso de forma predeterminada.

A continuación, se muestra el permiso que necesita un usuario:

```
{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole",
    "Condition": {
        "StringEquals": {
            "iam:PassedToService": "pods.eks.amazonaws.com"
        }
    }
}
```

Para restringir aún más el acceso de los usuarios a clústeres de EKS específicos, añada el filtro de AssociatedResourceArn atributos a la política de IAM. Limita la asunción de roles a los clústeres de EKS autorizados, lo que refuerza los controles de seguridad a nivel de recursos.

```
"Condition": {
        "ArnLike": {
            "iam:AssociatedResourceARN": [
                "arn:aws:eks:us-west-2:111122223333:cluster/*"
            ]
        }
```

## Configurar las asociaciones de Pod Identity de EKS
<a name="setting-up-enable-IAM-pod-identity-asociations"></a>

### Requisito previo
<a name="setting-up-enable-IAM-pod-identity-asociations-prereq"></a>

Asegúrese de que la identidad de IAM que crea la asociación de Pod Identity, como un usuario administrador de EKS, tenga el permiso `eks:CreatePodIdentityAssociation` y`iam:PassRole`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:CreatePodIdentityAssociation"
      ],
      "Resource": [
        "arn:aws:eks:*:*:cluster/*"
      ],
      "Sid": "AllowEKSCreatepodidentityassociation"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:aws:iam::*:role/*"
      ],
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "pods.eks.amazonaws.com"
        }
      },
      "Sid": "AllowIAMPassrole"
    }
  ]
}
```

------

### Crear asociaciones para el rol y la cuenta de servicio EMR
<a name="setting-up-enable-IAM-pod-identity-asociations-emr-service"></a>

------
#### [ Create EMR role associations through the AWS CLI ]

Cuando envía un trabajo a un espacio de nombres de Kubernetes, el administrador debe crear asociaciones entre el rol de ejecución de trabajos y la identidad de la cuenta de servicio administrado de EMR. Tenga en cuenta que la cuenta de servicio administrado de EMR se crea automáticamente en el momento del envío del trabajo y tiene como límite el espacio de nombres donde se envía el trabajo.

Con la versión 2.24.0 AWS CLI (anterior), ejecute el siguiente comando para crear asociaciones de roles con la identidad del pod.

Ejecute los siguientes comandos para crear asociaciones de roles con Pod Identity.

```
aws emr-containers create-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2
```

Nota:
+ Cada clúster puede tener un límite de 1000 asociaciones. Todos los roles de ejecución de trabajos: el mapeo de espacios de nombres requerirá 3 asociaciones para los pods de remitente, controlador y ejecutor del trabajo.
+ Solo puedes asociar roles que estén en la misma AWS cuenta que el clúster. Puede delegar el acceso desde otra cuenta al rol de esta cuenta que haya configurado para que lo utilice Pod Identities de EKS. Para ver un tutorial sobre cómo delegar el acceso`AssumeRole`, consulte el [tutorial de IAM: Delegar el acceso entre AWS cuentas mediante funciones de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html).

------
#### [ Create EMR role associations through Amazon EKS ]

EMR crea una cuenta de servicio con un patrón de nombres determinado cuando se envía un trabajo. Para realizar asociaciones manuales o integrar este flujo de trabajo con el AWS SDK, sigue estos pasos:

Cree el nombre de la cuenta de servicio:

```
emr-containers-sa-spark-%(SPARK_ROLE)s-%(AWS_ACCOUNT_ID)s-%(BASE36_ENCODED_ROLE_NAME)s
```

Los siguientes ejemplos crean una asociación de roles para un ejemplo de rol de ejecución de tareas JobExecutionRoleIRSAv2.

**Ejemplos de asociaciones de roles:**

```
RoleName: JobExecutionRoleIRSAv2
Base36EncodingOfRoleName: 2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

**Ejemplo de comando CLI:**

```
# setup for the client service account (used by job runner pod)
# emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# driver service account
# emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe        
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# executor service account
# emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

------

Una vez que haya completado todos los pasos necesarios para Pod Identity de EKS, puede omitir los siguientes pasos para configurar el IRSA:
+ [Habilite las funciones de IAM para las cuentas de servicio (IRSA) en el clúster EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html)
+ [Cree un rol de ejecución de tareas](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)
+ [Actualice la política de confianza del rol de ejecución del trabajo](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html)

Puede pasar directamente al siguiente paso: [Conceder a los usuarios acceso a Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html)

## Eliminar asociaciones de roles
<a name="setting-up-enable-IAM-pod-identity-asociations-delete-associations"></a>

Siempre que elimine un clúster virtual o un rol de ejecución de trabajos y ya no desee dar acceso a EMR a sus cuentas de servicio, debe eliminar las asociaciones del rol. Esto se debe a que EKS admite las asociaciones con recursos inexistentes (espacio de nombres y cuenta de servicio). Amazon EMR en EKS recomienda eliminar las asociaciones si se elimina el espacio de nombres o si el rol ya no se usa, a fin de liberar espacio para otras asociaciones.

**nota**  
Si no las elimina, las asociaciones persistentes podrían afectar a su capacidad de escalado, ya que EKS tiene limitaciones en cuanto al número de asociaciones que puede crear (límite máximo: 1000 asociaciones por clúster). Puede enumerar las asociaciones de Pod Identity en un espacio de nombres determinado para comprobar si hay alguna asociación persistente que deba eliminarse:

```
aws eks list-pod-identity-associations --cluster-name mycluster --namespace mynamespace
```

Con la AWS CLI versión 2.24.0 o superior, ejecute el siguiente comando emr-containers para eliminar las asociaciones de funciones de EMR:

```
aws emr-containers delete-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2
```

## Migrar automáticamente el IRSA existente a Pod Identity
<a name="setting-up-enable-IAM-pod-identity-auto-migrate"></a>

Puede usar la herramienta eksctl para migrar los roles de IAM para las cuentas de servicio (IRSA) existentes a las asociaciones de Pod Identity:

```
eksctl utils migrate-to-pod-identity \
    --cluster mycluster \
    --remove-oidc-provider-trust-relationship \
    --approve
```

Al ejecutar el comando sin la marca de `--approve`, solo se generará un plan que refleje los pasos de la migración y no se producirá ninguna migración real.

## Resolución de problemas
<a name="setting-up-enable-IAM-pod-identity-troubleshooting"></a>

### Mi trabajo falló con ClassNotFound una excepción para el proveedor de credenciales, NoClassDefinitionFound o no pude obtener el proveedor de credenciales.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-no-class"></a>

Pod Identity de EKS utiliza el proveedor de credenciales del contenedor para recuperar las credenciales necesarias. Si ha especificado un proveedor de credenciales personalizado, asegúrese de que funciona correctamente. Como alternativa, asegúrate de usar una versión correcta AWS del SDK que sea compatible con EKS Pod Identity. Para obtener más información, consulte [Introducción a Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

### El trabajo falló y el error «No se pudieron recuperar las credenciales debido al límite de tamaño [x]» que aparece en el eks-pod-identity-agent registro.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds"></a>

EMR en EKS crea cuentas de servicio de Kubernetes en función del nombre del rol de ejecución del trabajo. Si el nombre del rol es demasiado largo, EKS Auth no podrá recuperar las credenciales porque la combinación de `cluster_name`, `pod_name`, y `service_account_name` supera el límite de longitud. Identifique qué componente ocupa más espacio y ajuste el tamaño según corresponda.

### El trabajo falló y en el eks-pod-identity registro aparece el error «No se pudieron recuperar las credenciales xxx».
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds-error"></a>

Una posible causa de este problema podría ser que el clúster EKS esté configurado en subredes privadas sin PrivateLink configurarlo correctamente. Compruebe si el clúster está en una red privada y AWS PrivateLink configúrelo para solucionar el problema. Para obtener instrucciones detalladas, consulte [Introducción a Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

# Opción 2: habilite los roles de IAM para las cuentas de servicio (IRSA) en el clúster de EKS
<a name="setting-up-enable-IAM-service-accounts"></a>

La característica de roles de IAM para cuentas de servicio está disponible en los nuevos clústeres de la versión 1.14 de Amazon EKS y posteriores, y para clústeres de EKS que se actualizaron a las versiones 1.13 o posteriores a partir del 3 de septiembre de 2019. Para utilizar esta característica, puede actualizar los clústeres de EKS existentes a la versión 1.14 o posteriores. Para obtener más información, consulte [Actualización de una versión de Kubernetes de clúster de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).

Si el clúster admite roles de IAM para cuentas de servicio, tiene asociada una URL de emisor de [OpenID Connect](https://openid.net/connect/). Puede ver esta URL en la consola de Amazon EKS o utilizar el siguiente AWS CLI comando para recuperarla.

**importante**  
Debe usar la última versión de AWS CLI para recibir el resultado correcto de este comando.

```
aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text
```

El resultado esperado es el siguiente.

```
https://oidc.eks.<region-code>.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E
```

Para utilizar roles de IAM para cuentas de servicio en su clúster, debe crear un proveedor de identidad OIDC con [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) o la [Consola de administración de AWS](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console).

## A fin de crear un proveedor de identidad de OIDC de IAM para su clúster con `eksctl`
<a name="setting-up-OIDC-eksctl"></a>

Consulte su versión de `eksctl` con el siguiente comando. En este procedimiento, se presupone que ha instalado `eksctl` y que su versión de `eksctl` es al menos 0.32.0 o posterior.

```
eksctl version
```

Para obtener más información sobre cómo instalar o actualizar eksctl, consulte [Instalación o actualización de eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl).

Cree su proveedor de identidad OIDC para su clúster con el siguiente comando. Reemplace *cluster\$1name* por su propio valor.

```
eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve
```

## Para crear un proveedor de identidades OIDC de IAM para su clúster con el Consola de administración de AWS
<a name="setting-up-OIDC-console"></a>

Recupere la URL del emisor del OIDC de la descripción de su clúster en la consola Amazon EKS o utilice el siguiente comando. AWS CLI 

Utilice el siguiente comando para recuperar la URL del emisor de OIDC de la AWS CLI.

```
aws eks describe-cluster --name <cluster_name> --query "cluster.identity.oidc.issuer" --output text
```

Siga estos pasos para recuperar la URL del emisor de OIDC de la consola de Amazon EKS. 

1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. En el panel de navegación, elija **Proveedores de identidad** y, a continuación, elija **Crear un proveedor**.

   1. En **Provider Type (Tipo de proveedor)**, elija **Choose a provider type (Elegir un tipo de proveedor)** y, luego, elija **OpenID Connect**.

   1. En **Provider URL (URL del proveedor)**, pegue la URL del emisor OIDC de su clúster.

   1. En Audiencia, ingrese sts.amazonaws.com y seleccione **Paso siguiente**.

1. Compruebe que la información del proveedor es correcta y, a continuación, seleccione **Create (Crear)** para crear su proveedor de identidad.

# Crear un rol de ejecución de trabajos
<a name="creating-job-execution-role"></a>

Para ejecutar cargas de trabajo en Amazon EMR en EKS, debe crear un rol de IAM. En esta documentación, nos referimos a este rol como *rol de ejecución de trabajos*. Para obtener más información acerca de cómo crear un rol de IAM, consulte [Creación de roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) en la Guía del usuario de IAM. 

También debe crear una política de IAM que especifique los permisos para el rol de ejecución de trabajos y, a continuación, adjuntar la política de IAM a dicho rol. 

La siguiente política para la función de ejecución de tareas permite el acceso a los objetivos de recursos, Amazon S3 y CloudWatch. Estos permisos son necesarios para supervisar los trabajos y acceder a los registros. Para seguir el mismo proceso, utilice AWS CLI: 

Cree el rol de IAM para la ejecución del trabajo: creemos el rol que EMR utilizará para la ejecución del trabajo. Este es el rol que asumirán los trabajos de EMR cuando se ejecuten en EKS.

```
cat <<EoF > ~/environment/emr-trust-policy.json
 {
   "Version": "2012-10-17",		 	 	 
   "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "Service": "elasticmapreduce.amazonaws.com"
       },
       "Action": "sts:AssumeRole"
     }
   ]
 }
 EoF
  
 aws iam create-role --role-name EMRContainers-JobExecutionRole --assume-role-policy-document file://~/environment/emr-trust-policy.json
```

A continuación, debemos adjuntar las políticas de IAM requeridas al rol para que pueda escribir registros en s3 y cloudwatch.

```
cat <<EoF > ~/environment/EMRContainers-JobExecutionRole.json
 {
     "Version": "2012-10-17",		 	 	 
     "Statement": [
         {
             "Effect": "Allow",
             "Action": [
                 "s3:PutObject",
                 "s3:GetObject",
                 "s3:ListBucket"
             ],
             "Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
         },
         {
             "Effect": "Allow",
             "Action": [
                 "logs:PutLogEvents",
                 "logs:CreateLogStream",
               "logs:DescribeLogGroups",
                 "logs:DescribeLogStreams"
             ],
             "Resource": [
                 "arn:aws:logs:*:*:*"
             ]
         }
     ]
 } 
 EoF
 aws iam put-role-policy --role-name EMRContainers-JobExecutionRole --policy-name EMR-Containers-Job-Execution --policy-document file://~/environment/EMRContainers-JobExecutionRole.json
```

**nota**  
El acceso debe tener el alcance adecuado y no debe concederse a todos los objetos de S3 que desempeñen el rol de ejecución de trabajos.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket"
      ],
      "Sid": "AllowS3Putobject"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:PutLogEvents",
        "logs:CreateLogStream",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "arn:aws:logs:*:*:*"
      ],
      "Sid": "AllowLOGSPutlogevents"
    }
  ]
}
```

------

Para obtener más información, consulte [Usar funciones de ejecución de tareas](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html), [Configurar una ejecución de tareas para usar registros de S3](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) y [Configurar una ejecución de tareas para usar CloudWatch registros](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch).

# Actualizar la política de confianza del rol de ejecución de trabajos
<a name="setting-up-trust-policy"></a>

Cuando utiliza los roles de IAM para cuentas de servicio (IRSA) para ejecutar tareas en un espacio de nombres de Kubernetes, el administrador debe crear una relación de confianza entre el rol de ejecución de trabajos y la identidad de la cuenta de servicio administrada de EMR. Para crear la relación de confianza, se puede actualizar la política de confianza del rol de ejecución de trabajos. Tenga en cuenta que la cuenta de servicio administrado de EMR se crea automáticamente en el momento del envío del trabajo y tiene como límite el espacio de nombres donde se envía el trabajo.

Para actualizar la política de confianza, ejecute el siguiente comando.

```
 aws emr-containers update-role-trust-policy \
       --cluster-name cluster \
       --namespace namespace \
       --role-name iam_role_name_for_job_execution
```

Para obtener más información, consulte [Uso de roles de ejecución de trabajos con Amazon EMR en EKS](iam-execution-role.md).

**importante**  
El operador que ejecute el comando anterior debe tener los siguientes permisos: `eks:DescribeCluster`, `iam:GetRole`, `iam:UpdateAssumeRolePolicy`.

# Otorgar a los usuarios acceso a Amazon EMR en EKS
<a name="setting-up-iam"></a>

Para cualquier acción que lleve a cabo en Amazon EMR en EKS, necesita el permiso de IAM correspondiente. Debe crear una política de IAM que le permita llevar a cabo acciones de Amazon EMR en EKS y adjuntar la política al usuario o rol de IAM que utilice. 

En este tema se proporcionan los pasos para crear una política nueva y adjuntarla a un usuario. También cubre los permisos básicos que necesita para configurar su entorno de Amazon EMR en EKS. Le recomendamos que perfeccione los permisos para recursos específicos siempre que sea posible en función de las necesidades de su empresa.

## Crear una nueva política de IAM y adjuntarla a un usuario en la consola de IAM
<a name="setting-up-iam-console"></a>

**Crear una política de IAM nueva**

1. Inicie sesión en la consola de IAM Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. En el panel de navegación izquierdo de la consola de IAM elija **Políticas**.

1. En la página **Políticas**, seleccione **Crear una política**.

1. En la ventana **Crear política**, vaya a la pestaña **Editar JSON**. Cree un documento de política con una o más instrucciones JSON, tal como se muestra en los ejemplos que siguen a este procedimiento. A continuación, seleccione **Revisar política**.

1. En la pantalla **Review Policy (Revisar política)**, escriba su **Policy Name (Nombre de política)**; por ejemplo, `AmazonEMROnEKSPolicy`. Ingrese una descripción opcional y, a continuación, elija **Crear política**. 

**Adjuntar la política a un usuario o rol**

1. Inicie sesión en la consola de IAM Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 

1. En el panel de navegación, seleccione **Políticas**.

1. En la lista de políticas, seleccione la casilla situada junto a la política creada en la sección anterior. Puede utilizar el menú **Filtro** y el cuadro de búsqueda para filtrar la lista de políticas. 

1. Seleccione **Policy actions (Acciones de la política)** y, a continuación, **Attach (Adjuntar)**.

1. Elija el usuario o rol al que adjuntar la política. Puede utilizar el menú **Filtro** y el cuadro de búsqueda para filtrar la lista entidades principales. Después de seleccionar el usuario o rol al que adjuntará la política, seleccione **Adjuntar política**.

## Permisos para administrar clústeres virtuales
<a name="permissions-virtual-cluster"></a>

Para gestionar los clústeres virtuales de su AWS cuenta, cree una política de IAM con los siguientes permisos. Estos permisos le permiten crear, enumerar, describir y eliminar clústeres virtuales en su AWS cuenta.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "emr-containers.amazonaws.com"
        }
      },
      "Sid": "AllowIAMCreateservicelinkedrole"
    },
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:CreateVirtualCluster",
        "emr-containers:ListVirtualClusters",
        "emr-containers:DescribeVirtualCluster",
        "emr-containers:DeleteVirtualCluster"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEMRCONTAINERSCreatevirtualcluster"
    }
  ]
}
```

------

Amazon EMR está integrado con la administración de acceso a clústeres (CAM) de Amazon EKS, por lo que puede automatizar la configuración de las políticas AuthN y AuthZ necesarias para ejecutar trabajos de Amazon EMR Spark en los espacios de nombres de los clústeres de Amazon EKS. Para llevar a cabo esto, debe tener los siguientes permisos:

```
{
  "Effect": "Allow",
  "Action": [
    "eks:CreateAccessEntry"
  ],
  "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:cluster/<EKS_CLUSTER_NAME>"
}, 
{
  "Effect": "Allow",
  "Action": [
    "eks:DescribeAccessEntry",
    "eks:DeleteAccessEntry",
    "eks:ListAssociatedAccessPolicies",
    "eks:AssociateAccessPolicy",
    "eks:DisassociateAccessPolicy"
  ],
  "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:access-entry/<EKS_CLUSTER_NAME>/role/<AWS_ACCOUNT_ID>/AWSServiceRoleForAmazonEMRContainers/*"
}
```

Para obtener más información, consulte [Automatización de la habilitación del acceso a clústeres de Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-cam-integration).

Cuando se invoque la `CreateVirtualCluster` operación por primera vez desde una AWS cuenta, también necesitará `CreateServiceLinkedRole` los permisos para crear el rol vinculado al servicio para Amazon EMR en EKS. Para obtener más información, consulte [Uso de roles vinculados a servicios para Amazon EMR en EKS](using-service-linked-roles.md). 

## Permisos para enviar trabajos
<a name="permissions-submitting-jobs"></a>

Para enviar trabajos en los clústeres virtuales de su AWS cuenta, cree una política de IAM con los siguientes permisos. Estos permisos le permiten iniciar, enumerar, describir y cancelar la ejecución de trabajos para todos los clústeres virtuales de su cuenta. Debería considerar la posibilidad de agregar permisos para enumerar o describir los clústeres virtuales, lo que le permitirá comprobar el estado del clúster virtual antes de enviar los trabajos.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:StartJobRun",
        "emr-containers:ListJobRuns",
        "emr-containers:DescribeJobRun",
        "emr-containers:CancelJobRun"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEMRCONTAINERSStartjobrun"
    }
  ]
}
```

------

## Permisos de depuración y supervisión
<a name="permissions-debugging-monitoring"></a>

Para acceder a los registros enviados a Amazon S3 o ver los CloudWatch registros de eventos de la aplicación en la consola de Amazon EMR, cree una política de IAM con los siguientes permisos. Le recomendamos que perfeccione los permisos para recursos específicos siempre que sea posible en función de las necesidades de su empresa.

**importante**  
Si no ha creado ningún bucket de Amazon S3, debe agregar el permiso `s3:CreateBucket` a la instrucción de política. Si no ha creado ningún grupo de registros, debe agregar `logs:CreateLogGroup` a la instrucción de política.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:DescribeJobRun",
        "elasticmapreduce:CreatePersistentAppUI",
        "elasticmapreduce:DescribePersistentAppUI",
        "elasticmapreduce:GetPersistentAppUIPresignedURL"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEMRCONTAINERSDescribejobrun"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowS3Getobject"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:Get*",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowLOGSGet"
    }
  ]
}
```

------

Para obtener más información sobre cómo configurar una ejecución de trabajo para enviar registros a Amazon S3 CloudWatch, consulte [Configurar una ejecución de trabajo para usar registros de S3](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) y [Configurar una ejecución de trabajo para usar CloudWatch registros](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch).

# Registrar el clúster de Amazon EKS con Amazon EMR
<a name="setting-up-registration"></a>

El registro de su clúster es el último paso necesario para configurar Amazon EMR en EKS y ejecutar cargas de trabajo.

Utilice el siguiente comando para crear un clúster virtual con el nombre que desee para el clúster y el espacio de nombres de Amazon EKS que configuró en los pasos anteriores.

**nota**  
Cada clúster virtual debe tener un nombre único en todos los clústeres de EKS. Si dos clústeres virtuales tienen el mismo nombre, el proceso de implementación fallará aunque los dos clústeres virtuales pertenezcan a clústeres de EKS diferentes. 

```
aws emr-containers create-virtual-cluster \
--name virtual_cluster_name \
--container-provider '{
    "id": "cluster_name",
    "type": "EKS",
    "info": {
        "eksInfo": {
            "namespace": "namespace_name"
        }
    }
}'
```

Como alternativa, puede crear un archivo JSON que incluya los parámetros necesarios para el clúster virtual y, a continuación, ejecutar el comando `create-virtual-cluster` con la ruta al archivo JSON. Para obtener más información, consulte [Administración de clústeres virtuales](virtual-cluster.md).

**nota**  
Para validar la creación correcta de un clúster virtual, consulte el estado de los clústeres virtuales mediante la operación `list-virtual-clusters` o vaya a la página **Clústeres virtuales** de la consola de Amazon EMR. 

# Enviar una ejecución de trabajo con `StartJobRun`
<a name="emr-eks-jobs-submit"></a>

**Enviar una ejecución de trabajo con un archivo JSON con los parámetros especificados**

1. Cree un archivo `start-job-run-request.json` y especifique los parámetros necesarios para la ejecución del trabajo, tal como se muestra en el siguiente archivo JSON de ejemplo. Para obtener más información sobre los parámetros, consulte [Opciones para configurar una ejecución de trabajo](emr-eks-jobs-CLI.md#emr-eks-jobs-parameters).

   ```
   {
     "name": "myjob", 
     "virtualClusterId": "123456",  
     "executionRoleArn": "iam_role_name_for_job_execution", 
     "releaseLabel": "emr-6.2.0-latest", 
     "jobDriver": {
       "sparkSubmitJobDriver": {
         "entryPoint": "entryPoint_location",
         "entryPointArguments": ["argument1", "argument2", ...],  
          "sparkSubmitParameters": "--class <main_class> --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"
       }
     }, 
     "configurationOverrides": {
       "applicationConfiguration": [
         {
           "classification": "spark-defaults", 
           "properties": {
             "spark.driver.memory":"2G"
            }
         }
       ], 
       "monitoringConfiguration": {
         "persistentAppUI": "ENABLED", 
         "cloudWatchMonitoringConfiguration": {
           "logGroupName": "my_log_group", 
           "logStreamNamePrefix": "log_stream_prefix"
         }, 
         "s3MonitoringConfiguration": {
           "logUri": "s3://my_s3_log_location"
         }
       }
     }
   }
   ```

1. Utilice el comando `start-job-run` con una ruta al archivo `start-job-run-request.json` almacenado localmente.

   ```
   aws emr-containers start-job-run \
   --cli-input-json file://./start-job-run-request.json
   ```

**Para iniciar la ejecución de un trabajo con el comando `start-job-run`**

1. Proporcione todos los parámetros especificados en el comando `StartJobRun`, tal como se muestra en el siguiente ejemplo.

   ```
   aws emr-containers start-job-run \
   --virtual-cluster-id 123456 \
   --name myjob \
   --execution-role-arn execution-role-arn \
   --release-label emr-6.2.0-latest \
   --job-driver '{"sparkSubmitJobDriver": {"entryPoint": "entryPoint_location", "entryPointArguments": ["argument1", "argument2", ...], "sparkSubmitParameters": "--class <main_class> --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"}}' \
   --configuration-overrides '{"applicationConfiguration": [{"classification": "spark-defaults", "properties": {"spark.driver.memory": "2G"}}], "monitoringConfiguration": {"cloudWatchMonitoringConfiguration": {"logGroupName": "log_group_name", "logStreamNamePrefix": "log_stream_prefix"}, "persistentAppUI":"ENABLED",  "s3MonitoringConfiguration": {"logUri": "s3://my_s3_log_location" }}}'
   ```

1. En el caso de Spark SQL, ingrese todos los parámetros especificados en el comando `StartJobRun`, tal y como se muestra en el siguiente ejemplo.

   ```
   aws emr-containers start-job-run \
   --virtual-cluster-id 123456 \
   --name myjob \
   --execution-role-arn execution-role-arn \
   --release-label emr-6.7.0-latest \
   --job-driver '{"sparkSqlJobDriver": {"entryPoint": "entryPoint_location", "sparkSqlParameters": "--conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"}}' \
   --configuration-overrides '{"applicationConfiguration": [{"classification": "spark-defaults", "properties": {"spark.driver.memory": "2G"}}], "monitoringConfiguration": {"cloudWatchMonitoringConfiguration": {"logGroupName": "log_group_name", "logStreamNamePrefix": "log_stream_prefix"}, "persistentAppUI":"ENABLED",  "s3MonitoringConfiguration": {"logUri": "s3://my_s3_log_location" }}}'
   ```

# Uso de la clasificación de remitentes de trabajos
<a name="emr-eks-job-submitter"></a>

## Descripción general de
<a name="emr-eks-job-submitter-overview"></a>

La solicitud de `StartJobRun` de Amazon EMR en EKS crea un pod de *remitente de trabajos* (también conocido como *job-runner*) para generar el controlador de Spark. Puede utilizar la `emr-job-submitter` clasificación para configurar los selectores de nodos, añadir tolerancias, personalizar el registro y realizar otras modificaciones en el módulo de envío de tareas.

Las siguientes configuraciones están disponibles en la clasificación `emr-job-submitter`:

** `jobsubmitter.node.selector.[selectorKey]` **  
Se agrega al selector de nodos del módulo de envío de trabajos, con la clave *selectorKey* y el valor como valor de configuración. Por ejemplo, puede configurar un ` jobsubmitter.node.selector.identifier` selector de nodos con una clave `myIdentifier` `identifier` y un valor y el módulo de envío de trabajos tendrá un selector de nodos. `myIdentifier` Esto se puede usar para especificar en qué nodos se puede colocar el pod de remitente de trabajos. Para agregar varias claves de selección de nodos, defina varias configuraciones con este prefijo.

** `jobsubmitter.label.[labelKey]` **  
Se suma a las etiquetas del módulo de envío de trabajos, con la clave *labelKey* y el valor como valor de configuración. Para añadir varias etiquetas, defina varias configuraciones con este prefijo.

** `jobsubmitter.annotation.[annotationKey]` **  
Se suma a las anotaciones del módulo de envío del trabajo, con la clave *annotationKey* y el valor como valor de configuración. Para añadir varias anotaciones, defina varias configuraciones con este prefijo.

** `jobsubmitter.node.toleration.[tolerationKey]` **  
Añade [tolerancias al módulo](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) de envío de trabajos. De forma predeterminada, no se agrega ninguna tolerancia al módulo. La clave de la tolerancia será *tolerationKey* y el valor de la tolerancia será el valor de configuración. Si el valor de configuración se establece en una cadena que no esté vacía, el operador lo será. `Equals` Si el valor de configuración está establecido en`""`, entonces el operador lo será`Exists`.

** `jobsubmitter.node.toleration.[tolerationKey].[effect]` **  
Añade un efecto de tolerancia al prefijo*tolerationKey*. Este campo es obligatorio al añadir tolerancias. Los valores permitidos para el campo de efecto son ` NoExecute``NoSchedule`, y`PreferNoSchedule`.

** `jobsubmitter.node.toleration.[tolerationKey].[tolerationSeconds]` **  
Agrega TolerationSeconds al prefijo. *tolerationKey* Campo opcional. Solo se aplica cuando el efecto es. `NoExecute`

** `jobsubmitter.scheduler.name` **  
Establece un nombre de programador personalizado para el módulo de envío de trabajos.

** `jobsubmitter.logging` **  
Activa o deshabilita el registro en el módulo de envío de trabajos. Cuando está configurado, ` DISABLED` el contenedor de registro se elimina del módulo de envío de trabajos, lo que deshabilita cualquier registro para este módulo especificado en el módulo`monitoringConfiguration`, como o. `s3MonitoringConfiguration` `cloudWatchMonitoringConfiguration` Si esta configuración no está establecida o se establece en cualquier otro valor, se habilita el inicio de sesión en el módulo de envío de trabajos.

** `jobsubmitter.logging.image` **  
Establece una imagen personalizada que se utilizará en el contenedor de registro del pod de remitente de trabajos.

** `jobsubmitter.logging.request.cores` **  
Establece un valor personalizado para el número CPUs, en unidades de CPU, del contenedor de registro del módulo de envío de trabajos. De forma predeterminada, se establece en **100 m**.

** `jobsubmitter.logging.request.memory` **  
Establece un valor personalizado para la cantidad de memoria, en bytes, del contenedor de registro del pod de remitente de trabajos. De forma predeterminada, se establece en **200 Mi**. Un mebibyte es una unidad de medida similar a un megabyte.

** `jobsubmitter.container.image` **  
Establece una imagen personalizada para el contenedor del módulo de envío de `job-runner` trabajos.

** `jobsubmitter.container.image.pullPolicy` **  
Establece [imagePullPolicy](https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy)los contenedores del módulo de envío de trabajos.

Recomendamos colocar los pods de remitente de trabajos en las instancias bajo demanda. Colocar los pods de remitente de trabajos en las instancias de spot podría provocar un error en el trabajo si la instancia en la que se ejecuta el pod de remitente de trabajos está sujeta a una interrupción de la instancia de spot. También puede [colocar el módulo de envío de trabajos en una única zona de disponibilidad o utilizar cualquier etiqueta de Kubernetes que esté](#emr-eks-job-submitter-ex-ec2) aplicada a los nodos.

## Ejemplos de clasificación de remitentes de trabajos
<a name="emr-eks-job-submitter-examples"></a>

**Topics**
+ [Solicitud de `StartJobRun` con ubicación de nodos bajo demanda para el pod de remitente de trabajos](#emr-eks-job-submitter-ex-od)
+ [`StartJobRun`solicitud con ubicación de nodo Single-AZ y ubicación de tipo instancia Amazon EC2 para el pod de remitente del trabajo](#emr-eks-job-submitter-ex-ec2)
+ [`StartJobRun`solicitud con etiquetas, anotaciones y un programador personalizado para el pod del remitente del trabajo](#emr-eks-job-submitter-label-annotation-scheduler)
+ [`StartJobRun`solicitud con una tolerancia aplicada al módulo de presentación del trabajo con la clave`dedicated`, el valor`graviton_machines`, el efecto y una de `NoExecute` 60 segundos `tolerationSeconds`](#emr-eks-job-submitter-tolerations)
+ [`StartJobRun`solicitud con el registro deshabilitado para el módulo de envío de trabajos](#emr-eks-job-submitter-logging-disabled)
+ [`StartJobRun`solicitud con imagen, CPU y memoria de contenedor de registro personalizados para el módulo de envío de trabajos](#emr-eks-job-submitter-custom)
+ [`StartJobRun`solicitud con un contenedor de envío de trabajos personalizado, imagen y política de extracción](#emr-eks-job-submitter-custom-container)

### Solicitud de `StartJobRun` con ubicación de nodos bajo demanda para el pod de remitente de trabajos
<a name="emr-eks-job-submitter-ex-od"></a>

```
cat >spark-python-in-s3-nodeselector-job-submitter.json << EOF
{
  "name": "spark-python-in-s3-nodeselector", 
  "virtualClusterId": "virtual-cluster-id", 
  "executionRoleArn": "execution-role-arn", 
  "releaseLabel": "emr-6.11.0-latest", 
  "jobDriver": {
    "sparkSubmitJobDriver": {
      "entryPoint": "s3://S3-prefix/trip-count.py", 
      "sparkSubmitParameters": "--conf spark.driver.cores=5  --conf spark.executor.memory=20G --conf spark.driver.memory=15G --conf spark.executor.cores=6"
    }
  }, 
  "configurationOverrides": {
    "applicationConfiguration": [
      {
        "classification": "spark-defaults", 
        "properties": {
          "spark.dynamicAllocation.enabled":"false"
        }
      },
      {
        "classification": "emr-job-submitter",
        "properties": {
          "jobsubmitter.node.selector.eks.amazonaws.com/capacityType": "ON_DEMAND"
        }
      }
    ], 
    "monitoringConfiguration": {
      "cloudWatchMonitoringConfiguration": {
        "logGroupName": "/emr-containers/jobs", 
        "logStreamNamePrefix": "demo"
      }, 
      "s3MonitoringConfiguration": {
        "logUri": "s3://joblogs"
      }
    }
  }
}
EOF
aws emr-containers start-job-run --cli-input-json file:///spark-python-in-s3-nodeselector-job-submitter.json
```

### `StartJobRun`solicitud con ubicación de nodo Single-AZ y ubicación de tipo instancia Amazon EC2 para el pod de remitente del trabajo
<a name="emr-eks-job-submitter-ex-ec2"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-job-submitter",
      "properties": {
        "jobsubmitter.node.selector.topology.kubernetes.io/zone": "Availability Zone",
        "jobsubmitter.node.selector.node.kubernetes.io/instance-type":"m5.4xlarge"
      }
    }
  ]
}
```

### `StartJobRun`solicitud con etiquetas, anotaciones y un programador personalizado para el pod del remitente del trabajo
<a name="emr-eks-job-submitter-label-annotation-scheduler"></a>

```
"configurationOverrides": { 
  "applicationConfiguration": [ 
    {
      "classification": "emr-job-submitter", 
      "properties": {
        "jobsubmitter.label.label1": "value1",
        "jobsubmitter.label.label2": "value2",
        "jobsubmitter.annotation.ann1": "value1",
        "jobsubmitter.annotation.ann2": "value2",
        "jobsubmitter.scheduler.name": "custom-scheduler"
      }
    }
  ]
}
```

### `StartJobRun`solicitud con una tolerancia aplicada al módulo de presentación del trabajo con la clave`dedicated`, el valor`graviton_machines`, el efecto y una de `NoExecute` 60 segundos `tolerationSeconds`
<a name="emr-eks-job-submitter-tolerations"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-job-submitter",
      "properties": {
        "jobsubmitter.node.toleration.dedicated":"graviton_machines",
        "jobsubmitter.node.toleration.dedicated.effect":"NoExecute",
        "jobsubmitter.node.toleration.dedicated.tolerationSeconds":"60"
      }
    }
  ]
}
```

### `StartJobRun`solicitud con el registro deshabilitado para el módulo de envío de trabajos
<a name="emr-eks-job-submitter-logging-disabled"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-job-submitter",
      "properties": {
        "jobsubmitter.logging": "DISABLED"
      }
    }
  ], 
  "monitoringConfiguration": {
    "cloudWatchMonitoringConfiguration": {
      "logGroupName": "/emr-containers/jobs", 
      "logStreamNamePrefix": "demo"
    }, 
    "s3MonitoringConfiguration": {
      "logUri": "s3://joblogs"
    }
  }
}
```

### `StartJobRun`solicitud con imagen, CPU y memoria de contenedor de registro personalizados para el módulo de envío de trabajos
<a name="emr-eks-job-submitter-custom"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-job-submitter",
      "properties": {
        "jobsubmitter.logging.image": "YOUR_ECR_IMAGE_URL",
        "jobsubmitter.logging.request.memory": "200Mi",
        "jobsubmitter.logging.request.cores": "0.5"
      }
    }
  ], 
  "monitoringConfiguration": {
    "cloudWatchMonitoringConfiguration": {
      "logGroupName": "/emr-containers/jobs", 
      "logStreamNamePrefix": "demo"
    }, 
    "s3MonitoringConfiguration": {
      "logUri": "s3://joblogs"
    }
  }
}
```

### `StartJobRun`solicitud con un contenedor de envío de trabajos personalizado, imagen y política de extracción
<a name="emr-eks-job-submitter-custom-container"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-job-submitter",
      "properties": {
        "jobsubmitter.container.image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/emr6.11_custom_repo",
        "jobsubmitter.container.image.pullPolicy": "kubernetes pull policy"
      }
    }
  ]
}
```

# Uso de la clasificación de valores predeterminados de contenedores de Amazon EMR
<a name="emr-eks-job-submitter-container-defaults"></a>

## Descripción general de
<a name="emr-eks-job-submitter-container-defaults-overview"></a>

Las siguientes configuraciones están disponibles en la clasificación `emr-containers-defaults`:

** `job-start-timeout` **  
De forma predeterminada, se agota el tiempo de espera de un trabajo si no se puede iniciar y espera en estado de ` SUBMITTED` durante 15 minutos. Esta configuración cambia la cantidad de segundos que se deben esperar antes de que se agote el trabajo.

** `executor.logging` **  
Activa o deshabilita el registro en los módulos ejecutores. Cuando se establece esta opción, ` DISABLED` el contenedor de registro se elimina de los módulos ejecutores, lo que deshabilita cualquier registro de los módulos especificados en ellos`monitoringConfiguration`, como o. `s3MonitoringConfiguration` `cloudWatchMonitoringConfiguration` Si esta configuración no está establecida o se establece en cualquier otro valor, se habilita el inicio de sesión en los pods ejecutores.

** `logging.image` **  
Establece una imagen personalizada que se usará en el contenedor de registro de los pods del controlador y del ejecutor.

** `logging.request.cores` **  
Establece un valor personalizado para el número CPUs, en unidades de CPU, del contenedor de registro de los módulos del controlador y del ejecutor. No se establece de forma predeterminada.

** `logging.request.memory` **  
Establece un valor personalizado para la cantidad de memoria, en bytes, del contenedor de registro de los pods del controlador y del ejecutor. De forma predeterminada, se establece en **512 Mi**. Un mebibyte es una unidad de medida similar a un megabyte.

## Ejemplos de clasificación de remitentes de trabajos
<a name="emr-eks-job-submitter-container-examples"></a>

**Topics**
+ [Solicitud de `StartJobRun` con tiempo de espera de trabajo personalizado](#emr-eks-job-submitter-container-custom-timeout)
+ [`StartJobRun`solicitud con el registro deshabilitado para los pods de ejecución](#emr-eks-executor-logging-disabled)
+ [`StartJobRun`solicitud con imagen de contenedor de registro personalizado, CPU y memoria para los módulos de controlador y ejecutor](#emr-eks-job-submitter-container-custom-image-cpu)

### Solicitud de `StartJobRun` con tiempo de espera de trabajo personalizado
<a name="emr-eks-job-submitter-container-custom-timeout"></a>

```
{
  "name": "spark-python", 
  "virtualClusterId": "virtual-cluster-id", 
  "executionRoleArn": "execution-role-arn", 
  "releaseLabel": "emr-6.11.0-latest", 
  "jobDriver": {
    "sparkSubmitJobDriver": {
      "entryPoint": "s3://S3-prefix/trip-count.py"
    }
  }, 
  "configurationOverrides": {
    "applicationConfiguration": [
      {
        "classification": "emr-containers-defaults", 
        "properties": {
          "job-start-timeout": "1800"
        }
      }
    ], 
    "monitoringConfiguration": {
      "cloudWatchMonitoringConfiguration": {
        "logGroupName": "/emr-containers/jobs", 
        "logStreamNamePrefix": "demo"
      }, 
      "s3MonitoringConfiguration": {
        "logUri": "s3://joblogs"
      }
    }
  }
}
```

### `StartJobRun`solicitud con el registro deshabilitado para los pods de ejecución
<a name="emr-eks-executor-logging-disabled"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-containers-defaults", 
      "properties": {
        "executor.logging": "DISABLED"
      }
    }
  ], 
  "monitoringConfiguration": {
    "cloudWatchMonitoringConfiguration": {
      "logGroupName": "/emr-containers/jobs", 
      "logStreamNamePrefix": "demo"
    }, 
    "s3MonitoringConfiguration": {
      "logUri": "s3://joblogs"
    }
  }
}
```

### `StartJobRun`solicitud con imagen de contenedor de registro personalizado, CPU y memoria para los módulos de controlador y ejecutor
<a name="emr-eks-job-submitter-container-custom-image-cpu"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-containers-defaults", 
      "properties": {
        "logging.image": "YOUR_ECR_IMAGE_URL",
        "logging.request.memory": "200Mi",
        "logging.request.cores": "0.5"
      }
    }
  ], 
  "monitoringConfiguration": {
    "cloudWatchMonitoringConfiguration": {
      "logGroupName": "/emr-containers/jobs", 
      "logStreamNamePrefix": "demo"
    }, 
    "s3MonitoringConfiguration": {
      "logUri": "s3://joblogs"
    }
  }
}
```

# Ejecución de trabajos de Spark con el operador de Spark
<a name="spark-operator"></a>

Las versiones 6.10.0 y posteriores de Amazon EMR admiten el operador de Kubernetes para Apache Spark, o *el operador de Spark*, como modelo de envío de trabajos para Amazon EMR en EKS. Con el operador de Spark, puede implementar y administrar las aplicaciones de Spark con el tiempo de ejecución de versiones de Amazon EMR en sus propios clústeres de Amazon EKS. Una vez que haya implementado el operador de Spark en su clúster de Amazon EKS, puede enviar las solicitudes de Spark de inmediato al operador. El operador administra el ciclo de vida de las aplicaciones de Spark.

**nota**  
Amazon EMR calcula los precios de Amazon EKS en función de la vCPU y el consumo de memoria. Este cálculo se aplica a los pods de controladores y ejecutores. Este cálculo comienza cuando usted descarga la imagen de la aplicación de Amazon EMR hasta que finaliza el pod de Amazon EKS y se redondea al segundo más cercano.

**Topics**
+ [Configuración del operador de Spark para Amazon EMR en EKS](spark-operator-setup.md)
+ [Cómo comenzar a utilizar el operador de Spark para Amazon EMR en EKS](spark-operator-gs.md)
+ [Uso del escalado automático vertical con el operador de Spark para Amazon EMR en EKS](spark-operator-vas.md)
+ [Desinstalación del operador de Spark para Amazon EMR en EKS](spark-operator-uninstall.md)
+ [Uso de la configuración de supervisión para supervisar el operador de Spark Kubernetes y los trabajos de Spark](spark-operator-monitoring-configuration.md)
+ [Seguridad y operador de Spark con Amazon EMR en EKS](spark-operator-security.md)

# Configuración del operador de Spark para Amazon EMR en EKS
<a name="spark-operator-setup"></a>

Complete las siguientes tareas para preparar la configuración antes de instalar el operador de Spark en Amazon EKS. Si ya se registró en Amazon Web Services (AWS) y ha usado Amazon EKS, lo tiene todo casi listo para comenzar a utilizar Amazon EMR en EKS. Complete las siguientes tareas para la configuración del operador de Spark en Amazon ECS. Si ya ha completado alguno de los requisitos previos, puede omitirlos y pasar al siguiente.
+ **[Instalar o actualizar a la última versión de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)**: si ya ha instalado el AWS CLI, confirme que tiene la última versión.
+ **[Configure kubectl y eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) **: eksctl es una herramienta de línea de comandos que se utiliza para comunicarse con Amazon EKS.
+ **[Instale Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)**: el administrador de paquetes Helm para Kubernetes le ayuda a instalar y administrar aplicaciones en el clúster de Kubernetes. 
+ **[Comience con Amazon EKS: eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) **: siga los pasos para crear un nuevo clúster de Kubernetes con nodos en Amazon EKS.
+ **[Seleccione un URI de imagen base de Amazon EMR](docker-custom-images-tag.md) (versión 6.10.0 o posterior)**: el operador de Spark es compatible con las versiones 6.10.0 y posteriores de Amazon EMR.

# Cómo comenzar a utilizar el operador de Spark para Amazon EMR en EKS
<a name="spark-operator-gs"></a>

Este tema le ayuda a comenzar a utilizar el operador de Spark en Amazon EKS mediante la implementación de una aplicación de Spark y una aplicación de Schedule Spark.

## Instalar el operador de Spark
<a name="spark-operator-install"></a>

Siga estos pasos para instalar el operador de Kubernetes para Apache Spark.

1. Si aún no lo ha hecho, complete los pasos de [Configuración del operador de Spark para Amazon EMR en EKS](spark-operator-setup.md).

1. Autentique su cliente de Helm en el registro de Amazon ECR. En el siguiente comando, sustituya los *region-id* valores de la [Cuentas de registro de Amazon ECR por región](docker-custom-images-tag.md#docker-custom-images-ECR) página por los que prefiera Región de AWS y por el *ECR-registry-account* valor correspondiente a la región.

   ```
   aws ecr get-login-password \
   --region region-id | helm registry login \
   --username AWS \
   --password-stdin ECR-registry-account.dkr.ecr.region-id.amazonaws.com
   ```

1. Instale el operador de Spark con el siguiente comando.

   Para el parámetro `--version` del gráfico de Helm, use su etiqueta de lanzamiento de Amazon EMR sin el prefijo `emr-` y sin el sufijo de fecha. Por ejemplo, con la versión `emr-6.12.0-java17-latest`, especifique `6.12.0-java17`. El ejemplo del siguiente comando usa la versión `emr-7.12.0-latest`, por lo que especifica `7.12.0` para el gráfico de Helm `--version`.

   ```
   helm install spark-operator-demo \
     oci://895885662937.dkr.ecr.region-id.amazonaws.com/spark-operator \
     --set emrContainers.awsRegion=region-id \
     --version 7.12.0 \
     --namespace spark-operator \
     --create-namespace
   ```

   De forma predeterminada, el comando crea una cuenta de servicio `emr-containers-sa-spark-operator` para el operador de Spark. Para usar una cuenta de servicio diferente, proporcione el argumento `serviceAccounts.sparkoperator.name`. Por ejemplo:

   ```
   --set serviceAccounts.sparkoperator.name my-service-account-for-spark-operator
   ```

   Si quiere [usar el escalado automático vertical con el operador de Spark](), agregue la siguiente línea al comando de instalación para admitir webhooks para el operador:

   ```
   --set webhook.enable=true
   ```

1. Compruebe que haya instalado el gráfico de Helm con el comando `helm list`:

   ```
   helm list --namespace spark-operator -o yaml
   ```

   El comando `helm list` debería devolver la información de lanzamiento del gráfico de Helm recién implementado:

   ```
   app_version: v1beta2-1.3.8-3.1.1
   chart: spark-operator-7.12.0
   name: spark-operator-demo
   namespace: spark-operator
   revision: "1"
   status: deployed
   updated: 2023-03-14 18:20:02.721638196 +0000 UTC
   ```

1. Complete la instalación con todas las opciones adicionales que necesite. Para obtener más información, consulte la [https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/blob/master/charts/spark-operator-chart/README.md](https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/blob/master/charts/spark-operator-chart/README.md)documentación en GitHub.

## Ejecutar una aplicación de Spark
<a name="spark-operator-run"></a>

El operador de Spark es compatible con Amazon EMR 6.10.0 o una versión posterior. Cuando instala el operador de Spark, este crea la cuenta de servicio `emr-containers-sa-spark` para ejecutar las aplicaciones de Spark de forma predeterminada. Siga estos pasos para ejecutar una aplicación de Spark con el operador de Spark en Amazon EMR en EKS 6.10.0 o una versión posterior.

1. Antes de poder ejecutar una aplicación de Spark con el operador de Spark, complete los pasos indicados en [Configuración del operador de Spark para Amazon EMR en EKS](spark-operator-setup.md) y [Instalar el operador de Spark](#spark-operator-install). 

1. Cree un archivo de definición de `SparkApplication` `spark-pi.yaml` con el siguiente contenido: 

   ```
   apiVersion: "sparkoperator.k8s.io/v1beta2"
   kind: SparkApplication
   metadata:
     name: spark-pi
     namespace: spark-operator
   spec:
     type: Scala
     mode: cluster
     image: "895885662937.dkr.ecr.us-west-2.amazonaws.com/spark/emr-6.10.0:latest"
     imagePullPolicy: Always
     mainClass: org.apache.spark.examples.SparkPi
     mainApplicationFile: "local:///usr/lib/spark/examples/jars/spark-examples.jar"
     sparkVersion: "3.3.1"
     restartPolicy:
       type: Never
     volumes:
       - name: "test-volume"
         hostPath:
           path: "/tmp"
           type: Directory
     driver:
       cores: 1
       coreLimit: "1200m"
       memory: "512m"
       labels:
         version: 3.3.1
       serviceAccount: emr-containers-sa-spark
       volumeMounts:
         - name: "test-volume"
           mountPath: "/tmp"
     executor:
       cores: 1
       instances: 1
       memory: "512m"
       labels:
         version: 3.3.1
       volumeMounts:
         - name: "test-volume"
           mountPath: "/tmp"
   ```

1. Luego, implemente la aplicación de Spark con el siguiente comando. Esto también creará un objeto `SparkApplication` denominado `spark-pi`:

   ```
   kubectl apply -f spark-pi.yaml
   ```

1. Compruebe los eventos del objeto `SparkApplication` con el siguiente comando: 

   ```
   kubectl describe sparkapplication spark-pi --namespace spark-operator
   ```

Para obtener más información sobre cómo enviar solicitudes a Spark a través del operador de Spark, consulta [Cómo usar un `SparkApplication`](https://www.kubeflow.org/docs/components/spark-operator/user-guide/using-sparkapplication/) en la `spark-on-k8s-operator` documentación de. GitHub

## Uso de Amazon S3 para almacenamiento
<a name="spark-operator-s3-storage"></a>

Para usar Amazon S3 como opción de almacenamiento de archivos, añada las siguientes configuraciones al archivo YAML.

```
hadoopConf:
# EMRFS filesystem
  fs.s3.customAWSCredentialsProvider: com.amazonaws.auth.WebIdentityTokenCredentialsProvider
  fs.s3.impl: com.amazon.ws.emr.hadoop.fs.EmrFileSystem
  fs.AbstractFileSystem.s3.impl: org.apache.hadoop.fs.s3.EMRFSDelegate
  fs.s3.buffer.dir: /mnt/s3
  fs.s3.getObject.initialSocketTimeoutMilliseconds: "2000"
  mapreduce.fileoutputcommitter.algorithm.version.emr_internal_use_only.EmrFileSystem: "2"
  mapreduce.fileoutputcommitter.cleanup-failures.ignored.emr_internal_use_only.EmrFileSystem: "true"
sparkConf:
 # Required for EMR Runtime
 spark.driver.extraClassPath: /usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*
 spark.driver.extraLibraryPath: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
 spark.executor.extraClassPath: /usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*
 spark.executor.extraLibraryPath: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
```

 Si utiliza las versiones 7.2.0 o posteriores de Amazon EMR, las configuraciones se incluyen de forma predeterminada. En ese caso, puede establecer la ruta del archivo en `s3://<bucket_name>/<file_path>` en lugar de en `local://<file_path>` en el archivo YAML de la aplicación Spark. 

A continuación, envíe la aplicación de Spark como de costumbre.

# Uso del escalado automático vertical con el operador de Spark para Amazon EMR en EKS
<a name="spark-operator-vas"></a>

A partir de Amazon EMR 7.0, puede usar Amazon EMR en el escalado automático vertical de EKS para simplificar la administración de recursos. Ajusta automáticamente los recursos de memoria y CPU para adaptarlos a las necesidades de la carga de trabajo que proporciona a las aplicaciones de Spark de Amazon EMR. Para obtener más información, consulte [Uso del escalado automático vertical con trabajos de Spark de Amazon EMR](jobruns-vas.md).

En esta sección, se describe cómo configurar el operador de Spark para usar el escalado automático vertical.

## Requisitos previos
<a name="spark-operator-vas-prereqs"></a>

Antes de configurar la supervisión, asegúrese de completar las siguientes tareas de configuración:
+ Realice los pasos que se indican en [Configuración del operador de Spark para Amazon EMR en EKS](spark-operator-setup.md).
+ (opcional) Si anteriormente instalaste una versión anterior del operador Spark, elimina el SparkApplication/ScheduledSparkApplication CRD.

  ```
  kubectl delete crd sparkApplication
  kubectl delete crd scheduledSparkApplication
  ```
+ Realice los pasos que se indican en [Instalar el operador de Spark](spark-operator-gs.md#spark-operator-install). En el paso 3, agregue la siguiente línea al comando de instalación para admitir webhooks para el operador:

  ```
  --set webhook.enable=true
  ```
+ Realice los pasos que se indican en [Configuración del escalado automático vertical de Amazon EMR en EKS](jobruns-vas-setup.md).
+ Conceda acceso a los archivos de su ubicación de Amazon S3:

  1. Anote su cuenta de servicio del controlador y el operador con el `JobExecutionRole` que tenga permisos de S3.

     ```
     kubectl annotate serviceaccount -n spark-operator emr-containers-sa-spark eks.amazonaws.com/role-arn=JobExecutionRole
     kubectl annotate serviceaccount -n spark-operator emr-containers-sa-spark-operator eks.amazonaws.com/role-arn=JobExecutionRole
     ```

  1. Actualice la política de confianza de su rol de ejecución de trabajos en ese espacio de nombres.

     ```
     aws emr-containers update-role-trust-policy \
     --cluster-name cluster \
     --namespace ${Namespace}\
     --role-name iam_role_name_for_job_execution
     ```

  1. Edite la política de confianza del rol de IAM de su rol de ejecución de trabajos y actualice la `serviceaccount` de `emr-containers-sa-spark-*-*-xxxx` a `emr-containers-sa-*`.

     ```
     {
         "Effect": "Allow",
         "Principal": {
             "Federated": "OIDC-provider"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
             "StringLike": {
                 "OIDC": "system:serviceaccount:${Namespace}:emr-containers-sa-*"
             }
         }
     }
     ```

  1. Si utiliza Amazon S3 como almacenamiento de archivos, añada los valores predeterminados siguientes a su archivo yaml.

     ```
     hadoopConf:
     # EMRFS filesystem
       fs.s3.customAWSCredentialsProvider: com.amazonaws.auth.WebIdentityTokenCredentialsProvider
       fs.s3.impl: com.amazon.ws.emr.hadoop.fs.EmrFileSystem
       fs.AbstractFileSystem.s3.impl: org.apache.hadoop.fs.s3.EMRFSDelegate
       fs.s3.buffer.dir: /mnt/s3
       fs.s3.getObject.initialSocketTimeoutMilliseconds: "2000"
       mapreduce.fileoutputcommitter.algorithm.version.emr_internal_use_only.EmrFileSystem: "2"
       mapreduce.fileoutputcommitter.cleanup-failures.ignored.emr_internal_use_only.EmrFileSystem: "true"
     sparkConf:
      # Required for EMR Runtime
      spark.driver.extraClassPath: /usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*
      spark.driver.extraLibraryPath: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
      spark.executor.extraClassPath: /usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*
      spark.executor.extraLibraryPath: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
     ```

## Ejecutar un trabajo con escalado automático vertical en el operador de Spark
<a name="spark-operator-vas-run"></a>

Para poder ejecutar una aplicación de Spark con el operador de Spark, complete los pasos indicados en [Requisitos previos](#spark-operator-vas-prereqs). 

Para utilizar el escalado automático vertical con el operador de Spark, añada la siguiente configuración al controlador para la especificación de la aplicación de Spark a fin de activar el escalado automático vertical:

```
dynamicSizing:
  mode: Off
  signature: "my-signature"
```

Esta configuración permite el escalado automático vertical y es una configuración de firma obligatoria que le permite elegir una firma para su trabajo.

Para obtener más información sobre las configuraciones y los valores de los parámetros, consulte [Configuración del escalado automático vertical para Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/jobruns-vas-configure.html). De forma predeterminada, su trabajo se envía en el modo **Desactivado** de escalado automático vertical solo de supervisión. Este estado de supervisión le permite calcular y ver las recomendaciones de recursos sin llevar a cabo el escalado automático. Para obtener más información, consulte [Modos de escalado automático](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/jobruns-vas-configure.html#jobruns-vas-parameters-opt-mode).

El siguiente ejemplo muestra un archivo de definición de `SparkApplication` denominado `spark-pi.yaml` y con las configuraciones necesarias para utilizar el escalado automático vertical.

```
apiVersion: "sparkoperator.k8s.io/v1beta2"
kind: SparkApplication
metadata:
  name: spark-pi
  namespace: spark-operator
spec:
  type: Scala
  mode: cluster
  image: "895885662937.dkr.ecr.us-west-2.amazonaws.com/spark/emr-7.12.0:latest"
  imagePullPolicy: Always
  mainClass: org.apache.spark.examples.SparkPi
  mainApplicationFile: "local:///usr/lib/spark/examples/jars/spark-examples.jar"
  sparkVersion: "3.4.1"
  dynamicSizing:
    mode: Off
    signature: "my-signature"
  restartPolicy:
    type: Never
  volumes:
    - name: "test-volume"
      hostPath:
        path: "/tmp"
        type: Directory
  driver:
    cores: 1
    coreLimit: "1200m"
    memory: "512m"
    labels:
      version: 3.4.1
    serviceAccount: emr-containers-sa-spark
    volumeMounts:
      - name: "test-volume"
        mountPath: "/tmp"
  executor:
    cores: 1
    instances: 1
    memory: "512m"
    labels:
      version: 3.4.1
    volumeMounts:
      - name: "test-volume"
        mountPath: "/tmp"
```

Luego, implemente la aplicación de Spark con el siguiente comando. Esto también creará un objeto `SparkApplication` denominado `spark-pi`:

```
kubectl apply -f spark-pi.yaml
```

Para obtener más información sobre cómo enviar solicitudes a Spark a través del operador de Spark, consulta [Cómo usar un `SparkApplication`](https://www.kubeflow.org/docs/components/spark-operator/user-guide/using-sparkapplication/) en la `spark-on-k8s-operator` documentación de. GitHub

## Verificación de la funcionalidad de escalado automático vertical
<a name="spark-operator-vas-verify"></a>

Para comprobar que el escalado automático vertical funcione correctamente en el trabajo enviado, use kubectl para obtener el recurso personalizado `verticalpodautoscaler` y ver sus recomendaciones de escalado.

```
kubectl get verticalpodautoscalers --all-namespaces \ 
-l=emr-containers.amazonaws.com/dynamic.sizing.signature=my-signature
```

El resultado de esta consulta debe parecerse al siguiente:

```
NAMESPACE        NAME                                                          MODE   CPU   MEM         PROVIDED   AGE
spark-operator   ds-p73j6mkosvc4xeb3gr7x4xol2bfcw5evqimzqojrlysvj3giozuq-vpa   Off          580026651   True       15m
```

Si el resultado no es similar o contiene un código de error, consulte [Solución de problemas en el escalado automático vertical de Amazon EMR en EKS](troubleshooting-vas.md) para ver los pasos que le ayudarán a resolver el problema.

Para eliminar los pods y las aplicaciones del catálogo, ejecute el siguiente comando:

```
kubectl delete sparkapplication spark-pi
```

# Desinstalación del operador de Spark para Amazon EMR en EKS
<a name="spark-operator-uninstall"></a>

Siga estos pasos para desinstalar el operador de Spark.

1. Elimine el operador de Spark con el espacio de nombres correcto. En este ejemplo, el espacio de nombres es `spark-operator-demo`.

   ```
   helm uninstall spark-operator-demo -n spark-operator
   ```

1. Elimine la cuenta de servicio del operador de Spark:

   ```
   kubectl delete sa emr-containers-sa-spark-operator -n spark-operator
   ```

1. Elimina el operador Spark `CustomResourceDefinitions` (CRDs):

   ```
   kubectl delete crd sparkapplications.sparkoperator.k8s.io
   kubectl delete crd scheduledsparkapplications.sparkoperator.k8s.io
   ```

# Uso de la configuración de supervisión para supervisar el operador de Spark Kubernetes y los trabajos de Spark
<a name="spark-operator-monitoring-configuration"></a>

La configuración de supervisión le permite configurar fácilmente el archivado de registros de sus aplicaciones y registros de operadores de Spark en Amazon S3 o Amazon CloudWatch. Puede elegir uno o ambos. Al hacerlo, se agrega un contenedor asociado de agentes de registro a los pods de operadores, controladores y ejecutores de Spark y, posteriormente, se reenvían los registros de estos componentes a los receptores configurados.

## Requisitos previos
<a name="spark-operator-monitoring-configuration-prereqs"></a>

Antes de configurar la supervisión, asegúrese de completar las siguientes tareas de configuración:

1. (Opcional) Si anteriormente instalaste una versión anterior del operador Spark, elimina la *SparkApplication/ScheduledSparkApplication*CRD.

   ```
   kubectl delete crd scheduledsparkapplications.sparkoperator.k8s.io
   kubectl delete crd sparkapplications.sparkoperator.k8s.io
   ```

1. Cree un rol de operator/job ejecución en IAM si aún no lo tiene.

1. Ejecute el siguiente comando para actualizar la política de confianza del rol de operator/job ejecución que acaba de crear:

   ```
   aws emr-containers update-role-trust-policy \ 
   --cluster-name cluster \
   --namespace namespace \
   --role-name iam_role_name_for_operator/job_execution_role
   ```

1. Edite la política de confianza del rol de IAM de su rol de operator/job ejecución de la siguiente manera:

   ```
   {
       "Effect": "Allow",
       "Principal": {
           "Federated": "${OIDC-provider}"
       },
       "Action": "sts:AssumeRoleWithWebIdentity",
       "Condition": {
           "StringLike": {
               "OIDC_PROVIDER:sub": "system:serviceaccount:${Namespace}:emr-containers-sa-*"
           }
       }
   }
   ```

1. Cree una política *monitoringConfiguration* en IAM con los siguientes permisos:

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "logs:DescribeLogStreams",
           "logs:CreateLogStream",
           "logs:CreateLogGroup",
           "logs:PutLogEvents"
         ],
         "Resource": [
           "arn:aws:logs:*:*:log-group:log_group_name",
           "arn:aws:logs:*:*:log-group:log_group_name:*"
         ],
         "Sid": "AllowLOGSDescribelogstreams"
       },
       {
         "Effect": "Allow",
         "Action": [
           "logs:DescribeLogGroups"
         ],
         "Resource": [
           "*"
         ],
         "Sid": "AllowLOGSDescribeloggroups"
       },
       {
         "Effect": "Allow",
         "Action": [
           "s3:PutObject",
           "s3:GetObject",
           "s3:ListBucket"
         ],
         "Resource": [
           "arn:aws:s3:::bucket_name",
           "arn:aws:s3:::bucket_name/*"
         ],
         "Sid": "AllowS3Putobject"
       }
     ]
   }
   ```

------

1. Adjunte la política anterior a su función operator/job de ejecución.

# Registros del operador de Spark
<a name="spark-operator-monitoring-configuration-logs"></a>

Puede definir la configuración de supervisión de la siguiente manera cuando realice `helm install`:

```
helm install spark-operator spark-operator \
--namespace namespace \
--set emrContainers.awsRegion=aws_region \
--set emrContainers.monitoringConfiguration.image=log_agent_image_url \
--set emrContainers.monitoringConfiguration.s3MonitoringConfiguration.logUri=S3_bucket_uri \
--set emrContainers.monitoringConfiguration.cloudWatchMonitoringConfiguration.logGroupName=log_group_name \
--set emrContainers.monitoringConfiguration.cloudWatchMonitoringConfiguration.logStreamNamePrefix=log_stream_prefix \
--set emrContainers.monitoringConfiguration.sideCarResources.limits.cpuLimit=500m \
--set emrContainers.monitoringConfiguration.sideCarResources.limits.memoryLimit=512Mi \
--set emrContainers.monitoringConfiguration.containerLogRotationConfiguration.rotationSize=2GB \
--set emrContainers.monitoringConfiguration.containerLogRotationConfiguration.maxFilesToKeep=10 \
--set webhook.enable=true \
--set emrContainers.operatorExecutionRoleArn=operator_execution_role_arn
```

**Monitorización de la configuración**

A continuación, se describen las opciones de configuración disponibles en **monitoringConfiguration**.
+ **Imagen** (opcional): URL de la imagen del agente de registro. Se procesará emrReleaseLabel si no se proporciona.
+ **s3 MonitoringConfiguration** — Configure esta opción para archivar en Amazon S3.
  + **logUri** (obligatorio): la ruta del bucket de Amazon S3 donde desea almacenar sus registros.
  + Los siguientes son ejemplos de formatos para las rutas de los buckets de Amazon S3, después de que se carguen los registros. El primer ejemplo muestra que la rotación de registros no está habilitada.

    ```
    s3://${logUri}/${POD NAME}/operator/stdout.gz
    s3://${logUri}/${POD NAME}/operator/stderr.gz
    ```

    La rotación de registros está habilitada de forma predeterminada. Puede ver tanto un archivo rotado, con un índice creciente, como un archivo actual, que es igual al del ejemplo anterior.

    ```
    s3://${logUri}/${POD NAME}/operator/stdout_YYYYMMDD_index.gz
    s3://${logUri}/${POD NAME}/operator/stderr_YYYYMMDD_index.gz
    ```
+ **cloudWatchMonitoringConfiguración**: la clave de configuración a la que se debe configurar el reenvío. Amazon CloudWatch
  + **logGroupName**(obligatorio): nombre del grupo de Amazon CloudWatch registros al que desea enviar los registros. Si el grupo no existe, se crea automáticamente.
  + **logStreamNamePrefijo** (opcional): nombre del flujo de registros al que desea enviar los registros. El valor predeterminado es una cadena vacía. El formato Amazon CloudWatch es el siguiente:

    ```
    ${logStreamNamePrefix}/${POD NAME}/STDOUT or STDERR
    ```
+ **sideCarResources**(opcional): la clave de configuración para establecer los límites de recursos en el contenedor sidecar Fluentd lanzado.
  + **memoryLimit** (opcional): el límite de memoria. Ajústelo según sus necesidades. El valor predeterminado es 512Mi.
  + **cpuLimit** (opcional): el límite de la CPU. Ajústelo según sus necesidades. El valor predeterminado es 500 m.
+ **containerLogRotationConfiguración** (opcional): controla el comportamiento de rotación del registro del contenedor. Está habilitada de forma predeterminada.
  + **rotationSize** (obligatorio): especifica el tamaño del archivo para la rotación del registro. El rango de valores posibles va de 2 KB a 2 GB. La parte de la unidad numérica del parámetro rotationSize se pasa como un número entero. Como no se admiten valores decimales, puede especificar un tamaño de rotación de 1,5 GB, por ejemplo, con el valor 1500 MB. El valor predeterminado es 2 GB.
  + **maxFilesToConservar** (obligatorio): especifica el número máximo de archivos que se deben conservar en el contenedor una vez realizada la rotación. El valor mínimo es 1 y el máximo, 50. El valor predeterminado es 10.

Tras configurar *MonitoringConfiguration*, deberías poder comprobar los registros de los pods de Spark Operator en un bucket de Amazon S3 o Amazon CloudWatch en ambos. Para un bucket de Amazon S3, debe esperar 2 minutos para poder descartar el primer archivo de registro.

**Para encontrar los registros Amazon CloudWatch, dirígete a lo siguiente: **CloudWatch**> **Grupos de registros** > > /operator/stderr ***Log group name****Pod name***

****También puede ir a: > Grupos de registros > > /operator/stdout **CloudWatch***Log group name****Pod name*******

# Registros de aplicaciones de Spark
<a name="spark-operator-monitoring-application-logs"></a>

Puede definir la configuración de la siguiente manera:

```
apiVersion: "sparkoperator.k8s.io/v1beta2"
kind: SparkApplication
metadata:
  name: spark-pi
  namespace: namespace
spec:
  type: Scala
  mode: cluster
  imagePullPolicy: Always
  mainClass: org.apache.spark.examples.SparkPi
  mainApplicationFile: "local:///usr/lib/spark/examples/jars/spark-examples.jar"
  sparkVersion: "3.3.1"
  emrReleaseLabel: emr_release_label
  executionRoleArn: job_execution_role_arn
  restartPolicy:
    type: Never
  volumes:
    - name: "test-volume"
      hostPath:
        path: "/tmp"
        type: Directory
  driver:
    cores: 1
    coreLimit: "1200m"
    memory: "512m"
    labels:
      version: 3.3.1
    volumeMounts:
      - name: "test-volume"
        mountPath: "/tmp"
  executor:
    cores: 1
    instances: 1
    memory: "512m"
    labels:
      version: 3.3.1
    volumeMounts:
      - name: "test-volume"
        mountPath: "/tmp"
  monitoringConfiguration:
    image: "log_agent_image"
    s3MonitoringConfiguration:
      logUri: "S3_bucket_uri"
    cloudWatchMonitoringConfiguration:
      logGroupName: "log_group_name"
      logStreamNamePrefix: "log_stream_prefix"
    sideCarResources:
      limits:
        cpuLimit: "500m"
        memoryLimit: "250Mi"
    containerLogRotationConfiguration:
      rotationSize: "2GB"
      maxFilesToKeep: "10"
```

A continuación, se describen las opciones de configuración disponibles en **monitoringConfiguration**.
+ **Imagen** (opcional): URL de la imagen del agente de registro. Se recuperará si no se proporciona. emrReleaseLabel 
+ **s3 MonitoringConfiguration** — Configure esta opción para archivar en Amazon S3.
  + **logUri** (obligatorio): la ruta del bucket de Amazon S3 donde desea almacenar sus registros. El primer ejemplo muestra que la rotación de registros no está habilitada:

    ```
    s3://${logUri}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stdout.gz
    s3://${logUri}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stderr.gz
    ```

    El registro está habilitado de forma predeterminada. Puede utilizar tanto un archivo rotado (con índice creciente) como un archivo actual (uno sin la fecha).

    ```
    s3://${logUri}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stdout_YYYYMMDD_index.gz
    s3://${logUri}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stderr_YYYYMMDD_index.gz
    ```
+ **cloudWatchMonitoringConfiguración**: la clave de configuración a la que se debe configurar el reenvío. Amazon CloudWatch
  + **logGroupName**(obligatorio): el nombre del grupo de registros de Cloudwatch al que quieres enviar los registros. Si el grupo no existe, se crea automáticamente.
  + **logStreamNamePrefijo** (opcional): el nombre del flujo de registros al que quieres enviar los registros. El valor predeterminado es una cadena vacía. El formato CloudWatch es el siguiente:

    ```
    ${logStreamNamePrefix}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stdout
    ${logStreamNamePrefix}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stderr
    ```
+ **sideCarResources**(opcional): la clave de configuración para establecer los límites de recursos en el contenedor sidecar Fluentd lanzado.
  + **memoryLimit** (opcional): el límite de memoria. Ajústelo según sus necesidades. El valor predeterminado es 250Mi.
  + **cpuLimit**: el límite de la CPU. Ajústelo según sus necesidades. El valor predeterminado es 500 m.
+ **containerLogRotationConfiguración** (opcional): controla el comportamiento de rotación del registro del contenedor. Está habilitada de forma predeterminada.
  + **rotationSize** (obligatorio): especifica el tamaño del archivo para la rotación del registro. El rango de valores posibles va de 2 KB a 2 GB. La parte de la unidad numérica del parámetro rotationSize se pasa como un número entero. Como no se admiten valores decimales, puede especificar un tamaño de rotación de 1,5 GB, por ejemplo, con el valor 1500 MB. El valor predeterminado es 2 GB.
  + **maxFilesToConservar** (obligatorio): especifica el número máximo de archivos que se deben conservar en el contenedor una vez realizada la rotación. El valor mínimo es 1. El valor máximo es 50. El valor predeterminado es 10.

Tras configurar MonitoringConfiguration, deberías poder comprobar los registros del controlador y del ejecutor de la aplicación Spark en un bucket de Amazon S3 o en ambos. CloudWatch Para un bucket de Amazon S3, debe esperar 2 minutos para poder descartar el primer archivo de registro. Por ejemplo, en Amazon S3, la ruta del bucket es la siguiente:

**Amazon S3** **> **Buckets** > ***Bucket name***> *Spark application name - UUID* *Pod Name* > stderr.gz**

O bien:

**Amazon S3** **> **Buckets** > ***Bucket name***> *Spark application name - UUID* *Pod Name* > stdout.gz**

En CloudWatch, la ruta aparece de la siguiente manera:

**CloudWatch**> **Grupos de registros** > ***Log group name***>*Spark application name - UUID*/*Pod name***/stderr**

O bien:

**CloudWatch****> **Grupos de registros** > >/***Log group name***/stdout *Spark application name - UUID* *Pod name***

# Seguridad y operador de Spark con Amazon EMR en EKS
<a name="spark-operator-security"></a>

Existen dos formas de configurar los permisos de acceso a los clústeres cuando se utiliza el operador Spark. La primera es utilizar el control de acceso basado en roles, el control de acceso basado en roles (RBAC) restringe el acceso en función del rol de una persona dentro de una organización. Se ha convertido en la principal forma de gestionar el acceso. El segundo método de acceso consiste en asumir un AWS Identity and Access Management rol, que proporciona acceso a los recursos mediante permisos específicos asignados.

**Topics**
+ [Configuración de los permisos de acceso al clúster con control de acceso basado en roles (RBAC)](spark-operator-security-rbac.md)
+ [Configuración de los permisos de acceso al clúster con roles de IAM para las cuentas de servicio (IRSA)](spark-operator-security-irsa.md)

# Configuración de los permisos de acceso al clúster con control de acceso basado en roles (RBAC)
<a name="spark-operator-security-rbac"></a>

Para implementar el operador de Spark, Amazon EMR en EKS crea dos roles y cuentas de servicio para el operador y las aplicaciones de Spark.

**Topics**
+ [Rol y cuenta de servicio del operador](#spark-operator-sa-oper)
+ [Rol y cuenta de servicio de Spark](#spark-operator-sa-spark)

## Rol y cuenta de servicio del operador
<a name="spark-operator-sa-oper"></a>

Amazon EMR en EKS crea el **rol y la cuenta de servicio del operador** para administrar `SparkApplications` para los trabajos de Spark y otros recursos, como los servicios.

El nombre predeterminado de esta cuenta de servicio es `emr-containers-sa-spark-operator`.

Las siguientes reglas se aplican a este rol de servicio: 

```
 rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - "*"
- apiGroups:
  - ""
  resources:
  - services
  - configmaps
  - secrets
  verbs:
  - create
  - get
  - delete
  - update
- apiGroups:
  - extensions
  - networking.k8s.io
  resources:
  - ingresses
  verbs:
  - create
  - get
  - delete
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - resourcequotas
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - create
  - get
  - update
  - delete
- apiGroups:
  - admissionregistration.k8s.io
  resources:
  - mutatingwebhookconfigurations
  - validatingwebhookconfigurations
  verbs:
  - create
  - get
  - update
  - delete
- apiGroups:
  - sparkoperator.k8s.io
  resources:
  - sparkapplications
  - sparkapplications/status
  - scheduledsparkapplications
  - scheduledsparkapplications/status
  verbs:
  - "*"
  {{- if .Values.batchScheduler.enable }}
  # required for the `volcano` batch scheduler
- apiGroups:
  - scheduling.incubator.k8s.io
  - scheduling.sigs.dev
  - scheduling.volcano.sh
  resources:
  - podgroups
  verbs:
  - "*"
  {{- end }}
  {{ if .Values.webhook.enable }}
- apiGroups:
  - batch
  resources:
  - jobs
  verbs:
  - delete
  {{- end }}
```

## Rol y cuenta de servicio de Spark
<a name="spark-operator-sa-spark"></a>

Un pod controlador de Spark necesita una cuenta de servicio de Kubernetes en el mismo espacio de nombres que el pod. Esta cuenta de servicio necesita permisos para crear, obtener, enumerar, parchear y eliminar los pods ejecutores, así como para crear un servicio Headless de Kubernetes para el controlador. El controlador produce un error y se cierra sin la cuenta de servicio, a menos que la cuenta de servicio predeterminada del espacio de nombres del pod tenga los permisos necesarios.

El nombre predeterminado de esta cuenta de servicio es `emr-containers-sa-spark`.

Las siguientes reglas se aplican a este rol de servicio: 

```
 rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - "*"
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - "*"
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - "*"
- apiGroups:
  - ""
  resources:
  - persistentvolumeclaims
  verbs:
  - "*"
```

# Configuración de los permisos de acceso al clúster con roles de IAM para las cuentas de servicio (IRSA)
<a name="spark-operator-security-irsa"></a>

En esta sección se utiliza un ejemplo para demostrar cómo configurar una cuenta de servicio de Kubernetes para que asuma un rol. AWS Identity and Access Management Los pods que usan la cuenta de servicio pueden entonces acceder a cualquier AWS servicio al que el rol tenga permiso de acceso.

En el siguiente ejemplo, se ejecuta una aplicación de Spark para contar las palabras de un archivo en Amazon S3. Para ello, puede configurar roles de IAM para las cuentas de servicio (IRSA) a fin de autenticar y autorizar las cuentas de servicio de Kubernetes.

**nota**  
En este ejemplo, se utiliza el espacio de nombres “spark-operator” para el operador de Spark y para el espacio de nombres al que se envía la solicitud de Spark.

## Requisitos previos
<a name="spark-operator-security-irsa-prereqs"></a>

Antes de probar el ejemplo de esta página, complete los siguientes requisitos previos:
+ [Prepare la configuración para el operador de Spark]().
+ [Instalar el operador de Spark](spark-operator-gs.md#spark-operator-install).
+ [Cree un bucket de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html).
+ Guarde su poema favorito en un archivo de texto llamado `poem.txt` y súbalo a su bucket de S3. La aplicación de Spark que cree en esta página leerá el contenido del archivo de texto. Para obtener más información sobre cómo cargar archivos en S3, consulte [Cargar un objeto en el bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-an-object-bucket.html) en la *Guía del usuario de Amazon Simple Storage Service*.

## Configurar una cuenta de servicio de Kubernetes para que asuma un rol de IAM
<a name="spark-operator-security-irsa-config"></a>

Sigue los siguientes pasos para configurar una cuenta de servicio de Kubernetes para que asuma una función de IAM que los pods puedan usar para acceder a AWS los servicios a los que la función tiene permisos de acceso.

1. Tras completar el[Requisitos previos](#spark-operator-security-irsa-prereqs), utilice el AWS Command Line Interface para crear un `example-policy.json` archivo que permita el acceso de solo lectura al archivo que ha subido a Amazon S3:

   ```
   cat >example-policy.json <<EOF
   {
       "Version": "2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:ListBucket"
               ],
               "Resource": [
                   "arn:aws:s3:::my-pod-bucket",
                   "arn:aws:s3:::my-pod-bucket/*"
               ]
           }
       ]
   }
   EOF
   ```

1. Luego, cree una política de IAM `example-policy`:

   ```
   aws iam create-policy --policy-name example-policy --policy-document file://example-policy.json
   ```

1. A continuación, cree un rol de IAM `example-role` y asócielo a una cuenta de servicio de Kubernetes para el controlador de Spark:

   ```
   eksctl create iamserviceaccount --name driver-account-sa --namespace spark-operator \
   --cluster my-cluster --role-name "example-role" \
   --attach-policy-arn arn:aws:iam::111122223333:policy/example-policy --approve
   ```

1. Cree un archivo yaml con las vinculaciones de roles de clúster necesarias para la cuenta de servicio de controlador de Spark:

   ```
   cat >spark-rbac.yaml <<EOF
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: driver-account-sa
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: spark-role
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: edit
   subjects:
     - kind: ServiceAccount
       name: driver-account-sa
       namespace: spark-operator
   EOF
   ```

1. Aplique las configuraciones de la vinculación de roles del clúster:

   ```
   kubectl apply -f spark-rbac.yaml
   ```

El comando kubectl debería confirmar que la cuenta se ha creado correctamente:

```
serviceaccount/driver-account-sa created
clusterrolebinding.rbac.authorization.k8s.io/spark-role configured
```

## Ejecutar una aplicación desde el operador de Spark
<a name="spark-operator-security-irsa-run"></a>

Después de [configurar la cuenta de servicio de Kubernetes](), puede ejecutar una aplicación de Spark que cuente el número de palabras del archivo de texto que ha subido como parte de [Requisitos previos](#spark-operator-security-irsa-prereqs).

1. Cree un archivo nuevo `word-count.yaml` con una definición de `SparkApplication` para su aplicación de recuento de palabras, basado en Amazon EMR, versión 6.

   ```
   cat >word-count.yaml <<EOF
   apiVersion: "sparkoperator.k8s.io/v1beta2"
   kind: SparkApplication
   metadata:
     name: word-count
     namespace: spark-operator
   spec:
     type: Java
     mode: cluster
     image: "895885662937.dkr.ecr.us-west-2.amazonaws.com/spark/emr-6.10.0:latest"
     imagePullPolicy: Always
     mainClass: org.apache.spark.examples.JavaWordCount
     mainApplicationFile: local:///usr/lib/spark/examples/jars/spark-examples.jar
     arguments:
       - s3://my-pod-bucket/poem.txt
     hadoopConf:
      # EMRFS filesystem
       fs.s3.customAWSCredentialsProvider: com.amazonaws.auth.WebIdentityTokenCredentialsProvider
       fs.s3.impl: com.amazon.ws.emr.hadoop.fs.EmrFileSystem
       fs.AbstractFileSystem.s3.impl: org.apache.hadoop.fs.s3.EMRFSDelegate
       fs.s3.buffer.dir: /mnt/s3
       fs.s3.getObject.initialSocketTimeoutMilliseconds: "2000"
       mapreduce.fileoutputcommitter.algorithm.version.emr_internal_use_only.EmrFileSystem: "2"
       mapreduce.fileoutputcommitter.cleanup-failures.ignored.emr_internal_use_only.EmrFileSystem: "true"
     sparkConf:
       # Required for EMR Runtime
       spark.driver.extraClassPath: /usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*
       spark.driver.extraLibraryPath: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
       spark.executor.extraClassPath: /usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*
       spark.executor.extraLibraryPath: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
     sparkVersion: "3.3.1"
     restartPolicy:
       type: Never
     driver:
       cores: 1
       coreLimit: "1200m"
       memory: "512m"
       labels:
         version: 3.3.1
       serviceAccount: my-spark-driver-sa
     executor:
       cores: 1
       instances: 1
       memory: "512m"
       labels:
         version: 3.3.1
   EOF
   ```

   Si utiliza el operador de Spark con una versión de la versión 7, debe ajustar algunos de los valores de configuración:

   ```
   cat >word-count.yaml <<EOF
   apiVersion: "sparkoperator.k8s.io/v1beta2"
   kind: SparkApplication
   metadata:
     name: word-count
     namespace: spark-operator
   spec:
     type: Java
     mode: cluster
     image: "895885662937.dkr.ecr.us-west-2.amazonaws.com/spark/emr-7.7.0:latest"
     imagePullPolicy: Always
     mainClass: org.apache.spark.examples.JavaWordCount
     mainApplicationFile: local:///usr/lib/spark/examples/jars/spark-examples.jar
     arguments:
       - s3://my-pod-bucket/poem.txt
     hadoopConf:
      # EMRFS filesystem
       fs.s3.customAWSCredentialsProvider: com.amazonaws.auth.WebIdentityTokenCredentialsProvider
       fs.s3.impl: com.amazon.ws.emr.hadoop.fs.EmrFileSystem
       fs.AbstractFileSystem.s3.impl: org.apache.hadoop.fs.s3.EMRFSDelegate
       fs.s3.buffer.dir: /mnt/s3
       fs.s3.getObject.initialSocketTimeoutMilliseconds: "2000"
       mapreduce.fileoutputcommitter.algorithm.version.emr_internal_use_only.EmrFileSystem: "2"
       mapreduce.fileoutputcommitter.cleanup-failures.ignored.emr_internal_use_only.EmrFileSystem: "true"
     sparkConf:
       # Required for EMR Runtime
       spark.driver.extraClassPath: /usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/aws-java-sdk-v2/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*
       spark.driver.extraLibraryPath: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
       spark.executor.extraClassPath: /usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/aws-java-sdk-v2/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*
       spark.executor.extraLibraryPath: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native
     sparkVersion: "3.3.1"
     restartPolicy:
       type: Never
     driver:
       cores: 1
       coreLimit: "1200m"
       memory: "512m"
       labels:
         version: 3.3.1
       serviceAccount: my-spark-driver-sa
     executor:
       cores: 1
       instances: 1
       memory: "512m"
       labels:
         version: 3.3.1
   EOF
   ```

1. Envíe la aplicación de Spark.

   ```
   kubectl apply -f word-count.yaml
   ```

   El comando kubectl debería devolver la confirmación de que ha creado correctamente un objeto `SparkApplication` llamado `word-count`.

   ```
   sparkapplication.sparkoperator.k8s.io/word-count configured
   ```

1. Para comprobar los eventos del objeto `SparkApplication`, ejecute el siguiente comando:

   ```
   kubectl describe sparkapplication word-count -n spark-operator
   ```

   El comando kubectl debería devolver la descripción de `SparkApplication` junto con los eventos:

   ```
   Events:
     Type     Reason                               Age                    From            Message
     ----     ------                               ----                   ----            -------
     Normal   SparkApplicationSpecUpdateProcessed  3m2s (x2 over 17h)     spark-operator  Successfully processed spec update for SparkApplication word-count
     Warning  SparkApplicationPendingRerun         3m2s (x2 over 17h)     spark-operator  SparkApplication word-count is pending rerun
     Normal   SparkApplicationSubmitted            2m58s (x2 over 17h)    spark-operator  SparkApplication word-count was submitted successfully
     Normal   SparkDriverRunning                   2m56s (x2 over 17h)    spark-operator  Driver word-count-driver is running
     Normal   SparkExecutorPending                 2m50s                  spark-operator  Executor [javawordcount-fdd1698807392c66-exec-1] is pending
     Normal   SparkExecutorRunning                 2m48s                  spark-operator  Executor [javawordcount-fdd1698807392c66-exec-1] is running
     Normal   SparkDriverCompleted                 2m31s (x2 over 17h)    spark-operator  Driver word-count-driver completed
     Normal   SparkApplicationCompleted            2m31s (x2 over 17h)    spark-operator  SparkApplication word-count completed
     Normal   SparkExecutorCompleted               2m31s (x2 over 2m31s)  spark-operator  Executor [javawordcount-fdd1698807392c66-exec-1] completed
   ```

La aplicación ahora cuenta las palabras del archivo de S3. Para saber el número de palabras, consulte los archivos de registro de su controlador:

```
kubectl logs pod/word-count-driver -n spark-operator
```

El comando kubectl debería devolver el contenido del archivo de registro con los resultados de la aplicación de recuento de palabras.

```
INFO DAGScheduler: Job 0 finished: collect at JavaWordCount.java:53, took 5.146519 s
                Software: 1
```

Para obtener más información sobre cómo enviar solicitudes a Spark a través del operador de Spark, consulte la documentación sobre el [uso de un](https://www.kubeflow.org/docs/components/spark-operator/user-guide/using-sparkapplication/) operador de *Kubernetes para Apache Spark (spark-on-k8s-operator*) SparkApplication en. GitHub

# Ejecución de trabajos de Spark con spark-submit
<a name="spark-submit"></a>

Las versiones 6.10.0 y posteriores de Amazon EMR admiten `spark-submit` como herramienta de línea de comandos que puede utilizar para enviar y ejecutar aplicaciones de Spark en un clúster de Amazon EMR en EKS.

**nota**  
Amazon EMR calcula los precios de Amazon EKS en función de la vCPU y el consumo de memoria. Este cálculo se aplica a los pods de controladores y ejecutores. Este cálculo comienza cuando usted descarga la imagen de la aplicación de Amazon EMR hasta que finaliza el pod de Amazon EKS y se redondea al segundo más cercano.

**Topics**
+ [Configuración de spark-submit para Amazon EMR en EKS](spark-submit-setup.md)
+ [Comenzar a utilizar spark-submit para Amazon EMR en EKS](spark-submit-gs.md)
+ [Verificación de los requisitos de seguridad de la cuenta de servicio del controlador de Spark para spark-submit](spark-submit-security.md)

# Configuración de spark-submit para Amazon EMR en EKS
<a name="spark-submit-setup"></a>

Complete las siguientes tareas para llevar a cabo la configuración antes de poder ejecutar una aplicación con spark-submit en Amazon EMR en EKS. Si ya se registró en Amazon Web Services (AWS) y ha usado Amazon EKS, lo tiene todo casi listo para comenzar a utilizar Amazon EMR en EKS. Si ya ha completado alguno de los requisitos previos, puede omitirlos y pasar al siguiente.
+ **[Instalar o actualizar a la última versión de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)**: si ya ha instalado el AWS CLI, confirme que tiene la última versión.
+ **[Configure kubectl y eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) **: eksctl es una herramienta de línea de comandos que se utiliza para comunicarse con Amazon EKS.
+ **[Comience con Amazon EKS: eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) **: siga los pasos para crear un nuevo clúster de Kubernetes con nodos en Amazon EKS.
+ **[Seleccione un URI de imagen base de Amazon EMR](docker-custom-images-tag.md) (versión 6.10.0 o posterior)**: el comando `spark-submit` es compatible con las versiones 6.10.0 y posteriores de Amazon EMR.
+ Confirme que la cuenta de servicio de controlador tiene los permisos adecuados para crear y supervisar los módulos ejecutores. Para obtener más información, consulte [Verificación de los requisitos de seguridad de la cuenta de servicio del controlador de Spark para spark-submit](spark-submit-security.md).
+ Configure su [perfil de credenciales de AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) local.
+ En la consola de Amazon EKS, elija su clúster de EKS y, a continuación, busque el punto de conexión del clúster de EKS, que se encuentra en **Descripción general**, **Detalles** y, a continuación, en el **punto de conexión del servidor API**.

# Comenzar a utilizar spark-submit para Amazon EMR en EKS
<a name="spark-submit-gs"></a>

Amazon EMR 6.10.0 y las versiones posteriores admiten spark-submit para ejecutar aplicaciones de Spark en un clúster de Amazon EKS. En la siguiente sección, se muestra cómo enviar un comando para una aplicación Spark.

## Ejecutar una aplicación de Spark
<a name="spark-submit-run"></a>

Complete los pasos que se indican a continuación para ejecutar la aplicación de Spark:

1. Para poder ejecutar una aplicación de Spark con el comando `spark-submit`, complete los pasos que se indican en [Configuración de spark-submit para Amazon EMR en EKS](spark-submit-setup.md). 

1. Ejecute un contenedor con Amazon EMR en la imagen base de EKS. Consulte [Cómo seleccionar un URI de imagen base](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html) para obtener más información.

   ```
   kubectl run -it containerName --image=EMRonEKSImage --command -n namespace /bin/bash
   ```

1. Establezca los valores de las siguientes variables de entorno:

   ```
   export SPARK_HOME=spark-home
   export MASTER_URL=k8s://Amazon EKS-cluster-endpoint
   ```

1. Luego, envíe la solicitud de Spark con el siguiente comando:

   ```
   $SPARK_HOME/bin/spark-submit \
    --class org.apache.spark.examples.SparkPi \
    --master $MASTER_URL \
    --conf spark.kubernetes.container.image=895885662937.dkr.ecr.us-west-2.amazonaws.com/spark/emr-6.10.0:latest \
    --conf spark.kubernetes.authenticate.driver.serviceAccountName=spark \
    --deploy-mode cluster \
    --conf spark.kubernetes.namespace=spark-operator \
    local:///usr/lib/spark/examples/jars/spark-examples.jar 20
   ```

Para obtener más información acerca de cómo enviar aplicaciones a Spark, consulte [Envío de aplicaciones](https://spark.apache.org/docs/latest/submitting-applications.html) en la documentación de Apache Spark.

**importante**  
`spark-submit` solo admite el modo de clúster como mecanismo de envío.

# Verificación de los requisitos de seguridad de la cuenta de servicio del controlador de Spark para spark-submit
<a name="spark-submit-security"></a>

El pod controlador de Spark utiliza una cuenta de servicio de Kubernetes para acceder al servidor de la API de Kubernetes y crear y supervisar los pods ejecutores. La cuenta de servicio del controlador debe tener los permisos adecuados para enumerar, crear, editar, parchear y eliminar los pods de su clúster. Puede verificar que puede enumerar estos recursos con el siguiente comando:

```
kubectl auth can-i list|create|edit|delete|patch pods
```

Verifique que tiene los permisos necesarios para ejecutar cada comando.

```
kubectl auth can-i list pods
kubectl auth can-i create pods
kubectl auth can-i edit pods
kubectl auth can-i delete pods
kubectl auth can-i patch pods
```

Las siguientes reglas se aplican a este rol de servicio: 

```
 rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - "*"
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - "*"
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - "*"
- apiGroups:
  - ""
  resources:
  - persistentvolumeclaims
  verbs:
  - "*"
```

# Configuración de roles de IAM para cuentas de servicio (IRSA) para spark-submit
<a name="spark-submit-security-irsa"></a>

En las siguientes secciones, se explica cómo configurar roles de IAM para las cuentas de servicio (IRSA) a fin de autenticar y autorizar las cuentas de servicio de Kubernetes para que usted pueda ejecutar aplicaciones de Spark almacenadas en Amazon S3.

## Requisitos previos
<a name="spark-submit-security-irsa-prereqs"></a>

Antes de probar cualquiera de los ejemplos de esta documentación, asegúrese de que ha completado los siguientes requisitos previos:
+ [Ha finalizado la configuración de spark-submit](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/spark-submit-setup.html)
+ [Ha creado un bucket de S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html) y [ha cargado](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-an-object-bucket.html) el jar de aplicaciones de Spark

## Configuración de una cuenta de servicio de Kubernetes para asumir un rol de IAM
<a name="spark-submit-security-irsa-configure-kubernetes"></a>

En los siguientes pasos se explica cómo configurar una cuenta de servicio de Kubernetes para que asuma un rol de (IAM) AWS Identity and Access Management . Tras configurar los pods para que usen la cuenta de servicio, podrán acceder a cualquier cuenta a la Servicio de AWS que el rol tenga permiso de acceso.

1. [Cree un archivo de políticas para conceder acceso de solo lectura al objeto de Amazon S3 que cargó](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-an-object-bucket.html):

   ```
   cat >my-policy.json <<EOF
   {
       "Version": "2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:ListBucket"
               ],
               "Resource": [
                   "arn:aws:s3:::<my-spark-jar-bucket>",
                   "arn:aws:s3:::<my-spark-jar-bucket>/*"
               ]
           }
       ]
   }
   EOF
   ```

1. Creación de la política de IAM.

   ```
   aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
   ```

1. Cree un rol de IAM y asócielo a una cuenta de servicio de Kubernetes para el controlador de Spark

   ```
   eksctl create iamserviceaccount --name my-spark-driver-sa --namespace spark-operator \
   --cluster my-cluster --role-name "my-role" \
   --attach-policy-arn arn:aws:iam::111122223333:policy/my-policy --approve
   ```

1. Cree un archivo YAML con los [permisos](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/spark-submit-security.html) necesarios para la cuenta de servicio del controlador de Spark:

   ```
   cat >spark-rbac.yaml <<EOF
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     namespace: default
     name: emr-containers-role-spark
   rules:
   - apiGroups:
     - ""
     resources:
     - pods
     verbs:
     - "*"
   - apiGroups:
     - ""
     resources:
     - services
     verbs:
     - "*"
   - apiGroups:
     - ""
     resources:
     - configmaps
     verbs:
     - "*"
   - apiGroups:
     - ""
     resources:
     - persistentvolumeclaims
     verbs:
     - "*"
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: spark-role-binding
     namespace: default
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: emr-containers-role-spark
   subjects:
   - kind: ServiceAccount
     name: emr-containers-sa-spark
     namespace: default
   EOF
   ```

1. Aplique las configuraciones de la vinculación de roles del clúster.

   ```
   kubectl apply -f spark-rbac.yaml
   ```

1. El comando `kubectl` debería devolver la confirmación de la cuenta creada.

   ```
   serviceaccount/emr-containers-sa-spark created
   clusterrolebinding.rbac.authorization.k8s.io/emr-containers-role-spark configured
   ```

## Ejecución de la aplicación de Spark
<a name="spark-submit-security-irsa-app-run"></a>

Amazon EMR 6.10.0 y las versiones posteriores admiten spark-submit para ejecutar aplicaciones de Spark en un clúster de Amazon EKS. Complete los pasos que se indican a continuación para ejecutar la aplicación de Spark:

1. Asegúrese de que ha completado los pasos de [Configuración de spark-submit para Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/spark-submit-setup.html).

1. Establezca los valores de las siguientes variables de entorno:

   ```
   export SPARK_HOME=spark-home
   export MASTER_URL=k8s://Amazon EKS-cluster-endpoint
   ```

1. Luego, envíe la solicitud de Spark con el siguiente comando:

   ```
   $SPARK_HOME/bin/spark-submit \
    --class org.apache.spark.examples.SparkPi \
    --master $MASTER_URL \
    --conf spark.kubernetes.container.image=895885662937.dkr.ecr.us-west-2.amazonaws.com/spark/emr-6.15.0:latest \
    --conf spark.kubernetes.authenticate.driver.serviceAccountName=emr-containers-sa-spark \
    --deploy-mode cluster \
    --conf spark.kubernetes.namespace=default \
    --conf "spark.driver.extraClassPath=/usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*" \
    --conf "spark.driver.extraLibraryPath=/usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native" \
    --conf "spark.executor.extraClassPath=/usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*" \
    --conf "spark.executor.extraLibraryPath=/usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native" \
    --conf spark.hadoop.fs.s3.customAWSCredentialsProvider=com.amazonaws.auth.WebIdentityTokenCredentialsProvider \
    --conf spark.hadoop.fs.s3.impl=com.amazon.ws.emr.hadoop.fs.EmrFileSystem \
    --conf spark.hadoop.fs.AbstractFileSystem.s3.impl=org.apache.hadoop.fs.s3.EMRFSDelegate \
    --conf spark.hadoop.fs.s3.buffer.dir=/mnt/s3 \
    --conf spark.hadoop.fs.s3.getObject.initialSocketTimeoutMilliseconds="2000" \
    --conf spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version.emr_internal_use_only.EmrFileSystem="2" \
    --conf spark.hadoop.mapreduce.fileoutputcommitter.cleanup-failures.ignored.emr_internal_use_only.EmrFileSystem="true" \
    s3://my-pod-bucket/spark-examples.jar 20
   ```

1. Cuando el controlador de Spark finalice el trabajo de Spark, debería ver una línea de registro al final del envío que indica que el trabajo de Spark ha finalizado.

   ```
   23/11/24 17:02:14 INFO LoggingPodStatusWatcherImpl: Application org.apache.spark.examples.SparkPi with submission ID default:org-apache-spark-examples-sparkpi-4980808c03ff3115-driver finished
   23/11/24 17:02:14 INFO ShutdownHookManager: Shutdown hook called
   ```

## Limpieza
<a name="spark-submit-security-irsa-cleanup"></a>

Cuando termine de ejecutar las aplicaciones, puede realizar la limpieza con el siguiente comando.

```
kubectl delete -f spark-rbac.yaml
```

# Uso de Apache Livy con Amazon EMR en EKS
<a name="job-runs-apache-livy"></a>

Con las versiones 7.1.0 y posteriores de Amazon EMR, puede utilizar Apache Livy para enviar trabajos en Amazon EMR en EKS. Mediante Apache Livy, puede configurar su propio punto de conexión REST de Apache Livy y usarlo para implementar y administrar aplicaciones de Spark en sus clústeres de Amazon EKS. Una vez que haya instalado Livy en su clúster de Amazon EKS, puede utilizar el punto de conexión de Livy para enviar las aplicaciones de Spark a su servidor de Livy. El servidor administra el ciclo de vida de las aplicaciones de Spark.

**nota**  
Amazon EMR calcula los precios de Amazon EKS en función de la vCPU y el consumo de memoria. Este cálculo se aplica a los pods de controladores y ejecutores. Este cálculo comienza cuando usted descarga la imagen de la aplicación de Amazon EMR hasta que finaliza el pod de Amazon EKS y se redondea al segundo más cercano.

**Topics**
+ [Configuración de Apache Livy para Amazon EMR en EKS](job-runs-apache-livy-setup.md)
+ [Introducción a Apache Livy en Amazon EMR en EKS](job-runs-apache-livy-install.md)
+ [Ejecución de una aplicación de Spark con Apache Livy para Amazon EMR en EKS](job-runs-apache-livy-run-spark.md)
+ [Desinstalación de Apache Livy con Amazon EMR en EKS](job-runs-apache-livy-uninstall.md)
+ [Seguridad de Apache Livy con Amazon EMR en EKS](job-runs-apache-livy-security.md)
+ [Propiedades de instalación de Apache Livy en las versiones de Amazon EMR en EKS.](job-runs-apache-livy-installation-properties.md)
+ [Solucione los errores comunes de formato de las variables de entorno](job-runs-apache-livy-troubleshooting.md)

# Configuración de Apache Livy para Amazon EMR en EKS
<a name="job-runs-apache-livy-setup"></a>

Antes de poder instalar Apache Livy en el clúster de Amazon EKS, debe instalar y configurar un conjunto de herramientas con requisitos previos. Estas incluyen AWS CLI, que es una herramienta de línea de comandos básica para trabajar con AWS recursos, herramientas de línea de comandos para trabajar con Amazon EKS y un controlador que se utiliza en este caso de uso para hacer que la aplicación de clúster esté disponible en Internet y enrutar el tráfico de la red.
+ **[Instale o actualice a la versión más reciente de AWS CLI: si ya la](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)** ha instalado AWS CLI, confirme que tiene la última versión.
+ **[Configure kubectl y eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) **: eksctl es una herramienta de línea de comandos que se utiliza para comunicarse con Amazon EKS.
+ **[Instale Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)**: el administrador de paquetes Helm para Kubernetes le ayuda a instalar y administrar aplicaciones en el clúster de Kubernetes. 
+ **[Introducción a Amazon EKS: eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) **: siga los pasos para crear un nuevo clúster de Kubernetes con nodos en Amazon EKS.
+ **[Seleccione una etiqueta de versión de Amazon EMR](docker-custom-images-tag.md)**: el Apache Livy es compatible con las versiones 7.1.0 y superiores de Amazon EMR.
+ **[Instale el controlador ALB: el controlador](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html)** ALB administra los clústeres de AWS Elastic Load Balancing para Kubernetes. Crea un AWS Network Load Balancer (NLB) al crear un Kubernetes Ingress mientras se configura Apache Livy.

# Introducción a Apache Livy en Amazon EMR en EKS
<a name="job-runs-apache-livy-install"></a>

Siga los pasos que se describen a continuación para instalar Apache Livy. Incluyen la configuración del administrador de paquetes, la creación de un espacio de nombres para ejecutar las cargas de trabajo de Spark, la instalación de Livy, la configuración del equilibrio de carga y los pasos de verificación. Tiene que completar estos pasos para ejecutar un trabajo por lotes con Spark.

1. Si aún no lo ha hecho, configure [Apache Livy para Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html).

1. Autentique su cliente de Helm en el registro de Amazon ECR. Puede encontrar el `ECR-registry-account` valor correspondiente a sus [cuentas Región de AWS de registro de Amazon ECR por región](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html#docker-custom-images-ECR).

   ```
   aws ecr get-login-password \--region <AWS_REGION> | helm registry login \
   --username AWS \
   --password-stdin <ECR-registry-account>.dkr.ecr.<region-id>.amazonaws.com
   ```

1. Al configurar Livy, se crea una cuenta de servicio para el servidor de Livy y otra cuenta para la aplicación Spark. Para configurar IRSA para las cuentas de servicio, consulte [Configuración de los permisos de acceso con roles de IAM para las cuentas de servicio (IRSA)](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-irsa.html). 

1. Cree un espacio de nombres para ejecutar sus cargas de trabajo de Spark.

   ```
   kubectl create ns <spark-ns>
   ```

1. Utilice el siguiente comando para instalar Livy.

   Este punto de conexión de Livy solo está disponible internamente para la VPC del clúster de EKS. Para habilitar el acceso más allá de la VPC, establezca `—-set loadbalancer.internal=false` en su comando de instalación de Helm.
**nota**  
De forma predeterminada, el SSL no está habilitado en este punto de conexión de Livy y el punto de conexión solo está visible dentro de la VPC del clúster de EKS. Si configura `loadbalancer.internal=false` y `ssl.enabled=false`, expone un punto de conexión inseguro al exterior de su VPC. Para configurar un punto de conexión Livy seguro, consulte [Configuración de un punto de conexión seguro de Apache Livy con TLS/SSL](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-secure-endpoint.html). 

   ```
   helm install livy-demo \
     oci://895885662937.dkr.ecr.region-id.amazonaws.com/livy \
     --version 7.12.0 \
     --namespace livy-ns \
     --set image=ECR-registry-account.dkr.ecr.region-id.amazonaws.com/livy/emr-7.12.0:latest \
     --set sparkNamespace=<spark-ns> \
     --create-namespace
   ```

   Debería ver la siguiente salida.

   ```
   NAME: livy-demo
   LAST DEPLOYED: Mon Mar 18 09:23:23 2024
   NAMESPACE: livy-ns
   STATUS: deployed
   REVISION: 1
   TEST SUITE: None
   NOTES:
   The Livy server has been installed.
   Check installation status:
   1. Check Livy Server pod is running
     kubectl --namespace livy-ns get pods -l "app.kubernetes.io/instance=livy-demo"
   2. Verify created NLB is in Active state and it's target groups are healthy (if loadbalancer.enabled is true)
   
   Access LIVY APIs:
       # Ensure your NLB is active and healthy
       # Get the Livy endpoint using command:
       LIVY_ENDPOINT=$(kubectl get svc -n livy-ns -l app.kubernetes.io/instance=livy-demo,emr-containers.amazonaws.com/type=loadbalancer -o jsonpath='{.items[0].status.loadBalancer.ingress[0].hostname}' |  awk '{printf "%s:8998\n", $0}')
       # Access Livy APIs using http://$LIVY_ENDPOINT or https://$LIVY_ENDPOINT (if SSL is enabled)
       # Note: While uninstalling Livy, makes sure the ingress and NLB are deleted after running the helm command to avoid dangling resources
   ```

   Los nombres de las cuentas de servicio predeterminados para el servidor de Livy y la sesión de Spark son `emr-containers-sa-livy` y `emr-containers-sa-spark-livy`. Para usar nombres personalizados, use los parámetros `serviceAccounts.name` y `sparkServiceAccount.name`.

   ```
   --set serviceAccounts.name=my-service-account-for-livy
   --set sparkServiceAccount.name=my-service-account-for-spark
   ```

1. Compruebe que haya instalado el gráfico de Helm.

   ```
   helm list -n livy-ns -o yaml
   ```

   El comando `helm list` debería devolver la información sobre el nuevo gráfico de Helm:

   ```
   app_version: 0.7.1-incubating
   chart: livy-emr-7.12.0
   name: livy-demo
   namespace: livy-ns
   revision: "1"
   status: deployed
   updated: 2024-02-08 22:39:53.539243 -0800 PST
   ```

1. Compruebe que el Equilibrador de carga de red esté activo.

   ```
   LIVY_NAMESPACE=<livy-ns>
   LIVY_APP_NAME=<livy-app-name>
   AWS_REGION=<AWS_REGION>
   
   # Get the NLB Endpoint URL
   NLB_ENDPOINT=$(kubectl --namespace $LIVY_NAMESPACE get svc -l "app.kubernetes.io/instance=$LIVY_APP_NAME,emr-containers.amazonaws.com/type=loadbalancer" -o jsonpath='{.items[0].status.loadBalancer.ingress[0].hostname}') 
   
   # Get all the load balancers in the account's region
   ELB_LIST=$(aws elbv2 describe-load-balancers --region $AWS_REGION)
   
   # Get the status of the NLB that matching the endpoint from the Kubernetes service
   NLB_STATUS=$(echo $ELB_LIST | grep -A 8 "\"DNSName\": \"$NLB_ENDPOINT\"" | awk '/Code/{print $2}/}/' | tr -d '"},\n')
   echo $NLB_STATUS
   ```

1. Ahora compruebe que el grupo objetivo del Equilibrador de carga de red esté en buen estado.

   ```
   LIVY_NAMESPACE=<livy-ns>
   LIVY_APP_NAME=<livy-app-name>
   AWS_REGION=<AWS_REGION>
   
   # Get the NLB endpoint
   NLB_ENDPOINT=$(kubectl --namespace $LIVY_NAMESPACE get svc -l "app.kubernetes.io/instance=$LIVY_APP_NAME,emr-containers.amazonaws.com/type=loadbalancer" -o jsonpath='{.items[0].status.loadBalancer.ingress[0].hostname}') 
   
   # Get all the load balancers in the account's region
   ELB_LIST=$(aws elbv2 describe-load-balancers --region $AWS_REGION)
   
   # Get the NLB ARN from the NLB endpoint
   NLB_ARN=$(echo $ELB_LIST | grep -B 1 "\"DNSName\": \"$NLB_ENDPOINT\"" | awk '/"LoadBalancerArn":/,/"/'| awk '/:/{print $2}' | tr -d \",)
   
   # Get the target group from the NLB. Livy setup only deploys 1 target group
   TARGET_GROUP_ARN=$(aws elbv2 describe-target-groups --load-balancer-arn $NLB_ARN --region $AWS_REGION | awk '/"TargetGroupArn":/,/"/'| awk '/:/{print $2}' | tr -d \",)
   
   # Get health of target group
   aws elbv2 describe-target-health --target-group-arn $TARGET_GROUP_ARN
   ```

   Aquí se incluye un resultado de ejemplo que muestra el estado del grupo objetivo:

   ```
   {
       "TargetHealthDescriptions": [
           {
               "Target": {
                   "Id": "<target IP>",
                   "Port": 8998,
                   "AvailabilityZone": "us-west-2d"
               },
               "HealthCheckPort": "8998",
               "TargetHealth": {
                   "State": "healthy"
               }
           }
       ]
   }
   ```

   Una vez que el estado de su NLB pase a estar `active` y su grupo objetivo esté `healthy`, podrá continuar. Puede que tarde unos minutos.

1. Recupere el punto de conexión de Livy de la instalación de Helm. El hecho de que su punto de conexión de Livy sea seguro o no depende de si ha habilitado el SSL.

   ```
   LIVY_NAMESPACE=<livy-ns>
    LIVY_APP_NAME=livy-app-name
    LIVY_ENDPOINT=$(kubectl get svc -n livy-ns -l app.kubernetes.io/instance=livy-app-name,emr-containers.amazonaws.com/type=loadbalancer -o jsonpath='{.items[0].status.loadBalancer.ingress[0].hostname}' |  awk '{printf "%s:8998\n", $0}')
    echo "$LIVY_ENDPOINT"
   ```

1. Recupere la cuenta de servicio de Spark de la instalación de Helm

   ```
   SPARK_NAMESPACE=spark-ns
   LIVY_APP_NAME=<livy-app-name>
   SPARK_SERVICE_ACCOUNT=$(kubectl --namespace $SPARK_NAMESPACE get sa -l "app.kubernetes.io/instance=$LIVY_APP_NAME" -o jsonpath='{.items[0].metadata.name}')
   echo "$SPARK_SERVICE_ACCOUNT"
   ```

   Debería ver algo similar al siguiente resultado:

   ```
   emr-containers-sa-spark-livy
   ```

1. Si has configurado `internalALB=true` para habilitar el acceso desde fuera de tu VPC, crea una EC2 instancia de Amazon y asegúrate de que el Network Load Balancer permita el tráfico de red procedente de la instancia. EC2 Debe hacerlo para que la instancia pueda acceder a su punto de conexión de Livy. Para obtener más información sobre cómo exponer su punto de conexión de forma segura fuera de su VPC, consulte [Configuración con un punto de conexión de Apache Livy segurocon TLS/SSL](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-secure-endpoint.html).

1. Al instalar Livy, se crea la cuenta de servicio `emr-containers-sa-spark` para ejecutar las aplicaciones de Spark. Si tu aplicación de Spark utiliza AWS recursos como S3 o llama a operaciones de AWS API o CLI, debes vincular un rol de IAM con los permisos necesarios a tu cuenta de servicio de Spark. Para obtener más información, consulte [Configuración de los permisos de acceso con roles de IAM para las cuentas de servicio (IRSA).](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-irsa.html)

Apache Livy admite configuraciones adicionales que puede usar al instalar Livy. Para obtener más información, consulte Propiedades de instalación de Apache Livy en Amazon EMR en EKS.

# Ejecución de una aplicación de Spark con Apache Livy para Amazon EMR en EKS
<a name="job-runs-apache-livy-run-spark"></a>

Antes de poder ejecutar una aplicación de Spark con Apache Livy, asegúrese de haber completado los pasos de [Configuración de Apache Livy para Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html) y la [Introducción a Apache Livy para Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-install.html).

Puede usar Apache Livy para ejecutar dos tipos de aplicaciones:
+ Sesiones por lotes: un tipo de carga de trabajo de Livy para enviar trabajos por lotes a Spark.
+ Sesiones interactivas: un tipo de carga de trabajo de Livy que proporciona una interfaz visual y programática para ejecutar consultas de Spark.

**nota**  
Los pods controladores y ejecutores de sesiones diferentes pueden comunicarse entre sí. Los espacios de nombres no garantizan la seguridad entre los pods. Kubernetes no permite permisos selectivos en un subconjunto de pods dentro de un espacio de nombres determinado.

## Ejecución de sesiones por lotes
<a name="job-runs-apache-livy-run-spark-batch"></a>

Para enviar un trabajo por lotes, use el siguiente comando.

```
curl -s -k -H 'Content-Type: application/json' -X POST \
      -d '{
            "name": "my-session",
            "file": "entryPoint_location (S3 or local)",
            "args": ["argument1", "argument2", ...],
            "conf": {
                "spark.kubernetes.namespace": "<spark-namespace>",
                "spark.kubernetes.container.image": "public.ecr.aws/emr-on-eks/spark/emr-7.12.0:latest",
                "spark.kubernetes.authenticate.driver.serviceAccountName": "<spark-service-account>"
            }
          }' <livy-endpoint>/batches
```

Para monitorizar el trabajo por lotes, use el siguiente comando.

```
curl -s -k -H 'Content-Type: application/json' -X GET <livy-endpoint>/batches/my-session
```

## Ejecución de sesiones interactivas
<a name="job-runs-apache-livy-run-spark-interactive"></a>

Para ejecutar sesiones interactivas con Apache Livy, consulte los siguientes pasos.

1. Asegúrate de tener acceso a un cuaderno Jupyter autohospedado o gestionado, como un SageMaker cuaderno Jupyter con IA. Su cuaderno de Jupyter debe tener [sparkmagic](https://github.com/jupyter-incubator/sparkmagic/blob/master/README.md) instalado.

1. Cree un bucket para la configuración de Spark `spark.kubernetes.file.upload.path`. Asegúrese de que la cuenta de servicio de Spark tenga acceso de lectura y escritura al bucket. Para obtener más información sobre cómo configurar su cuenta de servicio de Spark, consulte Configuración de los permisos de acceso con roles de IAM para las cuentas de servicio (IRSA)

1. Cargue sparkmagic en el cuaderno de Jupyter con el comando `%load_ext sparkmagic.magics`.

1. Ejecute el comando `%manage_spark` para configurar su punto de conexión de Livy con el cuaderno de Jupyter. Seleccione la pestaña **Añadir puntos de conexión**, elija el tipo de autenticación configurado, añada el punto de conexión de Livy al cuaderno y, a continuación, elija **Añadir punto de conexión**.

1. Vuelva a ejecutar `%manage_spark` para crear el contexto de Spark y, a continuación, vaya a **Crear sesión**. Elija el punto de conexión de Livy, especifique un nombre de sesión único, elija un idioma y, a continuación, añada las siguientes propiedades.

   ```
   {
     "conf": {
       "spark.kubernetes.namespace": "livy-namespace",
       "spark.kubernetes.container.image": "public.ecr.aws/emr-on-eks/spark/emr-7.12.0:latest",
       "spark.kubernetes.authenticate.driver.serviceAccountName": "<spark-service-account>", 
       "spark.kubernetes.file.upload.path": "<URI_TO_S3_LOCATION_>"
     }
   }
   ```

1. Envíe la solicitud y espere a que cree el contexto de Spark.

1. Para monitorizar el estado de la sesión interactiva, ejecute el siguiente comando.

   ```
   curl -s -k -H 'Content-Type: application/json' -X GET livy-endpoint/sessions/my-interactive-session
   ```

## Monitorización de aplicaciones de Spark
<a name="job-runs-apache-livy-run-ui"></a>

Para monitorizar el progreso de sus aplicaciones de Spark con la IU de Livy, use el enlace `http://<livy-endpoint>/ui`.

# Desinstalación de Apache Livy con Amazon EMR en EKS
<a name="job-runs-apache-livy-uninstall"></a>

Siga los pasos a continuación para desinstalar Apache Livy.

1. Elimine la configuración de Livy con los nombres de su espacio de nombres y el nombre de la aplicación. En este ejemplo, el nombre de la aplicación es `livy-demo` y el espacio de nombres es `livy-ns`.

   ```
   helm uninstall livy-demo -n livy-ns
   ```

1. Al realizar la desinstalación, Amazon EMR en EKS elimina el servicio de Kubernetes en Livy, los balanceadores de carga y AWS los grupos de destino que creó durante la instalación. La eliminación de recursos puede tardar unos minutos. Asegúrese de que los recursos se eliminen antes de volver a instalar Livy en el espacio de nombres.

1. Elimina el espacio de nombres de Spark.

   ```
   kubectl delete namespace spark-ns
   ```

# Seguridad de Apache Livy con Amazon EMR en EKS
<a name="job-runs-apache-livy-security"></a>

Consulte los siguientes temas para obtener más información sobre la configuración de la seguridad de Apache Livy con Amazon EMR en EKS. Estas opciones incluyen el uso de la seguridad a nivel de capa de transporte, el control de acceso basado en roles, es decir, el acceso en función del rol de una persona dentro de una organización, y el uso de roles de IAM, que proporcionan acceso a los recursos en función de los permisos otorgados.

**Topics**
+ [Configuración de un punto de conexión de Apache Livy seguro con TLS/SSL](job-runs-apache-livy-secure-endpoint.md)
+ [Configuración de los permisos de las aplicaciones de Apache Livy y Spark con control de acceso basado en roles (RBAC)](job-runs-apache-livy-rbac.md)
+ [Configuración de los permisos de acceso con roles de IAM para las cuentas de servicio (IRSA)](job-runs-apache-livy-irsa.md)

# Configuración de un punto de conexión de Apache Livy seguro con TLS/SSL
<a name="job-runs-apache-livy-secure-endpoint"></a>

Consulte las siguientes secciones para obtener más información sobre la configuración de Apache Livy para Amazon EMR en EKS end-to-end con cifrado TLS y SSL.

## Configuración del cifrado TLS y SSL
<a name="job-runs-apache-livy-security-tls"></a>

Para configurar el cifrado SSL en su punto de conexión de Apache Livy, siga estos pasos.
+ [Instale el controlador CSI de Secrets Store y el proveedor de AWS secretos y configuración (ASCP)](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html): el controlador CSI de Secrets Store y el ASCP almacenan de forma segura los certificados JKS y las contraseñas de Livy que el pod del servidor Livy necesita para habilitar el SSL. También puede instalar solo el controlador CSI de Secrets Store y utilizar cualquier otro proveedor de secretos compatible.
+ [Cree un certificado ACM](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html): este certificado es necesario para proteger la conexión entre el cliente y el punto de conexión de ALB.
+ Configure un certificado JKS, una contraseña clave y una contraseña del almacén de claves, necesarios para proteger la conexión entre el AWS Secrets Manager terminal ALB y el servidor Livy.
+ Añada permisos a la cuenta de servicio de Livy para recuperar los secretos AWS Secrets Manager : el servidor de Livy necesita estos permisos para recuperar los secretos de ASCP y añadir las configuraciones de Livy para proteger el servidor de Livy. Para añadir permisos de IAM a la cuenta del servicio, consulte Configuración de los permisos de acceso con roles de IAM para las cuentas de servicio (IRSA).

### Configurar un certificado JKS con una clave y una contraseña de almacén de claves para AWS Secrets Manager
<a name="job-runs-apache-livy-jks-certificate"></a>

Siga estos pasos para configurar un certificado JKS con una clave y una contraseña de almacén de claves.

1. Genere un archivo de almacén de claves para el servidor de Livy.

   ```
   keytool -genkey -alias <host> -keyalg RSA -keysize 2048 –dname CN=<host>,OU=hw,O=hw,L=<your_location>,ST=<state>,C=<country> –keypass <keyPassword> -keystore <keystore_file> -storepass <storePassword> --validity 3650
   ```

1. Cree un certificado.

   ```
   keytool -export -alias <host> -keystore mykeystore.jks -rfc -file mycertificate.cert -storepass <storePassword>
   ```

1. Cree un archivo de almacén de confianza.

   ```
   keytool -import -noprompt -alias <host>-file <cert_file> -keystore <truststore_file> -storepass <truststorePassword>
   ```

1. Guarde el certificado JKS en. AWS Secrets Manager Sustituya `livy-jks-secret` por su secreto y `fileb://mykeystore.jks` por la ruta al certificado JKS de su almacén de claves.

   ```
   aws secretsmanager create-secret \ 
   --name livy-jks-secret \
   --description "My Livy keystore JKS secret" \
   --secret-binary fileb://mykeystore.jks
   ```

1. Guarde el almacén de claves y la contraseña de claves en Secrets Manager. Asegúrese de utilizar sus propios parámetros.

   ```
   aws secretsmanager create-secret \
   --name livy-jks-secret \
   --description "My Livy key and keystore password secret" \
   --secret-string "{\"keyPassword\":\"<test-key-password>\",\"keyStorePassword\":\"<test-key-store-password>\"}"
   ```

1. Cree un espacio de nombres del servidor de Livy con el siguiente comando.

   ```
   kubectl create ns <livy-ns>
   ```

1. Cree el objeto `ServiceProviderClass` para el servidor de Livy que tiene el certificado JKS y las contraseñas.

   ```
   cat >livy-secret-provider-class.yaml << EOF
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: aws-secrets
   spec:
     provider: aws
     parameters:
       objects: |
           - objectName: "livy-jks-secret"
             objectType: "secretsmanager"
           - objectName: "livy-passwords"
             objectType: "secretsmanager"
                        
   EOF
   kubectl apply -f livy-secret-provider-class.yaml -n <livy-ns>
   ```

## Introducción a Apache Livy con SSL habilitado
<a name="job-runs-apache-livy-ssl-enabled-getting-started"></a>

Después de habilitar el SSL en su servidor de Livy, debe configurar la `serviceAccount` para tener acceso a los secretos `keyStore` y `keyPasswords` en AWS Secrets Manager.

1. Cree el espacio de nombres del servidor de Livy.

   ```
   kubectl create namespace <livy-ns>
   ```

1. Configure la cuenta de servicio Livy para tener acceso a los secretos en Secrets Manager. Para obtener más información sobre la configuración de IRSA, consulte [Configuración de los IRSA durante la instalación de Apache Livy](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-irsa.html#job-runs-apache-livy-irsa).

   ```
   aws ecr get-login-password \--region region-id | helm registry login \
   --username AWS \
   --password-stdin ECR-registry-account.dkr.ecr.region-id.amazonaws.com
   ```

1. Instale Livy. Para el gráfico de Helm: parámetro de versión, utilice su etiqueta de versión de Amazon EMR, como `7.1.0`. También debe sustituir el identificador de cuenta de registro de Amazon ECR y el identificador de región por los suyos propios. IDs Puede encontrar el `ECR-registry-account` valor correspondiente a sus [cuentas Región de AWS de registro de Amazon ECR por región](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html#docker-custom-images-ECR).

   ```
   helm install <livy-app-name> \
     oci://895885662937.dkr.ecr.region-id.amazonaws.com/livy \
     --version 7.12.0 \
     --namespace livy-namespace-name \
     --set image=<ECR-registry-account.dkr.ecr>.<region>.amazonaws.com/livy/emr-7.12.0:latest \
     --set sparkNamespace=spark-namespace \
     --set ssl.enabled=true
     --set ssl.CertificateArn=livy-acm-certificate-arn
     --set ssl.secretProviderClassName=aws-secrets
     --set ssl.keyStoreObjectName=livy-jks-secret
     --set ssl.keyPasswordsObjectName=livy-passwords
     --create-namespace
   ```

1. Continúe con el paso 5 de la [Instalación de Apache Livy en Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html#job-runs-apache-livy-install).

# Configuración de los permisos de las aplicaciones de Apache Livy y Spark con control de acceso basado en roles (RBAC)
<a name="job-runs-apache-livy-rbac"></a>

Para implementar Livy, Amazon EMR en EKS crea una cuenta y un rol de servicio de servidor y un rol y una cuenta de servicio de Spark. Estos roles deben tener los permisos RBAC necesarios para finalizar la configuración y ejecutar las aplicaciones de Spark.

**Permisos RBAC para el rol y la cuenta de servicio del servidor**

Amazon EMR en EKS crea el rol y la cuenta de servicio de servidor de Livy para administrar sesiones de Livy para los trabajos de Spark y enrutar el tráfico hacia y desde los recursos de entrada y otros recursos.

El nombre predeterminado de esta cuenta de servicio es `emr-containers-sa-livy`. Debe tener los siguientes permisos.

```
rules:
- apiGroups:
  - ""
  resources:
  - "namespaces"
  verbs:
  - "get"
- apiGroups:
  - ""
  resources:
  - "serviceaccounts"
    "services"
    "configmaps"
    "events"
    "pods"
    "pods/log"
  verbs:
  - "get"
    "list"
    "watch"
    "describe"
    "create"
    "edit"
    "delete"
    "deletecollection"
    "annotate"
    "patch"
    "label"
 - apiGroups:
   - ""
   resources:
   - "secrets"
   verbs:
   - "create"
     "patch"
     "delete"
     "watch"
 - apiGroups:
   - ""
   resources:
   - "persistentvolumeclaims"
   verbs:
   - "get"
     "list"
     "watch"
     "describe"
     "create"
     "edit"
     "delete"
     "annotate"
     "patch"
     "label"
```

**Permisos RBAC para el rol y la cuenta de servicio de Spark**

Un pod controlador de Spark necesita una cuenta de servicio de Kubernetes en el mismo espacio de nombres que el pod. Esta cuenta de servicio necesita permisos para administrar los pods ejecutores y cualquier recurso que requiera el pod controlador. A menos que la cuenta de servicio predeterminada del espacio de nombres tenga los permisos necesarios, el controlador fallará y se cerrará. Los siguientes permisos RBAC son necesarios.

```
rules:
- apiGroups:
  - ""
    "batch"
    "extensions"
    "apps"
  resources:
  - "configmaps"
    "serviceaccounts"
    "events"
    "pods"
    "pods/exec"
    "pods/log"
    "pods/portforward"
    "secrets"
    "services"
    "persistentvolumeclaims"
    "statefulsets"
  verbs:
  - "create"
    "delete"
    "get"
    "list"
    "patch"
    "update"
    "watch"
    "describe"
    "edit"
    "deletecollection"
    "patch"
    "label"
```

# Configuración de los permisos de acceso con roles de IAM para las cuentas de servicio (IRSA)
<a name="job-runs-apache-livy-irsa"></a>

De forma predeterminada, el servidor Livy y los controladores y ejecutores de la aplicación Spark no tienen acceso a los recursos. AWS La cuenta de servicio del servidor y la cuenta de servicio Spark controlan el acceso a AWS los recursos de los pods del servidor Livy y de la aplicación Spark. Para conceder el acceso, debes asignar las cuentas de servicio a un rol de IAM que tenga los permisos necesarios AWS .

Puede configurar la asignación de IRSA antes de instalar Apache Livy, durante la instalación o después de finalizarla.

## Configuración de IRSA durante la instalación de Apache Livy (para la cuenta de servicio del servidor)
<a name="job-runs-apache-livy-irsa"></a>

**nota**  
Esta asignación solo es compatible con la cuenta de servicio del servidor.

1. Asegúrese de haber terminado la [configuración de Apache Livy para Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html) y de que está realizando la [instalación de Apache Livy con Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-install.html). 

1. Cree un espacio de nombres de Kubernetes para el servidor Livy. En este ejemplo, el nombre del espacio de nombres es `livy-ns`.

1. Crea una política de IAM que incluya los permisos Servicios de AWS para los que quieres que accedan tus pods. El siguiente ejemplo crea una política de IAM para obtener recursos de Amazon S3 para el punto de entrada de Spark.

   ```
   cat >my-policy.json <<EOF{
   "Version": "2012-10-17",		 	 	 
       "Statement": [
           {
   "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-spark-entrypoint-bucket"
           }
       ]
   }
   EOF
   
   aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
   ```

1. Usa el siguiente comando para configurar tu Cuenta de AWS ID en una variable.

   ```
   account_id=$(aws sts get-caller-identity --query "Account" --output text)
   ```

1. Establezca el proveedor de identidades de OpenID Connect (OIDC) de su clúster en una variable de entorno.

   ```
   oidc_provider=$(aws eks describe-cluster --name my-cluster --region $AWS_REGION --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")
   ```

1. Establezca variables para el espacio de nombres y el nombre de la cuenta de servicio. Asegúrese de utilizar sus propios valores.

   ```
   export namespace=default
   export service_account=my-service-account
   ```

1. Cree un archivo de política de confianza con el comando siguiente. Si desea conceder el acceso al rol a todas las cuentas de servicio de un espacio de nombres, copie el siguiente comando y sustituya `StringEquals` por `StringLike`; sustituya, también, `$service_account` por `*`.

   ```
   cat >trust-relationship.json <<EOF
   {
     "Version": "2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "arn:aws:iam::$account_id:oidc-provider/$oidc_provider"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "$oidc_provider:aud": "sts.amazonaws.com",
             "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account"
           }
         }
       }
     ]
   }
   EOF
   ```

1. Creación del rol.

   ```
   aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
   ```

1. Utilice el siguiente comando de instalación Helm para establecer el `serviceAccount.executionRoleArn` para asignar IRSA. A continuación, se muestra un ejemplo del comando de instalación Helm. Puede encontrar el `ECR-registry-account` valor correspondiente a sus [cuentas Región de AWS de registro de Amazon ECR por región](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html#docker-custom-images-ECR).

   ```
   helm install livy-demo \
     oci://895885662937.dkr.ecr.us-west-2.amazonaws.com/livy \
     --version 7.12.0 \
     --namespace livy-ns \
     --set image=ECR-registry-account.dkr.ecr.region-id.amazonaws.com/livy/emr-7.12.0:latest \
     --set sparkNamespace=spark-ns \
     --set serviceAccount.executionRoleArn=arn:aws:iam::123456789012:role/my-role
   ```

## Asignación del IRSA a una cuenta de servicio de Spark
<a name="job-runs-apache-livy-irsa-spark"></a>

Antes de asignar el IRSA a una cuenta de servicio de Spark, asegúrese de haber realizado los siguientes pasos:
+ Asegúrese de haber terminado la [configuración de Apache Livy para Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html) y de que está realizando la [instalación de Apache Livy con Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-install.html). 
+ Debe tener un proveedor de OpenID Connect (OIDC) de IAM para su clúster. Para ver si ya tiene este proveedor o cómo crear uno, consulte [Crear un proveedor de OIDC de IAM para su clúster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
+ Asegúrese de que tiene la versión 0.171.0 o posterior de la CLI de `eksctl` instalada o AWS CloudShell. Para instalar o actualizar `eksctl`, consulte [Instalación](https://eksctl.io/installation/) en la `eksctl` documentación.

Siga estos pasos para asignar el IRSA a su cuenta de servicio de Spark:

1. Ejecute el comando siguiente para obtener la cuenta de servicio de Spark.

   ```
   SPARK_NAMESPACE=<spark-ns>
   LIVY_APP_NAME=<livy-app-name>
   kubectl --namespace $SPARK_NAMESPACE describe sa -l "app.kubernetes.io/instance=$LIVY_APP_NAME" | awk '/^Name:/ {print $2}'
   ```

1. Establezca variables para el espacio de nombres y el nombre de la cuenta de servicio.

   ```
   export namespace=default
   export service_account=my-service-account
   ```

1. Use el siguiente comando para crear un archivo de política de confianza para el rol de IAM. El siguiente ejemplo da permiso a todas las cuentas de servicio dentro del espacio de nombres para utilizar el rol. Para ello, sustituya `StringEquals` por `StringLike`; sustituya, también, `$service_account` por \$1.

   ```
   cat >trust-relationship.json <<EOF
   {
     "Version": "2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "arn:aws:iam::$account_id:oidc-provider/$oidc_provider"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "$oidc_provider:aud": "sts.amazonaws.com",
             "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account"
           }
         }
       }
     ]
   }
   EOF
   ```

1. Creación del rol.

   ```
   aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
   ```

1. Asigne el servidor o la cuenta de servicio de Spark con el siguiente comando `eksctl`. Asegúrese de utilizar sus propios valores.

   ```
    eksctl create iamserviceaccount --name spark-sa \
    --namespace spark-namespace --cluster livy-eks-cluster \
    --attach-role-arn arn:aws:iam::0123456789012:role/my-role \
    --approve --override-existing-serviceaccounts
   ```

# Propiedades de instalación de Apache Livy en las versiones de Amazon EMR en EKS.
<a name="job-runs-apache-livy-installation-properties"></a>

La instalación de Apache Livy le permite seleccionar una versión del gráfico de Helm de Livy. El gráfico de Helm ofrece una variedad de propiedades para personalizar su experiencia de instalación y configuración. Estas propiedades son compatibles con las versiones 7.1.0 y posteriores de Amazon EMR en EKS.

**Topics**
+ [Propiedades de instalación de Amazon EMR 7.1.0](#job-runs-apache-livy-installation-properties-710)

## Propiedades de instalación de Amazon EMR 7.1.0
<a name="job-runs-apache-livy-installation-properties-710"></a>

La tabla siguiente describe todas las propiedades de Livy compatibles. Al instalar Apache Livy, puede elegir la versión del gráfico de Helm de Livy. Para establecer una propiedad durante la instalación, utilice el comando `--set <property>=<value>`.


| Propiedad | Description (Descripción) | Predeterminado | 
| --- | --- | --- | 
| imagen | El URI de la versión de Amazon EMR del servidor Livy. Se trata de una configuración obligatoria. | "" | 
| sparkNamespace | Espacio de nombres para ejecutar sesiones de Spark de Livy. Por ejemplo, especifique "livy". Se trata de una configuración obligatoria. | "" | 
| nameOverride | Proporcione un nombre en lugar de livy. El nombre se establece como una etiqueta para todos los recursos de Livy | "livy" | 
| fullnameOverride | Proporcione un nombre para usarlo en lugar de los nombres completos de los recursos. | "" | 
| ssl.enabled | Habilita el end-to-end SSL desde el punto final de Livy al servidor de Livy. | FALSO | 
| ssl.certificateArn | Si el SSL está habilitado, este es el ARN del certificado ACM para el NLB creado por el servicio. | "" | 
| ssl. secretProviderClassNombre | Si el SSL está habilitado, este es el nombre de clase del proveedor secreto para proteger el NLB para la conexión del servidor Livy con SSL. | "" | 
| ssl. keyStoreObjectNombre | Si el SSL está habilitado, este es el nombre del objeto del certificado del almacén de claves de la clase de proveedor secreto. | "" | 
| ssl. keyPasswordsObjectNombre | Si el SSL está activado, este es el nombre de objeto del secreto que contiene el almacén de claves y la contraseña de claves. | "" | 
| rbac.create | Si es verdadero, crea recursos RBAC. | FALSO | 
| serviceAccount.create | Si es verdadero, crea una cuenta de servicio de Livy. | TRUE | 
| serviceAccount.name | El nombre de la cuenta de servicio que se utilizará para Livy. Si no establece esta propiedad ni crea una cuenta de servicio, Amazon EMR en EKS generará automáticamente un nombre mediante la propiedad de anulación de fullname. | "emr-containers-sa-livy" | 
| Cuenta de servicio. executionRoleArn | El ARN del rol de ejecución de la cuenta de servicio de Livy. | "" | 
| sparkServiceAccount.crear | SI es verdadero, crea la cuenta de servicio de Spark en .Release.Namespace | TRUE | 
| sparkServiceAccount.name | El nombre de la cuenta de servicio que se utilizará para Spark. Si no establece esta propiedad ni crea una cuenta de servicio Spark, Amazon EMR en EKS generará automáticamente un nombre mediante la propiedad fullnameOverride con el sufijo -spark-livy. | «emr-containers-sa-spark-livy» | 
| service.name | Nombre del servicio de Livy | "emr-containers-livy" | 
| service.annotations | Anotaciones del servicio de Livy | \$1\$1 | 
| loadbalancer.enabled | Si se debe crear un equilibrador de carga para el servicio Livy utilizado para exponer el punto de conexión de Livy fuera del clúster de Amazon EKS. | FALSE | 
| loadbalancer.internal | Si se debe configurar el punto de conexión de Livy como interno en la VPC o externo. Si se establece esta propiedad en `FALSE` se expone el punto de conexión a fuentes externas a la VPC. Recomendamos proteger el punto de conexión con TLS/SSL. Para obtener más información, consulte [Configuración del cifrado TLS y SSL](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-security.html#job-runs-apache-livy-security-tls). | FALSE | 
| imagePullSecrets | La lista de nombres imagePullSecret que se utilizarán para extraer la imagen de Livy de los repositorios privados. | [] | 
| recursos | Las solicitudes de recursos y los límites de los contenedores de Livy. | \$1\$1 | 
| nodeSelector | Los nodos para los que programar los pods de Livy. | \$1\$1 | 
| toleraciones | Una lista que contiene las tolerancias de los pods de Livy a definir. | [] | 
| afinidad | Las reglas de afinidad de los pods de Livy. | \$1\$1 | 
| persistence.enabled | Si es verdadero, habilita la persistencia de los directorios de sesiones. | FALSO | 
| persistence.subPath | La subruta de PVC que se monta en los directorios de las sesiones. | "" | 
| persistence.existingClaim | El PVC a utilizar en lugar de crear uno nuevo. | \$1\$1 | 
| persistence.storageClass | La clase de almacenamiento a utilizar. Para definir este parámetro, utilice el formato storageClassName: <storageClass>. Si este parámetro se establece en "-", se deshabilita el aprovisionamiento dinámico. Si establece este parámetro en nulo o no especifica nada, Amazon EMR en EKS no establece un storageClassName y usa el aprovisionador predeterminado. | "" | 
| persistence.accessMode | El modo de acceso al PVC. | ReadWriteOnce | 
| persistence.size | El tamaño del PVC. | 20 Gi | 
| persistence.annotations | Anotaciones adicionales para el PVC. | \$1\$1 | 
| env.\$1 | Envs adicionales para establecer en el contenedor de Livy. Para obtener más información, consulte [Introducción de sus propias configuraciones de Livy y Spark durante la instalación de Livy](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-troubleshooting.html). | \$1\$1 | 
| envFrom.\$1 | Envs adicionales para establecer Livy desde un mapa de configuración o secreto. | [] | 
| livyConf.\$1 | Entradas livy.conf adicionales para establecer desde un mapa de configuración o secreto de Kubernetes montado. | \$1\$1 | 
| sparkDefaultsConf.\$1 | Entradas spark-defaults.conf adicionales para establecer desde un mapa de configuración o secreto de Kubernetes montado. | \$1\$1 | 

# Solucione los errores comunes de formato de las variables de entorno
<a name="job-runs-apache-livy-troubleshooting"></a>

Al introducir las configuraciones de Livy y Spark, hay formatos de variables de entorno que no son compatibles y pueden provocar errores. El procedimiento le guía por una serie de pasos que le ayudan a garantizar que utiliza los formatos correctos.

**Introducción de sus propias configuraciones de Livy y Spark durante la instalación de Livy**

Puede configurar cualquier variable de entorno de Apache Livy o Apache Spark con la propiedad Helm `env.*`. Siga los pasos que se indican a continuación para convertir la configuración de ejemplo `example.config.with-dash.withUppercase` a un formato de variable de entorno compatible.

1. Sustituya las letras mayúsculas por un 1 y la letra en minúscula. Por ejemplo, `example.config.with-dash.withUppercase` se convierte en `example.config.with-dash.with1uppercase`.

1. Sustituya los guiones (-) por 0. Por ejemplo, `example.config.with-dash.with1uppercase` se convierte en `example.config.with0dash.with1uppercase`.

1. Sustituya los puntos (.) por guiones bajos (\$1). Por ejemplo, `example.config.with0dash.with1uppercase` se convierte en `example_config_with0dash_with1uppercase`.

1. Sustituya todas las letras minúsculas por letras mayúsculas.

1. Añada el prefijo `LIVY_` al nombre de la variable.

1. Utilice la variable al instalar Livy a través del diagrama de Helm con el formato --set env. *YOUR\$1VARIABLE\$1NAME*.valor= *yourvalue*

Por ejemplo, para establecer las configuraciones de `livy.server.recovery.state-store = filesystem` y `spark.kubernetes.executor.podNamePrefix = my-prefix`, use estas propiedades de Helm:

```
—set env.LIVY_LIVY_SERVER_RECOVERY_STATE0STORE.value=filesystem
—set env.LIVY_SPARK_KUBERNETES_EXECUTOR_POD0NAME0PREFIX.value=myprefix
```

# Administración de las ejecuciones de trabajos de Amazon EMR en EKS
<a name="emr-eks-jobs-manage"></a>

En las siguientes secciones, se tratan temas que le ayudan a administrar las ejecuciones de trabajos de Amazon EMR en EKS. Estas incluyen configurar los parámetros de ejecución de los trabajos cuando los usas AWS CLI, configurar la forma en que se almacenan los datos de registro, ejecutar scripts SQL de Spark para ejecutar consultas, entender los estados de ejecución de los trabajos y saber cómo monitorear los trabajos. Si quiere configurar y completar una ejecución de trabajos para procesar datos, puede trabajar en estos temas, por lo general en orden.

**Topics**
+ [Administrar las ejecuciones de tareas con AWS CLI](emr-eks-jobs-CLI.md)
+ [Ejecutar scripts SQL de StartJobRun Spark a través de la API](emr-eks-jobs-spark-sql-parameters.md)
+ [Estados de ejecuciones de trabajos](emr-eks-jobs-states.md)
+ [Visualización de trabajos en la consola de Amazon EMR](emr-eks-jobs-console.md)
+ [Errores comunes al ejecutar trabajos](emr-eks-jobs-error.md)

# Administrar las ejecuciones de tareas con AWS CLI
<a name="emr-eks-jobs-CLI"></a>

En este tema se explica cómo gestionar las ejecuciones de tareas con AWS Command Line Interface (AWS CLI). Aborda detalles sobre las propiedades, como los parámetros de seguridad, el controlador y varios ajustes de anulación. También incluye subtemas que abarcan diversas formas de configurar el registro.

**Topics**
+ [Opciones para configurar una ejecución de trabajo](#emr-eks-jobs-parameters)
+ [Configure una ejecución de trabajo para utilizar registros de Amazon S3](emr-eks-jobs-s3.md)
+ [Configurar una ejecución de tareas para usar Amazon CloudWatch Logs](emr-eks-jobs-cloudwatch.md)
+ [Enumerar ejecuciones de trabajos](#emr-eks-jobs-list)
+ [Describir una ejecución de trabajo](#emr-eks-jobs-describe)
+ [Cancelar una ejecución de trabajo](#emr-eks-jobs-cancel)

## Opciones para configurar una ejecución de trabajo
<a name="emr-eks-jobs-parameters"></a>

Utilice las siguientes opciones para configurar los parámetros de ejecución del trabajo:
+ `--execution-role-arn`: debe proporcionar un rol de IAM que se utilice para ejecutar trabajos. Para obtener más información, consulte [Uso de roles de ejecución de trabajos con Amazon EMR en EKS](iam-execution-role.md). 
+ `--release-label`: puede implementar Amazon EMR en EKS con las versiones 5.32.0, 6.2.0 y posteriores de Amazon EMR. Amazon EMR en EKS no es compatible con las versiones de lanzamiento anteriores de Amazon EMR. Para obtener más información, consulte [Versiones de Amazon EMR en EKS](emr-eks-releases.md). 
+ `--job-driver`: el controlador de trabajo se utiliza para proporcionar información sobre el trabajo principal. Se trata de un campo de tipo unión en el que solo puede pasar uno de los valores del tipo de trabajo que desee ejecutar. Los tipos de trabajo admitidos son:
  + Envío de trabajos de Spark: se usa para ejecutar un comando a través de spark-submit. Puedes usar este tipo de trabajo para ejecutar Scala, SparkR PySpark, SparkSQL y cualquier otro trabajo compatible a través de Spark Submit. Este tipo de trabajo tiene los siguientes parámetros:
    + Punto de entrada: es la referencia HCFS (sistema de archivos compatible con Hadoop) al archivo principal que quieres ejecutar. jar/py 
    + EntryPointArguments - Se trata de un conjunto de argumentos que quieres pasar a tu archivo principal. jar/py Debería manejar la lectura de estos parámetros mediante su código de punto de entrada. Cada argumento de la matriz debe estar separado por una coma. EntryPointArguments no puede contener corchetes o paréntesis, como (), \$1\$1 o []. 
    + SparkSubmitParameters - Estos son los parámetros de chispa adicionales que desea enviar al trabajo. Use este parámetro para anular las propiedades predeterminadas de Spark, como la memoria del controlador o el número de ejecutores, como —conf o —class. Para obtener más información, consulte [Launching Applications with spark-submit](https://spark.apache.org/docs/latest/submitting-applications.html#launching-applications-with-spark-submit).
  + Trabajos de Spark SQL: se utilizan para ejecutar un archivo de consulta SQL a través de Spark SQL. Puede usar este tipo de trabajo para ejecutar trabajos de SparkSQL. Este tipo de trabajo tiene los siguientes parámetros:
    + Entrypoint: es la referencia del HCFS (sistema de archivos compatible con Hadoop) al archivo de consulta SQL que desea ejecutar.

      Para ver una lista de parámetros de Spark adicionales que puede usar para un trabajo de Spark SQL, consulte [Ejecutar scripts SQL de StartJobRun Spark a través de la API](emr-eks-jobs-spark-sql-parameters.md).
+ `--configuration-overrides`: puede anular las configuraciones predeterminadas de las aplicaciones suministrando un objeto de configuración. Puede utilizar una sintaxis abreviada para proporcionar la configuración o hacer referencia al objeto de configuración en un archivo JSON. Los objetos de configuración se componen de una clasificación, propiedades y configuraciones anidadas opcionales. Las propiedades se componen de la configuración que se desea anular en ese archivo. Es posible especificar varias clasificaciones para varias aplicaciones en un solo objeto JSON. Las clasificaciones de configuración disponibles varían según la versión de Amazon EMR. Para ver una lista de las clasificaciones de configuración que están disponibles para cada versión de Amazon EMR, consulte [Versiones de Amazon EMR en EKS](emr-eks-releases.md).

  Si pasa la misma configuración en una aplicación de anulación y en los parámetros de envío de Spark, prevalecerán los parámetros de envío de Spark. A continuación se muestra la lista completa de prioridades de configuración, en orden de mayor a menor.
  + Configuración proporcionada al crear `SparkSession`.
  + Configuración proporcionada como parte de `sparkSubmitParameters` mediante `—conf`.
  + Configuración proporcionada como parte de las anulaciones de aplicaciones.
  + Configuraciones optimizadas elegidas por Amazon EMR para la versión.
  + Configuraciones de código abierto predeterminadas para la aplicación.

  Para supervisar las ejecuciones de tareas mediante Amazon CloudWatch o Amazon S3, debe proporcionar los detalles de configuración de CloudWatch. Para obtener más información, consulte [Configure una ejecución de trabajo para utilizar registros de Amazon S3](emr-eks-jobs-s3.md) y [Configurar una ejecución de tareas para usar Amazon CloudWatch Logs](emr-eks-jobs-cloudwatch.md). Si el depósito o grupo de CloudWatch registros de S3 no existe, Amazon EMR lo crea antes de cargar los registros en el depósito.
+ Para obtener una lista adicional de las opciones de configuración de Kubernetes, consulte [Propiedades de Spark en Kubernetes](https://spark.apache.org/docs/latest/running-on-kubernetes.html#configuration). 

  Las siguientes configuraciones de Spark no son compatibles.
  + `spark.kubernetes.authenticate.driver.serviceAccountName`
  + `spark.kubernetes.authenticate.executor.serviceAccountName`
  + `spark.kubernetes.namespace`
  + `spark.kubernetes.driver.pod.name`
  + `spark.kubernetes.container.image.pullPolicy`
  + `spark.kubernetes.container.image`
**nota**  
Puede utilizar `spark.kubernetes.container.image` para imágenes de Docker personalizadas. Para obtener más información, consulte [Personalización de las imágenes de Docker para Amazon EMR en EKS](docker-custom-images.md).

# Configure una ejecución de trabajo para utilizar registros de Amazon S3
<a name="emr-eks-jobs-s3"></a>

Para poder supervisar el progreso del trabajo y solucionar los errores, debe configurar los trabajos para que envíen la información de registro a Amazon S3, Amazon CloudWatch Logs o ambos. Este tema le ayuda a empezar a publicar registros de aplicaciones en Amazon S3 en los trabajos que se lanzan con Amazon EMR en EKS.

**Política de IAM de los registros de S3**

Antes de que sus trabajos puedan enviar datos de registro a Amazon S3, se deben incluir los siguientes permisos en la política de permisos del rol de ejecución del trabajo. Reemplace *amzn-s3-demo-logging-bucket* con el nombre de su bucket de registro.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket",
        "arn:aws:s3:::amzn-s3-demo-bucket/*"
      ],
      "Sid": "AllowS3Putobject"
    }
  ]
}
```

------

**nota**  
Amazon EMR en EKS también puede crear un bucket de Amazon S3. Si no hay ningún bucket de Amazon S3 disponible, incluya el permiso `“s3:CreateBucket”` en la política de IAM.

Una vez que haya otorgado a su rol de ejecución los permisos adecuados para enviar registros a Amazon S3, los datos de registro se envían a las siguientes ubicaciones de Amazon S3 cuando `s3MonitoringConfiguration` se transfiere a la sección `monitoringConfiguration` de una solicitud `start-job-run`, como se muestra en [Administrar las ejecuciones de tareas con AWS CLI](emr-eks-jobs-CLI.md).
+ Registros del remitente://*virtual-cluster-id*/jobs/ /containers/*logUri*/(stderr.gz/stdout.gz*job-id*) *pod-name*
+ Registros de controladores:/*logUri*/*virtual-cluster-id*/jobs/ *job-id* /containers/ /spark- *spark-application-id* -driver/ *job-id* (stderr.gz/stdout.gz)
+ Registros de ejecutores:*logUri*//*virtual-cluster-id*/jobs/ *job-id* /containers//*executor-pod-name*/(*spark-application-id*stderr.gz/stdout.gz)

# Configurar una ejecución de tareas para usar Amazon CloudWatch Logs
<a name="emr-eks-jobs-cloudwatch"></a>

Para supervisar el progreso de los trabajos y solucionar los errores, debe configurar los trabajos para que envíen la información de registro a Amazon S3, Amazon CloudWatch Logs o ambos. Este tema le ayuda a empezar a utilizar CloudWatch los registros en los trabajos que se lanzan con Amazon EMR en EKS. Para obtener más información sobre CloudWatch los registros, consulte [Supervisión de los archivos de registro](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) en la Guía del CloudWatch usuario de Amazon.

**CloudWatch Registros: política de IAM**

Para que sus trabajos envíen datos de registro a CloudWatch Logs, se deben incluir los siguientes permisos en la política de permisos del rol de ejecución del trabajo. Sustituya *my\$1log\$1group\$1name* y por *my\$1log\$1stream\$1prefix* los nombres de su grupo de CloudWatch registros y los nombres de los flujos de registros, respectivamente. Amazon EMR en EKS crea el grupo de registros y el flujo de registros si no existen, siempre y cuando el ARN del rol de ejecución tenga los permisos adecuados. 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "arn:aws:logs:*:*:*"
      ],
      "Sid": "AllowLOGSCreatelogstream"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:PutLogEvents"
      ],
      "Resource": [
        "arn:aws:logs:*:*:log-group:my_log_group_name:log-stream:my_log_stream_prefix/*"
      ],
      "Sid": "AllowLOGSPutlogevents"
    }
  ]
}
```

------

**nota**  
Amazon EMR en EKS también puede crear un flujo de registro. Si no existe ningún flujo de registro, la política de IAM debe incluir el permiso `"logs:CreateLogGroup"`.

Una vez que hayas otorgado a tu función de ejecución los permisos adecuados, tu aplicación envía sus datos de registro a CloudWatch Logs cuando `cloudWatchMonitoringConfiguration` se los transfiere a la `monitoringConfiguration` sección de una `start-job-run` solicitud, como se muestra en la siguiente[Administrar las ejecuciones de tareas con AWS CLI](emr-eks-jobs-CLI.md).

En la `StartJobRun` API, *log\$1group\$1name * es el nombre del grupo de CloudWatch registros y *log\$1stream\$1prefix* el prefijo del nombre del flujo de CloudWatch registros. Puede consultar y buscar estos registros en la Consola de administración de AWS.
+ Registros del remitente:*logGroup*//*virtual-cluster-id*/jobs/ *logStreamPrefix* /containers//(stderr/stdout*job-id*) *pod-name*
+ Registros de controladores:///jobs/ /containers/ /spark- -driver/ (stderrstdout) *logGroup* *logStreamPrefix* *virtual-cluster-id* *job-id* *spark-application-id* *job-id*
+ Registros del ejecutor: *logGroup**logStreamPrefix*/*virtual-cluster-id*/*job-id*/jobs/ *spark-application-id* /containers//*executor-pod-name*/(stderr/stdout)

## Enumerar ejecuciones de trabajos
<a name="emr-eks-jobs-list"></a>

Puede ejecutar `list-job-run` para mostrar los estados de las ejecuciones de los trabajos, como se muestra en el siguiente ejemplo. 

```
aws emr-containers list-job-runs --virtual-cluster-id <cluster-id>
```

## Describir una ejecución de trabajo
<a name="emr-eks-jobs-describe"></a>

Puede ejecutar `describe-job-run` para obtener más detalles sobre el trabajo, como el estado, los detalles del estado y el nombre del trabajo, tal como se muestra en el siguiente ejemplo. 

```
aws emr-containers describe-job-run --virtual-cluster-id cluster-id --id job-run-id
```

## Cancelar una ejecución de trabajo
<a name="emr-eks-jobs-cancel"></a>

Puede ejecutar `cancel-job-run` para cancelar los trabajos en ejecución, tal como se muestra en el siguiente ejemplo.

```
aws emr-containers cancel-job-run --virtual-cluster-id cluster-id --id job-run-id
```

# Ejecutar scripts SQL de StartJobRun Spark a través de la API
<a name="emr-eks-jobs-spark-sql-parameters"></a>

Las versiones 6.7.0 y posteriores de Amazon EMR en EKS incluyen un controlador de tareas de Spark SQL para que pueda ejecutar scripts de Spark SQL a través de la API `StartJobRun`. Puede suministrar archivos de punto de entrada de SQL para ejecutar directamente consultas de Spark SQL en Amazon EMR en EKS con la API de `StartJobRun`, sin modificar los scripts de Spark SQL existentes. En la siguiente tabla, se enumeran los parámetros de Spark compatibles con los trabajos de Spark SQL a través de la StartJobRun API.

Puede elegir entre los siguientes parámetros de Spark para enviarlos a un trabajo de Spark SQL. Use estos parámetros para anular las propiedades predeterminadas de Spark.


| Opción | Description (Descripción) | 
| --- | --- | 
|  --name NAME  | Nombre de la aplicación | 
| --jars JARS | Lista de archivos jar separados por comas que se incluirán con el classpath de controlador y ejecutor. | 
| --packages | Lista de coordenadas Maven de los archivos jar separadas por comas para incluirlas en los classpaths de controlador y ejecutor. | 
| --exclude-packages | Lista separada por comas de groupId:artifactId, para excluir mientras se resuelven las dependencias proporcionadas en –packages para evitar conflictos de dependencia. | 
| --repositories | Lista de repositorios remotos adicionales separados por comas para buscar las coordenadas Maven proporcionadas con –packages. | 
| --files FILES | Lista de archivos separados por comas que se colocarán en el directorio de trabajo de cada ejecutor. | 
| --conf PROP=VALUE | Propiedad de configuración de Spark. | 
| --properties-file FILE | Ruta a un archivo desde el que cargar propiedades adicionales. | 
| --driver-memory MEM | Memoria para el controlador. 1024 MB por defecto. | 
| --driver-java-options | Opciones de Java adicionales para pasarlas al controlador. | 
| --driver-library-path | Entradas adicionales de la ruta de la biblioteca para pasarlas al controlador. | 
| --driver-class-path | Entradas de ruta de clases adicionales para pasarlas al controlador. | 
| --executor-memory MEM | Memoria por ejecutor. 1 GB por defecto. | 
| --driver-cores NUM | Número de núcleos utilizados por el controlador. | 
| -- total-executor-cores NUM | Núcleos totales para todos los ejecutores. | 
| --executor-cores NUM | Número de núcleos utilizados por cada ejecutor. | 
| --num-executors NUM | Número de ejecutores que se van a lanzar. | 
| -hivevar <key=value> | Sustitución de variables para aplicarla a los comandos de Hive, por ejemplo, -hivevar A=B | 
| -hiveconf <property=value> | Valor que se va a usar para la propiedad dada. | 

Para un trabajo de Spark SQL, cree un start-job-run-request archivo.json y especifique los parámetros necesarios para la ejecución del trabajo, como en el siguiente ejemplo:

```
{
  "name": "myjob", 
  "virtualClusterId": "123456",  
  "executionRoleArn": "iam_role_name_for_job_execution", 
  "releaseLabel": "emr-6.7.0-latest", 
  "jobDriver": {
    "sparkSqlJobDriver": {
      "entryPoint": "entryPoint_location",
       "sparkSqlParameters": "--conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"
    }
  }, 
  "configurationOverrides": {
    "applicationConfiguration": [
      {
        "classification": "spark-defaults", 
        "properties": {
          "spark.driver.memory":"2G"
         }
      }
    ], 
    "monitoringConfiguration": {
      "persistentAppUI": "ENABLED", 
      "cloudWatchMonitoringConfiguration": {
        "logGroupName": "my_log_group", 
        "logStreamNamePrefix": "log_stream_prefix"
      }, 
      "s3MonitoringConfiguration": {
        "logUri": "s3://my_s3_log_location"
      }
    }
  }
}
```

# Estados de ejecuciones de trabajos
<a name="emr-eks-jobs-states"></a>

Al enviar una ejecución de trabajo a una cola de trabajos de Amazon EMR en EKS, el trabajo pasa al estado `PENDING`. A continuación, pasa por los estados siguientes hasta que termina de ejecutarse correctamente (finaliza con el código `0`) o no (finaliza con un código distinto de cero). 

Las ejecuciones de trabajos pueden tener los siguientes estados:
+ `PENDING`: el estado inicial del trabajo cuando la ejecución del trabajo se envía a Amazon EMR en EKS. El trabajo está a la espera de enviarse al clúster virtual y Amazon EMR en EKS está trabajando para enviarlo.
+ `SUBMITTED`: una ejecución de trabajo que se envió correctamente al clúster virtual. A continuación, el programador de clústeres intenta ejecutar este trabajo en el clúster.
+ `RUNNING`: una ejecución de trabajo que se está ejecutando en el clúster virtual. En las aplicaciones de Spark, esto significa que el estado del proceso del controlador de Spark es `running`.
+ `FAILED`: una ejecución de trabajo que no se pudo enviar al clúster virtual o que se completó sin éxito. Consulta StateDetails y FailureReason encuentra información adicional sobre este error en el trabajo.
+ `COMPLETED`: una ejecución de trabajo que se ha completado correctamente.
+ `CANCEL_PENDING`: se ha solicitado la cancelación de una ejecución de trabajo. Amazon EMR en EKS está intentando cancelar el trabajo en el clúster virtual.
+ `CANCELLED`: una ejecución de trabajo que se canceló correctamente.

# Visualización de trabajos en la consola de Amazon EMR
<a name="emr-eks-jobs-console"></a>

Los datos de ejecución de los trabajos están disponibles para su visualización, por lo que puede monitorizar cada trabajo a medida que pasa por los estados. Para ver trabajos en la consola de Amazon EMR, siga estos pasos.

1. En el menú de la izquierda de la consola de Amazon EMR, en Amazon EMR en EKS, elija **Clústeres virtuales**.

1. En la lista de clústeres virtuales, seleccione el clúster virtual del que desee ver los trabajos.

1. En la tabla **Ejecuciones de tareas**, seleccione **Ver registros** para ver los detalles de una ejecución de trabajos.

**nota**  
La compatibilidad con la experiencia de un solo clic está habilitada de forma predeterminada. Se puede desactivar al configurar `persistentAppUI` a `DISABLED` en `monitoringConfiguration` durante el envío del trabajo. Para obtener más información, consulte [Ver interfaces de usuario de aplicaciones persistentes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html).

# Errores comunes al ejecutar trabajos
<a name="emr-eks-jobs-error"></a>

Se pueden producir los siguientes errores al ejecutar la API de `StartJobRun`. En la tabla se muestra cada error y se proporcionan los pasos de mitigación para que pueda abordar los problemas rápidamente.


| Mensaje de error | Condición de error | Siguiente paso recomendado | 
| --- | --- | --- | 
|  error: argumento -- *argument* es obligatorio  | Faltan parámetros obligatorios. | Agregue los argumentos que faltan a la solicitud de la API. | 
| Se produjo un error (AccessDeniedException) al llamar a la StartJobRun operación: el usuario: no ARN está autorizado a realizar: emr-containers: StartJobRun | Falta el rol de ejecución. | Consulte Uso de [Uso de roles de ejecución de trabajos con Amazon EMR en EKS](iam-execution-role.md).  | 
|  Se produjo un error (AccessDeniedException) al llamar a la StartJobRun operación: El usuario: no *ARN* está autorizado a realizar: emr-containers: StartJobRun  |  La persona que llama no tiene permiso para el rol de ejecución [formato válido o no válido] a través de claves de condición.  | Consulte [Uso de roles de ejecución de trabajos con Amazon EMR en EKS](iam-execution-role.md).  | 
|  Se produjo un error (AccessDeniedException) al llamar a la StartJobRun operación: El usuario: no *ARN* está autorizado a realizar: emr-containers: StartJobRun  |  El ARN del remitente del trabajo y del rol de ejecución provienen de cuentas diferentes.  | Asegúrese de que el remitente del trabajo y el ARN del rol de ejecución pertenezcan a la misma cuenta de AWS . | 
|  Se detectó 1 error de validación: el valor *Role* en 'executionRoleArn' no satisfacía el patrón de expresión regular del ARN: ^arn :( aws [a-zA-Z0-9-] \$1) :iam: :(\$1 d \$112\$1)? : (rol ((\$1 u002F) \$1 (\$1 u002F [\$1 u0021-\$1 u007F] \$1\$1 u002F)) [\$1 w\$1=, .@-] \$1)  |  La persona que llama tiene permisos para el rol de ejecución a través de claves de condición, pero la función no cumple con las restricciones del formato de ARN.  | Proporcione el rol de ejecución según el formato de ARN. Consulte [Uso de roles de ejecución de trabajos con Amazon EMR en EKS](iam-execution-role.md).  | 
|  Se ResourceNotFoundException ha producido un StartJobRun error () al llamar a la operación: el clúster virtual no existe. *Virtual Cluster ID*  |  No se encuentra el ID del clúster virtual.  | Proporcione un ID de clúster virtual registrado con Amazon EMR en EKS. | 
|  Se produjo un error (ValidationException) al llamar a la StartJobRun operación: el estado del clúster virtual no *state* es válido para crear un recurso JobRun.  |  El clúster virtual no está preparado para ejecutar el trabajo.  | Consulte [Estados del clúster virtual](virtual-cluster.md#virtual-cluster-states).  | 
|  Se produjo un error (ResourceNotFoundException) al llamar a la StartJobRun operación: la versión *RELEASE* no existe.  |  La versión especificada en el envío del trabajo es incorrecta.  | Consulte [Versiones de Amazon EMR en EKS](emr-eks-releases.md).  | 
|  Se produjo un error (AccessDeniedException) al llamar a la StartJobRun operación: el usuario: no *ARN* está autorizado a realizar: emr-containers: StartJobRun on resource: *ARN* con una denegación explícita. Se produjo un error (AccessDeniedException) al llamar a la StartJobRun operación: el usuario: no *ARN* está autorizado a realizar: emr-containers: on resource: StartJobRun *ARN*  | El usuario no está autorizado a llamar. StartJobRun | Consulte [Uso de roles de ejecución de trabajos con Amazon EMR en EKS](iam-execution-role.md).  | 
|  Se produjo un error (ValidationException) al llamar a la StartJobRun operación: ConfigurationOverrides.MonitoringConfiguration.s3 MonitoringConfiguration .LogUri no pudo cumplir la restricción: %s  |  La sintaxis del URI de la ruta de S3 no es válida.  | logURI debe tener el formato s3://...  | 

Se pueden producir los siguientes errores al ejecutar la API de `DescribeJobRun` antes de que se ejecute el trabajo.


| Mensaje de error | Condición de error | Siguiente paso recomendado | 
| --- | --- | --- | 
|   JobRun StateDetails: error en el envío.  *classification*No se admite la clasificación. failureReason: VALIDATION\$1ERROR state: FAILED.  | Los parámetros StartJobRun incluidos no son válidos. | Consulte [Versiones de Amazon EMR en EKS](emr-eks-releases.md).  | 
|  StateDetails: *EKS Cluster ID* el clúster no existe. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  | El clúster de EKS no está disponible. | Compruebe si el clúster de EKS existe y tiene los permisos correctos. Para obtener más información, consulte [Configuración de Amazon EMR en EKS](setting-up.md). | 
|  StateDetails: *EKS Cluster ID* El clúster no tiene permisos suficientes. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  |  Amazon EMR no tiene permisos para acceder al clúster de EKS.  | Compruebe que los permisos estén configurados para Amazon EMR en el espacio de nombres registrado. Para obtener más información, consulte [Configuración de Amazon EMR en EKS](setting-up.md). | 
|  StateDetails: actualmente no *EKS Cluster ID* se puede acceder al clúster. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  |  No se puede llegar al clúster de EKS.  | Compruebe si el clúster de EKS existe y tiene los permisos correctos. Para obtener más información, consulte [Configuración de Amazon EMR en EKS](setting-up.md). | 
|  StateDetails: el JobRun envío falló debido a un error interno. failureReason: INTERNAL\$1ERROR state: FAILED  |  Se produjo un error interno en el clúster de EKS.  | N/A | 
|  StateDetails: *EKS Cluster ID* El clúster no tiene recursos suficientes. failureReason: USER\$1ERROR state: FAILED  |  No hay recursos suficientes en el clúster de EKS para ejecutar el trabajo.  | Agregue más capacidad al grupo de nodos de EKS o configure el escalador automático de EKS. Para obtener más información, consulte [Escalador automático de clústeres](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html). | 

Se pueden producir los siguientes errores al ejecutar la API de `DescribeJobRun` tras la ejecución del trabajo.


| Mensaje de error | Condición de error | Siguiente paso recomendado | 
| --- | --- | --- | 
|  StateDetails: Problemas para monitorear su. JobRun  *EKS Cluster ID*El clúster no existe. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  | El clúster de EKS no existe. | Compruebe si el clúster de EKS existe y tiene los permisos correctos. Para obtener más información, consulte [Configuración de Amazon EMR en EKS](setting-up.md). | 
|  StateDetails: Problemas para monitorear su. JobRun *EKS Cluster ID*El clúster no tiene permisos suficientes. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  | Amazon EMR no tiene permisos para acceder al clúster de EKS. | Compruebe que los permisos estén configurados para Amazon EMR en el espacio de nombres registrado. Para obtener más información, consulte [Configuración de Amazon EMR en EKS](setting-up.md). | 
|  StateDetails: Problemas para monitorear su. JobRun No *EKS Cluster ID* se puede acceder al clúster en este momento. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  |  No se puede llegar al clúster de EKS.  | Compruebe si el clúster de EKS existe y tiene los permisos correctos. Para obtener más información, consulte [Configuración de Amazon EMR en EKS](setting-up.md). | 
|  StateDetails: Problemas para monitorizarlo JobRun debido a un error interno failureReason: INTERNAL\$1ERROR state: FAILED  |  Se ha producido un error interno que impide la JobRun supervisión.  | N/A | 

El siguiente error puede producirse cuando un trabajo no puede iniciarse y el trabajo espera 15 minutos en el estado ENVIADO. Esto puede deberse a la falta de recursos del clúster.


| Mensaje de error | Condición de error | Siguiente paso recomendado | 
| --- | --- | --- | 
|  tiempo de espera del clúster  | El estado del trabajo ha sido ENVIADO durante 15 minutos o más. | Puede anular la configuración predeterminada de 15 minutos para este parámetro con la modificación de configuración que se muestra a continuación.  | 

Use la siguiente configuración para cambiar el tiempo de espera del clúster a 30 minutos. Tenga en cuenta que proporciona el nuevo valor `job-start-timeout` en segundos:

```
{
"configurationOverrides": {
  "applicationConfiguration": [{
      "classification": "emr-containers-defaults",
      "properties": {
          "job-start-timeout":"1800"
      }
  }]
}
```

# Uso de plantillas de trabajos
<a name="job-templates"></a>

Una plantilla de trabajo almacena valores que se pueden compartir entre las invocaciones de la API `StartJobRun` al iniciar la ejecución de un trabajo. Admite dos casos de uso:
+ Para evitar valores de solicitud de la API de `StartJobRun` periódicos y repetitivos.
+ Para hacer cumplir una regla según la cual ciertos valores deben proporcionarse mediante solicitudes de la API de `StartJobRun`.

Las plantillas de trabajos permiten definir una plantilla reutilizable para las ejecuciones de trabajos a fin de aplicar una personalización adicional, por ejemplo:
+ Configuración de la capacidad de computación del ejecutor y del controlador
+ Establecer propiedades de seguridad y gobernanza, como los roles de IAM
+ Personalizar una imagen de docker para usarla en múltiples aplicaciones y canalizaciones de datos

En los temas siguientes se proporciona información detallada sobre el uso de plantillas, incluido cómo usarlas para iniciar la ejecución de un trabajo y cómo cambiar los parámetros de las plantillas.

**Topics**
+ [Creación y uso de una plantilla de trabajo para iniciar la ejecución de un trabajo](create-job-template.md)
+ [Definición de parámetros de plantilla de trabajo](use-job-template-parameters.md)
+ [Control del acceso a las plantillas de trabajos](iam-job-template.md)

# Creación y uso de una plantilla de trabajo para iniciar la ejecución de un trabajo
<a name="create-job-template"></a>

En esta sección se describe la creación de una plantilla de trabajo y su uso para iniciar la ejecución de un trabajo con AWS Command Line Interface (AWS CLI).

**Para crear una nueva plantilla de trabajo**

1. Cree un archivo `create-job-template-request.json` y especifique los parámetros necesarios para la plantilla de trabajo, como se muestra en el siguiente archivo JSON de ejemplo. Para obtener información sobre todos los parámetros disponibles, consulta la [CreateJobTemplate](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/Welcome.html)API.

   La mayoría de los valores necesarios para la API `StartJobRun` también lo son para `jobTemplateData`. Si desea utilizar marcadores de posición para cualquier parámetro y proporcionar valores al invocar StartJobRun mediante una plantilla de trabajo, consulte la siguiente sección sobre los parámetros de la plantilla de trabajo.

   ```
   {
      "name": "mytemplate",
      "jobTemplateData": {
           "executionRoleArn": "iam_role_arn_for_job_execution", 
           "releaseLabel": "emr-6.7.0-latest",
           "jobDriver": {
               "sparkSubmitJobDriver": { 
                   "entryPoint": "entryPoint_location",
                   "entryPointArguments": [ "argument1","argument2",...],
                   "sparkSubmitParameters": "--class <main_class> --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"
               }
           },
           "configurationOverrides": {
               "applicationConfiguration": [
                   {
                       "classification": "spark-defaults", 
                       "properties": {
                            "spark.driver.memory":"2G"
                       }
                   }
               ], 
               "monitoringConfiguration": {
                   "persistentAppUI": "ENABLED", 
                   "cloudWatchMonitoringConfiguration": {
                       "logGroupName": "my_log_group", 
                       "logStreamNamePrefix": "log_stream_prefix"
                   }, 
                   "s3MonitoringConfiguration": {
                       "logUri": "s3://my_s3_log_location/"
                   }
               }
           }
        }
   }
   ```

1. Utilice el comando `create-job-template` con una ruta al archivo `create-job-template-request.json` almacenado localmente.

   ```
   aws emr-containers create-job-template \ 
   --cli-input-json file://./create-job-template-request.json
   ```

**Para iniciar un trabajo con una plantilla de trabajo**

Especifique el ID del clúster virtual, el ID de la plantilla de trabajo y el nombre del trabajo en el comando `StartJobRun`, tal como se muestra en el siguiente ejemplo.

```
aws emr-containers start-job-run \
--virtual-cluster-id 123456 \
--name myjob \
--job-template-id 1234abcd
```

# Definición de parámetros de plantilla de trabajo
<a name="use-job-template-parameters"></a>

Los parámetros de la plantilla de trabajo le permiten especificar variables en la plantilla de trabajo. Los valores de estas variables de parámetros deberán especificarse al iniciar la ejecución de un trabajo con esa plantilla de trabajo. Los parámetros de la plantilla de trabajo se especifican en formato `${parameterName}`. Puede optar por especificar cualquier valor en un campo `jobTemplateData` como parámetro de la plantilla de trabajo. Para cada una de las variables de los parámetros de la plantilla de trabajo, especifique su tipo de datos (`STRING` o `NUMBER`) y, si lo desea, un valor por defecto. En el siguiente ejemplo, se muestra cómo especificar los parámetros de la plantilla de trabajo para los valores de ubicación del punto de entrada, clase principal y ubicación de registro de S3.

**Para especificar la ubicación del punto de entrada, la clase principal y la ubicación del registro de Amazon S3 como parámetros de la plantilla de trabajo**

1. Cree un archivo `create-job-template-request.json` y especifique los parámetros necesarios para la plantilla de trabajo, como se muestra en el siguiente archivo JSON de ejemplo. Para obtener más información sobre los parámetros, consulte la [CreateJobTemplate](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/Welcome.html)API.

   ```
   {
      "name": "mytemplate",
      "jobTemplateData": {
           "executionRoleArn": "iam_role_arn_for_job_execution", 
           "releaseLabel": "emr-6.7.0-latest",
           "jobDriver": {
               "sparkSubmitJobDriver": { 
                   "entryPoint": "${EntryPointLocation}",
                   "entryPointArguments": [ "argument1","argument2",...],
                   "sparkSubmitParameters": "--class ${MainClass} --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"
               }
           },
           "configurationOverrides": {
               "applicationConfiguration": [
                   {
                       "classification": "spark-defaults", 
                       "properties": {
                            "spark.driver.memory":"2G"
                       }
                   }
               ], 
               "monitoringConfiguration": {
                   "persistentAppUI": "ENABLED", 
                   "cloudWatchMonitoringConfiguration": {
                       "logGroupName": "my_log_group", 
                       "logStreamNamePrefix": "log_stream_prefix"
                   }, 
                   "s3MonitoringConfiguration": {
                       "logUri": "${LogS3BucketUri}"
                   }
               }
           },
           "parameterConfiguration": {
               "EntryPointLocation": {
                   "type": "STRING"
               },
               "MainClass": {
                   "type": "STRING",
                   "defaultValue":"Main"
               },
               "LogS3BucketUri": {
                   "type": "STRING",
                   "defaultValue":"s3://my_s3_log_location/"
               }
           }
       }
   }
   ```

1. Utilice el comando `create-job-template` con una ruta al archivo `create-job-template-request.json` almacenado localmente o en Amazon S3.

   ```
   aws emr-containers create-job-template \ 
   --cli-input-json file://./create-job-template-request.json
   ```

**Para iniciar un trabajo mediante una plantilla de trabajo con los parámetros de la plantilla de trabajo**

Para iniciar la ejecución de un trabajo con una plantilla de trabajo que contenga los parámetros de la plantilla de trabajo, especifique el identificador de la plantilla de trabajo y los valores de los parámetros de la plantilla de trabajo en la solicitud de la API de `StartJobRun`, tal como se muestra a continuación.

```
aws emr-containers start-job-run \
--virtual-cluster-id 123456 \
--name myjob \
--job-template-id 1234abcd \
--job-template-parameters '{"EntryPointLocation": "entry_point_location","MainClass": "ExampleMainClass","LogS3BucketUri": "s3://example_s3_bucket/"}'
```

# Control del acceso a las plantillas de trabajos
<a name="iam-job-template"></a>

La política de `StartJobRun` le permite imponer que un usuario o un rol solo pueda ejecutar trabajos mediante las plantillas de trabajo que usted especifique y no puede ejecutar operaciones `StartJobRun` sin usar las plantillas de trabajo especificadas. Para ello, primero asegúrese de conceder al usuario o rol un permiso de lectura para las plantillas de trabajos especificadas, tal y como se muestra a continuación.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:DescribeJobRun"
      ],
      "Resource": [
        "arn:aws:emr-containers:*:*:jobtemplate/job_template_1_id",
        "arn:aws:emr-containers:*:*:jobtemplate/job_template_2_id"
      ],
      "Sid": "AllowEMRCONTAINERSDescribejobtemplate"
    }
  ]
}
```

------

Para garantizar que un usuario o rol solo pueda invocar una operación `StartJobRun` cuando utilice plantillas de trabajo específicas, puede asignar el siguiente permiso de política de `StartJobRun` a un usuario o rol determinado.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:StartJobRun"
      ],
      "Resource": [
        "arn:aws:emr-containers:*:*:/virtualclusters/virtual_cluster_id"
      ],
      "Condition": {
        "ArnLike": {
          "emr-containers:JobTemplateArn": [
            "arn:aws:emr-containers:*:*:jobtemplate/job_template_1_id",
            "arn:aws:emr-containers:*:*:jobtemplate/job_template_2_id"
          ]
        }
      },
      "Sid": "AllowEMRCONTAINERSStartjobrun"
    }
  ]
}
```

------

Si la plantilla de trabajo especifica un parámetro de plantilla de trabajo dentro del campo ARN del rol de ejecución, el usuario podrá proporcionar un valor para este parámetro y, por lo tanto, podrá invocar `StartJobRun` mediante un rol de ejecución arbitrario. Para restringir los roles de ejecución que el usuario puede proporcionar, consulte **Controlar el acceso al rol de ejecución** en [Uso de roles de ejecución de trabajos con Amazon EMR en EKS](iam-execution-role.md). 

Si no se especifica ninguna condición en la política de acción `StartJobRun` anterior para un usuario o rol determinado, el usuario o el rol podrán invocar una acción `StartJobRun` en el clúster virtual especificado con una plantilla de trabajo arbitraria a la que tengan acceso de lectura o mediante un rol de ejecución arbitrario.

# Uso de plantillas de pods
<a name="pod-templates"></a>

A partir de las versiones 5.33.0 o 6.3.0 de Amazon EMR, Amazon EMR en EKS es compatible con la característica de plantillas de pods de Spark. Un pod es un grupo de uno o más contenedores, con recursos de red y almacenamiento compartidos, y una especificación sobre cómo ejecutar los contenedores. Las plantillas de pods son especificaciones que determinan cómo ejecutar cada pod. Puede usar archivos de plantillas de pods para definir las configuraciones del pod de controlador o ejecutor que las configuraciones de Spark no admiten. Para obtener más información sobre la característica de plantillas de pods de Spark, consulte [Plantillas de pods](https://spark.apache.org/docs/latest/running-on-kubernetes.html#pod-template). 

**nota**  
La característica de plantillas de pods solo funciona con los pods controladores y ejecutores. No puede configurar los pods del remitente de trabajos mediante la plantilla de pods.

## Escenarios habituales
<a name="pod-template-use-cases"></a>

Puede definir cómo ejecutar los trabajos de Spark en clústeres de EKS compartidos mediante plantillas de pods con Amazon EMR en EKS y ahorrar costos y mejorar la utilización y el rendimiento de los recursos.
+ Para reducir los costes, puede programar las tareas del controlador de Spark para que se ejecuten en las instancias EC2 bajo demanda de Amazon y, al mismo tiempo, programar las tareas del ejecutor de Spark para que se ejecuten en las instancias EC2 puntuales de Amazon. 
+ Para aumentar la utilización de los recursos, puede ayudar a varios equipos a ejecutar sus cargas de trabajo en el mismo clúster de EKS. Cada equipo dispondrá de un grupo de EC2 nodos de Amazon designado en el que ejecutar sus cargas de trabajo. Puede utilizar plantillas de pods para aplicar la tolerancia correspondiente a su carga de trabajo. 
+ Para mejorar la supervisión, puede ejecutar un contenedor de registro independiente para reenviar los registros a la aplicación de supervisión existente. 

Por ejemplo, el siguiente archivo de plantilla de pod muestra un escenario de uso común. 

```
apiVersion: v1
kind: Pod
spec:
  volumes:
    - name: source-data-volume
      emptyDir: {}
    - name: metrics-files-volume
      emptyDir: {}
  nodeSelector:
    eks.amazonaws.com/nodegroup: emr-containers-nodegroup
  containers:
  - name: spark-kubernetes-driver # This will be interpreted as driver Spark main container
    env:
      - name: RANDOM
        value: "random"
    volumeMounts:
      - name: shared-volume
        mountPath: /var/data
      - name: metrics-files-volume
        mountPath: /var/metrics/data
  - name: custom-side-car-container # Sidecar container
    image: <side_car_container_image>
    env:
      - name: RANDOM_SIDECAR
        value: random
    volumeMounts:
      - name: metrics-files-volume
        mountPath: /var/metrics/data
    command:
      - /bin/sh
      - '-c'
      -  <command-to-upload-metrics-files>
  initContainers:
  - name: spark-init-container-driver # Init container
    image: <spark-pre-step-image>
    volumeMounts:
      - name: source-data-volume # Use EMR predefined volumes
        mountPath: /var/data
    command:
      - /bin/sh
      - '-c'
      -  <command-to-download-dependency-jars>
```

La plantilla de pod lleva a cabo las tareas siguientes:
+ Agrega un nuevo [contenedor de inicialización](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) que se ejecuta antes de que se inicie el contenedor principal de Spark. El contenedor de inicio comparte el [EmptyDirvolumen](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) llamado `source-data-volume` con el contenedor principal de Spark. Puede hacer que su contenedor de inicialización ejecute los pasos de inicialización, como descargar dependencias o generar datos de entrada. A continuación, el contenedor principal de Spark consume los datos.
+ Agregue otro [contenedor asociado](https://kubernetes.io/docs/concepts/workloads/pods/#how-pods-manage-multiple-containers) que se ejecute junto con el contenedor principal de Spark. Los dos contenedores comparten otro volumen `EmptyDir` llamado `metrics-files-volume`. Su trabajo en Spark puede generar métricas, como las métricas de Prometheus. A continuación, el trabajo de Spark puede colocar las métricas en un archivo y hacer que el contenedor asociado cargue los archivos en su propio sistema de BI para análisis futuros.
+ Agregue una nueva variable de entorno al contenedor principal de Spark. Puede hacer que el trabajo consuma la variable de entorno.
+ Defina un [selector de nodos](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) para que el pod solo esté programado en el grupo de nodos `emr-containers-nodegroup`. Esto ayuda a aislar los recursos de computación entre trabajos y equipos.

## Habilitación de plantillas de pods con Amazon EMR en EKS
<a name="use-pod-templates"></a>

Para habilitar la característica de plantilla de pod con Amazon EMR en EKS, configure las propiedades de Spark `spark.kubernetes.driver.podTemplateFile` y `spark.kubernetes.executor.podTemplateFile` para que apunten a los archivos de plantillas de pods en Amazon S3. A continuación, Spark descarga el archivo de plantilla del pod y lo utiliza para crear los pods controladores y ejecutores.

**nota**  
Spark usa el rol de ejecución de trabajos para cargar la plantilla de pod, por lo que el rol de ejecución de tareas debe tener permisos de acceso a Amazon S3 para cargar las plantillas de pods. Para obtener más información, consulte [Crear un rol de ejecución de trabajos](creating-job-execution-role.md).

Puede utilizar los `SparkSubmitParameters` para especificar la ruta de Amazon S3 a la plantilla del pod, tal como se muestra en el siguiente archivo JSON de ejecución de tareas.

```
{
  "name": "myjob", 
  "virtualClusterId": "123456",  
  "executionRoleArn": "iam_role_name_for_job_execution", 
  "releaseLabel": "release_label", 
  "jobDriver": {
    "sparkSubmitJobDriver": {
      "entryPoint": "entryPoint_location",
      "entryPointArguments": ["argument1", "argument2", ...], 
       "sparkSubmitParameters": "--class <main_class> \
         --conf spark.kubernetes.driver.podTemplateFile=s3://path_to_driver_pod_template \
         --conf spark.kubernetes.executor.podTemplateFile=s3://path_to_executor_pod_template \
         --conf spark.executor.instances=2 \
         --conf spark.executor.memory=2G \
         --conf spark.executor.cores=2 \
         --conf spark.driver.cores=1"
    }
  }
}
```

Como alternativa, puede usar las `configurationOverrides` para especificar la ruta de Amazon S3 a la plantilla del pod, tal como se muestra en el siguiente archivo JSON de ejecución de tareas.

```
{
  "name": "myjob", 
  "virtualClusterId": "123456",  
  "executionRoleArn": "iam_role_name_for_job_execution", 
  "releaseLabel": "release_label", 
  "jobDriver": {
    "sparkSubmitJobDriver": {
      "entryPoint": "entryPoint_location",
      "entryPointArguments": ["argument1", "argument2", ...],  
       "sparkSubmitParameters": "--class <main_class> \
         --conf spark.executor.instances=2 \
         --conf spark.executor.memory=2G \
         --conf spark.executor.cores=2 \
         --conf spark.driver.cores=1"
    }
  }, 
  "configurationOverrides": {
    "applicationConfiguration": [
      {
        "classification": "spark-defaults", 
        "properties": {
          "spark.driver.memory":"2G",
          "spark.kubernetes.driver.podTemplateFile":"s3://path_to_driver_pod_template",
          "spark.kubernetes.executor.podTemplateFile":"s3://path_to_executor_pod_template"
         }
      }
    ]
  }
}
```

**nota**  
Debe seguir las pautas de seguridad cuando utilice la característica de plantilla de pod con Amazon EMR en EKS, como aislar el código de una aplicación que no sea de confianza. Para obtener más información, consulte [Prácticas recomendadas de seguridad de Amazon EMR en EKS](security-best-practices.md).
No puede cambiar los nombres de los contenedores principales de Spark mediante `spark.kubernetes.driver.podTemplateContainerName` y `spark.kubernetes.executor.podTemplateContainerName`, ya que estos nombres están codificados como `spark-kubernetes-driver` y `spark-kubernetes-executors`. Si quiere personalizar el contenedor principal de Spark, debe especificarlo en una plantilla de pod con estos nombres codificados.

## Campos de plantilla de pod
<a name="pod-templates-fields"></a>

Tenga en cuenta las siguientes restricciones de campo al configurar una plantilla de pod con Amazon EMR en EKS.
+ Amazon EMR en EKS solo permite los siguientes campos en una plantilla de pod para habilitar una programación adecuada de los trabajos.

  Estos son los campos de nivel de pod permitidos:
  + `apiVersion`
  + `kind`
  + `metadata`
  + `spec.activeDeadlineSeconds`
  + `spec.affinity`
  + `spec.containers`
  + `spec.enableServiceLinks`
  + `spec.ephemeralContainers`
  + `spec.hostAliases`
  + `spec.hostname`
  + `spec.imagePullSecrets`
  + `spec.initContainers`
  + `spec.nodeName`
  + `spec.nodeSelector`
  + `spec.overhead`
  + `spec.preemptionPolicy`
  + `spec.priority`
  + `spec.priorityClassName`
  + `spec.readinessGates`
  + `spec.runtimeClassName`
  + `spec.schedulerName`
  + `spec.subdomain`
  + `spec.terminationGracePeriodSeconds`
  + `spec.tolerations`
  + `spec.topologySpreadConstraints`
  + `spec.volumes`

  Estos son los campos de nivel de contenedor principal de Spark permitidos:
  + `env`
  + `envFrom`
  + `name`
  + `lifecycle`
  + `livenessProbe`
  + `readinessProbe`
  + `resources`
  + `startupProbe`
  + `stdin`
  + `stdinOnce`
  + `terminationMessagePath`
  + `terminationMessagePolicy`
  + `tty`
  + `volumeDevices`
  + `volumeMounts`
  + `workingDir`

  Cuando utiliza campos no permitidos en la plantilla de pod, Spark lanza una excepción y se produce un error en el trabajo. En el siguiente ejemplo, se muestra un mensaje de error en el registro del controlador de Spark porque hay campos no permitidos. 

  ```
  Executor pod template validation failed.
  Field container.command in Spark main container not allowed but specified.
  ```
+  Amazon EMR en EKS predefine los siguientes parámetros en una plantilla de pod. Los campos que especifique en una plantilla de pod no deben superponerse con estos campos. 

  Estos son los nombres de volumen predefinidos:
  + `emr-container-communicate`
  + `config-volume`
  + `emr-container-application-log-dir`
  + `emr-container-event-log-dir`
  + `temp-data-dir`
  + `mnt-dir`
  + `home-dir`
  + `emr-container-s3`

  Estos son los montajes de volumen predefinidos que solo se aplican al contenedor principal de Spark:
  + Nombre:`emr-container-communicate`; MountPath `/var/log/fluentd`
  + Nombre:`emr-container-application-log-dir`; MountPath: `/var/log/spark/user`
  + Nombre:`emr-container-event-log-dir`; MountPath: `/var/log/spark/apps`
  + Nombre:`mnt-dir`; MountPath: `/mnt`
  + Nombre:`temp-data-dir`; MountPath: `/tmp`
  + Nombre:`home-dir`; MountPath: `/home/hadoop`

  Estas son las variables de entorno predefinidas que solo se aplican al contenedor principal de Spark:
  + `SPARK_CONTAINER_ID`
  + `K8S_SPARK_LOG_URL_STDERR`
  + `K8S_SPARK_LOG_URL_STDOUT`
  + `SIDECAR_SIGNAL_FILE`
**nota**  
Puede seguir usando estos volúmenes predefinidos y montarlos en sus contenedores asociados adicionales. Por ejemplo, puede usar `emr-container-application-log-dir` y montarlo en su propio contenedor asociado definido en la plantilla de pod.

  Si los campos que especifique entran en conflicto con alguno de los campos predefinidos de la plantilla del pod, Spark lanza una excepción y se produce un error en el trabajo. En el siguiente ejemplo, se muestra un mensaje de error en el registro de la aplicación de Spark debido a conflictos con los campos predefinidos. 

  ```
  Defined volume mount path on main container must not overlap with reserved mount paths: [<reserved-paths>]
  ```

## Consideraciones sobre los contenedores asociados
<a name="pod-template-sidecar"></a>

Amazon EMR controla el ciclo de vida de los pods aprovisionados por Amazon EMR en EKS. Los contenedores asociados deben seguir el mismo ciclo de vida que el contenedor principal de Spark. Si inyecta contenedores asociados adicionales en sus pods, le recomendamos que los integre con la administración del ciclo de vida de los pods que Amazon EMR define para que el contenedor asociado pueda detenerse solo cuando salga el contenedor principal de Spark.

Para reducir costos, le recomendamos que implemente un proceso que impida que los pods controladores con contenedores asociados sigan funcionando una vez que haya completado el trabajo. El controlador de Spark elimina los pods ejecutores cuando el ejecutor ha terminado. Sin embargo, cuando se completa un programa de controlador, los contenedores asociados adicionales siguen funcionando. El pod se factura hasta que Amazon EMR en EKS limpie el pod controlador, normalmente en menos de un minuto después de que se complete el contenedor principal de Spark del controlador. Para reducir costos, puede integrar sus contenedores asociados adicionales con el mecanismo de administración del ciclo de vida que Amazon EMR en EKS define para los pods controladores y ejecutores, tal y como se describe en la siguiente sección.

El contenedor principal de Spark de los pods ejecutores y controladores envía `heartbeat` a un archivo `/var/log/fluentd/main-container-terminated` cada dos segundos. Al agregar el montaje de volumen `emr-container-communicate` predefinido de Amazon EMR a su contenedor asociado, puede definir un subproceso de dicho contenedor para hacer un seguimiento periódico de la hora de la última modificación de este archivo. A continuación, el subproceso se detiene automáticamente si descubre que el contenedor principal de Spark detiene el `heartbeat` durante más tiempo. 

El siguiente ejemplo muestra un subproceso que rastrea el archivo de latidos y se detiene solo. *your\$1volume\$1mount*Sustitúyala por la ruta en la que se monta el volumen predefinido. El script está incluido dentro de la imagen utilizada por el contenedor asociado. En un archivo de plantilla de pod, puede especificar un contenedor asociado con los comandos `sub_process_script.sh` y `main_command`.

```
MOUNT_PATH="your_volume_mount"
FILE_TO_WATCH="$MOUNT_PATH/main-container-terminated"
INITIAL_HEARTBEAT_TIMEOUT_THRESHOLD=60
HEARTBEAT_TIMEOUT_THRESHOLD=15
SLEEP_DURATION=10

function terminate_main_process() {
  # Stop main process
}

# Waiting for the first heartbeat sent by Spark main container
echo "Waiting for file $FILE_TO_WATCH to appear..."
start_wait=$(date +%s)
while ! [[ -f "$FILE_TO_WATCH" ]]; do
    elapsed_wait=$(expr $(date +%s) - $start_wait)
    if [ "$elapsed_wait" -gt "$INITIAL_HEARTBEAT_TIMEOUT_THRESHOLD" ]; then
        echo "File $FILE_TO_WATCH not found after $INITIAL_HEARTBEAT_TIMEOUT_THRESHOLD seconds; aborting"
        terminate_main_process
        exit 1
    fi
    sleep $SLEEP_DURATION;
done;
echo "Found file $FILE_TO_WATCH; watching for heartbeats..."

while [[ -f "$FILE_TO_WATCH" ]]; do
    LAST_HEARTBEAT=$(stat -c %Y $FILE_TO_WATCH)
    ELAPSED_TIME_SINCE_AFTER_HEARTBEAT=$(expr $(date +%s) - $LAST_HEARTBEAT)
    if [ "$ELAPSED_TIME_SINCE_AFTER_HEARTBEAT" -gt "$HEARTBEAT_TIMEOUT_THRESHOLD" ]; then
        echo "Last heartbeat to file $FILE_TO_WATCH was more than $HEARTBEAT_TIMEOUT_THRESHOLD seconds ago at $LAST_HEARTBEAT; terminating"
        terminate_main_process
        exit 0
    fi
    sleep $SLEEP_DURATION;
done;
echo "Outside of loop, main-container-terminated file no longer exists"
    
# The file will be deleted once the fluentd container is terminated

echo "The file $FILE_TO_WATCH doesn't exist any more;"
terminate_main_process
exit 0
```

# Uso de políticas de reintento de trabajos
<a name="jobruns-using-retry-policies"></a>

En Amazon EMR en EKS 6.9.0 y versiones posteriores, puede establecer una política de reintento para las ejecuciones de sus trabajos. Las políticas de reintento hacen que un pod controlador de tareas se reinicie automáticamente si se elimina o se produce un error. Esto hace que los trabajos de streaming Spark de larga duración sean más resilientes a errores.

## Establecer una política de reintento para un trabajo
<a name="setting-retry-policy"></a>

Para configurar una política de reintentos, proporciona un `RetryPolicyConfiguration` campo mediante la [StartJobRun](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_StartJobRun.html)API. A continuación, se muestra un ejemplo de `retryPolicyConfiguration`:

```
aws emr-containers start-job-run \
--virtual-cluster-id cluster_id \
--name sample-job-name \
--execution-role-arn execution-role-arn \
--release-label emr-6.9.0-latest \
--job-driver '{
  "sparkSubmitJobDriver": {
    "entryPoint": "local:///usr/lib/spark/examples/src/main/python/pi.py",
    "entryPointArguments": [ "2" ],
    "sparkSubmitParameters": "--conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"
  }
}' \
--retry-policy-configuration '{
    "maxAttempts": 5
  }' \
--configuration-overrides '{
  "monitoringConfiguration": {
    "cloudWatchMonitoringConfiguration": {
      "logGroupName": "my_log_group_name",
      "logStreamNamePrefix": "my_log_stream_prefix"
    },
    "s3MonitoringConfiguration": {
       "logUri": "s3://amzn-s3-demo-logging-bucket"
    }
  }
}'
```

**nota**  
`retryPolicyConfiguration`solo está disponible a partir de la AWS CLI versión 1.27.68. Para actualizarla AWS CLI a la última versión, consulte [Instalación o actualización de la última versión](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) de AWS CLI

Configure el campo `maxAttempts` con el número máximo de veces que desee que se reinicie el pod controlador de trabajos en caso de que se elimine o se produzca un error. El intervalo de ejecución entre dos intentos de reintento del controlador de tareas es un intervalo de reintento exponencial de (10 segundos, 20 segundos, 40 segundos...) limitado a 6 minutos, tal como se describe en la [documentación de Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-backoff-failure-policy).

**nota**  
Cada ejecución adicional del controlador de trabajos se facturará como otra ejecución de tareas y estará sujeta a los [precios de Amazon EMR en EKS](https://aws.amazon.com/emr/pricing/#Amazon_EMR_on_Amazon_EKS).

### Vuelva a intentar los valores de configuración de la política
<a name="retry-config"></a>
+ **Política de reintento predeterminada para un trabajo:** `StartJobRun` incluye una política de reintento establecida en un intento máximo de forma predeterminada. Puede configurar la política de reintento como desee.
**nota**  
Si `maxAttempts` de `retryPolicyConfiguration` se establece en 1, significa que no se llevará a cabo ningún reintento para que aparezca el pod controlador en caso de error.
+ **Inhabilitar la política de reintentos para un trabajo:** para deshabilitar una política de reintentos, establezca el valor máximo de intentos en retryPolicyConfiguration 1.

  ```
  "retryPolicyConfiguration": {
      "maxAttempts": 1
  }
  ```
+ **Defina maxAttempts para un trabajo dentro del rango válido:** la llamada de `StartJobRun` fallará si el valor `maxAttempts` está fuera del rango válido. El rango válido de `maxAttempts` es de 1 a 2 147 483 647 (entero de 32 bits), el rango admitido por los ajustes de configuración de Kubernetes `backOffLimit`. Para obtener más información, consulte [Política de retroceso de errores de pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-backoff-failure-policy) en la documentación de Kubernetes. Si el valor `maxAttempts` no es válido, se devuelve el siguiente mensaje de error:

  ```
  {
   "message": "Retry policy configuration's parameter value of maxAttempts is invalid"
  }
  ```

## Recuperación del estado de una política de reintento de un trabajo
<a name="retrieve-policy"></a>

Puede ver el estado de los reintentos de un trabajo con la tecla y. [https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_ListJobRuns.html](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_ListJobRuns.html) APIs Una vez que solicite un trabajo con una configuración de política de reintento habilitada, las respuestas `ListJobRun` y `DescribeJobRun` contendrán el estado de la política de reintentos en el campo `RetryPolicyExecution`. Además, la respuesta `DescribeJobRun` contendrá la `RetryPolicyConfiguration` que se ingresó en la solicitud de `StartJobRun` del trabajo.

**Respuestas de ejemplo**

------
#### [ ListJobRuns response ]

```
{
  "jobRuns": [
    ...
    ...
    "retryPolicyExecution" : {
      "currentAttemptCount": 2
    }
    ...
    ...
  ]
}
```

------
#### [ DescribeJobRun response ]

```
{
  ...
  ...
  "retryPolicyConfiguration": {
    "maxAttempts": 5
   },
   "retryPolicyExecution" : {
    "currentAttemptCount": 2
  },
  ...
  ...
}
```

------

Estos campos no estarán visibles cuando la política de reintento esté deshabilitada en el trabajo, tal como se describe en [Vuelva a intentar los valores de configuración de la política](#retry-config). 

## Supervisión de un trabajo con una política de reintento
<a name="monitoring-retry"></a>

Al activar una política de reintentos, se genera un CloudWatch evento para cada controlador de trabajo que se cree. Para suscribirse a estos eventos, configure una regla de CloudWatch eventos mediante el siguiente comando:

```
aws events put-rule \
--name cwe-test \
--event-pattern '{"detail-type": ["EMR Job Run New Driver Attempt"]}'
```

El evento devolverá información sobre el `newDriverPodName`, la marca de tiempo de `newDriverCreatedAt`, `previousDriverFailureMessage` y los `currentAttemptCount` de los controladores del trabajo. Estos eventos no se crearán si la política de reintento está deshabilitada.

Para obtener más información sobre cómo supervisar su trabajo con CloudWatch eventos, consulte[Supervisa los trabajos con Amazon CloudWatch Events](monitoring.md#monitoring-cloudwatch-events).

## Búsqueda de registros para controladores y ejecutores
<a name="finding-logs"></a>

Los nombres de los pods controladores siguen el formato `spark-<job id>-driver-<random-suffix>`. El mismo `random-suffix` se agrega a los nombres de los pods ejecutores que genera el controlador. Al usar este `random-suffix`, puede buscar los registros de un controlador y sus ejecutores asociados. El `random-suffix` solo está presente si la [política de reintento está habilitada](#retry-config) para el trabajo; de lo contrario, el `random-suffix` está ausente.

Para obtener más información sobre cómo configurar los trabajos con la configuración de supervisión del registro, consulte [Ejecutar una aplicación de Spark](getting-started.md#getting-started-run-spark-app).

# Uso de la rotación del registro de eventos de Spark
<a name="emr-eks-log-rotation"></a>

Con Amazon EMR 6.3.0 y versiones posteriores, puede activar la característica de rotación del registro de eventos de Spark de Amazon EMR en EKS. En lugar de generar un único archivo de registro de eventos, esta característica rota el archivo en función del intervalo de tiempo configurado y elimina los archivos de registro de eventos más antiguos.

La rotación de registros de eventos de Spark puede ayudarle a evitar posibles problemas con un archivo de registro de eventos de Spark de gran tamaño que se genera para trabajos de larga duración o en streaming. Por ejemplo, empieza un trabajo de Spark de larga duración con un registro de eventos activado con el parámetro `persistentAppUI`. El controlador de Spark genera un archivo de registro de eventos. Si el trabajo se ejecuta durante horas o días y el espacio en disco en el nodo de Kubernetes es limitado, el archivo de registro de evento puede consumir todo el espacio disponible en el disco. Activar la característica de rotación del registro de eventos de Spark resuelve el problema al dividir el archivo de registro en varios archivos y eliminar los archivos más antiguos.

**nota**  
Esta característica solo funciona con Amazon EMR en EKS. Amazon EMR que se ejecuta en Amazon EC2 no admite la rotación del registro de eventos de Spark.

Para activar la característica de rotación del registro de eventos de Spark, configure los siguientes parámetros de Spark:
+ `spark.eventLog.rotation.enabled`: activa la rotación del registro. Está deshabilitado de forma predeterminada en el archivo de configuración de Spark. Configúrelo en verdadero para activar la característica. 
+ `spark.eventLog.rotation.interval`: especifica el intervalo de tiempo para la rotación del registro. El valor mínimo es de 60 segundos. El valor de predeterminado es de 300 segundos. 
+ `spark.eventLog.rotation.minFileSize`: especifica un tamaño de archivo mínimo para rotar el archivo de registro. El valor mínimo y predeterminado es de 1 MB. 
+ `spark.eventLog.rotation.maxFilesToRetain`: especifica cuántos archivos de registro rotados se deben conservar durante la limpieza. El rango válido es de 1 a 10. El valor predeterminado es 2. 

Puede especificar estos parámetros en la sección `sparkSubmitParameters` de la API [`StartJobRun`](emr-eks-jobs-submit.md), tal como se muestra en el siguiente ejemplo.

```
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi --conf spark.eventLog.rotation.enabled=true --conf spark.eventLog.rotation.interval=300 --conf spark.eventLog.rotation.minFileSize=1m --conf spark.eventLog.rotation.maxFilesToRetain=2"
```

# Uso de la rotación de los registros de contenedores de Spark
<a name="emr-eks-log-rotation-container"></a>

Con Amazon EMR 6.11.0 y versiones posteriores, puede activar la característica de rotación de los registros de contenedores de Spark para Amazon EMR en EKS. En lugar de generar un único archivo `stdout` o un archivo de registro `stderr`, esta característica rota el archivo en función del tamaño de rotación configurado y elimina los archivos de registro más antiguos del contenedor.

Rotar los registros de un contenedor de Spark puede ayudarle a evitar posibles problemas con los archivos de registro de Spark de gran tamaño que se generan para trabajos de larga duración o en streaming. Por ejemplo, puede iniciar un trabajo de Spark de larga duración, y el controlador de Spark genera un archivo de registro de contenedor. Si el trabajo se ejecuta durante horas o días y el espacio en disco en el nodo de Kubernetes es limitado, el archivo de registro de contenedor puede consumir todo el espacio disponible en el disco. Al activar la rotación de los registros de contenedor de Spark, se divide el archivo de registro en varios archivos y se eliminan los archivos más antiguos.

Para activar la característica de rotación de los registros de contenedores de Spark, configure los siguientes parámetros de Spark:

**`containerLogRotationConfiguration`**  
Incluya este parámetro en `monitoringConfiguration` para activar la rotación del registro. Está deshabilitado de forma predeterminada. Debe usar `containerLogRotationConfiguration` además de `s3MonitoringConfiguration`.

**`rotationSize`**  
El parámetro `rotationSize` especifica el tamaño del archivo para la rotación del registro. El rango de valores posibles va de `2KB` a `2GB`. La parte de unidades numéricas del parámetro `rotationSize` se pasa como un número entero. Como no se admiten valores decimales, puede especificar un tamaño de rotación de 1,5 GB, por ejemplo, con el valor `1500MB`.

**`maxFilesToKeep`**  
El parámetro `maxFilesToKeep` especifica el número máximo de archivos que deben retenerse en el contenedor después de que se haya completado la rotación. El valor mínimo es 1 y el máximo, 50.

Puede especificar estos parámetros en la sección `monitoringConfiguration` de la API `StartJobRun`, tal como se muestra en el siguiente ejemplo. En este ejemplo, con `rotationSize = "10 MB"` y `maxFilesToKeep = 3`, Amazon EMR en EKS rota los registros a 10 MB, genera un nuevo archivo de registro y, a continuación, purga el archivo de registro más antiguo cuando el número de archivos de registro llega a 3.

```
{
  "name": "my-long-running-job", 
  "virtualClusterId": "123456",  
  "executionRoleArn": "iam_role_name_for_job_execution", 
  "releaseLabel": "emr-6.11.0-latest", 
  "jobDriver": {
    "sparkSubmitJobDriver": {
      "entryPoint": "entryPoint_location",
      "entryPointArguments": ["argument1", "argument2", ...],  
       "sparkSubmitParameters": "--class main_class --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"
    }
  }, 
  "configurationOverrides": {
    "applicationConfiguration": [
      {
        "classification": "spark-defaults", 
        "properties": {
          "spark.driver.memory":"2G"
         }
      }
    ], 
    "monitoringConfiguration": {
      "persistentAppUI": "ENABLED", 
      "cloudWatchMonitoringConfiguration": {
        "logGroupName": "my_log_group", 
        "logStreamNamePrefix": "log_stream_prefix"
      }, 
      "s3MonitoringConfiguration": {
        "logUri": "s3://my_s3_log_location"
      },
      "containerLogRotationConfiguration": {
        "rotationSize":"10MB",
        "maxFilesToKeep":"3"
      }
    }
  }
}
```

Para iniciar la ejecución de un trabajo con la rotación del registro de contenedor de Spark, incluya en el comando una ruta al archivo JSON que configuró en el comando [`StartJobRun`](emr-eks-jobs-submit.md).

```
aws emr-containers start-job-run \
--cli-input-json file://path-to-json-request-file
```

# Uso del escalado automático vertical con trabajos de Spark de Amazon EMR
<a name="jobruns-vas"></a>

El escalado automático vertical de Amazon EMR en EKS ajusta automáticamente los recursos de memoria y CPU para adaptarlos a las necesidades de la carga de trabajo que proporciona a las aplicaciones de Spark de Amazon EMR. Esto simplifica la administración de recursos.

Para hacer un seguimiento del historial de uso y del uso en tiempo real de los recursos de sus aplicaciones de Spark de Amazon EMR, el escalado automático vertical aprovecha el [escalador automático vertical de pods (VPA)](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) de Kubernetes. La capacidad de escalado automático vertical utiliza los datos que recopila el VPA para ajustar automáticamente los recursos de memoria y CPU asignados a las aplicaciones de Spark. Este proceso simplificado mejora la fiabilidad y optimiza los costos.

**Topics**
+ [Configuración](jobruns-vas-setup.md)
+ [Introducción](jobruns-vas-gs.md)
+ [Configuración](jobruns-vas-configure.md)
+ [Supervisión de las recomendaciones](jobruns-vas-monitor.md)
+ [Desinstalación](jobruns-vas-uninstall-operator.md)

# Configuración del escalado automático vertical de Amazon EMR en EKS
<a name="jobruns-vas-setup"></a>

Este tema le ayuda a preparar su clúster de Amazon EKS para enviar trabajos de Spark de Amazon EMR con escalado automático vertical. El proceso de configuración requiere que confirme o complete las tareas de las siguientes secciones:

**Topics**
+ [Requisitos previos](#jobruns-vas-prereqs)
+ [Instalar Operator Lifecycle Manager (OLM) en su clúster de Amazon EKS](#jobruns-vas-install-olm)
+ [Instalar el operador de escalado automático vertical de Amazon EMR en EKS](#jobruns-vas-install-operator)

## Requisitos previos
<a name="jobruns-vas-prereqs"></a>

Complete las siguientes tareas antes de instalar el operador de Kubernetes con escalado automático vertical en el clúster. Si ya ha completado alguno de los requisitos previos, puede omitirlos y pasar al siguiente.
+ **[Instalar o actualizar a la última versión de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)**: si ya ha instalado el AWS CLI, confirme que tiene la última versión.
+ **[Instale kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)**: es una herramienta de línea de comandos que se utiliza para comunicarse con el servidor de la API de Kubernetes. Necesita kubectl para instalar y supervisar los artefactos relacionados con el escalado automático vertical en su clúster de Amazon EKS.
+ **[Instale Operator SDK](https://sdk.operatorframework.io/docs/installation/)**: Amazon EMR en EKS utiliza Operator SDK como administrador de paquetes durante toda la vida útil del operador de escalado automático vertical que instale en el clúster.
+ **[Instale Docker](https://docs.docker.com/get-docker/)**: necesita acceso a la CLI de Docker para autenticar y obtener las imágenes de Docker verticales relacionadas con el escalado automático para instalarlas en su clúster de Amazon EKS.
+ **[Instale el servidor de métricas de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/metrics-server.html)**: primero debe instalar el servidor de métricas para que el escalador automático del pod vertical pueda obtener las métricas del servidor de la API de Kubernetes.
+ **[Comience con Amazon EKS: eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) (versión 1.24 o posterior)**: el escalado automático vertical es compatible con las versiones 1.24 y posteriores de Amazon EKS. Una vez creado el clúster, [regístrelo para usarlo en Amazon EMR](setting-up-registration.md).
+ **[Seleccione un URI de imagen base de Amazon EMR](docker-custom-images-tag.md) (versión 6.10.0 o posterior)**: el escalado automático vertical es compatible con las versiones 6.10.0 y posteriores de Amazon EMR.

## Instalar Operator Lifecycle Manager (OLM) en su clúster de Amazon EKS
<a name="jobruns-vas-install-olm"></a>

Utilice la CLI de Operator SDK para instalar Operator Lifecycle Manager (OLM) en el clúster de Amazon EMR en EKS en el que desee configurar el escalado automático vertical, tal como se muestra en el siguiente ejemplo. Una vez que lo haya configurado, puede usar OLM para instalar y administrar el ciclo de vida del [operador de escalado automático vertical de Amazon EMR.](#jobruns-vas-install-operator)

```
operator-sdk olm install
```

Para validar la instalación, ejecute el comando `olm status`:

```
operator-sdk olm status
```

Verifique que el comando devuelva un resultado correcto, similar al siguiente ejemplo:

```
INFO[0007] Successfully got OLM status for version X.XX
```

Si la instalación no se lleva a cabo correctamente, consulte [Solución de problemas en el escalado automático vertical de Amazon EMR en EKS](troubleshooting-vas.md).

## Instalar el operador de escalado automático vertical de Amazon EMR en EKS
<a name="jobruns-vas-install-operator"></a>

Siga estos pasos para instalar el operador de escalado automático vertical en su clúster de Amazon EKS:

1. Configure las siguientes variables de entorno que utilizará para completar la instalación:
   + **`$REGION`** apunta a la Región de AWS de su clúster. Por ejemplo, `us-west-2`.
   + **`$ACCOUNT_ID`** apunta al ID de cuenta de Amazon ECR de su región. Para obtener más información, consulte [Cuentas de registro de Amazon ECR por región](docker-custom-images-tag.md#docker-custom-images-ECR).
   + **`$RELEASE`** apunta a la versión de Amazon EMR que desea usar para su clúster. Con el escalado automático vertical, debe utilizar la versión 6.10.0 o una posterior de Amazon EMR.

1. A continuación, ingrese los tokens de autenticación del operador en el [registro de Amazon ECR](docker-custom-images-tag.md#docker-custom-images-ECR).

   ```
   aws ecr get-login-password \
    --region region-id | docker login \
    --username AWS \
    --password-stdin $ACCOUNT_ID.dkr.ecr.region-id.amazonaws.com
   ```

1. Instale Amazon EMR en EKS en el operador de escalado automático vertical con el siguiente comando:

   ```
   ECR_URL=$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com && \
   REPO_DEST=dynamic-sizing-k8s-operator-olm-bundle && \
   BUNDLE_IMG=emr-$RELEASE-dynamic-sizing-k8s-operator && \
   operator-sdk run bundle \
   $ECR_URL/$REPO_DEST/$BUNDLE_IMG\:latest
   ```

   Esto creará una versión del operador de escalado automático vertical en el espacio de nombres predeterminado del clúster de Amazon EKS. Utilice este comando para llevar a cabo la instalación en un espacio de nombres diferente:

   ```
   operator-sdk run bundle \
   $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/dynamic-sizing-k8s-operator-olm-bundle/emr-$RELEASE-dynamic-sizing-k8s-operator:latest \
   -n operator-namespace
   ```
**nota**  
Si el espacio de nombres que especifique no existe, OLM no instalará el operador. Para obtener más información, consulte [No se encontró el espacio de nombres de Kubernetes](troubleshooting-vas.md).

1. Compruebe que haya instalado correctamente el operador con la herramienta de línea de comandos kubectl de Kubernetes.

   ```
   kubectl get csv -n operator-namespace
   ```

   El comando `kubectl` debe devolver su operador de escalado vertical recién implementado con un estado de **Fase** **Correcto**. Si tiene problemas con la instalación o la configuración, consulte [Solución de problemas en el escalado automático vertical de Amazon EMR en EKS](troubleshooting-vas.md).

# Cómo empezar a utilizar el escalado automático vertical de Amazon EMR en EKS
<a name="jobruns-vas-gs"></a>

Utilice el escalado automático vertical en Amazon EMR en EKS cuando desee un ajuste automático de los recursos de memoria y CPU para adaptarlos a la carga de trabajo de la aplicación de Spark de Amazon EMR. Para obtener más información, consulte [Uso del escalado automático vertical con trabajos de Spark de Amazon EMR](jobruns-vas.html).

## Envío de un trabajo de Spark con escalado automático vertical
<a name="jobruns-vas-spark-submit"></a>

Cuando envíes un trabajo a través de la [StartJobRun](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_StartJobRun.html)API, añade las dos configuraciones siguientes al controlador para que tu trabajo de Spark active el escalado automático vertical:

```
"spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing":"true",
"spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.signature":"YOUR_JOB_SIGNATURE"
```

En el código anterior, la primera línea habilita la capacidad de escalado automático vertical. La siguiente línea es una configuración de firma obligatoria que le permite elegir una firma para su trabajo.

Para obtener más información sobre estas configuraciones y los valores de parámetros aceptables, consulte [Configuración del escalado automático vertical de Amazon EMR en EKS](jobruns-vas-configure.md). De forma predeterminada, su trabajo se envía en el modo **Desactivado** de escalado automático vertical solo de supervisión. Este estado de supervisión le permite calcular y ver las recomendaciones de recursos sin llevar a cabo el escalado automático. Para obtener más información, consulte [Modos de escalado automático vertical](jobruns-vas-configure.md#jobruns-vas-parameters-opt-mode).

En el siguiente ejemplo, se muestra cómo completar un ejemplo de comando `start-job-run` con escalado automático vertical:

```
aws emr-containers start-job-run \
--virtual-cluster-id $VIRTUAL_CLUSTER_ID \
--name $JOB_NAME \
--execution-role-arn $EMR_ROLE_ARN \
--release-label emr-6.10.0-latest \
--job-driver '{
  "sparkSubmitJobDriver": {
     "entryPoint": "local:///usr/lib/spark/examples/src/main/python/pi.py"
   }
 }' \
--configuration-overrides '{
    "applicationConfiguration": [{
        "classification": "spark-defaults",
        "properties": {
          "spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing": "true",
          "spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.signature": "test-signature"
        }
    }]
  }'
```

## Verificación de la funcionalidad de escalado automático vertical
<a name="jobruns-vas-verify"></a>

Para comprobar que el escalado automático vertical funcione correctamente en el trabajo enviado, use kubectl para obtener el recurso personalizado `verticalpodautoscaler` y ver sus recomendaciones de escalado. Por ejemplo, el siguiente comando solicita recomendaciones sobre el trabajo de ejemplo de la sección [Envío de un trabajo de Spark con escalado automático vertical](#jobruns-vas-spark-submit):

```
kubectl get verticalpodautoscalers --all-namespaces \
-l=emr-containers.amazonaws.com/dynamic.sizing.signature=test-signature
```

El resultado de esta consulta debe parecerse al siguiente:

```
NAME                                                          MODE   CPU         MEM PROVIDED   AGE
ds-jceyefkxnhrvdzw6djum3naf2abm6o63a6dvjkkedqtkhlrf25eq-vpa   Off    3304504865  True           87m
```

Si el resultado no es similar o contiene un código de error, consulte [Solución de problemas en el escalado automático vertical de Amazon EMR en EKS](troubleshooting-vas.md) para ver los pasos que le ayudarán a resolver el problema.

# Configuración del escalado automático vertical de Amazon EMR en EKS
<a name="jobruns-vas-configure"></a>

Puede configurar el escalado automático vertical al enviar trabajos de Amazon EMR Spark a través [StartJobRun](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_StartJobRun.html)de la API. Establezca los parámetros de configuración relacionados con el escalado automático en el pod controlador de Spark, tal como se muestra en el ejemplo de [Envío de un trabajo de Spark con escalado automático vertical](jobruns-vas-gs.md#jobruns-vas-spark-submit).

El operador de escalado automático vertical de Amazon EMR en EKS escucha los pods controladores que tienen escalado automático y, a continuación, configura la integración con el escalador automático vertical de pods (VPA) de Kubernetes con la configuración del pod controlador. Esto facilita el seguimiento de los recursos y el escalado automático de los pods ejecutores de Spark.

En las siguientes secciones, se describen los parámetros que puede usar al configurar el escalado automático vertical para su clúster de Amazon EKS.

**nota**  
Configure el parámetro de alternancia de características como una etiqueta y configure los parámetros restantes como anotaciones en el pod controlador de Spark. Los parámetros de escalado automático pertenecen al dominio `emr-containers.amazonaws.com/` y tienen el prefijo `dynamic.sizing`.

## Parámetros necesarios
<a name="jobruns-vas-parameters-req"></a>

Cuando envíe su trabajo, debe incluir los dos parámetros siguientes en el controlador de tareas de Spark:


| Key | Description (Descripción) | Valores aceptados | Predeterminado | Tipo | Parámetro de Spark1 | 
| --- | --- | --- | --- | --- | --- | 
|  `dynamic.sizing`  |  Conmutador de características  |  `true`, `false`  |  no configurado  |  etiqueta  |  `spark.kubernetes.driver.label.emr-containers.amazonaws.com/dynamic.sizing`  | 
|  `dynamic.sizing.signature`  |  Firma de trabajo  |  *string*  |  no configurado  |  anotación  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.signature`  | 

1 Utilice este parámetro como `SparkSubmitParameter` o `ConfigurationOverride` en la API de `StartJobRun`.
+ **`dynamic.sizing`**: puede activar y desactivar el escalado automático vertical con la etiqueta `dynamic.sizing`. Para activar el escalado automático vertical, establezca `dynamic.sizing` en `true` en el pod controlador de Spark. Si omite esta etiqueta o la establece en cualquier otro valor que no sea `true`, el escalado automático vertical está desactivado.
+ **`dynamic.sizing.signature`**: defina la firma del trabajo con la anotación `dynamic.sizing.signature` en el pod controlador. El escalado automático vertical agrega los datos de uso de recursos en diferentes ejecuciones de trabajos de Amazon EMR Spark para obtener recomendaciones de recursos. Usted proporciona el identificador único para vincular los trabajos.

  
**nota**  
Si el trabajo se repite en un intervalo fijo, como una vez al día o una vez por semana, la firma del trabajo debe permanecer igual para cada nueva instancia del trabajo. Esto garantiza que el escalado automático vertical pueda calcular y agregar las recomendaciones en diferentes ejecuciones del trabajo.

1 Utilice este parámetro como `SparkSubmitParameter` o `ConfigurationOverride` en la API de `StartJobRun`.

## Parámetros opcionales
<a name="jobruns-vas-parameters-opt"></a>

El escalado automático vertical también admite los siguientes parámetros opcionales. Configúrelos como anotaciones en el pod controlador.


| Key | Description (Descripción) | Valores aceptados | Predeterminado | Tipo | Parámetro de Spark1 | 
| --- | --- | --- | --- | --- | --- | 
|  `dynamic.sizing.mode`  |  Modo de escalado automático vertical  |  `Off`, `Initial`, `Auto`  |  `Off`  |  anotación  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.mode`  | 
|  `dynamic.sizing.scale.memory`  |  Permite escalar la memoria  |  *`true`, `false`*  |  `true`  |  anotación  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.memory`  | 
|  `dynamic.sizing.scale.cpu`  |  Activar o desactivar escalado de CPU  |  *`true`, `false`*  |  `false`  |  anotación  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.cpu`  | 
|  `dynamic.sizing.scale.memory.min`  |  Límite mínimo de escalado de memoria  | cadena, [cantidad de recursos de K8](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), por ejemplo: 1G |  no configurado  |  anotación  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.memory.min | 
|  `dynamic.sizing.scale.memory.max`  |  Límite máximo de escalado de memoria  | cadena, [cantidad de recursos de K8](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), por ejemplo: 4G |  no configurado  |  anotación  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.memory.max | 
|  `dynamic.sizing.scale.cpu.min`  |  Límite mínimo de escalado de CPU  | cadena, [cantidad de recursos de K8](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), por ejemplo: 1 |  no configurado  |  anotación  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.cpu.min | 
|  `dynamic.sizing.scale.cpu.max`  |  Límite máximo de escalado de CPU  | cadena, [cantidad de recursos de K8](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), por ejemplo: 2 |  no configurado  |  anotación  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.cpu.max | 

### Modos de escalado automático vertical
<a name="jobruns-vas-parameters-opt-mode"></a>

El parámetro `mode` se asigna a los diferentes modos de escalado automático que el VPA admite. Utilice la anotación `dynamic.sizing.mode` del pod controlador para configurar el modo. Se admiten los siguientes valores para este parámetro:
+ **Desactivado**: un modo de ejecución en seco en el que puede supervisar las recomendaciones, pero no se lleva a cabo el escalado automático. Este es el modo predeterminado para el escalado automático vertical. En este modo, el recurso del escalador automático vertical de pods asociado calcula las recomendaciones y usted puede supervisarlas mediante herramientas como kubectl, Prometheus y Grafana.
+ **Inicial**: en este modo, el VPA escala automáticamente los recursos cuando se inicia el trabajo si hay recomendaciones disponibles en función del historial de ejecución del trabajo, como en el caso de un trabajo periódico.
+ **Automático**: en este modo, el VPA expulsa los pods ejecutores de Spark y los escala automáticamente con la configuración de recursos recomendada cuando el pod controlador de Spark los reinicia. A veces, el VPA expulsa los pods ejecutores de Spark en ejecución, por lo que podría producirse una latencia adicional al volver a intentar el ejecutor interrumpido.

### Escalado de recursos
<a name="jobruns-vas-parameters-opt-rs"></a>

Al configurar el escalado automático vertical, puede elegir si desea escalar los recursos de CPU y memoria. Establezca las anotaciones `dynamic.sizing.scale.cpu` y `dynamic.sizing.scale.memory` en `true` o `false`. De forma predeterminada, el escalado de CPU está establecido en `false` y el escalado de memoria está establecido en `true`.

### Mínimos y máximos de recursos (límites)
<a name="jobruns-vas-parameters-opt-bounds"></a>

De forma opcional, también puede establecer límites en los recursos de CPU y memoria. Elija un valor mínimo y máximo para estos recursos con las anotaciones `dynamic.sizing.[memory/cpu].[min/max]` cuando habilite el escalado automático. De forma predeterminada, los recursos no tienen limitaciones. Configure las anotaciones como valores de cadena que representen la cantidad de recursos de Kubernetes. Por ejemplo, configure `dynamic.sizing.memory.max` en `4G` para representar 4 GB.

# Supervisión del escalado automático vertical de Amazon EMR en EKS
<a name="jobruns-vas-monitor"></a>

Puede usar la herramienta de línea de comandos **kubectl** de Kubernetes para enumerar las recomendaciones activas relacionadas con el escalado automático vertical de su clúster. También puede ver las firmas de trabajo rastreadas y eliminar los recursos innecesarios que estén asociados a las firmas.



## Enumerar las recomendaciones de escalado automático vertical para el clúster
<a name="jobruns-vas-monitor-list"></a>

Use kubectl para obtener el recurso `verticalpodautoscaler` y ver el estado actual y las recomendaciones. La siguiente consulta de ejemplo devuelve todos los recursos activos de su clúster de Amazon EKS.

```
kubectl get verticalpodautoscalers \
-o custom-columns="NAME:.metadata.name,"\
"SIGNATURE:.metadata.labels.emr-containers\.amazonaws\.com/dynamic\.sizing\.signature,"\
"MODE:.spec.updatePolicy.updateMode,"\
"MEM:.status.recommendation.containerRecommendations[0].target.memory" \
--all-namespaces
```

El resultado de esta consulta se parece al siguiente:

```
NAME                  SIGNATURE                MODE      MEM
ds-example-id-1-vpa   job-signature-1          Off       none
ds-example-id-2-vpa   job-signature-2          Initial   12936384283
```

## Consultar y eliminar las recomendaciones de escalado automático vertical para el clúster
<a name="jobruns-vas-monitor-query"></a>

Al eliminar un recurso de ejecución de trabajos de escalado automático vertical de Amazon EMR, se elimina automáticamente el objeto del VPA asociado que rastrea y almacena las recomendaciones.

En el siguiente ejemplo, se utiliza kubectl para purgar las recomendaciones de un trabajo que se identifica mediante una firma:

```
kubectl delete jobrun -n emr -l=emr-containers\.amazonaws\.com/dynamic\.sizing\.signature=integ-test
jobrun.dynamicsizing.emr.services.k8s.aws "ds-job-signature" deleted
```

Si no conoce la firma de trabajo específica o quiere purgar todos los recursos del clúster, puede usar `--all` o `--all-namespaces` en el comando en lugar del ID de trabajo único, tal como se muestra en el siguiente ejemplo:

```
kubectl delete jobruns --all --all-namespaces
jobrun.dynamicsizing.emr.services.k8s.aws "ds-example-id" deleted
```

# Desinstalar el operador de escalado automático vertical de Amazon EMR en EKS
<a name="jobruns-vas-uninstall-operator"></a>

Si desea eliminar el operador de escalado automático vertical de su clúster de Amazon EKS, utilice el comando `cleanup` con la CLI de Operator SDK, tal como se muestra en el siguiente ejemplo. Esto también elimina las dependencias ascendentes que se instalaron con el operador, como el escalador automático vertical de pods.

```
operator-sdk cleanup emr-dynamic-sizing
```

Si hay algún trabajo en ejecución en el clúster al eliminar el operador, esos trabajos seguirán ejecutándose sin la configuración de escalado automático vertical. Si envía trabajos en el clúster después de eliminar el operador, Amazon EMR en EKS ignorará cualquier parámetro relacionado con el escalado automático vertical que haya definido durante la [configuración](jobruns-vas-configure.md).