As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Execução de trabalhos do Spark com `StartJobRun`
<a name="job-runs"></a>

Esta seção inclui etapas detalhadas de configuração para preparar seu ambiente para executar trabalhos do Spark e, em seguida, fornece step-by-step instruções para enviar um trabalho executado com parâmetros especificados.

**Topics**
+ [Configuração do Amazon EMR no EKS](setting-up.md)
+ [Envio de uma execução de trabalho com `StartJobRun`](emr-eks-jobs-submit.md)
+ [Uso da classificação de envio de trabalho](emr-eks-job-submitter.md)
+ [Usar a classificação de padrões do contêiner do Amazon EMR](emr-eks-job-submitter-container-defaults.md)

# Configuração do Amazon EMR no EKS
<a name="setting-up"></a>

Conclua as tarefas apresentadas a seguir para se preparar para usar o Amazon EMR no EKS. Se você já se inscreveu na Amazon Web Services (AWS) e usa o Amazon EKS, está com quase tudo pronto para usar o Amazon EMR no EKS. Ignore qualquer tarefa que já tenha concluído.

**nota**  
Você também pode acompanhar o [Amazon EMR on EKS Workshop](https://emr-on-eks.workshop.aws/amazon-emr-eks-workshop.html) para configurar todos os recursos obrigatórios para executar trabalhos do Spark no Amazon EMR no EKS. O workshop também fornece automação usando CloudFormation modelos para criar os recursos necessários para você começar. Para outros modelos e melhores práticas, consulte nosso [Guia de práticas recomendadas de contêineres do EMR](https://aws.github.io/aws-emr-containers-best-practices/) em. GitHub

1. [Instale ou atualize para a versão mais recente do AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)

1. [Configuração do kubectl e eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)

1. [Conceitos básicos do Amazon EKS: eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)

1. [Habilite o acesso ao cluster para o Amazon EMR no EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html)

1. [Habilitar perfis do IAM para o cluster do EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM-roles.html)

1. [Concessão de acesso ao Amazon EMR no EKS para os usuários](setting-up-iam.md)

1. [Registro do cluster do Amazon EKS com o Amazon EMR](setting-up-registration.md)

# Habilitação do acesso ao cluster para o Amazon EMR no EKS
<a name="setting-up-cluster-access"></a>

As seções a seguir mostram algumas maneiras de habilitar o acesso ao cluster. A primeira é usando o gerenciamento de acesso ao cluster (CAM) do Amazon EKS e a segunda mostra como executar etapas manuais para habilitar o acesso ao cluster.

## Como habilitar o acesso ao cluster usando a entrada de acesso do EKS (recomendado)
<a name="setting-up-cluster-access-cam-integration"></a>

**nota**  
O `aws-auth` ConfigMap está obsoleto. [O método recomendado para gerenciar o acesso ao Kubernetes APIs é o Access Entries.](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)

O Amazon EMR é integrado ao [gerenciamento de acesso ao cluster (CAM) do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html), para que você possa automatizar a configuração das políticas AuthN e AuthZ necessárias para executar trabalhos Spark do Amazon EMR em namespaces de clusters do Amazon EKS. Quando você cria um cluster virtual usando um namespace de cluster do Amazon EKS, o Amazon EMR configura automaticamente todas as permissões necessárias, para que você não precise adicionar nenhuma etapa extra aos fluxos de trabalho atuais.

**nota**  
A integração do Amazon EMR com o CAM do Amazon EKS é compatível somente com novos clusters virtuais do Amazon EMR no EKS. Não é possível migrar clusters virtuais existentes para usar essa integração.

### Pré-requisitos
<a name="setting-up-cluster-access-cam-integration-prereqs"></a>
+ Verifique se você está executando a versão 2.15.3 ou superior do AWS CLI
+ O cluster do Amazon EKS deve estar na versão 1.23 ou posterior.

### Configuração
<a name="setting-up-cluster-access-cam-integration-setup"></a>

Para configurar a integração entre o Amazon EMR e as operações de AccessEntry API do Amazon EKS, certifique-se de ter concluído os seguintes itens:
+ Verifique se `authenticationMode` do cluster do Amazon EKS está configurado como `API_AND_CONFIG_MAP`.

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

  Se ainda não estiver, defina `authenticationMode` como `API_AND_CONFIG_MAP`.

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

  Para obter mais informações sobre modos de autenticação, consulte [Cluster authentication modes](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html#authentication-modes).
+ Certifique-se de que o [perfil do IAM](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html) que você está usando para executar `CreateVirtualCluster` e as operações da API `DeleteVirtualCluster` também tenha as seguintes permissões:

  ```
  {
    "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/*"
  }
  ```

### Conceitos e terminologia
<a name="setting-up-cluster-access-cam-integration-concepts"></a>

A seguir está uma lista de terminologias e conceitos relacionados ao CAM do Amazon EKS.
+ Cluster virtual (VC): representação lógica do namespace criado no Amazon EKS. É um link 1:1 para um namespace de cluster do Amazon EKS. Você pode usá-lo para executar workloads do Amazon EMR em um cluster do Amazon EKS dentro do namespace especificado.
+ Namespace: mecanismo para isolar grupos de recursos em um único cluster do EKS.
+ Política de acesso: permissões que concedem acesso e ações a um perfil do IAM em um cluster do EKS.
+ Entrada de acesso: uma entrada criada com um ARN de perfil. Você pode vincular a entrada de acesso a uma política de acesso para atribuir permissões específicas no cluster do Amazon EKS.
+ Cluster virtual integrado de entrada de acesso do EKS: o cluster virtual criado usando [operações de API de entrada de acesso](https://docs.aws.amazon.com/eks/latest/APIReference/API_Operations_Amazon_Elastic_Kubernetes_Service.html) do Amazon EKS.

## Como habilitar o acesso ao cluster usando `aws-auth`
<a name="setting-up-cluster-access-aws-auth"></a>

Você deve permitir o acesso do Amazon EMR no EKS a um namespace específico em seu cluster ao executar as seguintes ações: criar um perfil do Kubernetes, associar o perfil a um usuário do Kubernetes e mapear o usuário do Kubernetes com o perfil vinculado ao serviço [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). Essas ações são automatizadas em `eksctl` quando o comando de mapeamento de identidade do IAM é usado com `emr-containers` como nome do serviço. Você pode executar essas operações facilmente ao usar o comando apresentado a seguir.

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

*my\$1eks\$1cluster*Substitua pelo nome do seu cluster Amazon EKS e *kubernetes\$1namespace* substitua pelo namespace Kubernetes criado para executar cargas de trabalho do Amazon EMR. 

**Importante**  
Você deve fazer o download do eksctl mais recente usando a etapa anterior [Configuração do kubectl e eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) para usar esta funcionalidade. 

### Etapas manuais para habilitar o acesso ao cluster para o Amazon EMR no EKS
<a name="setting-up-cluster-access-manual"></a>

Você também pode usar as etapas manuais apresentadas a seguir para habilitar o acesso ao cluster para o Amazon EMR no EKS.

1. **Crie um perfil do Kubernetes em um namespace específico**

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

   Com o Amazon EKS, versões 1.22 a 1.29, execute o comando a seguir para criar um perfil do Kubernetes em um namespace específico. Esse perfil concede as permissões de RBAC obrigatórias ao Amazon EMR no 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 ]

   Com o Amazon EKS, versões 1.21 e anteriores, execute o comando a seguir para criar um perfil do Kubernetes em um namespace específico. Esse perfil concede as permissões de RBAC obrigatórias ao Amazon EMR no 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. **Crie uma associação de perfil do Kubernetes com escopo definido para o namespace**

   Execute o comando apresentado a seguir para criar uma associação de perfil do Kubernetes no namespace especificado. Essa associação de perfil concede as permissões definidas no perfil criado na etapa anterior a um usuário chamado `emr-containers`. Esse usuário identifica [perfis vinculados ao serviço para o Amazon EMR no EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html) e, dessa forma, permite que o Amazon EMR no EKS execute ações conforme definido pelo perfil criado.

   ```
   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. **Atualize mapa de configuração `aws-auth` do Kubernetes**

   Você pode usar uma das opções apresentadas a seguir para mapear o perfil vinculado ao serviço do Amazon EMR no EKS com o usuário `emr-containers` que foi associado ao perfil do Kubernetes na etapa anterior.

   **Opção 1: usar o `eksctl`**

   Execute o comando `eksctl` apresentado a seguir para mapear o perfil vinculado ao serviço do Amazon EMR no EKS com o usuário `emr-containers`.

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

   **Opção 2: sem usar o eksctl**

   1. Execute o comando apresentado a seguir para abrir o mapa de configuração `aws-auth` no editor de texto. 

      ```
      kubectl edit -n kube-system configmap/aws-auth
      ```
**nota**  
Se você receber um erro informando`Error from server (NotFound): configmaps "aws-auth" not found`, consulte as etapas em [Adicionar funções de usuário](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) no Guia do usuário do Amazon EKS para aplicar o estoque ConfigMap. 

   1. Adicione detalhes do perfil vinculado ao serviço do Amazon EMR no EKS à seção `mapRoles` do `ConfigMap`, em `data`. Adicione essa seção se ela ainda não existir no arquivo. A seção `mapRoles` atualizada em dados deve ser semelhante ao exemplo a seguir.

      ```
      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. Salve o arquivo e saia do seu editor de texto.

# Habilitar perfis do IAM para o cluster do EKS
<a name="setting-up-enable-IAM-roles"></a>

Os tópicos a seguir detalham as opções para habilitar perfis do IAM.

**Topics**
+ [Opção 1: habilitar a Identidade de Pods do EKS no cluster do EKS](setting-up-enable-IAM.md)
+ [Opção 2: habilitar perfis do IAM para contas de serviço (IRSA) no cluster do EKS](setting-up-enable-IAM-service-accounts.md)

# Opção 1: habilitar a Identidade de Pods do EKS no cluster do EKS
<a name="setting-up-enable-IAM"></a>

As associações de Identidade de Pods do Amazon EKS permitem gerenciar credenciais para suas aplicações de forma semelhante a como os perfis de instância do Amazon EC2 fornecem credenciais para instâncias do Amazon EC2. A Identidade de Pods do Amazon EKS fornece credenciais para suas workloads com uma API EKS Auth adicional e um pod de atendente executado em cada nó.

O Amazon EMR no EKS começa a oferecer suporte à identidade de pod do EKS desde o lançamento do emr-7.3.0 para o modelo de envio. StartJobRun 

Para obter mais informações sobre identidades de pods do EKS, consulte [Como funciona a Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html).

## Por que trabalhar com Identidades de pods do EKS?
<a name="setting-up-enable-IAM-pod-identity-why"></a>

Como parte da configuração do EMR, o perfil de execução de tarefas precisa estabelecer limites de confiança entre o perfil do IAM e contas de serviço em um namespace específico (de clusters virtuais do EMR). Com o IRSA, isso foi alcançado através da atualização da política de confiança do Perfil de execução de trabalho do EMR. No entanto, devido ao limite rígido de 4096 caracteres no comprimento da política de confiança do IAM, havia uma restrição para compartilhar um único perfil do IAM de execução de trabalho em um máximo de doze (12) clusters do EKS.

Com o suporte do EMR para identidades de pods, o limite de confiança entre as funções do IAM e as contas de serviço agora está sendo gerenciado pela equipe do EKS por meio da associação da identidade do pod do EKS. APIs

**nota**  
A fronteira de segurança para identidade de pods do EKS ainda está no nível da conta de serviço, e não no nível do pod.

## Considerações sobre Identidade de Pods
<a name="setting-up-enable-IAM-pod-identity-consider"></a>

Para obter informações sobre as Limitações de identidade de pods, consulte [Considerações sobre Identidade de pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations).

## Preparar a identidade de pods do EKS no cluster do EKS
<a name="setting-up-enable-IAM-pod-eks-cluster"></a>

### Verifique se a permissão necessária existe em NodeInstanceRole
<a name="setting-up-enable-IAM-pod-eks-cluster-permission"></a>

O perfil de nó `NodeInstanceRole` precisa de permissão o agente realizar a ação `AssumeRoleForPodIdentity` na API de autenticação do EKS. Você pode adicionar o seguinte à [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy), que é definida no Guia do usuário do Amazon EKS, ou usar uma política personalizada.

Se seu cluster EKS foi criado com a versão eksctl superior a **0.181.0,** a Amazon, incluindo a `AssumeRoleForPodIdentity` permissão necessária EKSWorkerNodePolicy, será anexada automaticamente à função de nó. Se a permissão não estiver presente, adicione manualmente a seguinte permissão à Amazon, EKSWorker NodePolicy que permite assumir uma função para a identidade do pod. Essa permissão é necessária pelo agente de identidade de pods do EKS para recuperar credenciais para pods.

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

****  

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

------

### Criar complemento do agente de identidade do pod do EKS
<a name="setting-up-enable-IAM-pod-eks-cluster-agent"></a>

Use o comando a seguir para criar o complemento Agente de identidade de pods do EKS com a versão mais recente:

```
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'
```

Use as etapas a seguir para criar o complemento Agente de identidade de pods do EKS no console do Amazon EKS:

1. Abra o console do Amazon EKS: [Console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. No painel de navegação esquerdo, selecione **Clusters** e depois o nome do cluster para o qual você deseja configurar o complemento do atendente de Identidade de Pods do EKS.

1. Escolha a guia **Add-ons** (Complementos).

1. Escolha **Obter mais complementos**.

1. Selecione a caixa no canto superior direito da caixa do complemento do atentente de Identidade de Pods do EKS e escolha **Editar**.

1. Na página **Configurar complementos selecionados**, selecione qualquer versão na lista suspensa **Versão**.

1. (Opcional) Expanda **Configurações opcionais** para inserir configurações adicionais. Por exemplo, é possível indicar um local alternativo para a imagem do contêiner e `ImagePullSecrets`. O esquema JSON com chaves aceitas é mostrado no **Esquema de configuração do complemento**.

   Insira as chaves e os valores de configuração em **Valores de configuração**.

1. Escolha **Próximo**.

1. Confirme se os pods do agente estão em execução no seu cluster por meio da CLI.

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

Veja a seguir um exemplo de saída:

```
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
```

Isso configura um novo DaemonSet no `kube-system` namespace. O Amazon EKS Pod Identity Agent, executado em cada nó do EKS, usa a [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)ação para recuperar credenciais temporárias da API EKS Auth. Essas credenciais são então disponibilizadas para AWS SDKs que você execute dentro de seus contêineres.

Para obter mais informações, verifique o pré-requisito no documento público: [Configurar o Agente de identidade de pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html).

## Criar um perfil de execução de trabalho
<a name="setting-up-enable-IAM-pod-create-job-role"></a>

### Criar ou atualizar o perfil de execução de trabalhos que permite a Identidade de Pods do EKS
<a name="setting-up-enable-IAM-pod-create-job-role-update"></a>

Para executar workloads no Amazon EMR no EKS, você precisa criar um perfil do IAM. Referimo-nos a esse perfil como perfil de execução de trabalho nesta documentação. Para obter mais informações sobre como criar o perfil do IAM, consulte [Criação de perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) no Guia do usuário.

Além disso, você deve criar uma política do IAM que especifique as permissões necessárias para o perfil de execução de trabalho e, em seguida, anexar essa política ao perfil para habilitar a Identidade de Pods do EKS.

Por exemplo, você tem o seguinte perfil de execução de trabalho. Para obter mais informações, consulte [Criar um perfil de execução de trabalho](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html).

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

**Importante**  
O Amazon EMR no EKS cria contas de serviço do Kubernetes automaticamente, com base no nome do perfil de execução do trabalho. Certifique-se de que o nome do perfil não seja muito longo, pois seu trabalho poderá falhar se a combinação de `cluster_name`, `pod_name`, `service_account_name` e exceder o limite de comprimento.

**Configuração do perfil de execução de trabalho**: certifique-se de que o perfil de execução de trabalho seja criado com a permissão de confiança abaixo para a Identidade de Pods do EKS. Para atualizar um perfil de execução de trabalho existente, configure-o para confiar na seguinte entidade principal de serviço do EKS como uma permissão adicional na política de confiança. Essa permissão de confiança pode coexistir com as políticas de confiança do 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
```

**Permissão do usuário**: os usuários necessitam da permissão `iam:PassRole` para executar chamadas de API `StartJobRun` ou enviar trabalhos. Essa permissão permite que os usuários passem o perfil de execução de trabalho ao EMR no EKS. Os administradores de trabalhos devem ter a permissão por padrão.

Abaixo está a permissão necessária para um usuário:

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

Para restringir ainda mais o acesso do usuário a clusters EKS específicos, adicione o filtro de AssociatedResourceArn atributos à política do IAM. Limita a atribuição de perfis a clusters do EKS autorizados, reforçando os controles de segurança no nível dos recursos.

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

## Configurar associações de identidade de pods do EKS
<a name="setting-up-enable-IAM-pod-identity-asociations"></a>

### Pré-requisito
<a name="setting-up-enable-IAM-pod-identity-asociations-prereq"></a>

Certifique-se de que a identidade do IAM que cria a associação de identidade de pods, como um usuário administrador do EKS, tenha a permissão `eks:CreatePodIdentityAssociation` e `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"
    }
  ]
}
```

------

### Criar associações para o perfil e a conta de serviço do EMR
<a name="setting-up-enable-IAM-pod-identity-asociations-emr-service"></a>

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

Quando você envia um trabalho para um namespace do Kubernetes, um administrador deve criar associações entre o perfil de execução do trabalho e a identidade da conta de serviço gerenciada do EMR. Observe que a conta de serviço gerenciado do EMR é criada automaticamente no envio do trabalho, com escopo definido para o namespace no qual o trabalho é enviado.

Com a versão 2.24.0 AWS CLI (acima), execute o comando a seguir para criar associações de função com a identidade do pod.

Execute o seguinte comando para criar associações de perfil com a identidade do pod:

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

Observação:
+ Cada cluster pode ter um limite de 1.000 associações. Para cada mapeamento de perfil de execução de trabalho - namespace, será necessário três associados para os pods de remetente, driver e executor de trabalho.
+ Você só pode associar funções que estejam na mesma AWS conta do cluster. É possível delegar o acesso de outra conta ao perfil nessa conta configurada por você para o EKS Pod Identities usar. Para ver um tutorial sobre delegação de acesso`AssumeRole`, consulte o [tutorial do IAM: Delegar acesso entre AWS contas usando funções do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html).

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

O EMR cria uma conta de serviço com um determinado padrão de nomenclatura quando um trabalho é enviado. Para fazer associações manuais ou integrar esse fluxo de trabalho ao AWS SDK, siga estas etapas:

Nome da conta de serviço do constructo:

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

Os exemplos abaixo criam uma associação de função para um exemplo de função de execução de Job JobExecutionRoleIRSAv2.

**Exemplos de associações de perfis:**

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

**Exemplo 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
```

