Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Esecuzione di processi Spark con `StartJobRun`
<a name="job-runs"></a>

Questa sezione include passaggi di configurazione dettagliati per preparare l'ambiente all'esecuzione dei job Spark e quindi fornisce step-by-step istruzioni per inviare un job eseguito con parametri specificati.

**Topics**
+ [Configurazione di Amazon EMR su EKS](setting-up.md)
+ [Invio di un'esecuzione di processo con `StartJobRun`](emr-eks-jobs-submit.md)
+ [Uso della classificazione del mittente di processi](emr-eks-job-submitter.md)
+ [Utilizzo della classificazione delle impostazioni predefinite dei container Amazon EMR](emr-eks-job-submitter-container-defaults.md)

# Configurazione di Amazon EMR su EKS
<a name="setting-up"></a>

Completa le attività seguenti per effettuare la configurazione di Amazon EMR su EKS. Se hai già effettuato la registrazione ad Amazon Web Services (AWS) e stai utilizzando Amazon EKS, ti manca poco per cominciare a utilizzare Amazon EMR su EKS. Salta le eventuali attività che hai già completato.

**Nota**  
È inoltre possibile seguire il [Workshop su Amazon EMR su EKS](https://emr-on-eks.workshop.aws/amazon-emr-eks-workshop.html) per configurare tutte le risorse necessarie per eseguire i processi Spark in Amazon EMR su EKS. Il workshop fornisce anche l'automazione utilizzando CloudFormation modelli per creare le risorse necessarie per iniziare. Per altri modelli e best practice, consulta la nostra [Guida alle best practice per i contenitori EMR](https://aws.github.io/aws-emr-containers-best-practices/) su. GitHub

1. [Installa o aggiorna alla versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)

1. [Configura kubectl ed eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html).

1. [Inizia a usare Amazon EKS — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)

1. [Abilita l'accesso al cluster per Amazon EMR su EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html)

1. [Abilita IAM Roles per il cluster EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM-roles.html)

1. [Concessione dell'accesso ad Amazon EMR su EKS agli utenti](setting-up-iam.md)

1. [Registrazione del cluster Amazon EKS con Amazon EMR](setting-up-registration.md)

# Abilitare l'accesso ai cluster per Amazon EMR su EKS
<a name="setting-up-cluster-access"></a>

Le sezioni seguenti mostrano un paio di modi per abilitare l'accesso al cluster. La prima consiste nell'utilizzare la gestione degli accessi al cluster Amazon EKS (CAM) e la seconda mostra come eseguire passaggi manuali per abilitare l'accesso al cluster.

## Abilita l'accesso al cluster utilizzando EKS Access Entry (consigliato)
<a name="setting-up-cluster-access-cam-integration"></a>

**Nota**  
La funzionalità `aws-auth` ConfigMap è obsoleta. [Il metodo consigliato per gestire l'accesso a Kubernetes APIs è Access Entries.](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)

Amazon EMR è integrato con [Amazon EKS Cluster Access Management (CAM)](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html), quindi puoi automatizzare la configurazione delle policy AuthN e AuthZ necessarie per eseguire i job Amazon EMR Spark nei namespace dei cluster Amazon EKS. Quando crei un cluster virtuale da uno spazio dei nomi del cluster Amazon EKS, Amazon EMR configura automaticamente tutte le autorizzazioni necessarie, quindi non è necessario aggiungere passaggi aggiuntivi ai flussi di lavoro correnti.

**Nota**  
L'integrazione di Amazon EMR con Amazon EKS CAM è supportata solo per i nuovi Amazon EMR su cluster virtuali EKS. Non puoi migrare i cluster virtuali esistenti per utilizzare questa integrazione.

### Prerequisiti
<a name="setting-up-cluster-access-cam-integration-prereqs"></a>
+ Assicurati di utilizzare la versione 2.15.3 o successiva di AWS CLI
+ Il tuo cluster Amazon EKS deve avere la versione 1.23 o successiva.

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

Per configurare l'integrazione tra Amazon EMR e le operazioni AccessEntry API di Amazon EKS, assicurati di aver completato i seguenti elementi:
+ Assicurati che quello `authenticationMode` del tuo cluster Amazon EKS sia impostato su`API_AND_CONFIG_MAP`.

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

  Se non lo è già, imposta `authenticationMode` su`API_AND_CONFIG_MAP`.

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

  Per ulteriori informazioni sulle modalità di autenticazione, vedere [Modalità di autenticazione del cluster](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html#authentication-modes).
+ Assicurati che il [ruolo IAM](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html) che stai utilizzando per eseguire le operazioni `CreateVirtualCluster` e `DeleteVirtualCluster` API disponga anche delle seguenti autorizzazioni:

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

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

Di seguito è riportato un elenco di terminologie e concetti relativi ad Amazon EKS CAM.
+ Cluster virtuale (VC): rappresentazione logica dello spazio dei nomi creato in Amazon EKS. È un collegamento 1:1 a uno spazio dei nomi del cluster Amazon EKS. Puoi usarlo per eseguire carichi di lavoro Amazon EMR su un cluster Amazon EKS all'interno dello spazio dei nomi specificato.
+ Namespace: meccanismo per isolare gruppi di risorse all'interno di un singolo cluster EKS.
+ Politica di accesso: autorizzazioni che garantiscono l'accesso e le azioni a un ruolo IAM all'interno di un cluster EKS.
+ Accesso: una voce creata con un ruolo arn. Puoi collegare la voce di accesso a una policy di accesso per assegnare autorizzazioni specifiche nel cluster Amazon EKS.
+ Cluster virtuale integrato con accesso EKS: il cluster virtuale creato utilizzando [le operazioni API di accesso](https://docs.aws.amazon.com/eks/latest/APIReference/API_Operations_Amazon_Elastic_Kubernetes_Service.html) di Amazon EKS.

## Abilita l'accesso al cluster utilizzando `aws-auth`
<a name="setting-up-cluster-access-aws-auth"></a>

È necessario consentire ad Amazon EMR su EKS l'accesso a uno spazio dei nomi specifico nel cluster mediante le seguenti operazioni: creazione di un ruolo Kubernetes, associazione del ruolo a un utente Kubernetes e mappatura dell'utente Kubernetes con il ruolo collegato al servizio [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). Queste operazioni sono automatizzate in `eksctl` quando il comando di mappatura di identità IAM viene utilizzato con `emr-containers` come nome di servizio. È possibile eseguire facilmente queste operazioni utilizzando il comando seguente.

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

Sostituiscilo *my\$1eks\$1cluster* con il nome del tuo cluster Amazon EKS e sostituiscilo *kubernetes\$1namespace* con lo spazio dei nomi Kubernetes creato per eseguire carichi di lavoro Amazon EMR. 

**Importante**  
È necessario scaricare la versione più recente di eksctl utilizzando il passaggio precedente. [Configurare](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) kubectl ed eksctl per utilizzare questa funzionalità. 

### Procedure manuali per abilitare l'accesso al cluster per Amazon EMR su EKS
<a name="setting-up-cluster-access-manual"></a>

È anche possibile utilizzare la seguente procedura manuale per abilitare l'accesso cluster per Amazon EMR su EKS.

1. **Creazione di un ruolo Kubernetes in uno spazio dei nomi specifico**

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

   Con Amazon EKS 1.22 - 1.29, esegui il comando seguente per creare un ruolo Kubernetes in uno spazio dei nomi specifico. Questo ruolo concede le necessarie autorizzazioni RBAC ad Amazon EMR su 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 e versioni precedenti, esegui il comando seguente per creare un ruolo Kubernetes in uno spazio dei nomi specifico. Questo ruolo concede le necessarie autorizzazioni RBAC ad Amazon EMR su 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. **Creazione dell'associazione di un ruolo Kubernetes allo spazio dei nomi**

   Esegui questo comando per creare l'associazione di un ruolo Kubernetes a uno spazio dei nomi specifico. Questa associazione di ruolo concede le autorizzazioni definite nel ruolo creato nel passaggio precedente a un utente denominato `emr-containers`. Questo utente identifica i [ruoli collegati ai servizi di Amazon EMR su EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html) e, di conseguenza, consente ad Amazon EMR su EKS di eseguire le operazioni definite dal ruolo che hai creato.

   ```
   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. **Aggiornamento della mappa di configurazione `aws-auth` di Kubernetes**

   Puoi utilizzare una delle seguenti opzioni per mappare il ruolo collegato ai servizi di Amazon EMR su EKS con l'utente `emr-containers` associato al ruolo Kubernetes nella fase precedente.

   **Opzione 1: usando `eksctl`**

   Esegui il comando `eksctl` seguente per mappare il ruolo collegato ai servizi di Amazon EMR su EKS con l'utente `emr-containers`.

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

   **Opzione 2: Senza utilizzare eksctl**

   1. Esegui il seguente comando per aprire la mappa di configurazione `aws-auth` nell'editor di testo. 

      ```
      kubectl edit -n kube-system configmap/aws-auth
      ```
**Nota**  
Se ricevi un messaggio di errore`Error from server (NotFound): configmaps "aws-auth" not found`, consulta la procedura in [Aggiungere ruoli utente](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) nella Guida per l'utente di Amazon EKS per applicare lo stock ConfigMap. 

   1. Aggiungi i dettagli del ruolo collegato ai servizi di Amazon EMR su EKS alla sezione `mapRoles` di `ConfigMap`, in `data`. Aggiungi questa sezione se non esiste già nel file. La sezione `mapRoles` aggiornata in dati ha l'aspetto seguente.

      ```
      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. Salva il file ed esci dall’editor di testo.

# Abilita IAM Roles per il cluster EKS
<a name="setting-up-enable-IAM-roles"></a>

I seguenti argomenti descrivono in dettaglio le opzioni per abilitare i ruoli IAM.

**Topics**
+ [Opzione 1: abilitare EKS Pod Identity sul cluster EKS](setting-up-enable-IAM.md)
+ [Opzione 2: abilitare IAM Roles for Service Accounts (IRSA) sul cluster EKS](setting-up-enable-IAM-service-accounts.md)

# Opzione 1: abilitare EKS Pod Identity sul cluster EKS
<a name="setting-up-enable-IAM"></a>

Le associazioni Amazon EKS Pod Identity offrono la possibilità di gestire le credenziali per le applicazioni, in modo simile a come i profili di istanza di Amazon EC2 forniscono le credenziali alle istanze Amazon EC2. Amazon EKS Pod Identity fornisce le credenziali per i tuoi carichi di lavoro con un'API EKS Auth aggiuntiva e un pod di agenti che viene eseguito su ogni nodo.

Amazon EMR su EKS inizia a supportare l'identità dei pod EKS dalla versione emr-7.3.0 per il modello di invio. StartJobRun 

Per ulteriori informazioni sulle identità dei pod EKS, consulta [Comprendere](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html) come funziona EKS Pod Identity.

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

Come parte della configurazione EMR, il Job Execution Role deve stabilire limiti di fiducia tra un ruolo IAM e gli account di servizio in uno spazio dei nomi specifico (di cluster virtuali EMR). Con IRSA, ciò è stato ottenuto aggiornando la politica di fiducia dell'EMR Job Execution Role. Tuttavia, a causa del limite massimo di 4096 caratteri alla lunghezza della policy di fiducia IAM, esisteva un vincolo alla condivisione di un singolo ruolo IAM Job Execution su un massimo di dodici (12) cluster EKS.

Con il supporto di EMR per Pod Identities, il confine di fiducia tra i ruoli IAM e gli account di servizio viene ora gestito dal team EKS tramite l'associazione di EKS pod identity. APIs

**Nota**  
Il limite di sicurezza per l'identità del pod EKS è ancora a livello di account di servizio, non a livello di pod.

## Considerazioni sull'identità dei pod
<a name="setting-up-enable-IAM-pod-identity-consider"></a>

Per informazioni sulle limitazioni relative all'identità dei Pod, consulta le [considerazioni relative all'identità di EKS Pod](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations).

## Prepara EKS Pod Identity in EKS Cluster
<a name="setting-up-enable-IAM-pod-eks-cluster"></a>

### Verifica se l'autorizzazione richiesta esiste in NodeInstanceRole
<a name="setting-up-enable-IAM-pod-eks-cluster-permission"></a>

Il ruolo del nodo `NodeInstanceRole` richiede l'autorizzazione dell'agente per eseguire l'`AssumeRoleForPodIdentity`azione nell'API di autenticazione EKS. Puoi aggiungere quanto segue ad [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy), definito nella Guida per l'utente di Amazon EKS, o utilizzare una politica personalizzata.

Se il tuo cluster EKS è stato creato con una versione eksctl successiva alla **0.181.0,** Amazon EKSWorkerNodePolicy, inclusa l'`AssumeRoleForPodIdentity`autorizzazione richiesta, verrà assegnato automaticamente al ruolo del nodo. Se l'autorizzazione non è presente, aggiungi manualmente la seguente autorizzazione ad Amazon EKSWorker NodePolicy che consente di assumere un ruolo per l'identità del pod. Questa autorizzazione è necessaria all'agente di identità dei pod EKS per recuperare le credenziali dei pod.

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

****  

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

------

### Crea il componente aggiuntivo EKS pod identity agent
<a name="setting-up-enable-IAM-pod-eks-cluster-agent"></a>

Usa il seguente comando per creare il componente aggiuntivo EKS Pod Identity Agent con la versione più 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'
```

Utilizza i seguenti passaggi per creare il componente aggiuntivo EKS Pod Identity Agent dalla console Amazon EKS:

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

1. Nel riquadro di navigazione a sinistra, seleziona **Cluster**, quindi scegli il nome del cluster per cui configurare il componente aggiuntivo di EKS Pod Identity Agent.

1. Selezionare la scheda **Componenti aggiuntivi**.

1. Scegli **Ottieni altri componenti aggiuntivi**.

1. Seleziona la casella nella parte superiore destra di quella del componente aggiuntivo relativo a EKS Pod Identity Agent e scegli **Avanti**.

1. Nella pagina **Configura le impostazioni dei componenti aggiuntivi selezionati**, seleziona una versione qualsiasi nell'elenco a discesa **Versione**.

1. (Facoltativo) Espandi **Impostazioni di configurazione facoltative** per inserire una configurazione aggiuntiva. Ad esempio, puoi fornire una posizione alternativa per l'immagine del container e `ImagePullSecrets`. Lo Schema JSON con le chiavi accettate sono mostrate in **Schema di configurazione del componente aggiuntivo**.

   Inserisci le chiavi e i valori di configurazione in **Valori di configurazione**.

1. Scegli **Next (Successivo)**.

1. Verifica che i pod dell'agente siano in esecuzione sul tuo cluster tramite la CLI.

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

Un esempio di output è il seguente:

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

Questo ne imposta uno nuovo DaemonSet nel `kube-system` namespace. Amazon EKS Pod Identity Agent, in esecuzione su ogni nodo EKS, utilizza l'[AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)azione per recuperare credenziali temporanee dall'API EKS Auth. Queste credenziali vengono quindi rese disponibili per l' AWS SDKs esecuzione all'interno dei contenitori.

Per ulteriori informazioni, consulta il prerequisito nel documento pubblico: [Configurazione di Amazon EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) Agent.

## Creare un ruolo Job Execution
<a name="setting-up-enable-IAM-pod-create-job-role"></a>

### Crea o aggiorna un ruolo di esecuzione del lavoro che consenta EKS Pod Identity
<a name="setting-up-enable-IAM-pod-create-job-role-update"></a>

Per eseguire carichi di lavoro con Amazon EMR su EKS, devi creare un ruolo IAM. Nella presente documentazione, tale ruolo viene definito ruolo di esecuzione di processo. Per ulteriori informazioni su come creare il ruolo IAM, consulta [Creazione di ruoli IAM nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) per l'utente.

Inoltre, è necessario creare una policy IAM che specifichi le autorizzazioni necessarie per il ruolo di esecuzione del lavoro e quindi allegare questa policy al ruolo per abilitare EKS Pod Identity.

Ad esempio, avete il seguente ruolo di esecuzione del lavoro. Per ulteriori informazioni, vedere [Creare un ruolo di esecuzione del lavoro](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 su EKS crea automaticamente account di servizio Kubernetes, in base al nome del ruolo di esecuzione del lavoro. Assicurati che il nome del ruolo non sia troppo lungo, poiché il lavoro potrebbe fallire se la combinazione di e `service_account_name` supera `cluster_name` il `pod_name` limite di lunghezza.

**Configurazione del ruolo di esecuzione** del lavoro: assicurati che il ruolo di esecuzione del lavoro sia creato con l'autorizzazione di fiducia seguente per EKS Pod Identity. Per aggiornare un ruolo di esecuzione del lavoro esistente, configuralo in modo che consideri attendibile il seguente principale del servizio EKS come autorizzazione aggiuntiva nella politica di fiducia. Questa autorizzazione di fiducia può coesistere con le politiche di trust IRSA esistenti.

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

**Autorizzazione utente**: gli utenti richiedono l'`iam:PassRole`autorizzazione per eseguire chiamate `StartJobRun` API o inviare lavori. Questa autorizzazione consente agli utenti di passare il ruolo di esecuzione del lavoro a EMR su EKS. Gli amministratori di Job devono disporre dell'autorizzazione per impostazione predefinita.

Di seguito è riportata l'autorizzazione necessaria per un utente:

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

Per limitare ulteriormente l'accesso degli utenti a cluster EKS specifici, aggiungi il filtro AssociatedResourceArn degli attributi alla policy IAM. Limita l'assunzione di ruoli ai cluster EKS autorizzati, rafforzando i controlli di sicurezza a livello di risorsa.

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

## Configura le associazioni di identità dei pod EKS
<a name="setting-up-enable-IAM-pod-identity-asociations"></a>

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

Assicurati che l'identità IAM che crea l'associazione di identità del pod, ad esempio un utente amministratore EKS, disponga dell'autorizzazione `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"
    }
  ]
}
```

------

### Creare associazioni per il ruolo e l'account del servizio EMR
<a name="setting-up-enable-IAM-pod-identity-asociations-emr-service"></a>

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

Quando invii un lavoro a un namespace Kubernetes, un amministratore deve creare associazioni tra il ruolo di esecuzione del lavoro e l'identità dell'account del servizio gestito EMR. Ricorda che l'account di servizio gestito da EMR viene creato in automatico all'invio del processo, nell'ambito dello spazio dei nomi in cui viene inviato il processo.

Con la AWS CLI (precedente versione 2.24.0), esegui il comando seguente per creare associazioni di ruoli con l'identità del pod.

Esegui il comando seguente per creare associazioni di ruoli con l'identità del pod:

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

Nota:
+ Ogni cluster può avere un limite di 1.000 associazioni. La mappatura di ogni ruolo di esecuzione del lavoro (namespace) richiederà 3 associazioni per i pod Job Submitter, Driver ed Executor.
+ È possibile associare solo ruoli che si trovano nello stesso account del cluster. AWS È possibile delegare l'accesso da un altro account al ruolo di questo account configurato per l'utilizzo delle associazioni EKS Pod Identity. Per un tutorial sulla delega dell'accesso e`AssumeRole`, consulta il [tutorial IAM: delega l'accesso tra AWS account utilizzando i ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html).

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

EMR crea un account di servizio con un determinato schema di denominazione quando viene inviato un lavoro. Per creare associazioni manuali o integrare questo flusso di lavoro con l' AWS SDK, procedi nel seguente modo:

Costruisci il nome dell'account del servizio:

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

Gli esempi seguenti creano un'associazione di ruoli per un ruolo di Job execution di esempio JobExecutionRoleIRSAv2.

**Esempi di associazioni di ruoli:**

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

**Esempio di 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
```

------

Dopo aver completato tutti i passaggi richiesti per l'identità del pod EKS, puoi saltare i seguenti passaggi per la configurazione IRSA:
+ [Abilita IAM Roles for Service Accounts (IRSA) sul cluster EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html)
+ [Crea un ruolo di esecuzione del lavoro](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)
+ [Aggiorna la politica di fiducia del ruolo di esecuzione del lavoro](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html)

Puoi passare direttamente al passaggio seguente: [Concedi agli utenti l'accesso ad Amazon EMR su EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html)

## Elimina le associazioni di ruoli
<a name="setting-up-enable-IAM-pod-identity-asociations-delete-associations"></a>

Ogni volta che si elimina un cluster virtuale o un ruolo di esecuzione del lavoro e non si desidera più concedere l'accesso a EMR ai relativi account di servizio, è necessario eliminare le associazioni per il ruolo. Questo perché EKS consente associazioni con risorse inesistenti (namespace e account di servizio). Amazon EMR su EKS consiglia di eliminare le associazioni se lo spazio dei nomi viene eliminato o il ruolo non è più in uso, per liberare spazio per altre associazioni.

**Nota**  
Le associazioni persistenti potrebbero potenzialmente influire sulla tua capacità di scalabilità se non le elimini, poiché EKS ha dei limiti sul numero di associazioni che puoi creare (limite minimo: 1000 associazioni per cluster). Puoi elencare le associazioni di identità dei pod in un determinato namespace per verificare se ci sono associazioni persistenti che devono essere ripulite:

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

Con AWS CLI (versione 2.24.0 o successiva), esegui il seguente comando emr-containers per eliminare le associazioni di ruolo di EMR:

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

## Migra automaticamente l'IRSA esistente su Pod Identity
<a name="setting-up-enable-IAM-pod-identity-auto-migrate"></a>

Puoi utilizzare lo strumento eksctl per migrare gli IAM Roles for Service Accounts (IRSA) esistenti alle associazioni di identità pod:

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

L'esecuzione del comando senza il `--approve` flag produrrà solo un piano che riflette le fasi della migrazione e non si verificherà alcuna migrazione effettiva.

## Risoluzione dei problemi
<a name="setting-up-enable-IAM-pod-identity-troubleshooting"></a>

### Il mio lavoro non è riuscito con NoClassDefinitionFound ClassNotFound Exception for Credentials Provider o non sono riuscito a ottenere il provider di credenziali.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-no-class"></a>

EKS Pod Identity utilizza il Container Credentials Provider per recuperare le credenziali necessarie. Se hai specificato un provider di credenziali personalizzato, assicurati che funzioni correttamente. In alternativa, assicurati di utilizzare una versione AWS SDK corretta che supporti EKS Pod Identity. Per ulteriori informazioni, consulta la sezione [Introduzione ad Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

### Job non riuscito con l'errore «Impossibile recuperare le credenziali a causa di [x] Size Limit» visualizzato nel eks-pod-identity-agent registro.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds"></a>

EMR su EKS crea account di servizio Kubernetes in base al nome del ruolo di esecuzione del lavoro. Se il nome del ruolo è troppo lungo, EKS Auth non riuscirà a recuperare le credenziali perché la combinazione di e supera il limite di `cluster_name` lunghezza. `pod_name` `service_account_name` Identifica quale componente occupa più spazio e regola le dimensioni di conseguenza.

### Job non riuscito con l'errore «Failed to Retrieve Credentials xxx» visualizzato nel eks-pod-identity registro.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds-error"></a>

Una possibile causa di questo problema potrebbe essere che il cluster EKS è configurato in sottoreti private senza una configurazione PrivateLink corretta per il cluster. Verifica se il cluster si trova in una rete privata e configuralo AWS PrivateLink per risolvere il problema. Per istruzioni dettagliate, consulta la sezione Guida [introduttiva ad Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

# Opzione 2: abilitare IAM Roles for Service Accounts (IRSA) sul cluster EKS
<a name="setting-up-enable-IAM-service-accounts"></a>

La funzionalità dei ruoli IAM per gli account di servizio è disponibile per i nuovi cluster Amazon EKS con Kubernetes versione 1.14 e successiva e per i cluster EKS aggiornati alle versioni 1.13 o successiva dopo il 3 settembre 2019 incluso. Per poter utilizzare questa funzionalità, puoi aggiornare i cluster EKS esistenti alla versione 1.14 o successiva. Per ulteriori informazioni, consulta [Aggiornamento di una versione Kubernetes del cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).

Se supporta i ruoli IAM per gli account di servizio, il cluster è associato a un URL dell'emittente [OpenID Connect](https://openid.net/connect/). Puoi visualizzare questo URL nella console Amazon EKS oppure puoi utilizzare il seguente AWS CLI comando per recuperarlo.

**Importante**  
È necessario utilizzare la versione più recente di AWS CLI per ricevere l'output corretto da questo comando.

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

L'output previsto è il seguente:

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

Per utilizzare i ruoli IAM per gli account di servizio nel cluster è necessario creare un provider di identità OIDC utilizzando [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) o la [Console di gestione AWS](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console).

## Creazione di un provider di identità IAM OIDC per il cluster con `eksctl`
<a name="setting-up-OIDC-eksctl"></a>

Controlla la versione della `eksctl` con il comando seguente. Questa procedura presuppone che `eksctl` sia installato e che la versione di `eksctl` sia 0.32.0 o successiva.

```
eksctl version
```

Per ulteriori informazioni sull'installazione o sull'aggiornamento di eksctl, consulta [Installazione o aggiornamento di eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl).

Crea il provider di identità OIDC per il cluster con il comando seguente. Sostituire *cluster\$1name* con il proprio valore.

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

## Per creare un provider di identità IAM OIDC per il cluster con Console di gestione AWS
<a name="setting-up-OIDC-console"></a>

Recupera l'URL dell'emittente OIDC dalla descrizione della console Amazon EKS del cluster o usa il seguente comando. AWS CLI 

Utilizza il seguente comando per recuperare l'URL dell'emittente OIDC dalla AWS CLI.

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

Utilizza la seguente procedura per recuperare l'URL dell'emittente OIDC dalla console Amazon EKS. 

1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Nel pannello di navigazione, scegli **Identity Providers (Provider di identità)**, quindi seleziona **Create Provider (Crea provider)**.

   1. Per **Tipo di provider**, seleziona **Scegli un tipo di provider** e quindi **OpenID Connect**.

   1. Per **URL provider**, incolla l'URL dell'emittente OIDC del cluster.

   1. Per Audience (Pubblico), digita sts.amazonaws.com e scegli **Next Step (Fase successiva)**.

1. Verifica che le informazioni del provider siano corrette, quindi seleziona **Crea** per creare il provider di identità.

# Creazione di un ruolo di esecuzione di processo
<a name="creating-job-execution-role"></a>

Per eseguire carichi di lavoro su Amazon EMR su EKS, occorre creare un ruolo IAM. Nella presente documentazione, tale ruolo viene definito *ruolo di esecuzione di processo*. Per ulteriori informazioni su come creare ruoli IAM, consulta [Creazione di ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) nella Guida per l'utente IAM. 

È necessario anche creare una policy IAM che specifichi le autorizzazioni per il ruolo di esecuzione di processo e, successivamente, collegare la policy IAM al ruolo di esecuzione di processo. 

La seguente politica per il ruolo di esecuzione del lavoro consente l'accesso a destinazioni di risorse, Amazon S3 e. CloudWatch Queste autorizzazioni sono necessarie per monitorare i processi e i log di accesso. Per seguire la stessa procedura, utilizza: AWS CLI

Creazione del ruolo IAM per l'esecuzione del lavoro: creiamo il ruolo che EMR utilizzerà per l'esecuzione del lavoro. Questo è il ruolo che i lavori EMR assumeranno quando verranno eseguiti su 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
```

Successivamente, dobbiamo collegare le politiche IAM richieste al ruolo in modo che possa scrivere i log su s3 e 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**  
L'accesso deve essere compreso in modo appropriato, non concesso a tutti gli oggetti S3 nel ruolo di esecuzione di processo.

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

------

Per ulteriori informazioni, consulta [Usare i ruoli di esecuzione dei job](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html), [Configurare un job run per utilizzare i log di S3 e [Configurare un](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch) job run per usare Logs](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3). CloudWatch 

# Aggiornamento della policy di affidabilità del ruolo di esecuzione di processo
<a name="setting-up-trust-policy"></a>

Quando si utilizzano ruoli IAM per gli account di servizio (IRSA) per eseguire processi in uno spazio dei nomi Kubernetes, un amministratore deve creare una relazione di fiducia tra il ruolo di esecuzione di processo e l'identità dell'account del servizio gestito da EMR. La relazione di fiducia può essere creata aggiornando la policy di affidabilità del ruolo di esecuzione di processo. Ricorda che l'account di servizio gestito da EMR viene creato in automatico all'invio del processo, nell'ambito dello spazio dei nomi in cui viene inviato il processo.

Per aggiornare la policy di affidabilità, esegui il comando seguente:

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

Per ulteriori informazioni, consulta [Uso dei ruoli di esecuzione di processo con Amazon EMR su EKS](iam-execution-role.md).

**Importante**  
L'operatore che esegue il comando precedente deve disporre delle seguenti autorizzazioni: `eks:DescribeCluster`, `iam:GetRole` e `iam:UpdateAssumeRolePolicy`.

# Concessione dell'accesso ad Amazon EMR su EKS agli utenti
<a name="setting-up-iam"></a>

Per qualsiasi azione eseguita su Amazon EMR su EKS, occorre disporre di un'autorizzazione IAM corrispondente. Innanzitutto, dovrai creare una policy IAM che ti permetta di eseguire le azioni di Amazon EMR su EKS e di allegare la policy all'utente o al ruolo IAM che utilizzi. 

In questo argomento vengono illustrate le fasi per la creazione di una nuova policy e il relativo collegamento a un utente. Inoltre, vengono elencate le autorizzazioni di base necessarie per configurare l'ambiente Amazon EMR su EKS. Consigliamo di perfezionare le autorizzazioni a risorse specifiche ove possibile in base alle esigenze aziendali.

## Creazione di una nuova policy IAM e collegamento della stessa a un utente nella console IAM
<a name="setting-up-iam-console"></a>

**Creazione di una nuova policy IAM**

1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)

1. Nel pannello di navigazione della console IAM seleziona **Policy**.

1. Nella pagina **Policy**, scegli **Crea policy**.

1. Nella finestra **Crea policy**, vai alla scheda **Modifica JSON**. Crea un documento di policy con una o più istruzioni JSON, come illustrato negli esempi che seguono questa procedura. Poi, scegli **Verifica policy**.

1. Nella schermata **Verifica policy**, inserisci il **Nome policy**, ad esempio `AmazonEMROnEKSPolicy`. Immetti una descrizione facoltativa e quindi seleziona **Crea policy**. 

**Collegamento della policy a un utente o ruolo**

1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 

1. Nel pannello di navigazione, seleziona **Policy**.

1. Nell'elenco di policy, seleziona la casella di spunta accanto alla policy creata nella sezione precedente. Puoi utilizzare il menu **Filtro** e la casella di ricerca per filtrare l'elenco di policy. 

1. Scegli **Operazioni di policy**, quindi **Collega**.

1. Seleziona l'utente o il ruolo a cui desideri collegare la policy. Puoi usare il menu **Filtro** e la casella di ricerca per filtrare l'elenco delle entità principali. Dopo aver scelto l'utente o il ruolo a cui collegare la policy, scegli **Collega policy**.

## Autorizzazioni per la gestione dei cluster virtuali
<a name="permissions-virtual-cluster"></a>

Per gestire i cluster virtuali nel tuo AWS account, crea una policy IAM con le seguenti autorizzazioni. Queste autorizzazioni ti consentono di creare, elencare, descrivere ed eliminare i cluster virtuali nel tuo account. AWS 

------
#### [ 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 è integrato con Amazon EKS Cluster Access Management (CAM), quindi puoi automatizzare la configurazione delle policy AuthN e AuthZ necessarie per eseguire i job Amazon EMR Spark nei namespace dei cluster Amazon EKS. A tale scopo, devi disporre delle seguenti autorizzazioni:

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

Per ulteriori informazioni, consulta [Automatizzare l'abilitazione dell'accesso ai cluster per Amazon EMR su](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-cam-integration) EKS.

Quando l'`CreateVirtualCluster`operazione viene richiamata per la prima volta da un AWS account, sono necessarie anche le `CreateServiceLinkedRole` autorizzazioni per creare il ruolo collegato al servizio per Amazon EMR su EKS. Per ulteriori informazioni, consulta [Utilizzo di ruoli collegati ai servizi per Amazon EMR su EKS](using-service-linked-roles.md). 

## Autorizzazioni per inviare i processi
<a name="permissions-submitting-jobs"></a>

Per inviare lavori sui cluster virtuali del tuo AWS account, crea una policy IAM con le seguenti autorizzazioni. Queste autorizzazioni ti consentono di avviare, elencare, descrivere ed annullare esecuzioni di processo per tutti i cluster virtuali nel tuo account. È consigliabile aggiungere autorizzazioni per elencare o descrivere cluster virtuali, il che ti consente di controllare lo stato del cluster virtuale prima di inviare i processi.

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

****  

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

------

## Autorizzazioni per il debug e il monitoraggio
<a name="permissions-debugging-monitoring"></a>

Per accedere ai log inviati ad Amazon S3 CloudWatch o per visualizzare i registri degli eventi delle applicazioni nella console Amazon EMR, crea una policy IAM con le seguenti autorizzazioni. Consigliamo di perfezionare le autorizzazioni a risorse specifiche quando possibile in base alle esigenze aziendali.

**Importante**  
Se non hai creato un bucket Amazon S3, dovrai aggiungere l'autorizzazione `s3:CreateBucket` per la dichiarazione di policy. Se non hai creato un gruppo di log, dovrai aggiungere `logs:CreateLogGroup` alla dichiarazione di policy.

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

------

Per ulteriori informazioni su come configurare l'esecuzione di un job per inviare i log ad Amazon S3 CloudWatch e, [consulta Configurare un job run per utilizzare i log S3](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) [e Configurare un job](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch) run to use Logs. CloudWatch 

# Registrazione del cluster Amazon EKS con Amazon EMR
<a name="setting-up-registration"></a>

La registrazione del cluster è l'ultimo passaggio necessario per configurare Amazon EMR su EKS per l'esecuzione dei carichi di lavoro.

Utilizza il comando seguente per creare un cluster virtuale con un nome a scelta per lo spazio dei nomi e il cluster Amazon EKS impostati nelle fasi precedenti.

**Nota**  
Ogni cluster virtuale deve avere un nome univoco in tutti i cluster EKS. Se due cluster virtuali hanno lo stesso nome, il processo di implementazione non riuscirà anche se i due cluster virtuali appartengono a cluster EKS diversi. 

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

In alternativa, puoi creare un file JSON che includa i parametri richiesti per il cluster virtuale e, successivamente, eseguire il comando `create-virtual-cluster` con il percorso del file JSON. Per ulteriori informazioni, consulta [Gestione dei cluster virtuali](virtual-cluster.md).

**Nota**  
Per convalidare la corretta creazione di un cluster virtuale, visualizza lo stato dei cluster virtuali utilizzando l'operazione `list-virtual-clusters` o andando alla pagina **Virtual Clusters (Cluster virtuali)** nella console di Amazon EMR. 

# Invio di un'esecuzione di processo con `StartJobRun`
<a name="emr-eks-jobs-submit"></a>

**Invio di un'esecuzione di processo mediante un file JSON con parametri specificati**

1. Crea un file `start-job-run-request.json` e specifica i parametri richiesti per l'esecuzione di processo, come illustrato nel file JSON di esempio seguente. Per ulteriori informazioni sui parametri, consulta [Opzioni per la configurazione di un'esecuzione di processo](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. Utilizza il comando `start-job-run` con un percorso per il file `start-job-run-request.json` archiviato localmente.

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

**Avvio di un'esecuzione di processo con il comando `start-job-run`**

1. Fornisci tutti i parametri specificati nel comando `StartJobRun`, come illustrato nell'esempio seguente.

   ```
   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. Per Spark SQL, fornisci tutti i parametri specificati nel comando `StartJobRun`, come illustrato nell'esempio seguente.

   ```
   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 della classificazione del mittente di processi
<a name="emr-eks-job-submitter"></a>

## Panoramica di
<a name="emr-eks-job-submitter-overview"></a>

La richiesta `StartJobRun` di Amazon EMR su EKS crea un pod del *mittente di processi* (noto anche come pod *job-runner*) per generare il driver Spark. È possibile utilizzare la `emr-job-submitter` classificazione per configurare i selettori di nodi, aggiungere tolleranze, personalizzare la registrazione e apportare altre modifiche al pod job submitter.

Le seguenti impostazioni sono disponibili nella classificazione: `emr-job-submitter`

** `jobsubmitter.node.selector.[selectorKey]` **  
Si aggiunge al selettore di nodi del pod job submitter, con key *selectorKey* e value come valore di configurazione. Ad esempio, puoi impostare su `myIdentifier` e ` jobsubmitter.node.selector.identifier` il pod job submitter avrà un selettore di nodi con una chiave e un valore. `identifier` `myIdentifier` Questo può essere usato per specificare su quali nodi può essere posizionato il pod Job Submitter. Per aggiungere più chiavi di selettore di nodi, imposta più configurazioni con questo prefisso.

** `jobsubmitter.label.[labelKey]` **  
Si aggiunge alle etichette del pod job submitter, con key *labelKey* e the value come valore di configurazione. Per aggiungere più etichette, imposta più configurazioni con questo prefisso.

** `jobsubmitter.annotation.[annotationKey]` **  
Si aggiunge alle annotazioni del pod job submitter, con key *annotationKey* e the value come valore di configurazione. Per aggiungere più annotazioni, imposta più configurazioni con questo prefisso.

** `jobsubmitter.node.toleration.[tolerationKey]` **  
Aggiunge [tolleranze](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) al contenitore Job Submitter. Per impostazione predefinita, non vengono aggiunte tolleranze al pod. La chiave della tolleranza sarà *tolerationKey* e il valore della tolleranza sarà il valore di configurazione. Se il valore di configurazione è impostato su una stringa non vuota, l'operatore lo sarà. `Equals` Se il valore di configurazione è impostato su`""`, l'operatore lo sarà`Exists`.

** `jobsubmitter.node.toleration.[tolerationKey].[effect]` **  
Aggiunge un effetto di tolleranza al prefisso*tolerationKey*. Questo campo è obbligatorio quando si aggiungono tolleranze. I valori consentiti per il campo dell'effetto sono ` NoExecute``NoSchedule`, e`PreferNoSchedule`.

** `jobsubmitter.node.toleration.[tolerationKey].[tolerationSeconds]` **  
Aggiunge TolerationSeconds al prefisso. *tolerationKey* Campo opzionale. Applicabile solo quando l'effetto è`NoExecute`.

** `jobsubmitter.scheduler.name` **  
Imposta un SchedulerName personalizzato per il pod job submitter.

** `jobsubmitter.logging` **  
Abilita o disabilita la registrazione sul pod Job Submitter. Quando è impostato su, ` DISABLED` il contenitore di registrazione viene rimosso dal pod job submitter, il che disabiliterà qualsiasi registrazione per questo pod specificata in, ad esempio o. `monitoringConfiguration` `s3MonitoringConfiguration` `cloudWatchMonitoringConfiguration` Quando questa impostazione non è impostata o è impostata su un altro valore, la registrazione sul pod job submitter è abilitata.

** `jobsubmitter.logging.image` **  
Imposta un'immagine personalizzata da utilizzare per il contenitore di registrazione nel pod job submitter.

** `jobsubmitter.logging.request.cores` **  
Imposta un valore personalizzato per il numero di CPUs, in unità CPU, per il contenitore di registrazione sul pod job submitter. **Per impostazione predefinita, questo valore è impostato su 100 m.**

** `jobsubmitter.logging.request.memory` **  
Imposta un valore personalizzato per la quantità di memoria, in byte, per il contenitore di registrazione nel pod job submitter. **Per impostazione predefinita, questo valore è impostato su 200 Mi.** Un mebibyte è un'unità di misura simile a un megabyte.

** `jobsubmitter.container.image` **  
Imposta un'immagine personalizzata per il contenitore del pod job submitter. `job-runner`

** `jobsubmitter.container.image.pullPolicy` **  
Imposta [imagePullPolicy](https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy)i contenitori del pod job submitter.

Consigliamo di posizionare i job submitter pod su istanze On-Demand. L'inserimento dei pod Job Submitter sulle istanze Spot potrebbe causare un errore del lavoro se l'istanza su cui viene eseguito il pod Job Submitter è soggetta a un'interruzione dell'istanza Spot. Puoi anche [posizionare il pod job submitter in un'unica zona di disponibilità o utilizzare qualsiasi](#emr-eks-job-submitter-ex-ec2) etichetta Kubernetes applicata ai nodi.

## Esempi di classificazione del mittente di processi
<a name="emr-eks-job-submitter-examples"></a>

**Topics**
+ [Richiesta `StartJobRun` con posizionamento dei nodi on demand per il pod del mittente di processi](#emr-eks-job-submitter-ex-od)
+ [`StartJobRun`richiesta con posizionamento del nodo Single-AZ e posizionamento del tipo di istanza Amazon EC2 per il pod Job Submitter](#emr-eks-job-submitter-ex-ec2)
+ [`StartJobRun`richiesta con etichette, annotazioni e uno scheduler personalizzato per il pod Job Submitter](#emr-eks-job-submitter-label-annotation-scheduler)
+ [`StartJobRun`richiesta con una tolleranza applicata al pod Job Submitter con chiave`dedicated`, valore `graviton_machines``NoExecute`, effetto e una di 60 secondi `tolerationSeconds`](#emr-eks-job-submitter-tolerations)
+ [`StartJobRun`richiesta con registrazione disabilitata per il pod job submitter](#emr-eks-job-submitter-logging-disabled)
+ [`StartJobRun`richiesta con immagine del contenitore di registrazione personalizzata, CPU e memoria per il pod job submitter](#emr-eks-job-submitter-custom)
+ [`StartJobRun`richiesta con un'immagine del contenitore Job Submitter e una policy pull personalizzate](#emr-eks-job-submitter-custom-container)

### Richiesta `StartJobRun` con posizionamento dei nodi on demand per il pod del mittente di processi
<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`richiesta con posizionamento del nodo Single-AZ e posizionamento del tipo di istanza Amazon EC2 per il pod Job Submitter
<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`richiesta con etichette, annotazioni e uno scheduler personalizzato per il pod Job Submitter
<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`richiesta con una tolleranza applicata al pod Job Submitter con chiave`dedicated`, valore `graviton_machines``NoExecute`, effetto e una di 60 secondi `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`richiesta con registrazione disabilitata per il pod job submitter
<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`richiesta con immagine del contenitore di registrazione personalizzata, CPU e memoria per il pod job submitter
<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`richiesta con un'immagine del contenitore Job Submitter e una policy pull personalizzate
<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"
      }
    }
  ]
}
```

# Utilizzo della classificazione delle impostazioni predefinite dei container Amazon EMR
<a name="emr-eks-job-submitter-container-defaults"></a>

## Panoramica di
<a name="emr-eks-job-submitter-container-defaults-overview"></a>

Le seguenti impostazioni sono disponibili nella classificazione: `emr-containers-defaults`

** `job-start-timeout` **  
Per impostazione predefinita, un processo scade se non può essere avviato e rimane nello ` SUBMITTED` stato per 15 minuti. Questa configurazione modifica il numero di secondi di attesa prima del timeout del processo.

** `executor.logging` **  
Abilita o disabilita la registrazione sugli executor pod. Quando questa opzione è impostata su, ` DISABLED` il contenitore di registrazione viene rimosso dai pod dell'executor, il che disabiliterà qualsiasi registrazione per questi pod specificati in, ad esempio o. `monitoringConfiguration` `s3MonitoringConfiguration` `cloudWatchMonitoringConfiguration` Quando questa impostazione non è impostata o è impostata su un altro valore, la registrazione sugli executor pod è abilitata.

** `logging.image` **  
Imposta un'immagine personalizzata da utilizzare per il contenitore di registrazione sui pod del driver e dell'executor.

** `logging.request.cores` **  
Imposta un valore personalizzato per il numero di CPUs, in unità CPU, per il contenitore di registrazione sui driver e sui pod dell'executor. Per impostazione predefinita, questo valore non è impostato.

** `logging.request.memory` **  
Imposta un valore personalizzato per la quantità di memoria, in byte, per il contenitore di registrazione sui pod driver e executor. **Per impostazione predefinita, questo valore è impostato su 512 Mi.** Un mebibyte è un'unità di misura simile a un megabyte.

## Esempi di classificazione del mittente di processi
<a name="emr-eks-job-submitter-container-examples"></a>

**Topics**
+ [`StartJobRun`richiesta con timeout di lavoro personalizzato](#emr-eks-job-submitter-container-custom-timeout)
+ [`StartJobRun`richiesta con registrazione disabilitata per gli executor pod](#emr-eks-executor-logging-disabled)
+ [`StartJobRun`richiesta con immagine del contenitore di registrazione personalizzata, CPU e memoria per i driver e gli executor pod](#emr-eks-job-submitter-container-custom-image-cpu)

### `StartJobRun`richiesta con timeout di lavoro personalizzato
<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`richiesta con registrazione disabilitata per gli executor pod
<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`richiesta con immagine del contenitore di registrazione personalizzata, CPU e memoria per i driver e gli executor pod
<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"
    }
  }
}
```