------

Depois de concluir todas as etapas necessárias para a Identidade de Pods do EKS, você pode pular as etapas a seguir para a configuração do IRSA:
+ [Ativar funções do IAM para contas de serviço (IRSA) no cluster EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html)
+ [Crie uma função de execução de tarefas](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)
+ [Atualize a política de confiança da função de execução do trabalho](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html)

É possível avançar diretamente para a etapa seguinte: [Conceder aos usuários acesso ao Amazon EMR no EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html)

## Excluir associações de perfil
<a name="setting-up-enable-IAM-pod-identity-asociations-delete-associations"></a>

Sempre que você excluir um cluster virtual ou um perfil de execução de trabalho e não quiser mais conceder acesso ao EMR às suas contas de serviço, você deverá excluir as associações do perfil. Isso ocorre porque o EKS permite associações com recursos inexistentes (namespace e conta de serviço). O Amazon EMR no EKS recomenda excluir as associações se o namespace for excluído ou se o perfil não estiver mais em uso, para liberar espaço para outras associações.

**nota**  
As associações persistentes podem afetar sua capacidade de escalar se você não as excluir, pois o EKS tem limitações no número de associações que você pode criar (limite flexível: 1000 associações por cluster). Você pode listar as associações de identidades de pods em um determinado namespace para verificar se há alguma associação remanescente que precisa ser limpa:

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

Com a AWS CLI (versão 2.24.0 ou superior), execute o seguinte comando emr-containers para excluir as associações de função do EMR:

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

## Migrar automaticamente o IRSA existente para a Identidade de Pods
<a name="setting-up-enable-IAM-pod-identity-auto-migrate"></a>

Você pode usar a ferramenta eksctl para migrar perfis do IAM existentes para contas de serviço (IRSA) para associações de identidade de pods:

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

A execução do comando sem o sinalizador `--approve` produzirá apenas um plano que reflete as etapas da migração, e nenhuma migração real ocorrerá.

## Solução de problemas
<a name="setting-up-enable-IAM-pod-identity-troubleshooting"></a>

### Meu trabalho falhou com NoClassDefinitionFound ou com ClassNotFound exceção do provedor de credenciais, ou falhou em obter o provedor de credenciais.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-no-class"></a>

A Identidade de Pods do EKS usa o Provedor de credenciais de contêiner para recuperar as credenciais necessárias. Se você especificou um provedor de credenciais personalizado, verifique se ele está funcionando corretamente. Como alternativa, verifique se você está usando uma versão correta do AWS SDK compatível com o EKS Pod Identity. Para obter mais informações, consulte [Conceitos básicos do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

### O trabalho falhou com o erro “Falha na recuperação de credenciais devido ao limite de tamanho [x]” mostrado no eks-pod-identity-agent registro.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds"></a>

O EMR no EKS cria contas de serviço do Kubernetes com base no nome do perfil de execução do trabalho. Se o nome do perfil for muito longo, o EKS Auth não conseguirá recuperar as credenciais porque a combinação de `cluster_name`, `pod_name` e `service_account_name` excede o limite de comprimento. Identifique qual componente está ocupando mais espaço e ajuste o tamanho de acordo.

### O trabalho falhou com o erro “Failed to Retrieve Credentials xxx” exibido no eks-pod-identity registro.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds-error"></a>

Uma possível causa desse problema pode ser que o cluster EKS esteja configurado em sub-redes privadas sem ser configurado corretamente PrivateLink para o cluster. Verifique se seu cluster está em uma rede privada e configure AWS PrivateLink para resolver o problema. Para obter instruções detalhadas, consulte [Comece a usar o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

# Opção 2: habilitar perfis do IAM para contas de serviço (IRSA) no cluster do EKS
<a name="setting-up-enable-IAM-service-accounts"></a>

O recurso de perfis do IAM para contas de serviço está disponível nas versões 1.14 e posteriores do Amazon EKS e para clusters do EKS atualizados para as versões 1.13 ou posteriores ou após 3 de setembro de 2019. Para usar esse recurso, é possível atualizar os clusters do EKS existentes para a versão 1.14 ou posterior. Para obter mais informações, consulte [Atualizar uma versão do Kubernetes do cluster do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).

Se o seu cluster oferecer suporte para perfis do IAM para contas de serviço, ele terá um URL do emissor [OpenID Connect](https://openid.net/connect/) associado a ele. Você pode visualizar essa URL no console do Amazon EKS ou usar o AWS CLI comando a seguir para recuperá-la.

**Importante**  
Você deve usar a versão mais recente do AWS CLI para receber a saída adequada desse comando.

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

A saída esperada é semelhante à apresentada a seguir.

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

Para usar perfis do IAM para contas de serviço em seu cluster, é necessário criar um provedor de identidades OIDC usando o [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) ou o [Console de gerenciamento da AWS](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console).

## Para criar um provedor de identidade OIDC do IAM para o cluster com o `eksctl`
<a name="setting-up-OIDC-eksctl"></a>

Verifique a versão do `eksctl` com o comando a seguir. Este procedimento pressupõe que você instalou o `eksctl` e que a versão do `eksctl` seja 0.32.0 ou posterior.

```
eksctl version
```

Para obter mais informações sobre como instalar ou atualizar o eksctl, consulte [Instalar ou atualizar o eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl).

Crie o provedor de identidade OIDC para o cluster com o seguinte comando. Substitua *cluster\$1name* pelos seus próprios valores.

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

## Para criar um provedor de identidade IAM OIDC para seu cluster com o Console de gerenciamento da AWS
<a name="setting-up-OIDC-console"></a>

Recupere a URL do emissor do OIDC na descrição do console Amazon EKS do seu cluster ou use o comando a seguir. AWS CLI 

Use o comando apresentado a seguir para recuperar o URL do emissor OIDC da AWS CLI.

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

Use as etapas apresentadas a seguir para recuperar o URL do emissor OIDC do console do Amazon EKS. 

1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. No painel de navegação, escolha **Provedores de identidade** e, em seguida, selecione **Criar provedor**.

   1. Para **Tipo de provedor**, escolha **Escolher um tipo de provedor** e escolha **OpenID Connect**.

   1. Em **Provider URL (URL do provedor)**, cole o URL emissor OIDC do cluster.

   1. Para Público, digite sts.amazonaws.com e escolha **Próxima etapa**.

1. Verifique se as informações do provedor estão corretas e escolha **Create (Criar)** para criar seu provedor de identidade.

# Criação de um perfil de execução de trabalho
<a name="creating-job-execution-role"></a>

Para executar workloads no Amazon EMR no EKS, você precisa criar um perfil do IAM. Referimo-nos a esse perfil como *perfil de execução de trabalho* nesta documentação. Para obter mais informações sobre como criar perfis do IAM, consulte [Criação de perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) no Guia do usuário do IAM. 

Você também deve criar uma política do IAM que especifique as permissões para o perfil de execução de trabalho e, em seguida, anexar a política do IAM ao perfil de execução de trabalho. 

A política a seguir para a função de execução do trabalho permite acesso a destinos de recursos, Amazon S3 e. CloudWatch Essas permissões são necessárias para monitorar trabalhos e acessar logs. Para seguir o mesmo processo usando o AWS CLI: 

Crie o perfil do IAM para execução do trabalho: vamos criar o perfil que o EMR usará para a execução do trabalho. Essa é o perfil que os trabalhos do EMR assumirão quando forem executados no 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
```

Em seguida, precisamos anexar as políticas do IAM necessárias ao perfil para que ele possa gravar logs no S3 e no 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**  
O acesso deve ter um escopo adequado e não ser concedido a todos os objetos do S3 no perfil de execução de trabalho.

------
#### [ 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 obter mais informações, consulte [Usando funções de execução de trabalho](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html), [Configurar uma execução de trabalho para usar registros do S3](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) e [Configurar uma execução de trabalho para usar CloudWatch registros](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch).

# Atualização da política de confiança do perfil de execução de trabalho
<a name="setting-up-trust-policy"></a>

Ao usar perfis do IAM para contas de serviço (IRSA) com a finalidade de executar trabalhos em um namespace do Kubernetes, um administrador deve criar uma relação de confiança entre o perfil de execução de trabalho e a identidade da conta de serviço gerenciado do EMR. A relação de confiança pode ser criada ao atualizar a política de confiança do perfil de execução de trabalho. Observe que a conta de serviço gerenciado do EMR é criada automaticamente no envio do trabalho, com escopo definido para o namespace no qual o trabalho é enviado.

Execute o comando apresentado a seguir para atualizar a política de confiança.

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

Para obter mais informações, consulte [Uso de perfis de execução de trabalho com o Amazon EMR no EKS](iam-execution-role.md).

**Importante**  
O operador que executa o comando acima deve ter estas permissões: `eks:DescribeCluster`, `iam:GetRole` e `iam:UpdateAssumeRolePolicy`.

# Concessão de acesso ao Amazon EMR no EKS para os usuários
<a name="setting-up-iam"></a>

Para as ações executadas no Amazon EMR no EKS, uma permissão do IAM correspondente para essa ação é necessária. Você deve criar uma política do IAM que permita executar ações do Amazon EMR no EKS e anexá-la ao perfil ou ao usuário do IAM que você usa. 

Este tópico fornece etapas para a criação de uma nova política e para o anexo dela a um usuário. Ele também abrange as permissões básicas necessárias para configurar o ambiente do Amazon EMR no EKS. Recomendamos redefinir as permissões para recursos específicos sempre que possível com base nas suas necessidades de negócios.

## Criação de uma nova política do IAM e anexo dela a um usuário no console do IAM
<a name="setting-up-iam-console"></a>

**Crie uma nova política do IAM**

1. Faça login no Console de gerenciamento da AWS e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. No painel de navegação esquerdo do console do IAM, escolha **Políticas**.

1. Na página **Policies** (Políticas), escolha **Create Policy** (Criar política).

1. Na janela **Criar política**, navegue até a guia **Editar JSON**. Crie um documento de política com uma ou mais instruções JSON, conforme mostrado nos exemplos que seguem este procedimento. Em seguida, escolha **Analisar política**.

1. Na tela **Review Policy** (Revisar política), insira o **Policy Name** (Nome da política), por exemplo, `AmazonEMROnEKSPolicy`. Insira uma descrição opcional e, em seguida, escolha **Criar política**. 

**Anexe a política a um usuário ou a um perfil**

1. Faça login no Console de gerenciamento da AWS e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 

1. No painel de navegação, selecione **Políticas**.

1. Na lista de políticas, marque a caixa de seleção ao lado da política criada na seção anterior. Você pode usar o menu **Filtro** e a caixa de pesquisa para filtrar a lista de políticas. 

1. Selecione **Ações da política** e escolha **Anexar**.

1. Escolha o usuário ou o perfil ao qual a política será anexada. Você pode usar o menu **Filter** (Filtro) e a caixa de pesquisa para filtrar a lista de entidades principais. Após escolher o usuário ou o perfil ao qual a política será anexada, selecione **Anexar política**.

## Permissões para o gerenciamento de clusters virtuais
<a name="permissions-virtual-cluster"></a>

Para gerenciar clusters virtuais em sua AWS conta, crie uma política do IAM com as seguintes permissões. Essas permissões permitem que você crie, liste, descreva e exclua clusters virtuais em sua AWS conta.

------
#### [ 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"
    }
  ]
}
```

------

O Amazon EMR é integrado ao gerenciamento de acesso ao cluster (CAM) do Amazon EKS, para que você possa automatizar a configuração das políticas AuthN e AuthZ necessárias para executar trabalhos Spark do Amazon EMR em namespaces de clusters do Amazon EKS. Para fazer isso, você deve ter as seguintes permissões:

```
{
  "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 obter mais informações, consulte [Automate enabling cluster access for Amazon EMR on EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-cam-integration).

Quando a `CreateVirtualCluster` operação é invocada pela primeira vez a partir de uma AWS conta, você também precisa das `CreateServiceLinkedRole` permissões para criar a função vinculada ao serviço para o Amazon EMR no EKS. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon EMR no EKS](using-service-linked-roles.md). 

## Permissões para o envio de trabalhos
<a name="permissions-submitting-jobs"></a>

Para enviar trabalhos nos clusters virtuais da sua AWS conta, crie uma política do IAM com as seguintes permissões. Essas permissões permitem iniciar, listar, descrever e cancelar execuções de trabalhos para todos os clusters virtuais em sua conta. Você deve considerar adicionar permissões para listar ou descrever clusters virtuais, o que permite verificar o estado do cluster virtual antes de enviar trabalhos.

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

****  

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

------

## Permissões para a depuração e o monitoramento
<a name="permissions-debugging-monitoring"></a>

Para obter acesso aos registros enviados para o Amazon S3 e CloudWatch, ou para visualizar os registros de eventos do aplicativo no console do Amazon EMR, crie uma política do IAM com as seguintes permissões. Recomendamos redefinir as permissões para recursos específicos sempre que possível com base nas suas necessidades de negócios.

**Importante**  
Se você não criou um bucket do Amazon S3, será necessário adicionar a permissão `s3:CreateBucket` à instrução de política. Se você não criou um grupo de logs, será necessário adicionar `logs:CreateLogGroup` à instrução 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 obter mais informações sobre como configurar uma execução de trabalho para enviar registros para o Amazon S3 CloudWatch, consulte [Configurar uma execução de trabalho para usar registros do S3 e [Configurar uma execução de trabalho para](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch) usar registros](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3). CloudWatch 

# Registro do cluster do Amazon EKS com o Amazon EMR
<a name="setting-up-registration"></a>

Registrar o cluster é a etapa final obrigatória para configurar o Amazon EMR no EKS para executar workloads.

Use o comando apresentado a seguir para criar um cluster virtual com um nome de sua escolha para o cluster e para o namespace do Amazon EKS configurados nas etapas anteriores.

**nota**  
Cada cluster virtual deve ter um nome exclusivo em todos os clusters do EKS. Se dois clusters virtuais tiverem o mesmo nome, o processo de implantação falhará mesmo que os dois clusters virtuais pertençam a clusters do 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, você pode criar um arquivo JSON que inclua os parâmetros obrigatórios para o cluster virtual e, em seguida, executar o comando `create-virtual-cluster` com o caminho para o arquivo JSON. Para obter mais informações, consulte [Gerenciamento de clusters virtuais](virtual-cluster.md).

**nota**  
Para validar a criação com êxito de um cluster virtual, visualize o status dos clusters virtuais ao usar a operação `list-virtual-clusters` ou acessar a página **Clusters virtuais** no console do Amazon EMR. 

# Envio de uma execução de trabalho com `StartJobRun`
<a name="emr-eks-jobs-submit"></a>

**Enviar uma execução de trabalho com um arquivo JSON com parâmetros especificados**

1. Crie um arquivo `start-job-run-request.json` e especifique os parâmetros obrigatórios para a execução de trabalho, como demonstrado pelo arquivo JSON de exemplo a seguir. Para obter mais informações sobre os parâmetros, consulte [Opções para a configuração de uma execução de trabalho](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. Use o comando `start-job-run` com um caminho para o arquivo `start-job-run-request.json` armazenado localmente.

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

**Iniciar uma execução de trabalho usando o comando `start-job-run`**

1. Forneça todos os parâmetros especificados no comando `StartJobRun`, como demonstrado pelo exemplo a seguir.

   ```
   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. Para o Spark SQL, forneça todos os parâmetros especificados no comando `StartJobRun`, como demonstrado pelo exemplo a seguir.

   ```
   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 da classificação de envio de trabalho
<a name="emr-eks-job-submitter"></a>

## Visão geral do
<a name="emr-eks-job-submitter-overview"></a>

A solicitação `StartJobRun` do Amazon EMR no EKS cria um pod de *envio de trabalho* (também conhecido como pod *job-runner*) para gerar o driver do Spark. Você pode usar a `emr-job-submitter` classificação para configurar seletores de nós, adicionar tolerâncias, personalizar o registro e fazer outras modificações no pod remetente do trabalho.

As seguintes configurações estão disponíveis na classificação `emr-job-submitter`:

** `jobsubmitter.node.selector.[selectorKey]` **  
É adicionado ao seletor de nós do pod remetente do trabalho, com a chave *selectorKey* e o valor como valor de configuração. Por exemplo, você pode ` jobsubmitter.node.selector.identifier` definir como `myIdentifier` e o pod remetente do trabalho terá um seletor de nós com uma chave `identifier` e um valor. `myIdentifier` Isso pode ser usado para especificar em quais nós o pod remetente do trabalho pode ser colocado. Para adicionar diversas chaves seletoras de nós, defina diversas configurações com esse prefixo.

** `jobsubmitter.label.[labelKey]` **  
Adiciona aos rótulos do pod remetente do trabalho, com a chave *labelKey* e o valor como valor de configuração. Para adicionar vários rótulos, defina várias configurações com esse prefixo.

** `jobsubmitter.annotation.[annotationKey]` **  
Adiciona às anotações do pod remetente do trabalho, com a chave *annotationKey* e o valor como valor de configuração. Para adicionar várias anotações, defina várias configurações com esse prefixo.

** `jobsubmitter.node.toleration.[tolerationKey]` **  
Adiciona [tolerâncias](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) ao pod do remetente do trabalho. Por padrão, não há tolerâncias adicionadas ao pod. A chave da tolerância será *tolerationKey* e o valor da tolerância será o valor da configuração. Se o valor da configuração for definido como uma string não vazia, o operador será`Equals`. Se o valor da configuração estiver definido como`""`, o operador será`Exists`.

** `jobsubmitter.node.toleration.[tolerationKey].[effect]` **  
Adiciona um efeito de tolerância ao prefixo*tolerationKey*. Esse campo é obrigatório ao adicionar tolerâncias. Os valores permitidos para o campo de efeito são ` NoExecute``NoSchedule`, `PreferNoSchedule` e.

** `jobsubmitter.node.toleration.[tolerationKey].[tolerationSeconds]` **  
Adiciona tolerationSeconds ao prefixo. *tolerationKey* Campo opcional. Aplicável somente quando o efeito é`NoExecute`.

** `jobsubmitter.scheduler.name` **  
Define um SchedulerName personalizado para o pod remetente do trabalho.

** `jobsubmitter.logging` **  
Ativa ou desativa o registro no pod remetente do trabalho. Quando isso é definido como, ` DISABLED` o contêiner de registro é removido do pod remetente do trabalho, o que desativará qualquer registro desse pod especificado no`monitoringConfiguration`, como `s3MonitoringConfiguration` ou. `cloudWatchMonitoringConfiguration` Quando essa configuração não está definida ou está definida com qualquer outro valor, o login no pod remetente do trabalho é ativado.

** `jobsubmitter.logging.image` **  
Define uma imagem personalizada a ser usada para o contêiner de registro em log no pod remetente do trabalho.

** `jobsubmitter.logging.request.cores` **  
Define um valor personalizado para o número CPUs, em unidades de CPU, do contêiner de registro no pod remetente do trabalho. Por padrão, ela é definida como **100m**.

** `jobsubmitter.logging.request.memory` **  
Define um valor personalizado para a quantidade de memória, em bytes, para o contêiner de log no pod do remetente do trabalho. Por padrão, ela é definida como **200Mi**. Um mebibyte é uma unidade de medida semelhante a um megabyte.

** `jobsubmitter.container.image` **  
Define uma imagem personalizada para o contêiner do pod remetente do `job-runner` trabalho.

** `jobsubmitter.container.image.pullPolicy` **  
Define os [imagePullPolicy](https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy)contêineres do pod remetente do trabalho para os contêineres.

Recomendamos colocar pods de remetentes de trabalhos em instâncias sob demanda. A colocação de pods remetentes de trabalhos em instâncias spot pode resultar em uma falha no trabalho se a instância em que o pod remetente de trabalho é executado estiver sujeita a uma interrupção da instância spot. Você também pode [colocar o pod remetente do trabalho em uma única zona de disponibilidade ou usar qualquer rótulo do Kubernetes aplicado aos nós](#emr-eks-job-submitter-ex-ec2).

## Exemplos de classificação de envio de trabalho
<a name="emr-eks-job-submitter-examples"></a>

**Topics**
+ [Solicitação `StartJobRun` com nó sob demanda estabelecido para o pod de envio de trabalho](#emr-eks-job-submitter-ex-od)
+ [`StartJobRun`solicitação com posicionamento de nó Single-AZ e posicionamento do tipo de instância Amazon EC2 para o pod remetente do trabalho](#emr-eks-job-submitter-ex-ec2)
+ [`StartJobRun`solicitação com rótulos, anotações e um agendador personalizado para o pod remetente do trabalho](#emr-eks-job-submitter-label-annotation-scheduler)
+ [`StartJobRun`solicitação com uma tolerância aplicada ao pod remetente do trabalho com chave`dedicated`, valor `graviton_machines``NoExecute`, efeito e a de 60 segundos `tolerationSeconds`](#emr-eks-job-submitter-tolerations)
+ [`StartJobRun`solicitação com registro desativado para o pod remetente do trabalho](#emr-eks-job-submitter-logging-disabled)
+ [`StartJobRun`solicitação com imagem de contêiner de registro personalizada, CPU e memória para o pod remetente do trabalho](#emr-eks-job-submitter-custom)
+ [`StartJobRun`solicitação com uma imagem personalizada do contêiner do remetente do trabalho e política de pull](#emr-eks-job-submitter-custom-container)

### Solicitação `StartJobRun` com nó sob demanda estabelecido para o pod de envio de trabalho
<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`solicitação com posicionamento de nó Single-AZ e posicionamento do tipo de instância Amazon EC2 para o pod remetente do trabalho
<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`solicitação com rótulos, anotações e um agendador personalizado para o pod remetente do trabalho
<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`solicitação com uma tolerância aplicada ao pod remetente do trabalho com chave`dedicated`, valor `graviton_machines``NoExecute`, efeito e a de 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`solicitação com registro desativado para o pod remetente do trabalho
<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`solicitação com imagem de contêiner de registro personalizada, CPU e memória para o pod remetente do trabalho
<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`solicitação com uma imagem personalizada do contêiner do remetente do trabalho e política de pull
<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"
      }
    }
  ]
}
```

# Usar a classificação de padrões do contêiner do Amazon EMR
<a name="emr-eks-job-submitter-container-defaults"></a>

## Visão geral do
<a name="emr-eks-job-submitter-container-defaults-overview"></a>

As seguintes configurações estão disponíveis na classificação `emr-containers-defaults`:

** `job-start-timeout` **  
Por padrão, um trabalho atingirá o tempo limite se não puder ser iniciado e esperar no estado ` SUBMITTED` por 15 minutos. Essa configuração altera o número de segundos de espera antes da expiração da tarefa.

** `executor.logging` **  
Ativa ou desativa o registro nos pods do executor. Quando isso é definido como, ` DISABLED` o contêiner de registro é removido dos pods do executor, o que desativará qualquer registro desses pods especificados no`monitoringConfiguration`, como ou. `s3MonitoringConfiguration` `cloudWatchMonitoringConfiguration` Quando essa configuração não está definida ou está definida com qualquer outro valor, o registro nos pods do executor é ativado.

** `logging.image` **  
Define uma imagem personalizada a ser utilizada para o contêiner de registro em log nos pods do driver e do executor.

** `logging.request.cores` **  
Define um valor personalizado para o número CPUs, em unidades de CPU, do contêiner de registro nos pods do driver e do executor. Isso não é definido por padrão.

** `logging.request.memory` **  
Define um valor personalizado para a quantidade de memória, em bytes, para o contêiner de registro em log nos pods do driver e do executor. Por padrão, ela é definida como **512Mi**. Um mebibyte é uma unidade de medida semelhante a um megabyte.

## Exemplos de classificação de envio de trabalho
<a name="emr-eks-job-submitter-container-examples"></a>

**Topics**
+ [Solicitação `StartJobRun` com tempo limite de trabalho personalizado](#emr-eks-job-submitter-container-custom-timeout)
+ [`StartJobRun`solicitação com registro desativado para pods de executores](#emr-eks-executor-logging-disabled)
+ [`StartJobRun`solicitação com imagem de contêiner de registro personalizada, CPU e memória para os pods de driver e executor](#emr-eks-job-submitter-container-custom-image-cpu)

### Solicitação `StartJobRun` com tempo limite de trabalho 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`solicitação com registro desativado para pods de executores
<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`solicitação com imagem de contêiner de registro personalizada, CPU e memória para os pods de driver e executor
<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"
    }
  }
}
```