Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Exécution de tâches Spark avec Amazon EMR sur EKS
<a name="job-runs-main"></a>

Une *exécution de tâche* est une unité de travail, telle qu'un fichier JAR, un PySpark script ou une requête SparkSQL Spark, que vous soumettez à Amazon EMR sur EKS. Cette rubrique fournit une vue d'ensemble de la gestion des exécutions de tâches à l'aide de la console Amazon EMR AWS CLI, de l'affichage des exécutions de tâches à l'aide de la console Amazon EMR et de la résolution des erreurs courantes d'exécution de tâches.

Notez que vous ne pouvez pas exécuter de tâches IPv6 Spark sur Amazon EMR sur EKS

**Note**  
Avant de soumettre une tâche exécutée à l'aide d'Amazon EMR on EKS, vous devez effectuer les étapes décrites dans la rubrique [Configuration d'Amazon EMR on EKS](setting-up.md).

**Topics**
+ [Exécution de tâches Spark avec `StartJobRun`](job-runs.md)
+ [Exécution de tâches Spark à l'aide de l'opérateur Spark](spark-operator.md)
+ [Exécution de tâches Spark en utilisant spark-submit](spark-submit.md)
+ [Utilisation d'Apache Livy avec Amazon EMR sur EKS](job-runs-apache-livy.md)
+ [Gestion des exécutions de tâches sur Amazon EMR on EKS](emr-eks-jobs-manage.md)
+ [Utilisation des modèles de tâche](job-templates.md)
+ [Utilisation de modèles de pods](pod-templates.md)
+ [Utilisation des politiques de relance des tâches](jobruns-using-retry-policies.md)
+ [Utilisation de la rotation des journaux des événements Spark](emr-eks-log-rotation.md)
+ [Utilisation de la rotation des journaux des conteneurs Spark](emr-eks-log-rotation-container.md)
+ [Utilisation de la mise à l'échelle automatique verticale avec les tâches Spark sur Amazon EMR](jobruns-vas.md)

# Exécution de tâches Spark avec `StartJobRun`
<a name="job-runs"></a>

Cette section inclut des étapes de configuration détaillées pour préparer votre environnement à exécuter des tâches Spark, puis fournit des step-by-step instructions pour soumettre une exécution de tâche avec des paramètres spécifiés.

**Topics**
+ [Configuration d'Amazon EMR on EKS](setting-up.md)
+ [Soumission d'une tâche exécutée avec `StartJobRun`](emr-eks-jobs-submit.md)
+ [Utilisation de la classification des soumissionnaires de tâches](emr-eks-job-submitter.md)
+ [Utilisation de la classification par défaut des conteneurs Amazon EMR](emr-eks-job-submitter-container-defaults.md)

# Configuration d'Amazon EMR on EKS
<a name="setting-up"></a>

Effectuez les tâches suivantes pour vous préparer à utiliser Amazon EMR on EKS. Si vous êtes déjà inscrit à Amazon Web Services (AWS) et que vous utilisez Amazon EKS, vous êtes presque prêt à utiliser Amazon EMR on EKS. Ignorez toutes les tâches que vous avez déjà effectuées.

**Note**  
Vous pouvez également suivre l'[atelier Amazon EMR on EKS](https://emr-on-eks.workshop.aws/amazon-emr-eks-workshop.html) pour configurer toutes les ressources nécessaires à l'exécution des tâches Spark sur Amazon EMR on EKS. L'atelier fournit également une automatisation en utilisant des CloudFormation modèles pour créer les ressources nécessaires à votre démarrage. Pour d'autres modèles et meilleures pratiques, consultez notre [guide des meilleures pratiques en matière de conteneurs EMR](https://aws.github.io/aws-emr-containers-best-practices/) sur. GitHub

1. [Installez ou mettez à jour vers la dernière version du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)

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

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

1. [Activer l'accès au cluster pour Amazon EMR sur EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html)

1. [Activer les rôles IAM pour le cluster EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM-roles.html)

1. [Autorisation des utilisateurs à accéder à Amazon EMR on EKS](setting-up-iam.md)

1. [Enregistrement du cluster Amazon EKS dans Amazon EMR](setting-up-registration.md)

# Activation de l'accès aux clusters pour Amazon EMR on EKS
<a name="setting-up-cluster-access"></a>

Les sections suivantes présentent deux manières d'activer l'accès au cluster. La première consiste à utiliser la gestion de l'accès au cluster (CAM) d'Amazon EKS et la seconde montre comment effectuer des étapes manuelles pour activer l'accès au cluster.

## Activer l'accès au cluster à l'aide d'EKS Access Entry (recommandé)
<a name="setting-up-cluster-access-cam-integration"></a>

**Note**  
`aws-auth` ConfigMap est obsolète. [La méthode recommandée pour gérer l'accès à Kubernetes APIs est celle des entrées d'accès.](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)

Amazon EMR est intégré à la [gestion des accès aux clusters (CAM) d'Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html), ce qui vous permet d'automatiser la configuration des politiques AuthN et AuthZ nécessaires pour exécuter des tâches Amazon EMR Spark dans les espaces de noms des clusters Amazon EKS. Lorsque vous créez un cluster virtuel à partir d'un espace de noms de cluster Amazon EKS, Amazon EMR configure automatiquement toutes les autorisations nécessaires, de sorte que vous n'avez pas besoin d'ajouter d'étapes supplémentaires à vos flux de travail actuels.

**Note**  
L'intégration d'Amazon EMR à Amazon EKS CAM n'est prise en charge que pour les nouveaux clusters virtuels Amazon EMR on EKS. Vous ne pouvez pas migrer des clusters virtuels existants pour utiliser cette intégration.

### Conditions préalables
<a name="setting-up-cluster-access-cam-integration-prereqs"></a>
+ Assurez-vous que vous utilisez la version 2.15.3 ou supérieure du AWS CLI
+ Votre cluster Amazon EKS doit être doté de la version 1.23 ou supérieure.

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

Pour configurer l'intégration entre Amazon EMR et les opérations d' AccessEntry API d'Amazon EKS, assurez-vous d'avoir effectué les étapes suivantes :
+ Assurez-vous que celui `authenticationMode` de votre cluster Amazon EKS est défini sur`API_AND_CONFIG_MAP`.

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

  Si ce n'est pas déjà le cas, réglez-le `authenticationMode` sur`API_AND_CONFIG_MAP`.

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

  Pour plus d'informations sur les modes d'authentification, consultez la section Modes [d'authentification de cluster](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html#authentication-modes).
+ Assurez-vous que le [rôle IAM](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html) que vous utilisez pour exécuter les opérations `CreateVirtualCluster` et `DeleteVirtualCluster` API dispose également des autorisations suivantes :

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

### Concepts et terminologie
<a name="setting-up-cluster-access-cam-integration-concepts"></a>

Vous trouverez ci-dessous une liste de terminologies et de concepts liés à Amazon EKS CAM.
+ Cluster virtuel (VC) : représentation logique de l'espace de noms créé dans Amazon EKS. Il s'agit d'un lien 1:1 vers un espace de noms de cluster Amazon EKS. Vous pouvez l'utiliser pour exécuter des charges de travail Amazon EMR sur un cluster Amazon EKS au sein de l'espace de noms spécifié.
+ Namespace : mécanisme permettant d'isoler des groupes de ressources au sein d'un seul cluster EKS.
+ Politique d'accès : autorisations qui accordent l'accès et les actions à un rôle IAM au sein d'un cluster EKS.
+ Entrée d'accès : entrée créée à l'aide d'un rôle arn. Vous pouvez lier l'entrée d'accès à une politique d'accès pour attribuer des autorisations spécifiques dans le cluster Amazon EKS.
+ Cluster virtuel intégré d'entrée d'accès EKS : cluster virtuel créé [à l'aide des opérations d'API d'entrée d'accès](https://docs.aws.amazon.com/eks/latest/APIReference/API_Operations_Amazon_Elastic_Kubernetes_Service.html) d'Amazon EKS.

## Activez l'accès au cluster en utilisant `aws-auth`
<a name="setting-up-cluster-access-aws-auth"></a>

Vous devez autoriser Amazon EMR on EKS à accéder à un espace de noms spécifique de votre cluster en effectuant les actions suivantes : créer un rôle Kubernetes, lier le rôle à un utilisateur Kubernetes et associer l'utilisateur Kubernetes au rôle lié au service [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). Ces actions sont automatisées dans `eksctl` lorsque la commande de mappage d'identité IAM est utilisée avec `emr-containers` comme nom de service. Vous pouvez effectuer ces opérations facilement à l'aide de la commande suivante.

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

*my\$1eks\$1cluster*Remplacez-le par le nom de votre cluster Amazon EKS et remplacez-le par l'espace *kubernetes\$1namespace* de noms Kubernetes créé pour exécuter les charges de travail Amazon EMR. 

**Important**  
Vous devez télécharger la dernière version d'eksctl en suivant l'étape précédente. [Configurez kubectl et eksctl pour](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) utiliser cette fonctionnalité. 

### Étapes manuelles à suivre pour activer l'accès aux clusters pour Amazon EMR on EKS
<a name="setting-up-cluster-access-manual"></a>

Vous pouvez également suivre les étapes manuelles ci-dessous pour activer l'accès aux clusters pour Amazon EMR on EKS.

1. **Création d'un rôle Kubernetes dans un espace de noms spécifique**

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

   Avec Amazon EKS 1.22 - 1.29, exécutez la commande suivante pour créer un rôle Kubernetes dans un espace de noms spécifique. Ce rôle accorde les autorisations RBAC nécessaires à Amazon EMR on 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 ]

   À l'aide d'Amazon EKS en version 1.21 et inférieure, exécutez la commande suivante pour créer un rôle Kubernetes dans un espace de noms spécifique. Ce rôle accorde les autorisations RBAC nécessaires à Amazon EMR on 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. **Création d'une liaison de rôle Kubernetes adaptée à l'espace de noms**

   Exécutez la commande suivante pour créer une liaison de rôle Kubernetes dans l'espace de noms donné. Cette liaison de rôle accorde les autorisations définies dans le rôle créé à l'étape précédente à un utilisateur nommé `emr-containers`. Cet utilisateur identifie les [rôles liés au service pour Amazon EMR on EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html) et permet ainsi à Amazon EMR on EKS d'effectuer les actions définies par le rôle que vous avez créé.

   ```
   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. **Mise à jour la carte de configuration `aws-auth` de Kubernetes**

   Vous pouvez utiliser l'une des options suivantes pour associer le rôle lié au service Amazon EMR on EKS à l'utilisateur `emr-containers` associé au rôle Kubernetes à l'étape précédente.

   **Option 1 : utilisation de l'outil `eksctl`**

   Exécutez la commande `eksctl` suivante pour associer le rôle lié au service Amazon EMR on EKS à l'utilisateur `emr-containers`.

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

   **Option 2 : sans utiliser eksctl**

   1. Exécutez la commande suivante pour ouvrir la carte de configuration `aws-auth` dans l'éditeur de texte. 

      ```
      kubectl edit -n kube-system configmap/aws-auth
      ```
**Note**  
Si vous recevez un message d'erreur`Error from server (NotFound): configmaps "aws-auth" not found`, consultez les étapes décrites dans la section [Ajouter des rôles d'utilisateur](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) dans le guide de l'utilisateur Amazon EKS pour appliquer le stock ConfigMap. 

   1. Ajoutez les détails du rôle lié au service Amazon EMR on EKS dans la section `mapRoles` de la `ConfigMap`, sous `data`. Ajoutez cette section si elle n'existe pas déjà dans le fichier. La section `mapRoles` mise à jour sous les données ressemble à l'exemple suivant.

      ```
      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. Enregistrez le fichier et quittez votre éditeur de texte.

# Activer les rôles IAM pour le cluster EKS
<a name="setting-up-enable-IAM-roles"></a>

Les rubriques suivantes décrivent les options permettant d'activer les rôles IAM.

**Topics**
+ [Option 1 : activer l'identité du pod EKS sur le cluster EKS](setting-up-enable-IAM.md)
+ [Option 2 : activer les rôles IAM pour les comptes de service (IRSA) sur le cluster EKS](setting-up-enable-IAM-service-accounts.md)

# Option 1 : activer l'identité du pod EKS sur le cluster EKS
<a name="setting-up-enable-IAM"></a>

Les associations de l’identité du pod Amazon EKS offrent une capacité de gestion des informations d’identification à utiliser pour les applications, de la même façon que les profils d’instance Amazon EC2 fournissent des informations d’identification aux instances EC2. L’identité du pod Amazon EKS fournit des informations d’identification à vos charges de travail avec une API d’authentification EKS supplémentaire et un pod d’agent qui s’exécute sur chaque nœud.

Amazon EMR on EKS commence à prendre en charge l'identité des pods EKS depuis la version emr-7.3.0 pour le modèle de soumission. StartJobRun 

Pour plus d'informations sur les identités des pods EKS, reportez-vous à la section [Comprendre le fonctionnement d'EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html).

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

Dans le cadre de la configuration d'EMR, le rôle Job Execution doit établir des limites de confiance entre un rôle IAM et des comptes de service dans un espace de noms spécifique (des clusters virtuels EMR). Avec l'IRSA, cela a été réalisé en mettant à jour la politique de confiance du rôle EMR Job Execution. Cependant, en raison de la limite stricte de 4 096 caractères imposée à la politique de confiance IAM, il était nécessaire de partager un seul rôle IAM d'exécution de tâches sur un maximum de douze (12) clusters EKS.

Grâce au support d'EMR pour Pod Identities, la limite de confiance entre les rôles IAM et les comptes de service est désormais gérée par l'équipe EKS via l'association d'EKS pod identity. APIs

**Note**  
La limite de sécurité pour l'identité du pod EKS est toujours au niveau du compte de service, et non au niveau du pod.

## Considérations relatives à l'identité des
<a name="setting-up-enable-IAM-pod-identity-consider"></a>

Pour plus d'informations sur les limites relatives à l'identité des pods, consultez la section [Considérations relatives à l'identité des pods d'EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations).

## Préparer l'identité du pod EKS dans le cluster EKS
<a name="setting-up-enable-IAM-pod-eks-cluster"></a>

### Vérifiez si l'autorisation requise existe dans NodeInstanceRole
<a name="setting-up-enable-IAM-pod-eks-cluster-permission"></a>

Le rôle de nœud `NodeInstanceRole` nécessite une autorisation pour que l'agent puisse effectuer l'`AssumeRoleForPodIdentity`action dans l'API EKS Auth. Vous pouvez ajouter les éléments suivants à l'[Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy), qui est défini dans le guide de l'utilisateur Amazon EKS, ou utiliser une politique personnalisée.

Si votre cluster EKS a été créé avec une version eksctl supérieure à **0.181.0,** Amazon EKSWorkerNodePolicy, y compris les `AssumeRoleForPodIdentity` autorisations requises, sera automatiquement attaché au rôle de nœud. Si l'autorisation n'est pas présente, ajoutez manuellement l'autorisation suivante à Amazon, EKSWorker NodePolicy qui permet d'assumer un rôle dans l'identité du pod. L'agent d'identité des pods EKS a besoin de cette autorisation pour récupérer les informations d'identification des pods.

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

****  

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

------

### Créer un module complémentaire pour l'agent d'identité EKS pod
<a name="setting-up-enable-IAM-pod-eks-cluster-agent"></a>

Utilisez la commande suivante pour créer le module complémentaire EKS Pod Identity Agent avec la dernière version :

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

Suivez les étapes suivantes pour créer le module complémentaire EKS Pod Identity Agent à partir de la console Amazon EKS :

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

1. Dans le panneau de navigation de gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire l’agent d’identité du pod EKS.

1. Choisissez l’onglet **Modules complémentaires**.

1. Choisissez **Obtenez plus de modules complémentaires**.

1. Cochez la case en haut à droite du module complémentaire de l’agent d’identité du pod EKS, puis sélectionnez **Suivant**.

1. Sur la page **Configurer les paramètres des modules complémentaires sélectionnés**, sélectionnez n'importe quelle version dans la liste déroulante **Version**.

1. (Facultatif) Développez les **Paramètres de configuration facultatifs** pour entrer une configuration supplémentaire. Par exemple, vous pouvez fournir un autre emplacement d’image de conteneur et `ImagePullSecrets`. Le schéma JSON avec les clés acceptées est présenté dans **Schéma de configuration du module complémentaire**.

   Saisissez les clés et les valeurs de configuration dans **Valeurs de configuration**.

1. Choisissez **Suivant**.

1. Vérifiez que les pods d'agent s'exécutent sur votre cluster via la CLI.

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

Voici un exemple de sortie :

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

Cela crée un nouveau nom DaemonSet dans l'espace de `kube-system` noms. L'agent Amazon EKS Pod Identity, qui s'exécute sur chaque nœud EKS, utilise cette [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)action pour récupérer des informations d'identification temporaires à partir de l'API EKS Auth. Ces informations d'identification sont ensuite mises à disposition pour AWS SDKs celles que vous exécutez dans vos conteneurs.

Pour plus d'informations, consultez la condition préalable dans le document public : [Configurer l'agent d'identité Amazon EKS Pod](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html).

## Création d'un rôle d'exécution de Job
<a name="setting-up-enable-IAM-pod-create-job-role"></a>

### Création ou mise à jour du rôle d'exécution des tâches qui autorise EKS Pod Identity
<a name="setting-up-enable-IAM-pod-create-job-role-update"></a>

Pour exécuter des charges de travail avec Amazon EMR sur EKS, vous devez créer un rôle IAM. Dans cette documentation, nous appelons ce rôle le rôle d'exécution des tâches. Pour plus d'informations sur la création du rôle IAM, consultez la section [Création de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) dans le guide de l'utilisateur.

En outre, vous devez créer une politique IAM qui spécifie les autorisations nécessaires pour le rôle d'exécution de la tâche, puis associer cette politique au rôle pour activer EKS Pod Identity.

Par exemple, vous avez le rôle d'exécution de tâches suivant. Pour plus d'informations, consultez la section [Création d'un rôle d'exécution de tâche](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html).

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

**Important**  
Amazon EMR on EKS crée automatiquement des comptes de service Kubernetes, en fonction du nom de votre rôle d'exécution de tâches. Assurez-vous que le nom du rôle n'est pas trop long, car votre tâche risque d'échouer si la combinaison de `cluster_name``pod_name`, et `service_account_name` dépasse la limite de longueur.

**Configuration du rôle d'exécution des tâches** : assurez-vous que le rôle d'exécution des tâches est créé avec l'autorisation de confiance ci-dessous pour EKS Pod Identity. Pour mettre à jour un rôle d'exécution de tâche existant, configurez-le pour qu'il approuve le principal de service EKS suivant en tant qu'autorisation supplémentaire dans la politique de confiance. Cette autorisation de confiance peut coexister avec les politiques de confiance existantes de l'IRSA.

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

**Autorisation utilisateur** : les utilisateurs doivent être `iam:PassRole` autorisés à exécuter des appels d'`StartJobRun`API ou à soumettre des tâches. Cette autorisation permet aux utilisateurs de transmettre le rôle d'exécution des tâches à EMR sur EKS. Les administrateurs de tâches doivent avoir l'autorisation par défaut.

Vous trouverez ci-dessous l'autorisation requise pour un utilisateur :

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

Pour restreindre davantage l'accès des utilisateurs à des clusters EKS spécifiques, ajoutez le filtre AssociatedResourceArn d'attributs à la politique IAM. Il limite l'attribution des rôles aux clusters EKS autorisés, renforçant ainsi vos contrôles de sécurité au niveau des ressources.

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

## Configurer les associations d'identité des pods EKS
<a name="setting-up-enable-IAM-pod-identity-asociations"></a>

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

Assurez-vous que l'identité IAM qui crée l'association d'identité du pod, par exemple un utilisateur administrateur EKS, dispose de l'autorisation `eks:CreatePodIdentityAssociation` et`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"
    }
  ]
}
```

------

### Créer des associations pour le rôle et le compte de service EMR
<a name="setting-up-enable-IAM-pod-identity-asociations-emr-service"></a>

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

Lorsque vous soumettez une tâche à un espace de noms Kubernetes, un administrateur doit créer des associations entre le rôle d'exécution de la tâche et l'identité du compte de service géré EMR. Notez que le compte de service géré EMR est automatiquement créé lors de la soumission de la tâche, dans la limite de l'espace de noms dans lequel la tâche est soumise.

Avec la version 2.24.0 AWS CLI (supérieure), exécutez la commande suivante pour créer des associations de rôles avec l'identité du pod.

Exécutez la commande suivante pour créer des associations de rôles avec pod identity :

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

Remarque :
+ Chaque cluster peut avoir une limite de 1 000 associations. Le mappage des rôles et des espaces de noms de chaque tâche nécessitera 3 associations pour les modules émetteur de tâches, pilote et exécuteur.
+ Vous ne pouvez associer que des rôles appartenant au même AWS compte que le cluster. Vous pouvez déléguer l’accès d’un autre compte au rôle de ce compte que vous configurez pour que les identités du pod EKS utilisent. Pour un didacticiel sur la délégation d'accès`AssumeRole`, voir [Tutoriel IAM : déléguer l'accès entre AWS comptes à l'aide de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html).

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

EMR crée un compte de service avec un certain modèle de dénomination lorsqu'une tâche est soumise. Pour créer des associations manuelles ou intégrer ce flux de travail au AWS SDK, procédez comme suit :

Nom du compte de service de construction :

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

Les exemples ci-dessous créent une association de rôles pour un exemple de rôle d'exécution de Job JobExecutionRoleIRSAv2.

**Exemples d'associations de rôles :**

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

**Exemple de commande 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
```

------

Une fois que vous avez effectué toutes les étapes requises pour l'identification du pod EKS, vous pouvez ignorer les étapes suivantes pour la configuration de l'IRSA :
+ [Activer les rôles IAM pour les comptes de service (IRSA) sur le cluster EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html)
+ [Création d'un rôle d'exécution de tâches](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)
+ [Mettre à jour la politique de confiance du rôle d'exécution des tâches](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html)

Vous pouvez passer directement à l'étape suivante : [Accorder aux utilisateurs l'accès à Amazon EMR](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html) sur EKS

## Supprimer les associations de rôles
<a name="setting-up-enable-IAM-pod-identity-asociations-delete-associations"></a>

Chaque fois que vous supprimez un cluster virtuel ou un rôle d'exécution de tâches et que vous ne souhaitez plus donner accès à EMR à ses comptes de service, vous devez supprimer les associations associées au rôle. Cela est dû au fait qu'EKS autorise les associations avec des ressources inexistantes (espace de noms et compte de service). Amazon EMR on EKS recommande de supprimer les associations si l'espace de noms est supprimé ou si le rôle n'est plus utilisé, afin de libérer de l'espace pour d'autres associations.

**Note**  
Les associations persistantes peuvent avoir un impact sur votre capacité à évoluer si vous ne les supprimez pas, car EKS limite le nombre d'associations que vous pouvez créer (limite souple : 1 000 associations par cluster). Vous pouvez répertorier les associations d'identité des pods dans un espace de noms donné pour vérifier s'il existe des associations persistantes qui doivent être nettoyées :

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

Avec la AWS CLI version 2.24.0 ou supérieure, exécutez la commande emr-containers suivante pour supprimer les associations de rôles d'EMR :

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

## Migrer automatiquement l'IRSA existant vers Pod Identity
<a name="setting-up-enable-IAM-pod-identity-auto-migrate"></a>

Vous pouvez utiliser l'outil eksctl pour migrer les rôles IAM existants pour les comptes de service (IRSA) vers des associations d'identité de pod :

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

L'exécution de la commande sans l'`--approve`indicateur produira uniquement un plan reflétant les étapes de migration, et aucune migration réelle n'aura lieu.

## Résolution des problèmes
<a name="setting-up-enable-IAM-pod-identity-troubleshooting"></a>

### Ma tâche a échoué avec NoClassDefinitionFound ou ClassNotFound Exception pour le fournisseur d'informations d'identification, ou je n'ai pas réussi à obtenir le fournisseur d'informations d'identification.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-no-class"></a>

EKS Pod Identity utilise le fournisseur d'informations d'identification du conteneur pour récupérer les informations d'identification nécessaires. Si vous avez spécifié un fournisseur d'identifiants personnalisés, assurez-vous qu'il fonctionne correctement. Vous pouvez également vous assurer que vous utilisez une version du AWS SDK correcte qui prend en charge l'EKS Pod Identity. Pour plus d'informations, consultez la section [Commencer avec Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

### La tâche a échoué en raison de l'erreur « Impossible de récupérer les informations d'identification en raison de la limite de taille [x] » affichée dans le eks-pod-identity-agent journal.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds"></a>

EMR sur EKS crée des comptes de service Kubernetes en fonction du nom du rôle d'exécution de la tâche. Si le nom du rôle est trop long, EKS Auth ne parviendra pas à récupérer les informations d'identification car la combinaison de `cluster_name``pod_name`, et `service_account_name` dépasse la limite de longueur. Identifiez le composant qui occupe le plus d'espace et ajustez la taille en conséquence.

### La tâche a échoué avec l'erreur « Failed to Retrieve Credentials xxx » affichée dans le eks-pod-identity journal.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds-error"></a>

Ce problème peut être dû au fait que le cluster EKS est configuré sous des sous-réseaux privés sans être correctement configuré PrivateLink pour le cluster. Vérifiez si votre cluster se trouve dans un réseau privé et configurez-le AWS PrivateLink pour résoudre le problème. Pour obtenir des instructions détaillées, reportez-vous à la section [Commencer avec Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

# Option 2 : activer les rôles IAM pour les comptes de service (IRSA) sur le cluster EKS
<a name="setting-up-enable-IAM-service-accounts"></a>

La fonctionnalité des rôles IAM pour les comptes de service est disponible sur Amazon EKS en version 1.14 ou ultérieure et pour les clusters EKS mis à jour vers la version 1.13 ou ultérieure à partir du 3 septembre 2019. Pour utiliser cette fonctionnalité, vous pouvez mettre à jour les clusters EKS existants vers la version 1.14 ou une version ultérieure. Pour plus d'informations, consultez la rubrique [Mise à jour de la version Kubernetes d'un cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).

Si votre cluster prend en charge les rôles IAM pour les comptes de service, une URL d'émetteur [OpenID Connect](https://openid.net/connect/) lui est associée. Vous pouvez consulter cette URL dans la console Amazon EKS ou utiliser la AWS CLI commande suivante pour la récupérer.

**Important**  
Vous devez utiliser la dernière version de AWS CLI pour obtenir le résultat approprié de cette commande.

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

Le résultat attendu est le suivant.

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

Pour utiliser les rôles IAM pour les comptes de service dans votre cluster, vous devez créer un fournisseur d'identité OIDC à l'aide d'[eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) ou de la [AWS Management Console](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console).

## Pour créer un fournisseur d'identité OIDC IAM pour votre cluster avec `eksctl`
<a name="setting-up-OIDC-eksctl"></a>

Vous pouvez vérifier la version de votre `eksctl` à l'aide de la commande suivante. Cette procédure suppose que vous avez installé `eksctl` et que votre version `eksctl` est 0.32.0 ou une version ultérieure.

```
eksctl version
```

Pour plus d'informations sur l'installation ou la mise à niveau d'eksctl, consultez la rubrique [Installation ou mise à niveau d'eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl).

Créez votre fournisseur d'identité OIDC pour votre cluster avec la commande suivante. Remplacez *cluster\$1name* par votre propre valeur.

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

## Pour créer un fournisseur d'identité IAM OIDC pour votre cluster à l'aide du AWS Management Console
<a name="setting-up-OIDC-console"></a>

Récupérez l'URL de l'émetteur OIDC dans la description de votre cluster sur la console Amazon EKS, ou utilisez la commande suivante AWS CLI .

Utilisez la commande suivante pour récupérer l'URL de l'émetteur OIDC à partir de la AWS CLI.

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

Suivez les étapes ci-dessous pour récupérer l'URL de l'émetteur OIDC à partir de la console Amazon EKS. 

1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Dans le volet de navigation, choisissez **Fournisseurs d'identité**, puis **Créer un fournisseur**.

   1. Sous **Provider Type (Type de fournisseur)**, choisissez **Choose a provider type (Choisir un type de fournisseur)**, puis choisissez **OpenID Connect**.

   1. Pour **Provider URL (URL du fournisseur**, collez l'URL de l'émetteur OIDC pour votre cluster.

   1. Pour Public ciblé, saisissez sts.amazonaws.com et choisissez **Étape suivante**.

1. Vérifiez que les informations du fournisseur sont correctes, puis choisissez **Créer (Create)** pour créer votre fournisseur d'identité.

# Création d'un rôle d'exécution des tâches
<a name="creating-job-execution-role"></a>

Pour exécuter des charges de travail sur Amazon EMR on EKS, vous devez créer un rôle IAM. Dans cette documentation, nous appelons ce rôle le *rôle d'exécution des tâches*. Pour plus d'informations sur la création de rôles IAM, consultez [Création de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) dans le Guide de l'utilisateur IAM. 

Vous devez également créer une politique IAM qui spécifie les autorisations pour le rôle d'exécution des tâches, puis associer la politique IAM au rôle d'exécution des tâches. 

La politique suivante pour le rôle d'exécution des tâches autorise l'accès aux cibles de ressources, Amazon S3 et CloudWatch. Ces autorisations sont nécessaires pour surveiller les tâches et les journaux d'accès. Pour suivre le même processus en utilisant AWS CLI : 

Créer un rôle IAM pour l'exécution des tâches : créons le rôle qu'EMR utilisera pour l'exécution des tâches. C'est le rôle que les tâches EMR assumeront lorsqu'elles s'exécuteront sur 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
```

Ensuite, nous devons associer les politiques IAM requises au rôle afin qu'il puisse écrire des journaux sur s3 et 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
```

**Note**  
L'accès doit être défini de manière appropriée et ne pas être accordé à tous les objets S3 du rôle d'exécution des tâches.

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

------

Pour plus d'informations, consultez les [sections Utilisation des rôles d'exécution de tâches](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html), [Configuration d'une exécution de tâche pour utiliser les journaux S3](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) et [Configuration d'une exécution de tâche pour utiliser CloudWatch les journaux](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch).

# Mise à jour la politique d'approbation du rôle d'exécution des tâches
<a name="setting-up-trust-policy"></a>

Lorsque vous utilisez les rôles IAM pour les comptes de service (IRSA) pour exécuter des tâches sur un espace de noms Kubernetes, un administrateur doit créer une relation d'approbation entre le rôle d'exécution des tâches et l'identité du compte de service géré EMR. La relation d'approbation peut être créée en mettant à jour la politique d'approbation du rôle d'exécution des tâches. Notez que le compte de service géré EMR est automatiquement créé lors de la soumission de la tâche, dans la limite de l'espace de noms dans lequel la tâche est soumise.

Pour mettre à jour la politique d'approbation, exécutez la commande suivante.

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

Pour de plus amples informations, veuillez consulter [Utilisation des rôles d'exécution de tâches avec Amazon EMR on EKS](iam-execution-role.md).

**Important**  
L'opérateur exécutant la commande ci-dessus doit disposer des autorisations suivantes : `eks:DescribeCluster`, `iam:GetRole`, `iam:UpdateAssumeRolePolicy`.

# Autorisation des utilisateurs à accéder à Amazon EMR on EKS
<a name="setting-up-iam"></a>

Pour toute action que vous effectuez sur Amazon EMR on EKS, vous avez besoin d'une autorisation IAM correspondant à cette action. Vous devez créer une politique IAM qui vous permet d'exécuter les actions Amazon EMR on EKS et l'attacher à l'utilisateur IAM ou au rôle que vous utilisez. 

Cette rubrique décrit les étapes à suivre pour créer une nouvelle politique et l'associer à un utilisateur. Elle couvre également les autorisations de base dont vous avez besoin pour configurer votre environnement Amazon EMR on EKS. Nous vous recommandons d'affiner les autorisations relatives à des ressources spécifiques dans la mesure du possible en fonction des besoins de votre entreprise.

## Création d'une nouvelle politique IAM et association de celle-ci à un utilisateur dans la console IAM
<a name="setting-up-iam-console"></a>

**Création d'une nouvelle politique IAM**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le volet de navigation gauche de la console IAM, choisissez **Politiques**.

1. Sur la page **Politiques**, choisissez **Créer une politique**.

1. Dans la fenêtre **Créer une politique**, accédez à l'onglet **Modifier JSON**. Créez un document de politique avec une ou plusieurs instructions JSON, comme indiqué dans les exemples suivant cette procédure. Ensuite, choisissez **Examiner la politique**.

1. Sur l’écran **Review policy** (Examiner la politique), saisissez votre **Policy Name** (Nom de politique), par exemple, `AmazonEMROnEKSPolicy`. Saisissez une description facultative, puis sélectionnez **Créer une politique**. 

**Attacher la politique à un utilisateur ou à un rôle**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 

1. Dans le panneau de navigation, choisissez **Politiques**.

1. Dans la liste des politiques, cochez la case en regard de la politique créée dans la section précédente. Vous pouvez utiliser le menu **Filtre** et la zone de recherche pour filtrer la liste de politiques. 

1. Sélectionnez **Policy Actions** (Actions de politique), puis sélectionnez **Attach** (Attacher).

1. Choisissez l'utilisateur ou le rôle auquel attacher la politique. Vous pouvez utiliser le menu **Filtre** et la zone de recherche pour filtrer la liste des entités du principal. Après avoir choisi l'utilisateur auquel attacher la politique, sélectionnez **Attacher la politique**.

## Autorisations pour la gestion des clusters virtuels
<a name="permissions-virtual-cluster"></a>

Pour gérer les clusters virtuels dans votre AWS compte, créez une politique IAM avec les autorisations suivantes. Ces autorisations vous permettent de créer, de répertorier, de décrire et de supprimer des clusters virtuels dans votre AWS compte.

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

****  

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

------

Amazon EMR est intégré à la gestion des accès aux clusters (CAM) d'Amazon EKS, ce qui vous permet d'automatiser la configuration des politiques AuthN et AuthZ nécessaires pour exécuter des tâches Amazon EMR Spark dans les espaces de noms des clusters Amazon EKS. Pour ce faire, vous devez disposer des autorisations suivantes :

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

Pour plus d'informations, consultez [Automatiser l'activation de l'accès au cluster pour Amazon EMR sur](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-cam-integration) EKS.

Lorsque l'`CreateVirtualCluster`opération est invoquée pour la première fois depuis un AWS compte, vous devez également disposer des `CreateServiceLinkedRole` autorisations nécessaires pour créer le rôle lié à un service pour Amazon EMR sur EKS. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon EMR on EKS](using-service-linked-roles.md). 

## Autorisations pour la soumission de tâches
<a name="permissions-submitting-jobs"></a>

Pour soumettre des tâches sur les clusters virtuels de votre AWS compte, créez une politique IAM avec les autorisations suivantes. Ces autorisations vous permettent de démarrer, de répertorier, de décrire et d'annuler des exécutions de tâches pour tous les clusters virtuels de votre compte. Vous devriez envisager d'ajouter des autorisations pour répertorier ou décrire les clusters virtuels, ce qui vous permet de vérifier l'état du cluster virtuel avant de soumettre des tâches.

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

****  

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

------

## Autorisations pour le débogage et la surveillance
<a name="permissions-debugging-monitoring"></a>

Pour accéder aux journaux transmis à Amazon S3 et/ou pour consulter les CloudWatch journaux des événements de l'application dans la console Amazon EMR, créez une politique IAM avec les autorisations suivantes. Nous vous recommandons d'affiner les autorisations relatives à des ressources spécifiques dans la mesure du possible en fonction des besoins de votre entreprise.

**Important**  
Si vous n'avez pas créé de compartiment Amazon S3, vous devez ajouter une autorisation `s3:CreateBucket` à la déclaration de politique. Si vous n'avez pas créé de groupe de journaux, vous devez ajouter `logs:CreateLogGroup` à la déclaration de politique.

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

------

Pour plus d'informations sur la façon de configurer l'exécution d'une tâche pour envoyer des journaux vers Amazon S3 CloudWatch, consultez [Configurer une exécution de tâche pour utiliser les journaux S3](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) et [Configurer une exécution de tâche pour utiliser CloudWatch les journaux](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch).

# Enregistrement du cluster Amazon EKS dans Amazon EMR
<a name="setting-up-registration"></a>

L'enregistrement de votre cluster est la dernière étape nécessaire pour configurer Amazon EMR on EKS afin d'exécuter des charges de travail.

Utilisez la commande suivante pour créer un cluster virtuel portant le nom de votre choix pour le cluster Amazon EKS et l'espace de noms que vous avez configurés aux étapes précédentes.

**Note**  
Chaque cluster virtuel doit avoir un nom unique pour tous les clusters EKS. Si deux clusters virtuels portent le même nom, le processus de déploiement échouera même s'ils appartiennent à des clusters EKS différents. 

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

Vous pouvez également créer un fichier JSON qui inclut les paramètres requis pour le cluster virtuel, puis exécuter la commande `create-virtual-cluster` avec le chemin d'accès au fichier JSON. Pour de plus amples informations, veuillez consulter [Gestion des clusters virtuels](virtual-cluster.md).

**Note**  
Pour valider la création réussie d'un cluster virtuel, consultez l'état des clusters virtuels à l'aide de l'opération `list-virtual-clusters` ou en accédant à la page **Clusters virtuels** de la console Amazon EMR. 

# Soumission d'une tâche exécutée avec `StartJobRun`
<a name="emr-eks-jobs-submit"></a>

**Soumission d'une tâche exécutée à l'aide d'un fichier JSON avec les paramètres spécifiés**

1. Créez un fichier `start-job-run-request.json` et indiquez les paramètres requis pour l'exécution de votre tâche, comme le montre l'exemple de fichier JSON ci-dessous. Pour plus d’informations sur les paramètres, consultez [Options de configuration d'une exécution de tâche](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. Utilisez la commande `start-job-run` avec un chemin d'accès au fichier `start-job-run-request.json` stocké localement.

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

**Démarrage de l'exécution d'une tâche à l'aide la commande `start-job-run`**

1. Fournissez tous les paramètres spécifiés dans la commande `StartJobRun`, comme le montre l'exemple ci-dessous.

   ```
   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. Pour Spark SQL, fournissez tous les paramètres spécifiés dans la commande `StartJobRun`, comme le montre l'exemple ci-dessous.

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

# Utilisation de la classification des soumissionnaires de tâches
<a name="emr-eks-job-submitter"></a>

## Présentation de
<a name="emr-eks-job-submitter-overview"></a>

La demande `StartJobRun` d'Amazon EMR on EKS crée un pod *soumissionnaire de tâche* (également connu sous le nom de pod *exécuteur de tâche*) pour lancer le pilote Spark. Vous pouvez utiliser la `emr-job-submitter` classification pour configurer les sélecteurs de nœuds, ajouter des tolérances, personnaliser la journalisation et apporter d'autres modifications au module d'envoi des tâches.

Les paramètres suivants sont disponibles dans la `emr-job-submitter` classification :

** `jobsubmitter.node.selector.[selectorKey]` **  
S'ajoute au sélecteur de nœuds du module d'envoi de tâches, avec la clé *selectorKey* et la valeur comme valeur de configuration. Par exemple, vous pouvez ` jobsubmitter.node.selector.identifier` définir sur `myIdentifier` et le module de soumission des tâches comportera un sélecteur de nœuds avec une clé `identifier` et une valeur. `myIdentifier` Cela peut être utilisé pour spécifier sur quels nœuds le pod de soumission de tâches peut être placé. Pour ajouter plusieurs clés de sélection de nœuds, définissez plusieurs configurations avec ce préfixe.

** `jobsubmitter.label.[labelKey]` **  
S'ajoute aux étiquettes du module d'envoi de tâches, avec la clé *labelKey* et la valeur comme valeur de configuration. Pour ajouter plusieurs étiquettes, définissez plusieurs configurations avec ce préfixe.

** `jobsubmitter.annotation.[annotationKey]` **  
S'ajoute aux annotations du module d'envoi des tâches, avec la clé *annotationKey* et la valeur comme valeur de configuration. Pour ajouter plusieurs annotations, définissez plusieurs configurations avec ce préfixe.

** `jobsubmitter.node.toleration.[tolerationKey]` **  
Ajoute [des tolérances](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) au module d'envoi des tâches. Par défaut, aucune tolérance n'est ajoutée au module. La clé de la tolérance sera *tolerationKey* et la valeur de la tolérance sera la valeur de configuration. Si la valeur de configuration est définie sur une chaîne non vide, l'opérateur le sera`Equals`. Si la valeur de configuration est définie sur`""`, l'opérateur le sera`Exists`.

** `jobsubmitter.node.toleration.[tolerationKey].[effect]` **  
Ajoute un effet de tolérance au préfixe*tolerationKey*. Ce champ est obligatoire lors de l'ajout de tolérances. Les valeurs autorisées pour le champ d'effet sont ` NoExecute``NoSchedule`, et`PreferNoSchedule`.

** `jobsubmitter.node.toleration.[tolerationKey].[tolerationSeconds]` **  
Ajoute TolerationSeconds au préfixe. *tolerationKey* Champ facultatif. Applicable uniquement lorsque l'effet est présent`NoExecute`.

** `jobsubmitter.scheduler.name` **  
Définit un SchedulerName personnalisé pour le module d'envoi des tâches.

** `jobsubmitter.logging` **  
Active ou désactive la journalisation sur le module d'envoi des tâches. Lorsque ce paramètre est défini sur, ` DISABLED` le conteneur de journalisation est supprimé du module d'envoi des tâches, ce qui désactive toute journalisation pour ce module spécifiée dans le`monitoringConfiguration`, tel que `s3MonitoringConfiguration` ou. `cloudWatchMonitoringConfiguration` Lorsque ce paramètre n'est pas défini ou qu'il est défini sur une autre valeur, la connexion au module d'envoi des tâches est activée.

** `jobsubmitter.logging.image` **  
Définit une image personnalisée à utiliser pour le conteneur de journalisation dans le module d'envoi des tâches.

** `jobsubmitter.logging.request.cores` **  
Définit une valeur personnalisée pour le nombre CPUs, en unités de processeur, du conteneur de journalisation sur le module d'envoi des tâches. Par défaut, ce paramètre est réglé sur **100 m.**

** `jobsubmitter.logging.request.memory` **  
Définit une valeur personnalisée pour la quantité de mémoire, en octets, pour le conteneur de journalisation sur le module d'envoi des tâches. Par défaut, ce paramètre est réglé sur **200 Mi**. Un mébioctet est une unité de mesure similaire à un mégaoctet.

** `jobsubmitter.container.image` **  
Définit une image personnalisée pour le conteneur du module d'envoi de `job-runner` tâches.

** `jobsubmitter.container.image.pullPolicy` **  
Définit [imagePullPolicy](https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy)les conteneurs du module de soumission des tâches.

Nous vous recommandons de placer les modules d'envoi de tâches sur des instances à la demande. Le fait de placer des modules d'envoi de tâches sur des instances Spot peut entraîner l'échec d'une tâche si l'instance sur laquelle s'exécute le module d'envoi de tâches est sujette à une interruption d'instance Spot. Vous pouvez également [placer le module d'envoi des tâches dans une seule zone de disponibilité ou utiliser les étiquettes Kubernetes appliquées aux nœuds](#emr-eks-job-submitter-ex-ec2).

## Exemples de classification des soumissionnaires de tâches
<a name="emr-eks-job-submitter-examples"></a>

**Topics**
+ [Demande `StartJobRun` avec placement de nœuds à la demande pour le pod soumissionnaire de tâches](#emr-eks-job-submitter-ex-od)
+ [`StartJobRun`demande avec placement d'un nœud mono-AZ et placement du type d'instance Amazon EC2 pour le module d'envoi des tâches](#emr-eks-job-submitter-ex-ec2)
+ [`StartJobRun`demande avec des étiquettes, des annotations et un planificateur personnalisé pour le module d'envoi des tâches](#emr-eks-job-submitter-label-annotation-scheduler)
+ [`StartJobRun`demande avec une tolérance appliquée au module d'envoi de la tâche avec clé`dedicated`, valeur `graviton_machines``NoExecute`, effet et un `tolerationSeconds` délai de 60 secondes](#emr-eks-job-submitter-tolerations)
+ [`StartJobRun`demande avec journalisation désactivée pour le module d'envoi de tâches](#emr-eks-job-submitter-logging-disabled)
+ [`StartJobRun`demande avec image du conteneur de journalisation personnalisé, processeur et mémoire pour le module d'envoi des tâches](#emr-eks-job-submitter-custom)
+ [`StartJobRun`demande avec une image de conteneur d'envoi de tâches personnalisée et une politique d'extraction](#emr-eks-job-submitter-custom-container)

### Demande `StartJobRun` avec placement de nœuds à la demande pour le pod soumissionnaire de tâches
<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`demande avec placement d'un nœud mono-AZ et placement du type d'instance Amazon EC2 pour le module d'envoi des tâches
<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`demande avec des étiquettes, des annotations et un planificateur personnalisé pour le module d'envoi des tâches
<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`demande avec une tolérance appliquée au module d'envoi de la tâche avec clé`dedicated`, valeur `graviton_machines``NoExecute`, effet et un `tolerationSeconds` délai de 60 secondes
<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`demande avec journalisation désactivée pour le module d'envoi de tâches
<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`demande avec image du conteneur de journalisation personnalisé, processeur et mémoire pour le module d'envoi des tâches
<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`demande avec une image de conteneur d'envoi de tâches personnalisée et une politique d'extraction
<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"
      }
    }
  ]
}
```

# Utilisation de la classification par défaut des conteneurs Amazon EMR
<a name="emr-eks-job-submitter-container-defaults"></a>

## Présentation de
<a name="emr-eks-job-submitter-container-defaults-overview"></a>

Les paramètres suivants sont disponibles dans la `emr-containers-defaults` classification :

** `job-start-timeout` **  
Par défaut, une tâche expirera si elle ne peut pas démarrer et qu'elle attend dans son ` SUBMITTED` état pendant 15 minutes. Cette configuration modifie le nombre de secondes à attendre avant l'expiration de la tâche.

** `executor.logging` **  
Active ou désactive la journalisation sur les pods de l'exécuteur. Lorsque ce paramètre est défini sur, ` DISABLED` le conteneur de journalisation est supprimé des pods de l'exécuteur, ce qui désactivera toute journalisation pour ces pods spécifiés dans le`monitoringConfiguration`, tel que `s3MonitoringConfiguration` ou`cloudWatchMonitoringConfiguration`. Lorsque ce paramètre n'est pas défini ou qu'il est défini sur une autre valeur, la connexion aux pods de l'exécuteur est activée.

** `logging.image` **  
Définit une image personnalisée à utiliser pour le conteneur de journalisation sur les modules pilote et exécuteur.

** `logging.request.cores` **  
Définit une valeur personnalisée pour le nombre CPUs, en unités de processeur, du conteneur de journalisation sur les pods pilote et exécuteur. Par défaut, ce paramètre n'est pas défini.

** `logging.request.memory` **  
Définit une valeur personnalisée pour la quantité de mémoire, en octets, pour le conteneur de journalisation sur les pods pilote et exécuteur. Par défaut, ce paramètre est réglé sur **512 Mi**. Un mébioctet est une unité de mesure similaire à un mégaoctet.

## Exemples de classification des soumissionnaires de tâches
<a name="emr-eks-job-submitter-container-examples"></a>

**Topics**
+ [`StartJobRun`demande avec délai d'expiration de tâche personnalisé](#emr-eks-job-submitter-container-custom-timeout)
+ [`StartJobRun`demande avec journalisation désactivée pour les modules d'exécution](#emr-eks-executor-logging-disabled)
+ [`StartJobRun`demande avec image du conteneur de journalisation personnalisé, processeur et mémoire pour les pods pilote et exécuteur](#emr-eks-job-submitter-container-custom-image-cpu)

### `StartJobRun`demande avec délai d'expiration de tâche personnalisé
<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`demande avec journalisation désactivée pour les modules d'exécution
<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`demande avec image du conteneur de journalisation personnalisé, processeur et mémoire pour les pods pilote et exécuteur
<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"
    }
  }
}
```

# Exécution de tâches Spark à l'aide de l'opérateur Spark
<a name="spark-operator"></a>

Les versions 6.10.0 et supérieures d'Amazon EMR prennent en charge l'opérateur Kubernetes pour Apache Spark, ou *l'opérateur Spark*, en tant que modèle de soumission de tâches pour Amazon EMR on EKS. Grâce à l'opérateur Spark, vous pouvez déployer et gérer des applications Spark à l'aide du moteur d'exécution Amazon EMR sur vos propres clusters Amazon EKS. Une fois que vous avez déployé l'opérateur Spark dans votre cluster Amazon EKS, vous pouvez directement soumettre des applications Spark à l'aide de cet opérateur. L'opérateur gère le cycle de vie des applications Spark.

**Note**  
Amazon EMR calcule les tarifs sur Amazon EKS en fonction du vCPU et de la consommation de mémoire. Ce calcul s'applique aux modules pilote et exécuteur. Ce calcul commence à partir du moment où vous téléchargez l'image de votre application Amazon EMR jusqu'à ce que le module Amazon EKS se termine et est arrondi à la seconde près.

**Topics**
+ [Configuration de l'opérateur Spark pour Amazon EMR on EKS](spark-operator-setup.md)
+ [Les premiers pas avec l'opérateur Spark pour Amazon EMR on EKS](spark-operator-gs.md)
+ [Utiliser l'autoscaling vertical avec l'opérateur Spark pour Amazon EMR sur EKS](spark-operator-vas.md)
+ [Désinstallation de l'opérateur Spark pour Amazon EMR on EKS](spark-operator-uninstall.md)
+ [Utilisation de la configuration de surveillance pour surveiller l'opérateur Spark Kubernetes et les tâches Spark](spark-operator-monitoring-configuration.md)
+ [Sécurité et opérateur Spark avec Amazon EMR on EKS](spark-operator-security.md)

# Configuration de l'opérateur Spark pour Amazon EMR on EKS
<a name="spark-operator-setup"></a>

Effectuez les tâches suivantes pour vous préparer avant d'installer l'opérateur Spark sur Amazon EKS. Si vous êtes déjà inscrit à Amazon Web Services (AWS) et que vous avez utilisé Amazon EKS, vous êtes presque prêt à utiliser Amazon EMR on EKS. Effectuez les tâches suivantes pour vous préparer pour l'utilisation de l'opérateur Spark sur Amazon EKS. Si vous avez déjà rempli l'une des conditions préalables, vous pouvez l'ignorer et passer à la suivante.
+ **[Installation ou mise à jour vers la dernière version du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)** — Si vous avez déjà installé le AWS CLI, vérifiez que vous disposez de la dernière version.
+ **[Configurer kubectl et eksctl — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)** est un outil de ligne de commande que vous utilisez pour communiquer avec Amazon EKS.
+ **[Installer Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)** – Le gestionnaire de packages Helm pour Kubernetes vous aide à installer et à gérer des applications sur votre cluster Kubernetes. 
+ **[Commencez avec Amazon EKS — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)** — Suivez les étapes pour créer un nouveau cluster Kubernetes avec des nœuds dans Amazon EKS.
+ **[Sélectionner l'URI d'une image de base Amazon EMR](docker-custom-images-tag.md) (version 6.10.0 ou supérieure)** – L'opérateur Spark est pris en charge par les versions  6.10.0 et supérieures d'Amazon EMR.

# Les premiers pas avec l'opérateur Spark pour Amazon EMR on EKS
<a name="spark-operator-gs"></a>

Cette rubrique vous aide à commencer à utiliser l'opérateur Spark sur Amazon EKS en déployant une application Spark et une application Schedule Spark.

## Installation de l'opérateur Spark
<a name="spark-operator-install"></a>

Procédez comme suit pour installer l'opérateur Kubernetes pour Apache Spark.

1. Si vous ne l'avez pas déjà fait, suivez les étapes de [Configuration de l'opérateur Spark pour Amazon EMR on EKS](spark-operator-setup.md).

1. Authentifiez votre client Helm dans le registre Amazon ECR. Dans la commande suivante, remplacez les *region-id* valeurs par vos valeurs préférées Région AWS et par la *ECR-registry-account* valeur correspondante pour la région [Comptes de registre Amazon ECR par région](docker-custom-images-tag.md#docker-custom-images-ECR) sur la page.

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

1. Installez l'opérateur Spark à l'aide de la commande suivante.

   Pour le paramètre `--version` des Charts de Helm, utilisez votre étiquette de version Amazon EMR avec le préfixe `emr-` et le suffixe de date supprimés. Par exemple, pour la version `emr-6.12.0-java17-latest`, spécifiez `6.12.0-java17`. L'exemple de la commande ci-dessous utilise la version `emr-7.12.0-latest`, elle spécifie donc `7.12.0` pour les Charts de Helm `--version`.

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

   Par défaut, la commande crée un compte de service `emr-containers-sa-spark-operator` pour l'opérateur Spark. Pour utiliser un autre compte de service, saisissez l'argument `serviceAccounts.sparkoperator.name`. Par exemple :

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

   Si vous souhaitez [utiliser l'autoscaling vertical avec l'opérateur Spark](), ajoutez la ligne suivante à la commande d'installation pour autoriser les webhooks pour l'opérateur :

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

1. Vérifiez que vous avez installé les Charts de Helm à l'aide de la commande `helm list` :

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

   La commande `helm list` doit vous renvoyer les informations relatives à la version des Charts de Helm qui vient d'être déployée :

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

1. Terminez l'installation avec toutes les options supplémentaires dont vous avez besoin. Pour plus d'informations, consultez la [https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/blob/master/charts/spark-operator-chart/README.md](https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/blob/master/charts/spark-operator-chart/README.md)documentation sur GitHub.

## Exécution d'une application Spark
<a name="spark-operator-run"></a>

L'opérateur Spark est pris en charge avec Amazon EMR en version 6.10.0 ou supérieure. Lorsque vous installez l'opérateur Spark, il crée le compte de service `emr-containers-sa-spark` pour exécuter les applications Spark par défaut. Suivez les étapes ci-dessous pour exécuter une application Spark avec l'opérateur Spark sur Amazon EMR on EKS en version 6.10.0 ou supérieure.

1. Pour pouvoir exécuter une application Spark à l'aide de l'opérateur Spark, suivez les étapes indiquées dans [Configuration de l'opérateur Spark pour Amazon EMR on EKS](spark-operator-setup.md) et [Installation de l'opérateur Spark](#spark-operator-install). 

1. Créez un fichier de définition `SparkApplication` `spark-pi.yaml` avec le contenu suivant : 

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

1. Maintenant, soumettez l'application Spark à l'aide de la commande suivante. Cela créera également un objet `SparkApplication` nommé `spark-pi` :

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

1. Vérifiez les événements de l'objet `SparkApplication` à l'aide de la commande suivante : 

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

Pour plus d'informations sur l'envoi d'applications à Spark via l'opérateur Spark, consultez la section [Utiliser un `SparkApplication`](https://www.kubeflow.org/docs/components/spark-operator/user-guide/using-sparkapplication/) dans la `spark-on-k8s-operator` documentation sur GitHub.

## Utiliser Amazon S3 pour le stockage
<a name="spark-operator-s3-storage"></a>

Pour utiliser Amazon S3 comme option de stockage de fichiers, ajoutez les configurations suivantes à votre fichier YAML.

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

 Si vous utilisez les versions 7.2.0 et supérieures d'Amazon EMR, les configurations sont incluses par défaut. Dans ce cas, vous pouvez définir le chemin du fichier sur `s3://<bucket_name>/<file_path>` plutôt que `local://<file_path>` dans le fichier YAML de l'application Spark. 

Soumettez ensuite l'application Spark comme d'habitude.

# Utiliser l'autoscaling vertical avec l'opérateur Spark pour Amazon EMR sur EKS
<a name="spark-operator-vas"></a>

À partir d'Amazon EMR 7.0, vous pouvez utiliser la mise à l'échelle automatique verticale d'Amazon EMR on EKS pour simplifier la gestion des ressources. Elle permet d'adapter automatiquement les ressources de mémoire et de CPU aux besoins de la charge de travail que vous fournissez aux applications Spark sur Amazon EMR. Pour de plus amples informations, veuillez consulter [Utilisation de la mise à l'échelle automatique verticale avec les tâches Spark sur Amazon EMR](jobruns-vas.md).

Cette section décrit comment configurer l'opérateur Spark pour utiliser l'autoscaling vertical.

## Conditions préalables
<a name="spark-operator-vas-prereqs"></a>

Avant de configurer la surveillance, veillez à effectuer les tâches de configuration suivantes :
+ Suivez les étapes de [Configuration de l'opérateur Spark pour Amazon EMR on EKS](spark-operator-setup.md).
+ (facultatif) Si vous avez déjà installé une ancienne version de l'opérateur Spark, supprimez le SparkApplication/ScheduledSparkApplication CRD.

  ```
  kubectl delete crd sparkApplication
  kubectl delete crd scheduledSparkApplication
  ```
+ Suivez les étapes de [Installation de l'opérateur Spark](spark-operator-gs.md#spark-operator-install). À l'étape 3, ajoutez la ligne suivante à la commande d'installation pour autoriser les webhooks pour l'opérateur :

  ```
  --set webhook.enable=true
  ```
+ Suivez les étapes de [Configuration de la mise à l'échelle automatique verticale pour Amazon EMR on EKS](jobruns-vas-setup.md).
+ Donnez accès aux fichiers se trouvant dans votre emplacement Amazon S3 :

  1. Annotez le compte de service de votre chauffeur et de votre opérateur avec `JobExecutionRole` les autorisations S3.

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

  1. Mettez à jour la politique de confiance de votre rôle d'exécution des tâches dans cet espace de noms.

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

  1. Modifiez la politique de confiance du rôle IAM de votre rôle d'exécution des tâches et mettez à jour le `serviceaccount` formulaire `emr-containers-sa-spark-*-*-xxxx` vers`emr-containers-sa-*`.

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

  1. Si vous utilisez Amazon S3 comme espace de stockage de fichiers, ajoutez les valeurs par défaut suivantes à votre fichier yaml.

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

## Exécuter une tâche avec l'autoscaling vertical sur l'opérateur Spark
<a name="spark-operator-vas-run"></a>

Pour pouvoir exécuter une application Spark à l'aide de l'opérateur Spark, vous devez suivre les étapes indiquées dans [Conditions préalables](#spark-operator-vas-prereqs). 

Pour utiliser la mise à l'échelle automatique verticale avec l'opérateur Spark, ajoutez la configuration suivante au pilote correspondant aux spécifications de votre application Spark afin d'activer la mise à l'échelle automatique verticale :

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

Cette configuration permet une mise à l'échelle automatique verticale et constitue une configuration de signature obligatoire qui vous permet de choisir une signature pour votre tâche.

Pour plus d'informations sur les configurations et les valeurs des paramètres, consultez [Configuration de l'autoscaling vertical pour Amazon EMR sur](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/jobruns-vas-configure.html) EKS. Par défaut, votre tâche est soumise en mode **Désactivé**, réservé à la surveillance uniquement, de la mise à l'échelle automatique verticale. Cet état de surveillance vous permet de calculer et de consulter les recommandations en matière de ressources sans procéder à la mise à l'échelle automatique. Pour plus d'informations, consultez la section [Modes de mise à l'échelle automatique verticaux](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/jobruns-vas-configure.html#jobruns-vas-parameters-opt-mode).

Voici un exemple de fichier de `SparkApplication` définition nommé `spark-pi.yaml` avec les configurations requises pour utiliser l'autoscaling vertical.

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

Maintenant, soumettez l'application Spark à l'aide de la commande suivante. Cela créera également un objet `SparkApplication` nommé `spark-pi` :

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

Pour plus d'informations sur l'envoi d'applications à Spark via l'opérateur Spark, consultez la section [Utiliser un `SparkApplication`](https://www.kubeflow.org/docs/components/spark-operator/user-guide/using-sparkapplication/) dans la `spark-on-k8s-operator` documentation sur GitHub.

## Vérification de la fonctionnalité de mise à l'échelle automatique verticale
<a name="spark-operator-vas-verify"></a>

Pour vérifier que la mise à l'échelle automatique verticale fonctionne correctement pour la tâche soumise, utilisez kubectl pour obtenir la ressource personnalisée `verticalpodautoscaler` et consulter vos recommandations de mise à l'échelle.

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

Le résultat de cette requête devrait ressembler à ce qui suit :

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

Si votre résultat ne ressemble pas à cela ou contient un code d'erreur, consultez [Résolution des problèmes de mise à l'échelle automatique verticale d'Amazon EMR on EKS](troubleshooting-vas.md) pour des étapes permettant de résoudre le problème.

Pour supprimer les modules et les applications, exécutez la commande suivante :

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

# Désinstallation de l'opérateur Spark pour Amazon EMR on EKS
<a name="spark-operator-uninstall"></a>

Procédez comme suit pour désinstaller l'opérateur Spark.

1. Supprimez l'opérateur Spark en utilisant le bon espace de noms. Dans cet exemple, l'espace de noms est `spark-operator-demo`.

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

1. Supprimez le compte de service de l'opérateur Spark :

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

1. Supprimez l'opérateur Spark `CustomResourceDefinitions` (CRDs) :

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

# Utilisation de la configuration de surveillance pour surveiller l'opérateur Spark Kubernetes et les tâches Spark
<a name="spark-operator-monitoring-configuration"></a>

La configuration de surveillance vous permet de configurer facilement l'archivage des journaux de votre application Spark et des journaux des opérateurs sur Amazon S3 ou vers Amazon CloudWatch. Vous pouvez choisir l'un ou les deux. Cela ajoute un sidecar d'agent de journalisation à vos modules d'opérateur, de pilote et d'exécuteur Spark, puis transmet les journaux de ces composants aux récepteurs que vous avez configurés.

## Conditions préalables
<a name="spark-operator-monitoring-configuration-prereqs"></a>

Avant de configurer la surveillance, veillez à effectuer les tâches de configuration suivantes :

1. (Facultatif) Si vous avez déjà installé une ancienne version de l'opérateur Spark, supprimez le *SparkApplication/ScheduledSparkApplication*CRD.

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

1. Créez un rôle operator/job d'exécution dans IAM si vous n'en avez pas déjà un.

1. Exécutez la commande suivante pour mettre à jour la politique de confiance du rôle operator/job d'exécution que vous venez de créer :

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

1. Modifiez la politique de confiance du rôle IAM de votre rôle operator/job d'exécution comme suit :

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

1. Créez une politique de *configuration de surveillance* dans IAM avec les autorisations suivantes :

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

****  

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

------

1. Associez la politique ci-dessus à votre rôle operator/job d'exécution.

# Journaux des opérateurs Spark
<a name="spark-operator-monitoring-configuration-logs"></a>

Vous pouvez définir la configuration de surveillance de la manière suivante lors de cette opération `helm install` :

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

**Configuration de surveillance**

Les options de configuration disponibles sous **MonitoringConfiguration** sont les suivantes.
+ **Image** (facultatif) — Enregistrez l'URL de l'image de l'agent. Je viendrai le chercher emrReleaseLabel s'il n'est pas fourni.
+ **s3 MonitoringConfiguration** — Définissez cette option pour archiver sur Amazon S3.
  + **LoGURI** — (obligatoire) — Le chemin du compartiment Amazon S3 dans lequel vous souhaitez stocker vos journaux.
  + Vous trouverez ci-dessous des exemples de formats pour les chemins de compartiment Amazon S3, une fois les journaux chargés. Le premier exemple montre qu'aucune rotation des journaux n'est activée.

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

    La rotation des journaux est activée par défaut. Vous pouvez voir à la fois un fichier pivoté, avec un index incrémenté, et un fichier en cours, identique à l'exemple précédent.

    ```
    s3://${logUri}/${POD NAME}/operator/stdout_YYYYMMDD_index.gz
    s3://${logUri}/${POD NAME}/operator/stderr_YYYYMMDD_index.gz
    ```
+ **cloudWatchMonitoringConfiguration** : clé de configuration vers laquelle configurer le transfert Amazon CloudWatch.
  + **logGroupName**(obligatoire) — Nom du groupe de Amazon CloudWatch journaux auquel vous souhaitez envoyer des journaux. Le groupe est automatiquement créé s'il n'existe pas.
  + **logStreamNamePréfixe** (facultatif) : nom du flux de journaux auquel vous souhaitez envoyer des journaux. La valeur par défaut est une chaîne vide. Le format Amazon CloudWatch est le suivant :

    ```
    ${logStreamNamePrefix}/${POD NAME}/STDOUT or STDERR
    ```
+ **sideCarResources**(facultatif) — La clé de configuration pour définir les limites de ressources sur le conteneur latéral Fluentd lancé.
  + **Limite de mémoire** (facultatif) — Limite de mémoire. Ajustez selon vos besoins. La valeur par défaut est 512Mi.
  + **CPULimit** (facultatif) — Limite du processeur. Ajustez selon vos besoins. La valeur par défaut est de 500 m.
+ **containerLogRotationConfiguration** (facultatif) — Contrôle le comportement de rotation du journal du conteneur. Il est activé par défaut.
  + **RotationSize** (obligatoire) — Spécifie la taille du fichier pour la rotation du journal. La plage de valeurs possibles est comprise entre 2 Ko et 2 Go. La partie unitaire numérique du paramètre rotationSize est transmise sous forme d'entier. Les valeurs décimales n'étant pas prises en charge, vous pouvez indiquer une taille de rotation de 1,5 Go, par exemple, avec la valeur 1500 Mo. La valeur par défaut est 2 Go.
  + **maxFilesToConserver** (obligatoire) — Spécifie le nombre maximum de fichiers à conserver dans le conteneur après la rotation. La valeur minimale est 1 et la valeur maximale est 50. La valeur par défaut est 10.

Après avoir configuré *MonitoringConfiguration*, vous devriez être en mesure de consulter les journaux des pods Spark Operator sur un compartiment Amazon S3 ou Amazon CloudWatch sur les deux. Pour un compartiment Amazon S3, vous devez attendre 2 minutes pour que le premier fichier journal soit vidé.

Pour trouver les connexions Amazon CloudWatch, vous pouvez accéder à ce qui suit : **CloudWatch**> **Groupes de journaux** > > ***Log group name**Pod name*****/operator/stderr**

Vous pouvez également accéder à : **CloudWatch**> **Groupes de journaux** > > ***Log group name**Pod name*****/operator/stdout**

# Journaux des applications Spark
<a name="spark-operator-monitoring-application-logs"></a>

Vous pouvez définir cette configuration de la manière suivante.

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

Les options de configuration disponibles sous **MonitoringConfiguration** sont les suivantes.
+ **Image** (facultatif) — Enregistrez l'URL de l'image de l'agent. Je viendrai le chercher emrReleaseLabel s'il n'est pas fourni.
+ **s3 MonitoringConfiguration** — Définissez cette option pour archiver sur Amazon S3.
  + **LoGURI** (obligatoire) — Le chemin du compartiment Amazon S3 dans lequel vous souhaitez stocker vos journaux. Le premier exemple montre qu'aucune rotation des journaux n'est activée :

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

    La rotation des journaux est activée par défaut. Vous pouvez utiliser à la fois un fichier pivoté (avec index incrémenté) et un fichier actuel (sans horodatage).

    ```
    s3://${logUri}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stdout_YYYYMMDD_index.gz
    s3://${logUri}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stderr_YYYYMMDD_index.gz
    ```
+ **cloudWatchMonitoringConfiguration** : clé de configuration vers laquelle configurer le transfert Amazon CloudWatch.
  + **logGroupName**(obligatoire) — Le nom du groupe de journaux Cloudwatch auquel vous souhaitez envoyer des journaux. Le groupe est automatiquement créé s'il n'existe pas.
  + **logStreamNamePréfixe** (facultatif) : nom du flux de journaux auquel vous souhaitez envoyer des journaux. La valeur par défaut est une chaîne vide. Le format CloudWatch est le suivant :

    ```
    ${logStreamNamePrefix}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stdout
    ${logStreamNamePrefix}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stderr
    ```
+ **sideCarResources**(facultatif) — La clé de configuration pour définir les limites de ressources sur le conteneur latéral Fluentd lancé.
  + **Limite de mémoire** (facultatif) — Limite de mémoire. Ajustez selon vos besoins. La valeur par défaut est 250 Mi.
  + **CPULimit — Limite** du processeur. Ajustez selon vos besoins. La valeur par défaut est de 500 m.
+ **containerLogRotationConfiguration** (facultatif) — Contrôle le comportement de rotation du journal du conteneur. Il est activé par défaut.
  + **RotationSize** (obligatoire) — Spécifie la taille du fichier pour la rotation du journal. La plage de valeurs possibles est comprise entre 2 Ko et 2 Go. La partie unitaire numérique du paramètre rotationSize est transmise sous forme d'entier. Les valeurs décimales n'étant pas prises en charge, vous pouvez indiquer une taille de rotation de 1,5 Go, par exemple, avec la valeur 1500 Mo. La valeur par défaut est 2 Go.
  + **maxFilesToConserver** (obligatoire) — Spécifie le nombre maximum de fichiers à conserver dans le conteneur après la rotation. La valeur minimale est de 1. La valeur maximale est de 50. La valeur par défaut est 10.

Après avoir configuré MonitoringConfiguration, vous devriez être en mesure de consulter les journaux du pilote et de l'exécuteur de votre application Spark sur un compartiment Amazon S3, ou sur les deux. CloudWatch Pour un compartiment Amazon S3, vous devez attendre 2 minutes pour que le premier fichier journal soit vidé. Par exemple, dans Amazon S3, le chemin du compartiment apparaît comme suit :

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

Ou:

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

Dans CloudWatch, le chemin apparaît comme suit :

**CloudWatch**> **Groupes de journaux** > ***Log group name***>*Spark application name - UUID*/*Pod name***/stderr**

Ou:

**CloudWatch**> **Groupes de journaux** > ***Log group name***>*Spark application name - UUID*/*Pod name***/stdout**

# Sécurité et opérateur Spark avec Amazon EMR on EKS
<a name="spark-operator-security"></a>

Il existe deux manières de configurer les autorisations d'accès au cluster lorsque vous utilisez l'opérateur Spark. La première consiste à utiliser le contrôle d'accès basé sur les rôles. Le contrôle d'accès basé sur les rôles (RBAC) restreint l'accès en fonction du rôle d'une personne au sein d'une organisation. C'est devenu le principal moyen de gérer l'accès. La deuxième méthode d'accès consiste à assumer un Gestion des identités et des accès AWS rôle, qui fournit un accès aux ressources au moyen d'autorisations spécifiques attribuées.

**Topics**
+ [Configuration des autorisations d'accès au cluster avec le contrôle d'accès basé sur les rôles (RBAC)](spark-operator-security-rbac.md)
+ [Configuration des autorisations d'accès au cluster avec des rôles IAM pour les comptes de service (IRSA)](spark-operator-security-irsa.md)

# Configuration des autorisations d'accès au cluster avec le contrôle d'accès basé sur les rôles (RBAC)
<a name="spark-operator-security-rbac"></a>

Pour déployer l'opérateur Spark, Amazon EMR on EKS crée deux rôles et comptes de service pour l'opérateur Spark et les applications Spark.

**Topics**
+ [Compte de service et rôle de l'opérateur](#spark-operator-sa-oper)
+ [Compte de service et rôle Spark](#spark-operator-sa-spark)

## Compte de service et rôle de l'opérateur
<a name="spark-operator-sa-oper"></a>

Amazon EMR on EKS crée le **compte de service et le rôle de l'opérateur** pour gérer `SparkApplications` pour les tâches Spark et pour d'autres ressources telles que les services.

Le nom par défaut de ce compte de service est `emr-containers-sa-spark-operator`.

Les règles suivantes s'appliquent à cette fonction du service : 

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

## Compte de service et rôle Spark
<a name="spark-operator-sa-spark"></a>

Le pod du pilote Spark a besoin d'un compte de service Kubernetes dans le même espace de noms que le pod. Ce compte de service a besoin d'autorisations pour créer, obtenir, répertorier, patcher et supprimer des pods d'exécuteurs, ainsi que pour créer un service Kubernetes sans tête pour le pilote. Le pilote échoue et se termine sans le compte de service, sauf si le compte de service par défaut dans l'espace de noms du pod dispose des autorisations requises.

Le nom par défaut de ce compte de service est `emr-containers-sa-spark`.

Les règles suivantes s'appliquent à cette fonction du service : 

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

# Configuration des autorisations d'accès au cluster avec des rôles IAM pour les comptes de service (IRSA)
<a name="spark-operator-security-irsa"></a>

Cette section utilise un exemple pour montrer comment configurer un compte de service Kubernetes pour qu'il assume un rôle. Gestion des identités et des accès AWS Les pods qui utilisent le compte de service peuvent ensuite accéder à tout AWS service auquel le rôle est autorisé à accéder.

L'exemple suivant exécute une application Spark pour compter les mots d'un fichier dans Amazon S3. Pour ce faire, vous pouvez configurer des rôles IAM pour les comptes de service (IRSA) afin d'authentifier et d'autoriser les comptes de service Kubernetes.

**Note**  
Cet exemple utilise l'espace de noms « spark-operator » pour l'opérateur Spark et pour l'espace de noms dans lequel vous soumettez l'application Spark.

## Conditions préalables
<a name="spark-operator-security-irsa-prereqs"></a>

Avant d'essayer l'exemple présenté sur cette page, vous devez remplir les conditions préalables suivantes :
+ [Préparez-vous pour l'utilisation de l'opérateur Spark]().
+ [Installation de l'opérateur Spark](spark-operator-gs.md#spark-operator-install).
+ [Créez un compartiment Amazon S3.](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html)
+ Enregistrez votre poème préféré dans un fichier texte nommé `poem.txt`, puis chargez ce fichier dans votre compartiment S3. L'application Spark que vous créez sur cette page lira le contenu du fichier texte. Pour plus d'informations sur le chargement des fichiers sur S3, consultez la rubrique [Chargement d'un objet dans votre compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-an-object-bucket.html) du *Guide de l'utilisateur Amazon Simple Storage Service*.

## Configuration d'un compte de service Kubernetes pour qu'il assume un rôle IAM
<a name="spark-operator-security-irsa-config"></a>

Suivez les étapes ci-dessous pour configurer un compte de service Kubernetes afin qu'il assume un rôle IAM que les pods peuvent utiliser pour accéder aux AWS services auxquels le rôle est autorisé à accéder.

1. Une fois le[Conditions préalables](#spark-operator-security-irsa-prereqs), utilisez le AWS Command Line Interface pour créer un `example-policy.json` fichier qui autorise un accès en lecture seule au fichier que vous avez chargé sur Amazon S3 :

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

1. Ensuite, créez une politique IAM `example-policy` :

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

1. Puis créez un rôle IAM `example-role` et associez-le à un compte de service Kubernetes pour le pilote Spark :

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

1. Créez un fichier yaml avec les liaisons de rôle de cluster qui sont nécessaires pour le compte de service du pilote Spark :

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

1. Appliquez les configurations de liaison des rôle du cluster :

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

La commande kubectl doit confirmer la création réussie du compte :

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

## Exécution d'une application depuis l'opérateur Spark
<a name="spark-operator-security-irsa-run"></a>

Après avoir [configuré le compte de service Kubernetes](), vous pouvez exécuter une application Spark qui compte le nombre de mots contenus dans le fichier texte que vous avez chargé dans le cadre des conditions préalables [Conditions préalables](#spark-operator-security-irsa-prereqs).

1. Créez un nouveau fichier`word-count.yaml`, avec une `SparkApplication` définition pour votre application de comptage de mots, sur la base de la version 6 d'Amazon EMR.

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

   Si vous utilisez l'opérateur Spark dans une version 7, vous devez ajuster certaines valeurs de configuration :

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

1. Soumettez l'application Spark.

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

   La commande kubectl doit renvoyer la confirmation que vous avez créé avec succès un objet `SparkApplication` appelé `word-count`.

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

1. Pour vérifier les événements de l'objet `SparkApplication`, exécutez la commande suivante :

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

   La commande kubectl doit renvoyer la description de `SparkApplication` avec les événements :

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

L'application compte maintenant les mots de votre fichier S3. Pour connaître le nombre de mots, consultez les fichiers journaux de votre pilote :

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

La commande kubectl doit renvoyer le contenu du fichier journal avec les résultats de votre application de comptage de mots.

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

Pour plus d'informations sur la façon de soumettre des applications à Spark via l'opérateur Spark, consultez la documentation relative SparkApplication à [l'utilisation d'un](https://www.kubeflow.org/docs/components/spark-operator/user-guide/using-sparkapplication/) opérateur *Kubernetes pour Apache Spark (opérateur spark-on-k 8s) sur.* GitHub

# Exécution de tâches Spark en utilisant spark-submit
<a name="spark-submit"></a>

Les versions 6.10.0 et supérieures d'Amazon EMR prennent en charge `spark-submit` en tant qu'outil de ligne de commande que vous pouvez utiliser pour soumettre et exécuter des applications Spark sur un cluster Amazon EMR on EKS.

**Note**  
Amazon EMR calcule les tarifs sur Amazon EKS en fonction du vCPU et de la consommation de mémoire. Ce calcul s'applique aux modules pilote et exécuteur. Ce calcul commence à partir du moment où vous téléchargez l'image de votre application Amazon EMR jusqu'à ce que le module Amazon EKS se termine et est arrondi à la seconde près.

**Topics**
+ [Configuration de spark-submit pour Amazon EMR on EKS](spark-submit-setup.md)
+ [Les premiers pas avec spark-submit pour Amazon EMR on EKS](spark-submit-gs.md)
+ [Vérifiez les exigences de sécurité du compte Spark Driver Service pour Spark-Submit](spark-submit-security.md)

# Configuration de spark-submit pour Amazon EMR on EKS
<a name="spark-submit-setup"></a>

Effectuez les tâches suivantes pour vous préparer à exécuter une application en utilisant spark-submit sur Amazon EMR on EKS. Si vous êtes déjà inscrit à Amazon Web Services (AWS) et que vous avez utilisé Amazon EKS, vous êtes presque prêt à utiliser Amazon EMR on EKS. Si vous avez déjà rempli l'une des conditions préalables, vous pouvez l'ignorer et passer à la suivante.
+ **[Installation ou mise à jour vers la dernière version du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)** — Si vous avez déjà installé le AWS CLI, vérifiez que vous disposez de la dernière version.
+ **[Configurer kubectl et eksctl — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)** est un outil de ligne de commande que vous utilisez pour communiquer avec Amazon EKS.
+ **[Commencez avec Amazon EKS — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)** — Suivez les étapes pour créer un nouveau cluster Kubernetes avec des nœuds dans Amazon EKS.
+ **[Sélectionner l'URI d'une image de base Amazon EMR](docker-custom-images-tag.md) (version 6.10.0 ou supérieure)** – La commande `spark-submit` est prise en charge par les versions 6.10.0 et supérieures d'Amazon EMR.
+ Confirmez que le compte de service du pilote dispose des autorisations nécessaires pour créer et surveiller les pods d'exécuteurs. Pour de plus amples informations, veuillez consulter [Vérifiez les exigences de sécurité du compte Spark Driver Service pour Spark-Submit](spark-submit-security.md).
+ Configurez votre [profil d'informations d'identification AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) local.
+ Dans la console Amazon EKS, choisissez votre cluster EKS, puis recherchez le point de terminaison du cluster EKS, situé sous **Vue d'ensemble**, **Détails**, puis point de **terminaison du serveur API**.

# Les premiers pas avec spark-submit pour Amazon EMR on EKS
<a name="spark-submit-gs"></a>

Amazon EMR en version 6.10.0 et supérieure prend en charge spark-submit pour l'exécution d'applications Spark sur un cluster Amazon EKS. La section qui suit explique comment envoyer une commande pour une application Spark.

## Exécution d'une application Spark
<a name="spark-submit-run"></a>

Pour exécuter l'application Spark, procédez comme suit :

1. Pour pouvoir exécuter une application Spark à l'aide de la commande `spark-submit`, suivez les étapes indiquées dans [Configuration de spark-submit pour Amazon EMR on EKS](spark-submit-setup.md). 

1. Exécutez un conteneur avec une image de base Amazon EMR on EKS. Consultez [Comment sélectionner un URI d'image de base](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html) pour plus d'informations.

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

1. Définissez les valeurs des variables d'environnement suivantes :

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

1. Maintenant, soumettez l'application Spark avec la commande suivante :

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

Pour plus d'informations sur la soumission des applications à Spark, consultez la rubrique [Soumission d'applications](https://spark.apache.org/docs/latest/submitting-applications.html) dans la documentation Apache Spark.

**Important**  
`spark-submit` prend uniquement en charge le mode cluster comme mécanisme de soumission.

# Vérifiez les exigences de sécurité du compte Spark Driver Service pour Spark-Submit
<a name="spark-submit-security"></a>

Le pod du pilote Spark utilise un compte de service Kubernetes pour accéder au serveur d'API Kubernetes afin de créer et de surveiller les pods d'exécuteurs. Le compte de service du pilote doit disposer des autorisations appropriées pour répertorier, créer, modifier, corriger et supprimer les pods dans votre cluster. Vous pouvez vérifier que vous pouvez répertorier ces ressources en exécutant la commande suivante :

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

Vérifiez que vous disposez des autorisations nécessaires en exécutant chaque commande.

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

Les règles suivantes s'appliquent à cette fonction du service : 

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

# Configuration des rôles IAM pour les comptes de service (IRSA) pour spark-submit
<a name="spark-submit-security-irsa"></a>

Les sections suivantes expliquent comment configurer les rôles IAM pour les comptes de service (IRSA) afin d'authentifier et d'autoriser les comptes de service Kubernetes afin que vous puissiez exécuter des applications Spark stockées dans Amazon S3.

## Conditions préalables
<a name="spark-submit-security-irsa-prereqs"></a>

Avant d'essayer l'un des exemples de cette documentation, assurez-vous que vous avez rempli les conditions préalables suivantes :
+ [Configuration de Spark-Submit terminée](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/spark-submit-setup.html)
+ [Création d'un compartiment S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html) et [téléchargement du fichier](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-an-object-bucket.html) jar de l'application Spark

## Configuration d'un compte de service Kubernetes pour qu'il assume un rôle IAM
<a name="spark-submit-security-irsa-configure-kubernetes"></a>

Les étapes suivantes expliquent comment configurer un compte de service Kubernetes pour qu'il assume un rôle Gestion des identités et des accès AWS (IAM). Une fois que vous avez configuré les pods pour utiliser le compte de service, ils peuvent accéder à tous Service AWS ceux auxquels le rôle est autorisé à accéder.

1. [Créez un fichier de politique pour autoriser l'accès en lecture seule à l'objet Amazon S3 que vous avez chargé :](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-an-object-bucket.html)

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

1. Créez la politique IAM.

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

1. Créez un rôle IAM et associez-le à un compte de service Kubernetes pour le pilote Spark

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

1. Créez un fichier YAML avec les [autorisations](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/spark-submit-security.html) requises pour le compte de service de pilote Spark :

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

1. Appliquez les configurations de liaison des rôles du cluster.

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

1. La `kubectl` commande doit renvoyer une confirmation du compte créé.

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

## Exécution de l'application Spark
<a name="spark-submit-security-irsa-app-run"></a>

Amazon EMR en version 6.10.0 et supérieure prend en charge spark-submit pour l'exécution d'applications Spark sur un cluster Amazon EKS. Pour exécuter l'application Spark, procédez comme suit :

1. Assurez-vous d'avoir suivi les étapes décrites dans [Configuration de spark-submit pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/spark-submit-setup.html) sur EKS.

1. Définissez les valeurs des variables d'environnement suivantes :

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

1. Maintenant, soumettez l'application Spark avec la commande suivante :

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

1. Une fois que le pilote Spark a terminé la tâche Spark, vous devriez voir une ligne de journal à la fin de la soumission indiquant que la tâche Spark est terminée.

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

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

Lorsque vous avez terminé d'exécuter vos applications, vous pouvez effectuer le nettoyage à l'aide de la commande suivante.

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

# Utilisation d'Apache Livy avec Amazon EMR sur EKS
<a name="job-runs-apache-livy"></a>

Avec les versions 7.1.0 et supérieures d'Amazon EMR, vous pouvez utiliser Apache Livy pour soumettre des tâches sur Amazon EMR sur EKS. À l'aide d'Apache Livy, vous pouvez configurer votre propre point de terminaison REST Apache Livy et l'utiliser pour déployer et gérer des applications Spark sur vos clusters Amazon EKS. Après avoir installé Livy dans votre cluster Amazon EKS, vous pouvez utiliser le point de terminaison Livy pour envoyer des applications Spark à votre serveur Livy. Le serveur gère le cycle de vie des applications Spark.

**Note**  
Amazon EMR calcule les tarifs sur Amazon EKS en fonction du vCPU et de la consommation de mémoire. Ce calcul s'applique aux modules pilote et exécuteur. Ce calcul commence à partir du moment où vous téléchargez l'image de votre application Amazon EMR jusqu'à ce que le module Amazon EKS se termine et est arrondi à la seconde près.

**Topics**
+ [Configuration d'Apache Livy pour Amazon EMR sur EKS](job-runs-apache-livy-setup.md)
+ [Commencer à utiliser Apache Livy sur Amazon EMR sur EKS](job-runs-apache-livy-install.md)
+ [Exécution d'une application Spark avec Apache Livy pour Amazon EMR sur EKS](job-runs-apache-livy-run-spark.md)
+ [Désinstaller Apache Livy avec Amazon EMR sur EKS](job-runs-apache-livy-uninstall.md)
+ [Sécurité pour Apache Livy avec Amazon EMR sur EKS](job-runs-apache-livy-security.md)
+ [Propriétés d'installation d'Apache Livy sur Amazon EMR sur les versions EKS](job-runs-apache-livy-installation-properties.md)
+ [Résoudre les erreurs de format courantes liées aux variables d'environnement](job-runs-apache-livy-troubleshooting.md)

# Configuration d'Apache Livy pour Amazon EMR sur EKS
<a name="job-runs-apache-livy-setup"></a>

Avant de pouvoir installer Apache Livy sur votre cluster Amazon EKS, vous devez installer et configurer un ensemble d'outils prérequis. Il s'agit notamment de l' AWS CLI outil de ligne de commande fondamental pour utiliser les AWS ressources, des outils de ligne de commande pour travailler avec Amazon EKS et d'un contrôleur utilisé dans ce cas d'utilisation pour mettre votre application de cluster à disposition sur Internet et pour acheminer le trafic réseau.
+ **[Installation ou mise à jour vers la dernière version du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)** — Si vous avez déjà installé le AWS CLI, vérifiez que vous disposez de la dernière version.
+ **[Configurer kubectl et eksctl — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)** est un outil de ligne de commande que vous utilisez pour communiquer avec Amazon EKS.
+ **[Installer Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)** – Le gestionnaire de packages Helm pour Kubernetes vous aide à installer et à gérer des applications sur votre cluster Kubernetes. 
+ **[Commencez avec Amazon EKS — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)** — Suivez les étapes pour créer un nouveau cluster Kubernetes avec des nœuds dans Amazon EKS.
+ **[Sélectionnez une étiquette de version Amazon EMR](docker-custom-images-tag.md)** : Apache Livy est compatible avec les versions 7.1.0 et supérieures d'Amazon EMR.
+ **[Installez le contrôleur ALB : le contrôleur](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html)** ALB gère AWS Elastic Load Balancing pour les clusters Kubernetes. Il crée un AWS Network Load Balancer (NLB) lorsque vous créez une entrée Kubernetes lors de la configuration d'Apache Livy.

# Commencer à utiliser Apache Livy sur Amazon EMR sur EKS
<a name="job-runs-apache-livy-install"></a>

Procédez comme suit pour installer Apache Livy. Elles incluent la configuration du gestionnaire de packages, la création d'un espace de noms pour exécuter les charges de travail Spark, l'installation de Livy, la configuration de l'équilibrage de charge et les étapes de vérification. Vous devez suivre ces étapes pour exécuter un traitement par lots avec Spark.

1. Si ce n'est pas déjà fait, configurez [Apache Livy pour Amazon EMR sur](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html) EKS.

1. Authentifiez votre client Helm dans le registre Amazon ECR. Vous pouvez trouver la `ECR-registry-account` valeur correspondante pour vos [comptes Région AWS de registre Amazon ECR par région.](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html#docker-custom-images-ECR)

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

1. La configuration de Livy crée un compte de service pour le serveur Livy et un autre compte pour l'application Spark. Pour configurer l'IRSA pour les comptes de service, consultez la section [Configuration des autorisations d'accès avec les rôles IAM pour les comptes de service (IRSA](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-irsa.html)). 

1. Créez un espace de noms pour exécuter vos charges de travail Spark.

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

1. Utilisez la commande suivante pour installer Livy.

   Ce point de terminaison Livy est uniquement disponible en interne pour le VPC dans le cluster EKS. Pour activer l'accès au-delà du VPC, définissez `—-set loadbalancer.internal=false` votre commande d'installation Helm.
**Note**  
Par défaut, le protocole SSL n'est pas activé dans ce point de terminaison Livy et le point de terminaison n'est visible que dans le VPC du cluster EKS. Si vous définissez `loadbalancer.internal=false` et`ssl.enabled=false`, vous exposez un point de terminaison non sécurisé à l'extérieur de votre VPC. Pour configurer un point de terminaison Livy sécurisé, voir [Configuration d'un point de terminaison Apache Livy sécurisé avec TLS/SSL](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-secure-endpoint.html). 

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

   Le résultat suivant doit s'afficher.

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

   Les noms de compte de service par défaut pour le serveur Livy et la session Spark sont `emr-containers-sa-livy` et`emr-containers-sa-spark-livy`. Pour utiliser des noms personnalisés, utilisez les `sparkServiceAccount.name` paramètres `serviceAccounts.name` et.

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

1. Vérifiez que vous avez installé le graphique Helm.

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

   La `helm list` commande doit renvoyer des informations sur votre nouveau graphique Helm.

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

1. Vérifiez que le Network Load Balancer est actif.

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

1. Vérifiez maintenant que le groupe cible du Network Load Balancer est sain.

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

   Voici un exemple de sortie qui montre l'état du groupe cible :

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

   Une fois que le statut de votre NLB sera atteint `active` et que votre groupe cible l'est`healthy`, vous pouvez continuer. Cette opération peut durer quelques minutes.

1. Récupérez le point de terminaison Livy depuis l'installation de Helm. La sécurité de votre point de terminaison Livy dépend de l'activation ou non du protocole SSL.

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

1. Récupérez le compte de service Spark depuis l'installation de Helm

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

   Le résultat doit ressembler à celui-ci :

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

1. Si vous avez configuré `internalALB=true` pour activer l'accès depuis l'extérieur de votre VPC, créez une EC2 instance Amazon et assurez-vous que le Network Load Balancer autorise le trafic réseau provenant de l'instance. EC2 Vous devez le faire pour que l'instance ait accès à votre point de terminaison Livy. Pour plus d'informations sur l'exposition sécurisée de votre point de terminaison en dehors de votre VPC, consultez [Configuration avec un point de terminaison Apache Livy sécurisé avec](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-secure-endpoint.html) TLS/SSL.

1. L'installation de Livy crée le compte de service `emr-containers-sa-spark` pour exécuter les applications Spark. Si votre application Spark utilise des AWS ressources telles que S3 ou appelle des opérations d' AWS API ou de CLI, vous devez associer un rôle IAM doté des autorisations nécessaires à votre compte de service Spark. Pour plus d'informations, voir [Configuration des autorisations d'accès avec les rôles IAM pour les comptes de service (IRSA](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-irsa.html)).

Apache Livy prend en charge des configurations supplémentaires que vous pouvez utiliser lors de l'installation de Livy. Pour plus d'informations, consultez la section Propriétés d'installation d'Apache Livy sur Amazon EMR sur les versions EKS.

# Exécution d'une application Spark avec Apache Livy pour Amazon EMR sur EKS
<a name="job-runs-apache-livy-run-spark"></a>

Avant de pouvoir exécuter une application Spark avec Apache Livy, assurez-vous d'avoir suivi les étapes décrites dans [Configuration d'Apache Livy pour Amazon EMR sur EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html) et [Démarrage avec Apache Livy pour Amazon](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-install.html) EMR sur EKS.

Vous pouvez utiliser Apache Livy pour exécuter deux types d'applications :
+ Sessions par lots : type de charge de travail Livy permettant de soumettre des tâches par lots Spark.
+ Sessions interactives : type de charge de travail Livy qui fournit une interface programmatique et visuelle pour exécuter des requêtes Spark.

**Note**  
Les pods pilote et exécuteur issus de différentes sessions peuvent communiquer entre eux. Les espaces de noms ne garantissent aucune sécurité entre les pods. Kubernetes n'autorise pas d'autorisations sélectives sur un sous-ensemble de pods au sein d'un espace de noms donné.

## Exécution de sessions par lots
<a name="job-runs-apache-livy-run-spark-batch"></a>

Pour soumettre un traitement par lots, utilisez la commande suivante.

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

Pour surveiller votre traitement par lots, utilisez la commande suivante.

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

## Organisation de sessions interactives
<a name="job-runs-apache-livy-run-spark-interactive"></a>

Pour exécuter des sessions interactives avec Apache Livy, suivez les étapes ci-dessous.

1. Assurez-vous d'avoir accès à un bloc-notes Jupyter auto-hébergé ou géré, tel qu'un bloc-notes Jupyter SageMaker AI. [Sparkmagic](https://github.com/jupyter-incubator/sparkmagic/blob/master/README.md) doit être installé sur votre bloc-notes Jupyter.

1. Créez un bucket pour la configuration de Spark`spark.kubernetes.file.upload.path`. Assurez-vous que le compte de service Spark dispose d'un accès en lecture et en écriture au bucket. Pour plus de détails sur la configuration de votre compte de service Spark, consultez Configuration des autorisations d'accès avec les rôles IAM pour les comptes de service (IRSA)

1. Chargez sparkmagic dans le bloc-notes Jupyter à l'aide de la commande. `%load_ext sparkmagic.magics`

1. Exécutez la commande `%manage_spark` pour configurer votre point de terminaison Livy avec le bloc-notes Jupyter. **Choisissez l'onglet **Ajouter des points de terminaison**, choisissez le type d'authentification configuré, ajoutez le point de terminaison Livy au bloc-notes, puis choisissez Ajouter un point de terminaison.**

1. Exécutez à `%manage_spark` nouveau pour créer le contexte Spark, puis accédez à la **session Create**. Choisissez le point de terminaison Livy, spécifiez un nom de session unique, choisissez une langue, puis ajoutez les propriétés suivantes.

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

1. Soumettez l'application et attendez qu'elle crée le contexte Spark.

1. Pour contrôler l'état de la session interactive, exécutez la commande suivante.

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

## Surveillance des applications Spark
<a name="job-runs-apache-livy-run-ui"></a>

Pour suivre la progression de vos applications Spark avec l'interface utilisateur Livy, utilisez le lien`http://<livy-endpoint>/ui`.

# Désinstaller Apache Livy avec Amazon EMR sur EKS
<a name="job-runs-apache-livy-uninstall"></a>

Pour désinstaller Apache Livy, procédez comme suit.

1. Supprimez la configuration de Livy en utilisant les noms de votre espace de noms et le nom de votre application. Dans cet exemple, le nom de l'application est `livy-demo` et l'espace de noms est`livy-ns`.

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

1. Lors de la désinstallation, Amazon EMR on EKS supprime le service Kubernetes dans Livy, les équilibreurs de charge et AWS les groupes cibles que vous avez créés lors de l'installation. La suppression de ressources peut prendre quelques minutes. Assurez-vous que les ressources sont supprimées avant de réinstaller Livy sur l'espace de noms.

1. Supprimez l'espace de noms Spark.

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

# Sécurité pour Apache Livy avec Amazon EMR sur EKS
<a name="job-runs-apache-livy-security"></a>

Consultez les rubriques suivantes pour en savoir plus sur la configuration de la sécurité pour Apache Livy avec Amazon EMR sur EKS. Ces options incluent l'utilisation de la sécurité de la couche de transport, le contrôle d'accès basé sur les rôles, c'est-à-dire l'accès basé sur le rôle d'une personne au sein d'une organisation, et l'utilisation des rôles IAM, qui fournissent un accès aux ressources, en fonction des autorisations accordées.

**Topics**
+ [Configuration d'un point de terminaison Apache Livy sécurisé avec TLS/SSL](job-runs-apache-livy-secure-endpoint.md)
+ [Configuration des autorisations des applications Apache Livy et Spark avec le contrôle d'accès basé sur les rôles (RBAC)](job-runs-apache-livy-rbac.md)
+ [Configuration des autorisations d'accès avec des rôles IAM pour les comptes de service (IRSA)](job-runs-apache-livy-irsa.md)

# Configuration d'un point de terminaison Apache Livy sécurisé avec TLS/SSL
<a name="job-runs-apache-livy-secure-endpoint"></a>

Consultez les sections suivantes pour en savoir plus sur la configuration d'Apache Livy pour Amazon EMR sur EKS end-to-end avec le chiffrement TLS et SSL.

## Configuration du chiffrement TLS et SSL
<a name="job-runs-apache-livy-security-tls"></a>

Pour configurer le chiffrement SSL sur votre point de terminaison Apache Livy, procédez comme suit.
+ [Installez le pilote CSI Secrets Store et le fournisseur de AWS secrets et de configuration (ASCP) : le pilote CSI et l'ASCP](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html) de Secrets Store stockent en toute sécurité les certificats JKS et les mots de passe de Livy dont le pod de serveur Livy a besoin pour activer le protocole SSL. Vous pouvez également installer uniquement le pilote CSI Secrets Store et utiliser n'importe quel autre fournisseur de secrets compatible.
+ [Créez un certificat ACM : ce certificat](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) est nécessaire pour sécuriser la connexion entre le client et le point de terminaison ALB.
+ Configurez un certificat JKS, un mot de passe clé et un mot de passe de banque de clés pour AWS Secrets Manager  : nécessaire pour sécuriser la connexion entre le point de terminaison ALB et le serveur Livy.
+ Ajoutez des autorisations au compte de service Livy pour récupérer les secrets AWS Secrets Manager  : le serveur Livy a besoin de ces autorisations pour récupérer les secrets depuis ASCP et ajouter les configurations Livy pour sécuriser le serveur Livy. Pour ajouter des autorisations IAM à un compte de service, voir Configuration des autorisations d'accès avec des rôles IAM pour les comptes de service (IRSA).

### Configuration d'un certificat JKS avec une clé et un mot de passe de keystore pour AWS Secrets Manager
<a name="job-runs-apache-livy-jks-certificate"></a>

Procédez comme suit pour configurer un certificat JKS avec une clé et un mot de passe pour le keystore.

1. Générez un fichier keystore pour le serveur Livy.

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

1. Créez un certificat.

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

1. Créez un fichier Truststore.

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

1. Enregistrez le certificat JKS dans. AWS Secrets Manager`livy-jks-secret`Remplacez-le par votre code secret et `fileb://mykeystore.jks` par le chemin d'accès à votre certificat JKS de keystore.

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

1. Enregistrez le keystore et le mot de passe clé dans Secrets Manager. Assurez-vous d'utiliser vos propres paramètres.

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

1. Créez un espace de noms de serveur Livy à l'aide de la commande suivante.

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

1. Créez l'`ServiceProviderClass`objet pour le serveur Livy qui possède le certificat JKS et les mots de passe.

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

## Commencer à utiliser Apache Livy compatible SSL
<a name="job-runs-apache-livy-ssl-enabled-getting-started"></a>

Après avoir activé le SSL sur votre serveur Livy, vous devez configurer le `serviceAccount` pour avoir accès aux `keyPasswords` secrets `keyStore` et. AWS Secrets Manager

1. Créez l'espace de noms du serveur Livy.

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

1. Configurez le compte de service Livy pour avoir accès aux secrets dans Secrets Manager. Pour plus d'informations sur la configuration de l'IRSA, voir [Configuration de l'IRSA lors de l'installation d'Apache Livy](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-irsa.html#job-runs-apache-livy-irsa).

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

1. Installez Livy. Pour le paramètre Helm chart --version, utilisez votre étiquette de version Amazon EMR, telle que. `7.1.0` Vous devez également remplacer l'ID de compte de registre Amazon ECR et l'ID de région par les vôtres. IDs Vous pouvez trouver la `ECR-registry-account` valeur correspondante pour vos [comptes Région AWS de registre Amazon ECR par région.](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html#docker-custom-images-ECR)

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

1. Continuez à partir de l'étape 5 de l'[installation d'Apache Livy sur Amazon EMR](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html#job-runs-apache-livy-install) sur EKS.

# Configuration des autorisations des applications Apache Livy et Spark avec le contrôle d'accès basé sur les rôles (RBAC)
<a name="job-runs-apache-livy-rbac"></a>

Pour déployer Livy, Amazon EMR on EKS crée un compte et un rôle de service de serveur, ainsi qu'un compte et un rôle de service Spark. Ces rôles doivent disposer des autorisations RBAC nécessaires pour terminer la configuration et exécuter les applications Spark.

**Autorisations RBAC pour le compte de service et le rôle du serveur**

Amazon EMR on EKS crée le compte de service et le rôle du serveur Livy pour gérer les sessions Livy pour les tâches Spark et acheminer le trafic vers et depuis l'entrée et d'autres ressources.

Le nom par défaut de ce compte de service est `emr-containers-sa-livy`. Il doit disposer des autorisations suivantes.

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

**Autorisations RBAC pour le compte et le rôle du service Spark**

Le pod du pilote Spark a besoin d'un compte de service Kubernetes dans le même espace de noms que le pod. Ce compte de service a besoin d'autorisations pour gérer les modules d'exécution et toutes les ressources requises par le module de pilotes. À moins que le compte de service par défaut de l'espace de noms ne dispose des autorisations requises, le pilote échoue et se ferme. Les autorisations RBAC suivantes sont requises.

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

# Configuration des autorisations d'accès avec des rôles IAM pour les comptes de service (IRSA)
<a name="job-runs-apache-livy-irsa"></a>

Par défaut, le serveur Livy et le pilote et les exécuteurs de l'application Spark n'ont pas accès aux AWS ressources. Le compte de service du serveur et le compte de service Spark contrôlent l'accès aux AWS ressources pour le serveur Livy et les pods de l'application Spark. Pour accorder l'accès, vous devez associer les comptes de service à un rôle IAM disposant des AWS autorisations nécessaires.

Vous pouvez configurer le mappage IRSA avant d'installer Apache Livy, pendant l'installation ou après l'avoir terminée.

## Configuration de l'IRSA lors de l'installation d'Apache Livy (pour le compte de service du serveur)
<a name="job-runs-apache-livy-irsa"></a>

**Note**  
Ce mappage n'est pris en charge que pour le compte de service du serveur.

1. Assurez-vous que vous avez terminé de [configurer Apache Livy pour Amazon EMR sur](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html) EKS et que vous êtes en train [d'installer Apache Livy avec Amazon EMR](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-install.html) sur EKS. 

1. Créez un espace de noms Kubernetes pour le serveur Livy. Dans cet exemple, le nom de l'espace de noms est`livy-ns`.

1. Créez une politique IAM qui inclut les Services AWS autorisations auxquelles vous souhaitez que vos pods accèdent. L'exemple suivant crée une politique IAM permettant d'obtenir des ressources Amazon S3 pour le point d'entrée Spark.

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

1. Utilisez la commande suivante pour attribuer une variable à votre Compte AWS identifiant.

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

1. Définissez le fournisseur d'identité OpenID Connect (OIDC) de votre cluster sur une variable d'environnement.

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

1. Définissez des variables pour l'espace de noms et le nom du compte de service. Veillez à utiliser vos propres valeurs.

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

1. Créez un fichier de politique de confiance à l'aide de la commande suivante. Si vous souhaitez accorder l'accès au rôle à tous les comptes de service d'un espace de noms, copiez la commande suivante, remplacez `StringEquals` par `StringLike` et remplacez `$service_account` par`*`.

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

1. Créez le rôle.

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

1. Utilisez la commande d'installation Helm suivante pour configurer IRSA `serviceAccount.executionRoleArn` pour mapper l'IRSA. Voici un exemple de commande d'installation de Helm. Vous pouvez trouver la `ECR-registry-account` valeur correspondante pour vos [comptes Région AWS de registre Amazon ECR par région.](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html#docker-custom-images-ECR)

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

## Associer IRSA à un compte de service Spark
<a name="job-runs-apache-livy-irsa-spark"></a>

Avant de mapper IRSA à un compte de service Spark, assurez-vous d'avoir effectué les tâches suivantes :
+ Assurez-vous que vous avez terminé de [configurer Apache Livy pour Amazon EMR sur](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html) EKS et que vous êtes en train [d'installer Apache Livy avec Amazon EMR](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-install.html) sur EKS. 
+ Vous devez disposer d'un fournisseur IAM OpenID Connect (OIDC) existant pour votre cluster. Pour savoir si vous en avez déjà un ou comment en créer un, voir [Créer un fournisseur IAM OIDC pour votre cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
+ Assurez-vous d'avoir installé la version 0.171.0 ou ultérieure de la `eksctl` CLI installée ou. AWS CloudShell Pour installer ou mettre à jour`eksctl`, consultez la section [Installation](https://eksctl.io/installation/) de la `eksctl` documentation.

Pour associer IRSA à votre compte de service Spark, procédez comme suit :

1. Utilisez la commande suivante pour obtenir le compte de service Spark.

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

1. Définissez vos variables pour l'espace de noms et le nom du compte de service.

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

1. Utilisez la commande suivante pour créer un fichier de politique de confiance pour le rôle IAM. L'exemple suivant autorise tous les comptes de service de l'espace de noms à utiliser le rôle. Pour ce faire, remplacez `StringEquals` par `StringLike` et remplacez `$service_account` par \$1.

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

1. Créez le rôle.

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

1. Mappez le serveur ou le compte de service Spark à l'aide de la `eksctl` commande suivante. Assurez-vous d'utiliser vos propres valeurs.

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

# Propriétés d'installation d'Apache Livy sur Amazon EMR sur les versions EKS
<a name="job-runs-apache-livy-installation-properties"></a>

L'installation d'Apache Livy vous permet de sélectionner une version du graphique Livy Helm. Le diagramme Helm propose une variété de propriétés pour personnaliser votre expérience d'installation et de configuration. Ces propriétés sont prises en charge pour Amazon EMR sur EKS versions 7.1.0 et supérieures.

**Topics**
+ [Propriétés d'installation d'Amazon EMR 7.1.0](#job-runs-apache-livy-installation-properties-710)

## Propriétés d'installation d'Amazon EMR 7.1.0
<a name="job-runs-apache-livy-installation-properties-710"></a>

Le tableau suivant décrit toutes les propriétés Livy prises en charge. Lors de l'installation d'Apache Livy, vous pouvez choisir la version du graphique Livy Helm. Pour définir une propriété lors de l'installation, utilisez la commande`--set <property>=<value>`.


| Propriété | Description | Par défaut | 
| --- | --- | --- | 
| image | L'URI de version Amazon EMR du serveur Livy. Il s'agit d'une configuration obligatoire. | "" | 
| Espace de noms Spark | Espace de noms pour exécuter des sessions Livy Spark. Par exemple, spécifiez « livy ». Il s'agit d'une configuration obligatoire. | "" | 
| Nom Override | Entrez un nom au lieu delivy. Le nom est défini comme étiquette pour toutes les ressources Livy | « Livy » | 
| Nom complet Override | Indiquez un nom à utiliser au lieu du nom complet des ressources. | "" | 
| activé par SSL | Active le end-to-end protocole SSL depuis le point de terminaison Livy vers le serveur Livy. | FALSE | 
| Certificat SSL ARN | Si le protocole SSL est activé, il s'agit de l'ARN du certificat ACM pour le NLB créé par le service. | "" | 
| ssl. secretProviderClassNom | Si le protocole SSL est activé, il s'agit du nom de classe du fournisseur secret permettant de sécuriser le NLB pour la connexion au serveur Livy avec SSL. | "" | 
| ssl. keyStoreObjectNom | Si le protocole SSL est activé, le nom de l'objet du certificat keystore dans la classe du fournisseur secret. | "" | 
| ssl. keyPasswordsObjectNom | Si le protocole SSL est activé, nom de l'objet du secret contenant le keystore et le mot de passe clé. | "" | 
| rbac.create | Si vrai, crée des ressources RBAC. | FALSE | 
| Compte de service. Créer | Si c'est vrai, crée un compte de service Livy. | TRUE | 
| Nom du compte de service | Le nom du compte de service à utiliser pour Livy. Si vous ne définissez pas cette propriété et ne créez pas de compte de service, Amazon EMR sur EKS génère automatiquement un nom à l'aide de la propriété fullname override. | "emr-containers-sa-livy" | 
| Compte de service. executionRoleArn | L'ARN du rôle d'exécution du compte de service Livy. | "" | 
| sparkServiceAccount.créer | SI c'est vrai, crée le compte de service Spark dans .Release.Namespace | TRUE | 
| sparkServiceAccount.nom | Le nom du compte de service à utiliser pour Spark. Si vous ne définissez pas cette propriété et ne créez pas de compte de service Spark, Amazon EMR sur EKS génère automatiquement un nom avec le suffixe de la fullnameOverride propriété. -spark-livy | « emr-containers-sa-spark -Livy » | 
| nom du service | Nom du service Livy | "emr-containers-livy" | 
| service.annotations | Annotations du service Livy | \$1\$1 | 
| loadbalancer.enabled | S'il faut créer un équilibreur de charge pour le service Livy utilisé pour exposer le point de terminaison Livy en dehors du cluster Amazon EKS. | FALSE | 
| équilibreur de charge interne | S'il faut configurer le point de terminaison Livy en tant qu'interne au VPC ou externe. La définition de cette propriété pour `FALSE` exposer le point de terminaison à des sources extérieures au VPC. Nous vous recommandons de sécuriser votre terminal avec le protocole TLS/SSL. Pour plus d'informations, consultez la section [Configuration du chiffrement TLS et SSL](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-security.html#job-runs-apache-livy-security-tls). | FALSE | 
| imagePullSecrets | La liste des imagePullSecret noms à utiliser pour extraire une image de Livy depuis des référentiels privés. | [] | 
| resources | Les demandes de ressources et les limites pour les conteneurs Livy. | \$1\$1 | 
| nodeSelector | Les nœuds pour lesquels planifier les modules Livy. | \$1\$1 | 
| tolérances | Une liste contenant les tolérances à définir pour les pods Livy. | [] | 
| affinité | Les règles d'affinité des Livy Pods. | \$1\$1 | 
| persistence.enabled | Si vrai, active la persistance pour les répertoires de sessions. | FALSE | 
| Persistence.subPath | Le sous-chemin PVC à monter dans les répertoires de sessions. | "" | 
| Persistance. Réclamation existante | Le PVC à utiliser au lieu d'en créer un nouveau. | \$1\$1 | 
| Persistance. Classe de stockage | Classe de stockage à utiliser. Pour définir ce paramètre, utilisez le formatstorageClassName: <storageClass>. La définition de ce paramètre pour "-" désactiver le provisionnement dynamique. Si vous définissez ce paramètre sur null ou si vous ne spécifiez rien, Amazon EMR sur EKS ne définit pas de fournisseur storageClassName et utilise le fournisseur par défaut. | "" | 
| Persistance. Mode d'accès | Le mode d'accès au PVC. | ReadWriteOnce | 
| persistence.size | La taille du PVC. | 20 Gi | 
| persistence.annotations | Annotations supplémentaires pour le PVC. | \$1\$1 | 
| env. \$1 | Envs supplémentaires à régler sur le conteneur Livy. Pour plus d'informations, voir Saisir [vos propres configurations Livy et Spark lors de l'installation](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-troubleshooting.html) de Livy. | \$1\$1 | 
| Env à partir de. \$1 | Environnements supplémentaires à définir sur Livy à partir d'une carte de configuration ou d'un secret de Kubernetes. | [] | 
| LivyConf. \$1 | Entrées livy.conf supplémentaires à définir à partir d'une carte ou d'un secret de configuration Kubernetes monté. | \$1\$1 | 
| sparkDefaultsConf.\$1 | spark-defaults.confEntrées supplémentaires à définir à partir d'une carte ou d'un secret de configuration Kubernetes monté. | \$1\$1 | 

# Résoudre les erreurs de format courantes liées aux variables d'environnement
<a name="job-runs-apache-livy-troubleshooting"></a>

Lorsque vous saisissez des configurations Livy et Spark, certains formats de variables d'environnement ne sont pas pris en charge et peuvent provoquer des erreurs. La procédure vous guide à travers une série d'étapes pour vous assurer que vous utilisez les bons formats.

**Entrez vos propres configurations Livy et Spark lors de l'installation de Livy**

Vous pouvez configurer n'importe quelle variable d'environnement Apache Livy ou Apache Spark avec la propriété `env.*` Helm. Suivez les étapes ci-dessous pour convertir l'exemple de configuration dans un format `example.config.with-dash.withUppercase` de variable d'environnement pris en charge.

1. Remplacez les lettres majuscules par un 1 et une minuscule de la lettre. Par exemple, `example.config.with-dash.withUppercase` devient `example.config.with-dash.with1uppercase`.

1. Remplacez les tirets (-) par 0. Par exemple, `example.config.with-dash.with1uppercase` devient `example.config.with0dash.with1uppercase`

1. Remplacez les points (.) par des traits de soulignement (\$1). Par exemple, `example.config.with0dash.with1uppercase` devient `example_config_with0dash_with1uppercase`.

1. Remplacez toutes les lettres minuscules par des lettres majuscules.

1. Ajoutez le préfixe `LIVY_` au nom de la variable.

1. Utilisez la variable lors de l'installation de Livy via le graphique de barre en utilisant le format --set env. *YOUR\$1VARIABLE\$1NAME*.valeur= *yourvalue*

Par exemple, pour définir les configurations Livy et Spark `livy.server.recovery.state-store = filesystem` et utiliser `spark.kubernetes.executor.podNamePrefix = my-prefix` les propriétés Helm suivantes :

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

# Gestion des exécutions de tâches sur Amazon EMR on EKS
<a name="emr-eks-jobs-manage"></a>

Les sections suivantes couvrent des sujets qui vous aident à gérer vos exécutions de tâches Amazon EMR on EKS. Il s'agit notamment de configurer les paramètres d'exécution des tâches lorsque vous utilisez le AWS CLI, de configurer le mode de stockage des données de vos journaux, d'exécuter des scripts Spark SQL pour exécuter des requêtes, de comprendre les états d'exécution des tâches et de savoir comment surveiller les tâches. Vous pouvez parcourir ces rubriques, généralement dans l'ordre, si vous souhaitez configurer et terminer une exécution de travail pour traiter des données.

**Topics**
+ [Gérer les exécutions de tâches à l'aide du AWS CLI](emr-eks-jobs-CLI.md)
+ [Exécution de scripts Spark SQL via l' StartJobRun API](emr-eks-jobs-spark-sql-parameters.md)
+ [États d'exécution de la tâche](emr-eks-jobs-states.md)
+ [Affichage des tâches dans la console Amazon EMR](emr-eks-jobs-console.md)
+ [Erreurs courantes lors de l'exécution de tâches](emr-eks-jobs-error.md)

# Gérer les exécutions de tâches à l'aide du AWS CLI
<a name="emr-eks-jobs-CLI"></a>

Cette rubrique explique comment gérer les exécutions de tâches avec le AWS Command Line Interface (AWS CLI). Il décrit en détail les propriétés, telles que les paramètres de sécurité, le pilote et les divers paramètres de remplacement. Il inclut également des sous-rubriques qui couvrent les différentes manières de configurer la journalisation.

**Topics**
+ [Options de configuration d'une exécution de tâche](#emr-eks-jobs-parameters)
+ [Configuration d'une exécution de tâche pour utiliser les journaux Amazon S3](emr-eks-jobs-s3.md)
+ [Configurer une tâche exécutée pour utiliser Amazon CloudWatch Logs](emr-eks-jobs-cloudwatch.md)
+ [Liste des exécutions de tâches](#emr-eks-jobs-list)
+ [Description d'une exécution de tâche](#emr-eks-jobs-describe)
+ [Annulation d'une exécution de tâche](#emr-eks-jobs-cancel)

## Options de configuration d'une exécution de tâche
<a name="emr-eks-jobs-parameters"></a>

Utilisez les options suivantes pour configurer les paramètres d'exécution des tâches :
+ `--execution-role-arn` : vous devez indiquer un rôle IAM utilisé pour exécuter des tâches. Pour de plus amples informations, veuillez consulter [Utilisation des rôles d'exécution de tâches avec Amazon EMR on EKS](iam-execution-role.md). 
+ `--release-label` : vous pouvez déployer Amazon EMR on EKS à l'aide d'Amazon EMR en version 5.32.0 et 6.2.0 ou ultérieure. Amazon EMR on EKS n'est pas pris en charge dans les versions précédentes d'Amazon EMR. Pour de plus amples informations, veuillez consulter [Versions Amazon EMR on EKS](emr-eks-releases.md). 
+ `--job-driver` : le pilote de tâche est utilisé pour fournir des informations sur la tâche principale. Il s'agit d'un champ de type union dans lequel vous ne pouvez transmettre qu'une seule des valeurs correspondant au type de tâche que vous souhaitez exécuter. Les types de tâches prises en charge incluent :
  + Tâches de soumission Spark : utilisées pour exécuter une commande via la soumission Spark. Vous pouvez utiliser ce type de tâche pour exécuter Scala, SparkR PySpark, SparkSQL et toute autre tâche prise en charge par le biais de Spark Submit. Ce type de tâche a les paramètres suivants :
    + Point d'entrée : il s'agit de la référence HCFS (système de fichiers compatible Hadoop) au jar/py fichier principal que vous souhaitez exécuter.
    + EntryPointArguments - Il s'agit d'un tableau d'arguments que vous souhaitez transmettre à votre jar/py fichier principal. Vous devez gérer la lecture de ces paramètres à l'aide de votre code entrypoint. Chaque argument du tableau doit être séparé par une virgule. EntryPointArguments ne peut pas contenir de crochets ou de parenthèses, tels que (), \$1\$1 ou []. 
    + SparkSubmitParameters - Il s'agit des paramètres Spark supplémentaires que vous souhaitez envoyer à la tâche. Utilisez ce paramètre pour remplacer les propriétés Spark par défaut, telles que la mémoire du pilote ou le nombre d'exécuteurs tels que —conf ou —class. Pour plus d'informations, consultez la rubrique [Lancement d'applications à l'aide de spark-submit](https://spark.apache.org/docs/latest/submitting-applications.html#launching-applications-with-spark-submit).
  + Tâches SQL Spark : utilisées pour exécuter un fichier de requête SQL via Spark SQL. Vous pouvez utiliser ce type de tâche pour exécuter des tâches Spark SQL. Ce type de tâche a les paramètres suivants :
    + Entrypoint : c'est la référence HCFS (système de fichiers compatible Hadoop) au fichier de requête SQL que vous souhaitez exécuter.

      Pour obtenir la liste des paramètres Spark supplémentaires que vous pouvez utiliser pour une tâche Spark SQL, consultez [Exécution de scripts Spark SQL via l' StartJobRun API](emr-eks-jobs-spark-sql-parameters.md).
+ `--configuration-overrides` : vous pouvez remplacer les configurations par défaut des applications en fournissant un objet de configuration. Vous pouvez utiliser une syntaxe abrégée pour fournir la configuration, ou vous pouvez faire référence à l'objet de configuration dans un fichier JSON. Les objets de configuration sont composés d'une classification, de propriétés et de configurations imbriquées en option. Les propriétés sont les paramètres que vous souhaitez remplacer dans ce fichier. Vous pouvez spécifier plusieurs classifications pour plusieurs applications d'un seul objet JSON. Les classifications de configuration qui sont disponibles varient d'une version d'Amazon EMR à l'autre. Pour obtenir une liste des classifications de configurations disponibles pour chaque version d'Amazon EMR, consultez [Versions Amazon EMR on EKS](emr-eks-releases.md).

  Si vous transmettez la même configuration dans un remplacement d'application et dans les paramètres de soumission Spark, les paramètres de soumission  Spark auront la priorité. La liste complète des priorités de configuration suit, de la priorité la plus élevée à la plus faible.
  + Configuration fournie lors de la création de `SparkSession`.
  + Configuration fournie dans le cadre de `sparkSubmitParameters` en utilisant `—conf`.
  + Configuration fournie dans le cadre des remplacements d'applications.
  + Configurations optimisées choisies par Amazon EMR pour la version.
  + Configurations open-source par défaut pour l'application.

  Pour surveiller les exécutions de tâches à l'aide d'Amazon CloudWatch ou d'Amazon S3, vous devez fournir les détails de configuration pour CloudWatch. Pour plus d’informations, consultez [Configuration d'une exécution de tâche pour utiliser les journaux Amazon S3](emr-eks-jobs-s3.md) et [Configurer une tâche exécutée pour utiliser Amazon CloudWatch Logs](emr-eks-jobs-cloudwatch.md). Si le compartiment ou le groupe de CloudWatch journaux S3 n'existe pas, Amazon EMR le crée avant de télécharger les journaux dans le compartiment.
+ Pour une liste supplémentaire d'options de configuration Kubernetes, consultez la rubrique [Propriétés Spark sur Kubernetes](https://spark.apache.org/docs/latest/running-on-kubernetes.html#configuration). 

  Les configurations Spark suivantes ne sont pas prises en charge.
  + `spark.kubernetes.authenticate.driver.serviceAccountName`
  + `spark.kubernetes.authenticate.executor.serviceAccountName`
  + `spark.kubernetes.namespace`
  + `spark.kubernetes.driver.pod.name`
  + `spark.kubernetes.container.image.pullPolicy`
  + `spark.kubernetes.container.image`
**Note**  
Vous pouvez utiliser `spark.kubernetes.container.image` pour personnaliser les images Docker. Pour de plus amples informations, veuillez consulter [Personnalisation d'images Docker pour Amazon EMR on EKS](docker-custom-images.md).

# Configuration d'une exécution de tâche pour utiliser les journaux Amazon S3
<a name="emr-eks-jobs-s3"></a>

Pour être en mesure de suivre l'avancement des tâches et de résoudre les problèmes d'échec, vous devez configurer vos tâches de manière à envoyer des informations de journal à Amazon S3, Amazon CloudWatch Logs ou aux deux. Cette rubrique vous aide à commencer à publier des journaux d'application sur Amazon S3 pour vos tâches lancées à l'aide d'Amazon EMR on EKS.

**Politique IAM des journaux S3**

Pour que vos tâches puissent envoyer des données de journal à Amazon S3, les autorisations suivantes doivent être incluses dans la politique d'autorisations du rôle d'exécution des tâches. *amzn-s3-demo-logging-bucket*Remplacez-le par le nom de votre bucket de journalisation.

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

****  

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

------

**Note**  
Amazon EMR on EKS peut également créer un compartiment Amazon S3. Si aucun compartiment Amazon S3 n'est disponible, incluez l'autorisation `“s3:CreateBucket”` dans la politique IAM.

Une fois que vous avez donné à votre rôle d'exécution les autorisations appropriées pour envoyer des journaux à Amazon S3, les données de vos journaux sont envoyées aux emplacements Amazon S3 suivants lorsque la `s3MonitoringConfiguration` est transmise dans la section `monitoringConfiguration` d'une demande `start-job-run`, comme indiqué dans [Gérer les exécutions de tâches à l'aide du AWS CLI](emr-eks-jobs-CLI.md).
+ Journaux des soumissionnaires -//*virtual-cluster-id*/jobs/ /containers/*logUri*/(*job-id*stderr.gz/stdout.gz) *pod-name*
+ Journaux de pilotes -//*virtual-cluster-id*/jobs/ *logUri* *job-id* /containers/ /spark- -driver/ (stderr.gz/stdout.gz*spark-application-id*) *job-id*
+ Journaux de l'exécuteur -//*virtual-cluster-id*/jobs/ *logUri* *job-id* /containers///(stderr.gz/stdout.gz*spark-application-id*) *executor-pod-name*

# Configurer une tâche exécutée pour utiliser Amazon CloudWatch Logs
<a name="emr-eks-jobs-cloudwatch"></a>

Pour suivre l'avancement des tâches et résoudre les problèmes d'échec, vous devez configurer vos tâches de manière à envoyer des informations de journal à Amazon S3, Amazon CloudWatch Logs ou aux deux. Cette rubrique vous aide à commencer à utiliser CloudWatch les journaux sur vos tâches lancées avec Amazon EMR sur EKS. Pour plus d'informations sur CloudWatch les journaux, consultez la section [Surveillance des fichiers journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) dans le guide de CloudWatch l'utilisateur Amazon.

**CloudWatch Politique IAM des journaux**

Pour que vos tâches envoient des données de journal à CloudWatch Logs, les autorisations suivantes doivent être incluses dans la politique d'autorisation relative au rôle d'exécution des tâches. Remplacez *my\$1log\$1group\$1name* et *my\$1log\$1stream\$1prefix* par les noms de votre groupe de CloudWatch journaux et les noms de vos flux de journaux, respectivement. Amazon EMR on EKS crée le groupe de journaux et le flux de journaux s'ils n'existent pas, à condition que l'ARN du rôle d'exécution dispose des autorisations appropriées. 

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

****  

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

------

**Note**  
Amazon EMR on EKS peut également créer un flux de journaux. S'il n'existe pas de flux de journaux, la politique IAM doit inclure l'autorisation `"logs:CreateLogGroup"`.

Une fois que vous avez accordé les autorisations appropriées à votre rôle d'exécution, votre application envoie ses données de journal à CloudWatch Logs lorsqu'elles `cloudWatchMonitoringConfiguration` sont transmises dans la `monitoringConfiguration` section d'une `start-job-run` demande, comme indiqué dans[Gérer les exécutions de tâches à l'aide du AWS CLI](emr-eks-jobs-CLI.md).

Dans l'`StartJobRun`API, *log\$1group\$1name * il s'agit du nom du groupe de journaux pour CloudWatch et *log\$1stream\$1prefix* du préfixe du nom du flux de journaux pour CloudWatch. Vous pouvez afficher et y faire des recherches dans la AWS Management Console.
+ Journaux de l'expéditeur -*logGroup*//*virtual-cluster-id*/jobs/ *logStreamPrefix* /containers//(*job-id*stderr/stdout) *pod-name*
+ Journaux de pilotes -*logGroup*//*virtual-cluster-id*/jobs/ *logStreamPrefix* *job-id* /containers/ /spark- -driver/ (stderrstdout*spark-application-id*) *job-id*
+ Journaux de l'exécuteur -*logGroup*//*virtual-cluster-id*/jobs/ *logStreamPrefix* *job-id* /containers///(*spark-application-id*stderr/stdout) *executor-pod-name*

## Liste des exécutions de tâches
<a name="emr-eks-jobs-list"></a>

Vous pouvez exécuter `list-job-run` pour afficher l'état des exécutions de tâches, comme le montre l'exemple ci-dessous. 

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

## Description d'une exécution de tâche
<a name="emr-eks-jobs-describe"></a>

Vous pouvez exécuter `describe-job-run` pour obtenir plus de détails sur la tâche, tels que l'état de la tâche, les détails de l'état et le nom de la tâche, comme le montre l'exemple ci-dessous. 

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

## Annulation d'une exécution de tâche
<a name="emr-eks-jobs-cancel"></a>

Vous pouvez exécuter `cancel-job-run` pour annuler des tâches en cours d'exécution, comme le montre l'exemple ci-dessous.

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

# Exécution de scripts Spark SQL via l' StartJobRun API
<a name="emr-eks-jobs-spark-sql-parameters"></a>

Les versions 6.7.0 et ultérieures d'Amazon EMR on EKS comprennent un pilote de tâche Spark SQL qui vous permet d'exécuter des scripts Spark SQL via l'API `StartJobRun`. Vous pouvez fournir des fichiers de points d'entrée SQL pour exécuter directement des requêtes Spark SQL sur Amazon EMR on EKS à l'aide de l'API `StartJobRun`, sans aucune modification des scripts Spark SQL existants. Le tableau suivant répertorie les paramètres Spark pris en charge pour les tâches SQL Spark via l' StartJobRun API.

Vous pouvez choisir parmi les paramètres Spark suivants à envoyer à une tâche SQL Spark. Utilisez ces paramètres pour remplacer les propriétés Spark par défaut.


| Option | Description | 
| --- | --- | 
|  --name NOM  | Nom de l'application | 
| --jars fichiers JAR | Liste des fichiers JAR, séparés par des virgules, à inclure dans le chemin de classe du pilote et de l'exécuteur. | 
| --packages | Liste des coordonnées Maven des fichiers JAR, séparées par des virgules, à inclure dans les chemins de classe du pilote et de l'exécuteur. | 
| --exclude-packages | Liste des groupId:artifactId, séparés par des virgules, à exclure lors de la résolution des dépendances fournies dans –packages afin d'éviter les conflits de dépendances. | 
| --repositories | Liste des référentiels distants supplémentaires, séparés par des virgules, à rechercher pour les coordonnées maven données fournies –packages. | 
| --files FICHIERS | Liste des fichiers, séparés par des virgules, à placer dans le répertoire de travail de chaque exécuteur. | 
| --conf PROPRIÉTÉ = VALEUR | Propriété de configuration Spark. | 
| --properties-file FICHIER | Chemin d'accès au fichier à partir duquel charger des propriétés supplémentaires. | 
| --driver-memory MEM | Mémoire pour le pilote. Par défaut, 1024 Mo. | 
| --driver-java-options | Options Java supplémentaires à transmettre au pilote. | 
| --driver-library-path | Entrées de chemin de bibliothèque supplémentaires à transmettre au pilote. | 
| --driver-class-path | Entrées de chemin de classe supplémentaires à transmettre au pilote. | 
| --executor-memory MEM | Mémoire par exécuteur. Valeur par défaut : 1 Go. | 
| --driver-cores NUM | Nombre de cœurs utilisés par le pilote. | 
| -- total-executor-cores NOMBRE | Nombre total de cœurs pour tous les exécuteurs. | 
| --executor-cores NUM | Nombre de cœurs utilisés par chaque exécuteur. | 
| --num-executors NUM | Nombre d'exécuteurs à lancer. | 
| -hivevar <key=value> | Substitution de variables à appliquer aux commandes Hive, par exemple, -hivevar A=B | 
| -hiveconf <property=value> | Valeur à utiliser pour la propriété donnée. | 

Pour une tâche SQL Spark, créez un fichier start-job-run-request .json et spécifiez les paramètres requis pour l'exécution de votre tâche, comme dans l'exemple suivant :

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

# États d'exécution de la tâche
<a name="emr-eks-jobs-states"></a>

Lorsque vous envoyez une tâche à une file d'attente de tâches Amazon EMR on EKS, l'exécution de la tâche passe à l'état `PENDING`. Elle passe ensuite par les états suivants jusqu'à ce qu'elle réussisse (se termine avec le code `0`) ou qu'elle échoue (se termine avec un code non nul). 

Les exécutions de tâches peuvent avoir les états suivants :
+ `PENDING` : état initial de la tâche lorsque l'exécution de tâche est soumise à Amazon EMR on EKS. La tâche attend d'être soumise au cluster virtuel, et Amazon EMR on EKS travaille à la soumission de cette tâche.
+ `SUBMITTED` : une exécution de tâche qui a été soumise avec succès au cluster virtuel. Le planificateur de cluster essaie ensuite d'exécuter cette tâche sur le cluster.
+ `RUNNING` : une tâche exécutée dans le cluster virtuel. Dans les applications Spark, cela signifie que le processus du pilote Spark est en état `running`.
+ `FAILED` : une exécution de tâche qui n'a pas pu être soumise au cluster virtuel ou qui s'est terminée sans succès. Regardez StateDetails et trouvez FailureReason des informations supplémentaires sur cet échec de travail.
+ `COMPLETED` : une exécution de travail qui s'est terminée avec succès.
+ `CANCEL_PENDING` : l'annulation d'une exécution de tâche a été demandée. Amazon EMR on EKS essaie d'annuler la tâche sur le cluster virtuel.
+ `CANCELLED` : une exécution de tâche qui a été annulée avec succès.

# Affichage des tâches dans la console Amazon EMR
<a name="emr-eks-jobs-console"></a>

Les données d'exécution des tâches peuvent être consultées, ce qui vous permet de surveiller chaque tâche au fur et à mesure qu'elle passe par les états. Pour afficher les tâches dans la console Amazon EMR, procédez comme suit.

1. Dans le menu de gauche de la console Amazon EMR, sous Amazon EMR on EKS, choisissez **Clusters virtuels**.

1. Dans la liste des clusters virtuels, sélectionnez le cluster virtuel dont vous souhaitez consulter les tâches.

1. Dans le tableau **Exécutions de tâches**, sélectionnez **Afficher les journaux** pour afficher les détails d'une exécution de tâche.

**Note**  
La prise en charge de l'expérience en un clic est activée par défaut. Elle peut être désactivée en réglant `persistentAppUI` sur `DISABLED` dans `monitoringConfiguration` lors de la soumission des tâches. Pour de plus amples informations, veuillez consulter [Afficher les interfaces utilisateur d'application persistante](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html).

# Erreurs courantes lors de l'exécution de tâches
<a name="emr-eks-jobs-error"></a>

Les erreurs suivantes peuvent se produire lorsque vous exécutez l'API `StartJobRun`. Le tableau répertorie chaque erreur et fournit des mesures d'atténuation afin que vous puissiez résoudre les problèmes rapidement.


| Message d’erreur | Condition d'erreur | Étapes suivantes recommandées | 
| --- | --- | --- | 
|  erreur : argument -- *argument* est obligatoire  | Les paramètres obligatoires sont manquants. | Ajoutez les arguments manquants à la demande de l'API. | 
| Une erreur s'est produite (AccessDeniedException) lors de l'appel de l' StartJobRunopération : L'utilisateur : n'ARNest pas autorisé à effectuer : emr-containers : StartJobRun | Le rôle d'exécution est manquant. | Consultez la rubrique Utilisation de [Utilisation des rôles d'exécution de tâches avec Amazon EMR on EKS](iam-execution-role.md).  | 
|  Une erreur s'est produite (AccessDeniedException) lors de l'appel de l' StartJobRunopération : L'utilisateur : n'*ARN*est pas autorisé à effectuer : emr-containers : StartJobRun  |  L'appelant n'est pas autorisé à accéder au rôle d'exécution [format valide/non valide] via les clés de condition.  | Consultez [Utilisation des rôles d'exécution de tâches avec Amazon EMR on EKS](iam-execution-role.md).  | 
|  Une erreur s'est produite (AccessDeniedException) lors de l'appel de l' StartJobRunopération : L'utilisateur : n'*ARN*est pas autorisé à effectuer : emr-containers : StartJobRun  |  L'ARN du soumissionnaire de la tâche et celui du rôle d'exécution proviennent de comptes différents.  | Assurez-vous que l'ARN du soumissionnaire de la tâche et celui du rôle d'exécution proviennent du même compte  AWS . | 
|  1 erreur de validation détectée : la valeur *Role* à « executionRoleArn » ne répondait pas au modèle d'expression régulière ARN : ^arn :( aws [a-Za-Z0-9-] \$1) :iam : :( \$1 d \$112\$1) ? : (rôle ((\$1 u002F) \$1 (\$1 u002F [\$1 u0021- \$1 u007F] \$1 \$1 u002F)) [\$1 w\$1=, .@-] \$1)  |  L'appelant dispose d'autorisations pour le rôle d'exécution via des clés de condition, mais le rôle ne satisfait pas aux contraintes du format ARN.  | Indiquez le rôle d'exécution en respectant le format ARN. Consultez [Utilisation des rôles d'exécution de tâches avec Amazon EMR on EKS](iam-execution-role.md).  | 
|  Une erreur s'est produite (ResourceNotFoundException) lors de l'appel de l' StartJobRunopération : Le cluster virtuel *Virtual Cluster ID* n'existe pas.  |  L'identifiant du cluster virtuel est introuvable.  | Indiquez un identifiant de cluster virtuel enregistré dans Amazon EMR on EKS. | 
|  Une erreur s'est produite (ValidationException) lors de l'appel de l' StartJobRunopération : l'état du cluster virtuel n'*state*est pas valide pour créer une ressource JobRun.  |  Le cluster virtuel n'est pas prêt à exécuter la tâche.  | Consultez [États du cluster virtuel](virtual-cluster.md#virtual-cluster-states).  | 
|  Une erreur s'est produite (ResourceNotFoundException) lors de l'appel de l' StartJobRunopération : Release *RELEASE* doesn't exist.  |  La version spécifiée lors de la soumission de la tâche est incorrecte.  | Consultez [Versions Amazon EMR on EKS](emr-eks-releases.md).  | 
|  Une erreur s'est produite (AccessDeniedException) lors de l'appel de l' StartJobRunopération : L'utilisateur : n'*ARN*est pas autorisé à effectuer : emr-containers : StartJobRun on resource : *ARN* avec un refus explicite. Une erreur s'est produite (AccessDeniedException) lors de l'appel de l' StartJobRunopération : L'utilisateur : n'*ARN*est pas autorisé à effectuer : emr-containers : StartJobRun on resource : *ARN*  | L'utilisateur n'est pas autorisé à appeler StartJobRun. | Consultez [Utilisation des rôles d'exécution de tâches avec Amazon EMR on EKS](iam-execution-role.md).  | 
|  Une erreur s'est produite (ValidationException) lors de l'appel de l' StartJobRunopération : ConfigurationOverrides.MonitoringConfiguration.s3 MonitoringConfiguration .LogURI n'a pas réussi à satisfaire la contrainte : %s  |  La syntaxe de l'URI du chemin S3 n'est pas valide.  | logUri doit être au format s3 ://...  | 

Les erreurs suivantes peuvent se produire lorsque vous exécutez l'API `DescribeJobRun` avant les exécutions de tâches.


| Message d’erreur | Condition d'erreur | Étapes suivantes recommandées | 
| --- | --- | --- | 
|  StateDetails : échec JobRun de la soumission.  La classification *classification* n'est pas prise en charge. failureReason : VALIDATION\$1ERROR état : ÉCHEC.  | Les paramètres saisis ne StartJobRun sont pas valides. | Consultez [Versions Amazon EMR on EKS](emr-eks-releases.md).  | 
|  StateDetails : *EKS Cluster ID* Le cluster n'existe pas. failureReason : CLUSTER\$1UNAVAILABLE état : ÉCHEC  | Le cluster EKS n'est pas disponible. | Vérifiez si le cluster EKS existe et dispose des autorisations appropriées. Pour de plus amples informations, veuillez consulter [Configuration d'Amazon EMR on EKS](setting-up.md). | 
|  StateDetails : *EKS Cluster ID* Le cluster ne dispose pas d'autorisations suffisantes. failureReason : CLUSTER\$1UNAVAILABLE état : ÉCHEC  |  Amazon EMR n'est pas autorisé à accéder au cluster EKS.  | Vérifiez que les autorisations sont configurées pour Amazon EMR sur l'espace de noms enregistré. Pour de plus amples informations, veuillez consulter [Configuration d'Amazon EMR on EKS](setting-up.md). | 
|  StateDetails : *EKS Cluster ID* Le cluster n'est actuellement pas accessible. failureReason : CLUSTER\$1UNAVAILABLE état : ÉCHEC  |  Le cluster EKS n'est pas accessible.  | Vérifiez que le cluster EKS existe et qu'il dispose des autorisations appropriées. Pour de plus amples informations, veuillez consulter [Configuration d'Amazon EMR on EKS](setting-up.md). | 
|  StateDetails : JobRun la soumission a échoué en raison d'une erreur interne. failureReason : INTERNAL\$1ERROR état : ÉCHEC  |  Une erreur interne s'est produite avec le cluster EKS.  | N/A | 
|  StateDetails : *EKS Cluster ID* Le cluster ne dispose pas de ressources suffisantes. failureReason : USER\$1ERROR état : ÉCHEC  |  Les ressources du cluster EKS sont insuffisantes pour exécuter la tâche.  | Ajoutez de la capacité au groupe de nœuds EKS ou configurez EKS Autoscaler. Pour plus d'informations, consultez la rubrique [Cluster Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html). | 

Les erreurs suivantes peuvent se produire lorsque vous exécutez l'API `DescribeJobRun` après les exécutions de tâches.


| Message d’erreur | Condition d'erreur | Étapes suivantes recommandées | 
| --- | --- | --- | 
|  StateDetails : Problème lors de la surveillance de votre. JobRun  *EKS Cluster ID*Le cluster n'existe pas. failureReason : CLUSTER\$1UNAVAILABLE état : ÉCHEC  | Le cluster EKS n'existe pas. | Vérifiez que le cluster EKS existe et qu'il dispose des autorisations appropriées. Pour de plus amples informations, veuillez consulter [Configuration d'Amazon EMR on EKS](setting-up.md). | 
|  StateDetails : Problème lors de la surveillance de votre. JobRun *EKS Cluster ID*Le cluster ne dispose pas d'autorisations suffisantes. failureReason : CLUSTER\$1UNAVAILABLE état : ÉCHEC  | Amazon EMR n'est pas autorisé à accéder au cluster EKS. | Vérifiez que les autorisations sont configurées pour Amazon EMR sur l'espace de noms enregistré. Pour de plus amples informations, veuillez consulter [Configuration d'Amazon EMR on EKS](setting-up.md). | 
|  StateDetails : Problème lors de la surveillance de votre. JobRun *EKS Cluster ID*Le cluster n'est actuellement pas joignable. failureReason : CLUSTER\$1UNAVAILABLE état : ÉCHEC  |  Le cluster EKS n'est pas accessible.  | Vérifiez que le cluster EKS existe et qu'il dispose des autorisations appropriées. Pour de plus amples informations, veuillez consulter [Configuration d'Amazon EMR on EKS](setting-up.md). | 
|  StateDetails : Problème lors de la surveillance de votre JobRun compte en raison d'une erreur interne failureReason : INTERNAL\$1ERROR état : ÉCHEC  |  Une erreur interne s'est produite et empêche la JobRun surveillance.  | N/A | 

L'erreur suivante peut se produire lorsqu'une tâche ne peut pas démarrer et qu'elle reste en attente en état SOUMIS pendant 15 minutes. Cela peut être dû à un manque de ressources du cluster.


| Message d’erreur | Condition d'erreur | Étapes suivantes recommandées | 
| --- | --- | --- | 
|  délai d'expiration du cluster  | La tâche est à l'état SOUMIS depuis 15 minutes ou plus. | Vous pouvez remplacer la valeur par défaut de 15 minutes pour ce paramètre par la configuration ci-dessous.  | 

Utilisez la configuration ci-dessous pour modifier le paramètre de délai d'expiration du cluster à 30 minutes. Notez que vous indiquez la nouvelle valeur `job-start-timeout` en secondes :

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

# Utilisation des modèles de tâche
<a name="job-templates"></a>

Un modèle de tâche stocke des valeurs qui peuvent être partagées lors de l'invocation de l'API `StartJobRun` pour démarrer une exécution de tâche. Il prend en charge deux cas d'utilisation :
+ Pour éviter les valeurs répétitives et récurrentes des demandes de l'API `StartJobRun`.
+ Pour imposer une règle selon laquelle certaines valeurs doivent être fournies via des demandes de l'API `StartJobRun`.

Les modèles de tâches vous permettent de définir un modèle réutilisable pour les exécutions de tâches afin d'appliquer une personnalisation supplémentaire, par exemple :
+ Configuration de la capacité de calcul de l'exécuteur et du pilote
+ Définition des propriétés de sécurité et de gouvernance telles que les rôles IAM
+ Personnalisation d'une image Docker à utiliser dans plusieurs applications et pipelines de données

Les rubriques suivantes fournissent des informations détaillées sur l'utilisation des modèles, notamment sur leur utilisation pour démarrer l'exécution d'une tâche et sur la modification des paramètres des modèles.

**Topics**
+ [Création et utilisation d'un modèle de tâche pour démarrer une exécution de tâche](create-job-template.md)
+ [Définition des paramètres du modèle de tâche](use-job-template-parameters.md)
+ [Contrôle de l'accès aux modèles de tâches](iam-job-template.md)

# Création et utilisation d'un modèle de tâche pour démarrer une exécution de tâche
<a name="create-job-template"></a>

Cette section décrit la création d'un modèle de tâche et son utilisation pour démarrer une tâche exécutée avec le AWS Command Line Interface (AWS CLI).

**Création d'un modèle de tâche**

1. Créez un fichier `create-job-template-request.json` et indiquez les paramètres requis pour votre modèle de tâche, comme le montre l'exemple de fichier JSON ci-dessous. Pour plus d'informations sur tous les paramètres disponibles, consultez l'[CreateJobTemplate](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/Welcome.html)API.

   La plupart des valeurs requises pour l'API `StartJobRun` le sont également pour `jobTemplateData`. Si vous souhaitez utiliser des espaces réservés pour n'importe quel paramètre et fournir des valeurs lors de l'appel à StartJobRun l'aide d'un modèle de tâche, consultez la section suivante sur les paramètres du modèle de tâche.

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

1. Utilisez la commande `create-job-template` avec un chemin d'accès au fichier `create-job-template-request.json` stocké localement.

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

**Démarrage d'une exécution de tâche à l'aide d'un modèle de tâche**

Saisissez l'identifiant du cluster virtuel, l'identifiant du modèle de tâche et le nom de la tâche dans la commande `StartJobRun`, comme indiqué dans l'exemple ci-dessous.

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

# Définition des paramètres du modèle de tâche
<a name="use-job-template-parameters"></a>

Les paramètres du modèle de tâche vous permettent d'indiquer des variables dans le modèle de tâche. Les valeurs de ces variables de paramètres devront être indiquées lors du démarrage d'une exécution de tâche à l'aide de ce modèle de tâche. Les paramètres du modèle de tâche sont indiqués au format `${parameterName}`. Vous pouvez choisir d'indiquer n'importe quelle valeur dans un champ `jobTemplateData` comme paramètre de modèle de tâche. Pour chacune des variables de paramètre du modèle de tâche, indiquez son type de données (`STRING` ou `NUMBER`) et éventuellement une valeur par défaut. L'exemple ci-dessous montre comment vous pouvez indiquer les paramètres du modèle de tâche pour l'emplacement du point d'entrée, la classe principale et les valeurs de l'emplacement du journal S3.

**Indication de l'emplacement du point d'entrée, de la classe principale et de l'emplacement du journal Amazon S3 en tant que paramètres du modèle de tâche**

1. Créez un fichier `create-job-template-request.json` et indiquez les paramètres requis pour votre modèle de tâche, comme le montre l'exemple de fichier JSON ci-dessous. Pour plus d'informations sur les paramètres, consultez l'[CreateJobTemplate](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/Welcome.html)API.

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

1. Utilisez la commande `create-job-template` avec un chemin d'accès au fichier `create-job-template-request.json` stocké localement ou dans Amazon S3.

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

**Démarrage d'une exécution de tâche à l'aide d'un modèle de tâche et des paramètres du modèle de tâche**

Pour démarrer une tâche avec un modèle de tâche contenant les paramètres du modèle de tâche, indiquez l'identifiant du modèle de tâche ainsi que les valeurs des paramètres du modèle de tâche dans la demande de l'API `StartJobRun`, comme indiqué ci-dessous.

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

# Contrôle de l'accès aux modèles de tâches
<a name="iam-job-template"></a>

La politique `StartJobRun` vous permet de vous assurer qu'un utilisateur ou un rôle ne peut exécuter des tâches qu'à l'aide de modèles de tâches que vous indiquez et ne peut pas exécuter d'opérations `StartJobRun` sans utiliser les modèles de tâches indiqués. Pour ce faire, assurez-vous d'abord d'accorder à l'utilisateur ou au rôle une autorisation de lecture pour les modèles de tâches spécifiés, comme indiqué ci-dessous.

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

****  

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

------

Pour garantir qu'un utilisateur ou un rôle ne peut invoquer une opération `StartJobRun` que s'il utilise des modèles de tâches spécifiques, vous pouvez accorder l'autorisation de politique `StartJobRun` suivante à un utilisateur ou à un rôle donné.

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

****  

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

------

Si le modèle de tâche spécifie un paramètre de modèle de tâche dans le champ ARN du rôle d'exécution, l'utilisateur pourra indiquer une valeur pour ce paramètre et pourra ainsi invoquer `StartJobRun` à l'aide d'un rôle d'exécution arbitraire. Pour limiter les rôles d'exécution que l'utilisateur peut indiquer, consultez la rubrique **Contrôle de l'accès au rôle d'exécution** dans [Utilisation des rôles d'exécution de tâches avec Amazon EMR on EKS](iam-execution-role.md). 

Si aucune condition n'est indiquée dans la politique d'action `StartJobRun` ci-dessus pour un utilisateur ou un rôle donné, l'utilisateur ou le rôle sera autorisé à invoquer une action `StartJobRun` sur le cluster virtuel indiqué en utilisant un modèle de tâche arbitraire auquel il a accès en lecture ou en utilisant un rôle d'exécution arbitraire.

# Utilisation de modèles de pods
<a name="pod-templates"></a>

À partir des versions 5.33.0 ou 6.3.0 d'Amazon EMR, Amazon EMR on EKS prend en charge la fonctionnalité de modèle de pod de Spark. Le pod est un groupe d'un ou plusieurs conteneurs, avec des ressources de stockage et de réseau partagées, et une spécification sur la manière d'exécuter les conteneurs. Les modèles de pods sont des spécifications qui déterminent comment exécuter chaque pod. Vous pouvez utiliser des fichiers de modèles de pods pour définir les configurations des pods de pilote ou d'exécuteur que les configurations Spark ne prennent pas en charge. Pour plus d'informations sur la fonctionnalité de modèle de pod de Spark, consultez la rubrique [Modèle de pod](https://spark.apache.org/docs/latest/running-on-kubernetes.html#pod-template). 

**Note**  
La fonctionnalité de modèle de pod ne fonctionne qu'avec les pods de pilote et d'exécuteur. Vous ne pouvez pas configurer les modules d'envoi de tâches à l'aide du modèle de module.

## Scénarios courants
<a name="pod-template-use-cases"></a>

Vous pouvez définir comment exécuter des tâches Spark sur des clusters EKS partagés en utilisant des modèles de pods sur Amazon EMR on EKS et économiser des coûts tout en améliorant l'utilisation des ressources et les performances.
+ Pour réduire les coûts, vous pouvez planifier l'exécution des tâches du pilote Spark sur des instances Amazon EC2 On-Demand tout en planifiant l'exécution des tâches de l'exécuteur Spark sur des instances Amazon EC2 Spot. 
+ Pour augmenter l'utilisation des ressources, vous pouvez prendre en charge plusieurs équipes exécutant leurs charges de travail sur le même cluster EKS. Chaque équipe aura un groupe de EC2 nœuds Amazon désigné sur lequel exécuter ses charges de travail. Vous pouvez utiliser des modèles de pods pour appliquer une tolérance correspondante à leur charge de travail. 
+ Pour améliorer la surveillance, vous pouvez utiliser un conteneur de journalisation distinct pour transmettre les journaux à votre application de surveillance existante. 

Par exemple, le fichier de modèle de pod suivant illustre un scénario d'utilisation courant. 

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

Le modèle de pod exécute les tâches suivantes :
+ Ajoutez un nouveau [conteneur d'initialisation](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) qui est exécuté avant le démarrage du conteneur principal Spark. Le conteneur d'initialisation partage le [EmptyDirvolume](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) appelé `source-data-volume` avec le conteneur principal Spark. Vous pouvez demander à votre conteneur d'initialisation d'exécuter des étapes d'initialisation, telles que le téléchargement de dépendances ou la génération de données d'entrée. Le conteneur principal Spark consomme ensuite les données.
+ Ajoutez un autre [conteneur sidecar](https://kubernetes.io/docs/concepts/workloads/pods/#how-pods-manage-multiple-containers) exécuté en même temps que le conteneur principal Spark. Les deux conteneurs partagent un autre volume `EmptyDir` appelé `metrics-files-volume`. Votre tâche Spark peut générer des métriques, telles que les métriques  Prometheus. La tâche Spark peut ensuite placer les métriques dans un fichier et demander au conteneur sidecar de charger les fichiers dans votre propre système de BI en vue d'une analyse ultérieure.
+ Ajoutez une nouvelle variable d'environnement au conteneur principal Spark. Vous pouvez demander à votre tâche de consommer la variable d'environnement.
+ Définissez un [sélecteur de nœuds](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) afin que le pod soit uniquement planifié sur le groupe de nœuds `emr-containers-nodegroup`. Cela permet d'isoler les ressources informatiques entre les tâches et les équipes.

## Activation des modèles de pods avec Amazon EMR on EKS
<a name="use-pod-templates"></a>

Pour activer la fonctionnalité de modèle de pod avec Amazon EMR on EKS, configurez les propriétés `spark.kubernetes.driver.podTemplateFile` et `spark.kubernetes.executor.podTemplateFile` de Spark pour qu'elles renvoient aux fichiers de modèle de pod sur Amazon S3. Spark télécharge ensuite le fichier de modèle de pod et l'utilise pour construire des pods de pilote et d'exécuteur.

**Note**  
Spark utilise le rôle d'exécution de tâches pour charger le modèle de pod. Le rôle d'exécution de tâches doit donc être autorisé à accéder à Amazon S3 afin de charger les modèles de pod. Pour de plus amples informations, veuillez consulter [Création d'un rôle d'exécution des tâches](creating-job-execution-role.md).

Vous pouvez utiliser les `SparkSubmitParameters` pour indiquer le chemin Amazon S3 vers le modèle de pod, comme le montre le fichier JSON d'exécution de tâches suivant.

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

Vous pouvez également utiliser les `configurationOverrides` pour indiquer le chemin Amazon S3 vers le modèle de pod, comme le montre le fichier JSON d'exécution de tâches suivant.

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

**Note**  
Vous devez suivre les consignes de sécurité lorsque vous utilisez la fonctionnalité de modèle de pod avec Amazon EMR on EKS, telles que l'isolation du code d'application non fiable. Pour de plus amples informations, veuillez consulter [Bonnes pratiques de sécurité pour Amazon EMR on EKS](security-best-practices.md).
Vous ne pouvez pas modifier les noms des conteneurs principaux Spark en utilisant `spark.kubernetes.driver.podTemplateContainerName` et `spark.kubernetes.executor.podTemplateContainerName`, car ces noms sont codés en dur comme `spark-kubernetes-driver` et `spark-kubernetes-executors`. Si vous souhaitez personnaliser le conteneur principal Spark, vous devez indiquer le conteneur dans un modèle de pod avec ces noms codés en dur.

## Champs du modèle de pod
<a name="pod-templates-fields"></a>

Tenez compte des restrictions de champ suivantes lors de la configuration d'un modèle de pod avec Amazon EMR on EKS.
+ Amazon EMR on EKS n'autorise que les champs suivants dans un modèle de pod pour permettre une planification correcte des tâches.

  Voici les champs autorisés au niveau du pod :
  + `apiVersion`
  + `kind`
  + `metadata`
  + `spec.activeDeadlineSeconds`
  + `spec.affinity`
  + `spec.containers`
  + `spec.enableServiceLinks`
  + `spec.ephemeralContainers`
  + `spec.hostAliases`
  + `spec.hostname`
  + `spec.imagePullSecrets`
  + `spec.initContainers`
  + `spec.nodeName`
  + `spec.nodeSelector`
  + `spec.overhead`
  + `spec.preemptionPolicy`
  + `spec.priority`
  + `spec.priorityClassName`
  + `spec.readinessGates`
  + `spec.runtimeClassName`
  + `spec.schedulerName`
  + `spec.subdomain`
  + `spec.terminationGracePeriodSeconds`
  + `spec.tolerations`
  + `spec.topologySpreadConstraints`
  + `spec.volumes`

  Voici les champs autorisés au niveau du conteneur principal Spark :
  + `env`
  + `envFrom`
  + `name`
  + `lifecycle`
  + `livenessProbe`
  + `readinessProbe`
  + `resources`
  + `startupProbe`
  + `stdin`
  + `stdinOnce`
  + `terminationMessagePath`
  + `terminationMessagePolicy`
  + `tty`
  + `volumeDevices`
  + `volumeMounts`
  + `workingDir`

  Lorsque vous utilisez des champs non autorisés dans le modèle de pod, Spark génère une exception et la tâche échoue. L'exemple suivant montre un message d'erreur dans le journal du contrôleur  Spark en raison de champs non autorisés. 

  ```
  Executor pod template validation failed.
  Field container.command in Spark main container not allowed but specified.
  ```
+  Amazon EMR on EKS prédéfinit les paramètres suivants dans un modèle de pod. Les champs que vous indiquez dans un modèle de pod ne doivent pas se chevaucher avec ces champs. 

  Voici les noms de volumes prédéfinis :
  + `emr-container-communicate`
  + `config-volume`
  + `emr-container-application-log-dir`
  + `emr-container-event-log-dir`
  + `temp-data-dir`
  + `mnt-dir`
  + `home-dir`
  + `emr-container-s3`

  Voici les montages de volume prédéfinis qui s'appliquent uniquement au conteneur principal Spark :
  + Nom : `emr-container-communicate` ; MountPath : `/var/log/fluentd`
  + Nom : `emr-container-application-log-dir` ; MountPath : `/var/log/spark/user`
  + Nom : `emr-container-event-log-dir` ; MountPath : `/var/log/spark/apps`
  + Nom : `mnt-dir` ; MountPath : `/mnt`
  + Nom : `temp-data-dir` ; MountPath : `/tmp`
  + Nom : `home-dir` ; MountPath : `/home/hadoop`

  Voici les variables d'environnement prédéfinies qui s'appliquent uniquement au conteneur principal Spark :
  + `SPARK_CONTAINER_ID`
  + `K8S_SPARK_LOG_URL_STDERR`
  + `K8S_SPARK_LOG_URL_STDOUT`
  + `SIDECAR_SIGNAL_FILE`
**Note**  
Vous pouvez toujours utiliser ces volumes prédéfinis et les monter dans vos conteneurs sidecar supplémentaires. Par exemple, vous pouvez utiliser `emr-container-application-log-dir` et le monter sur votre propre conteneur sidecar défini dans le modèle de pod.

  Si les champs que vous indiquez entrent en conflit avec l'un des champs prédéfinis du modèle de pod, Spark génère une exception et la tâche échoue. L'exemple suivant montre un message d'erreur dans le journal de l'application Spark en raison de conflits avec les champs prédéfinis. 

  ```
  Defined volume mount path on main container must not overlap with reserved mount paths: [<reserved-paths>]
  ```

## Considérations relatives aux conteneurs sidecar
<a name="pod-template-sidecar"></a>

Amazon EMR contrôle le cycle de vie des pods provisionnés par Amazon EMR on EKS. Les conteneurs sidecar doivent suivre le même cycle de vie que le conteneur principal Spark. Si vous injectez des conteneurs sidecar supplémentaires dans vos pods, nous vous recommandons d'intégrer la gestion du cycle de vie des pods définie par Amazon EMR afin que le conteneur sidecar puisse s'arrêter de lui-même lorsque le conteneur principal Spark s'arrête.

Pour réduire les coûts, nous vous recommandons de mettre en œuvre un processus qui empêche les pods de pilotes avec des conteneurs sidecar de continuer à fonctionner après la fin de votre tâche. Le pilote Spark supprime les pods de l'exécuteur lorsque celui-ci a terminé sa tâche. Toutefois, lorsqu'un programme de pilote est terminé, les conteneurs sidecar supplémentaires continuent de fonctionner. Le pod est facturé jusqu'à ce qu'Amazon EMR on EKS nettoie le pod du pilote, généralement en moins d'une minute après la fin de l'exécution du conteneur principal Spark du pilote. Pour réduire les coûts, vous pouvez intégrer vos conteneurs sidecar supplémentaires au mécanisme de gestion du cycle de vie qu'Amazon EMR on EKS définit pour les pods de pilote et d'exécuteur, comme décrit dans la section suivante.

Le conteneur principal Spark dans les pods de pilote et d'exécuteur envoie `heartbeat` à un `/var/log/fluentd/main-container-terminated` de fichier toutes les deux secondes. En ajoutant le montage de volume `emr-container-communicate` prédéfini Amazon EMR à votre conteneur sidecar, vous pouvez définir un sous-processus de votre conteneur sidecar pour suivre périodiquement l'heure de la dernière modification de ce fichier. Le sous-processus s'arrête alors de lui-même s'il découvre que le conteneur principal Spark arrête la `heartbeat` pendant une durée plus longue. 

L'exemple suivant illustre un sous-processus qui suit le fichier de pulsation et s'arrête de lui-même. *your\$1volume\$1mount*Remplacez-le par le chemin où vous montez le volume prédéfini. Le script est intégré à l'image utilisée par le conteneur sidecar. Dans un fichier de modèle de pod, vous pouvez indiquer un conteneur de  sidecar à l'aide des commandes `sub_process_script.sh` et `main_command` suivantes.

```
MOUNT_PATH="your_volume_mount"
FILE_TO_WATCH="$MOUNT_PATH/main-container-terminated"
INITIAL_HEARTBEAT_TIMEOUT_THRESHOLD=60
HEARTBEAT_TIMEOUT_THRESHOLD=15
SLEEP_DURATION=10

function terminate_main_process() {
  # Stop main process
}

# Waiting for the first heartbeat sent by Spark main container
echo "Waiting for file $FILE_TO_WATCH to appear..."
start_wait=$(date +%s)
while ! [[ -f "$FILE_TO_WATCH" ]]; do
    elapsed_wait=$(expr $(date +%s) - $start_wait)
    if [ "$elapsed_wait" -gt "$INITIAL_HEARTBEAT_TIMEOUT_THRESHOLD" ]; then
        echo "File $FILE_TO_WATCH not found after $INITIAL_HEARTBEAT_TIMEOUT_THRESHOLD seconds; aborting"
        terminate_main_process
        exit 1
    fi
    sleep $SLEEP_DURATION;
done;
echo "Found file $FILE_TO_WATCH; watching for heartbeats..."

while [[ -f "$FILE_TO_WATCH" ]]; do
    LAST_HEARTBEAT=$(stat -c %Y $FILE_TO_WATCH)
    ELAPSED_TIME_SINCE_AFTER_HEARTBEAT=$(expr $(date +%s) - $LAST_HEARTBEAT)
    if [ "$ELAPSED_TIME_SINCE_AFTER_HEARTBEAT" -gt "$HEARTBEAT_TIMEOUT_THRESHOLD" ]; then
        echo "Last heartbeat to file $FILE_TO_WATCH was more than $HEARTBEAT_TIMEOUT_THRESHOLD seconds ago at $LAST_HEARTBEAT; terminating"
        terminate_main_process
        exit 0
    fi
    sleep $SLEEP_DURATION;
done;
echo "Outside of loop, main-container-terminated file no longer exists"
    
# The file will be deleted once the fluentd container is terminated

echo "The file $FILE_TO_WATCH doesn't exist any more;"
terminate_main_process
exit 0
```

# Utilisation des politiques de relance des tâches
<a name="jobruns-using-retry-policies"></a>

Dans Amazon EMR on EKS en version 6.9.0 et ultérieure, vous pouvez définir une politique de relance pour vos exécutions de tâches. Les politiques de relance entraînent le redémarrage automatique d'un pod de pilote de tâche en cas d'échec ou de suppression. Cela permet aux tâches de streaming Spark de longue durée d'être plus résistantes aux échecs.

## Définition d'une politique de relance pour une tâche
<a name="setting-retry-policy"></a>

Pour configurer une politique de nouvelle tentative, vous devez fournir un `RetryPolicyConfiguration` champ à l'aide de l'[StartJobRun](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_StartJobRun.html)API. Voici un exemple de `retryPolicyConfiguration` :

```
aws emr-containers start-job-run \
--virtual-cluster-id cluster_id \
--name sample-job-name \
--execution-role-arn execution-role-arn \
--release-label emr-6.9.0-latest \
--job-driver '{
  "sparkSubmitJobDriver": {
    "entryPoint": "local:///usr/lib/spark/examples/src/main/python/pi.py",
    "entryPointArguments": [ "2" ],
    "sparkSubmitParameters": "--conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"
  }
}' \
--retry-policy-configuration '{
    "maxAttempts": 5
  }' \
--configuration-overrides '{
  "monitoringConfiguration": {
    "cloudWatchMonitoringConfiguration": {
      "logGroupName": "my_log_group_name",
      "logStreamNamePrefix": "my_log_stream_prefix"
    },
    "s3MonitoringConfiguration": {
       "logUri": "s3://amzn-s3-demo-logging-bucket"
    }
  }
}'
```

**Note**  
`retryPolicyConfiguration`n'est disponible qu'à partir de la version AWS CLI 1.27.68. Pour effectuer la mise AWS CLI à jour vers la dernière version, voir [Installation ou mise à jour de la dernière version du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)

Indiquez dans ce champ `maxAttempts` le nombre maximum de fois que vous souhaitez que le pod de pilote de tâches soit redémarré en cas d'échec ou de suppression. [L'intervalle d'exécution entre deux tentatives de relance du pilote de tâche est un intervalle de relance exponentiel de (10 secondes, 20 secondes, 40 secondes, etc.) qui est plafonné à 6 minutes, comme décrit dans la documentation Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-backoff-failure-policy).

**Note**  
Chaque exécution supplémentaire d'un pilote de tâche sera facturée comme une autre tâche et sera soumise à la [tarification d'Amazon EMR on EKS](https://aws.amazon.com/emr/pricing/#Amazon_EMR_on_Amazon_EKS).

### Valeurs de configuration de la politique de relance
<a name="retry-config"></a>
+ **Politique de relance par défaut d'une tâche :** `StartJobRun` comprend une politique de relance définie par défaut sur 1 tentative maximum. Vous pouvez configurer la politique de relance comme vous le souhaitez.
**Note**  
Si le paramètre `maxAttempts` de `retryPolicyConfiguration` est défini sur 1, cela signifie qu'aucune nouvelle tentative n'aura lieu pour relancer le pod du pilote en cas d'échec.
+ **Désactivation de la politique de nouvelles tentatives pour une tâche :** pour désactiver une politique de nouvelles tentatives, définissez la valeur maximale de tentatives sur 1. retryPolicyConfiguration 

  ```
  "retryPolicyConfiguration": {
      "maxAttempts": 1
  }
  ```
+ **Définition du paramètre maxAttempts d'une tâche dans la plage valide :** l'appel `StartJobRun` échouera si la valeur `maxAttempts` est en dehors de la plage valide. La plage `maxAttempts` valide est comprise entre 1 et 2 147 483 647 (entier 32 bits), qui correspond à la plage prise en charge pour le paramètre de configuration `backOffLimit` de Kubernetes. Pour plus d'informations, consultez la rubrique [Politique en cas d'échec du mécanisme de retrait exponentiel pour le redémarrage des pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-backoff-failure-policy) dans la documentation de Kubernetes. Si la valeur `maxAttempts` n'est pas valide, le message d'erreur suivant est renvoyé :

  ```
  {
   "message": "Retry policy configuration's parameter value of maxAttempts is invalid"
  }
  ```

## Récupération de l'état de la politique de relance d'une tâche
<a name="retrieve-policy"></a>

Vous pouvez consulter l'état des nouvelles tentatives pour une tâche avec le [https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_ListJobRuns.html](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_ListJobRuns.html)et [https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_DescribeJobRun.html](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_DescribeJobRun.html) APIs. Lorsque vous demandez une tâche avec une configuration de politique de relance activée, les réponses `ListJobRun` et `DescribeJobRun` contiennent l'état de la politique de relance dans le champ `RetryPolicyExecution`. En outre, la réponse `DescribeJobRun` contiendra la `RetryPolicyConfiguration` saisie dans la demande `StartJobRun` pour la tâche.

**Exemples de réponses**

------
#### [ ListJobRuns response ]

```
{
  "jobRuns": [
    ...
    ...
    "retryPolicyExecution" : {
      "currentAttemptCount": 2
    }
    ...
    ...
  ]
}
```

------
#### [ DescribeJobRun response ]

```
{
  ...
  ...
  "retryPolicyConfiguration": {
    "maxAttempts": 5
   },
   "retryPolicyExecution" : {
    "currentAttemptCount": 2
  },
  ...
  ...
}
```

------

Ces champs ne seront pas visibles lorsque la politique de relance est désactivée dans la tâche, comme décrit ci-dessous dans [Valeurs de configuration de la politique de relance](#retry-config). 

## Surveillance d'une tâche à l'aide d'une politique de relance
<a name="monitoring-retry"></a>

Lorsque vous activez une politique de nouvelle tentative, un CloudWatch événement est généré pour chaque pilote de tâche créé. Pour vous abonner à ces événements, configurez une règle d' CloudWatch événement à l'aide de la commande suivante :

```
aws events put-rule \
--name cwe-test \
--event-pattern '{"detail-type": ["EMR Job Run New Driver Attempt"]}'
```

L'événement renverra des informations sur le `newDriverPodName`, l'horodatage `newDriverCreatedAt`, le `previousDriverFailureMessage` et les `currentAttemptCount` des pilotes de tâche. Ces événements ne seront pas créés si la politique de relance est désactivée.

Pour plus d'informations sur la façon de surveiller votre travail à l'aide d' CloudWatch événements, consultez[Surveillez les offres d'emploi avec Amazon CloudWatch Events](monitoring.md#monitoring-cloudwatch-events).

## Recherche de journaux pour les pilotes et les exécuteurs
<a name="finding-logs"></a>

Les noms des pods de pilotes suivent le format `spark-<job id>-driver-<random-suffix>`. Le même `random-suffix` est ajouté aux noms des pods d'exécuteur générés par le pilote. Lorsque vous utilisez ce `random-suffix`, vous pouvez trouver les journaux d'un pilote et de ses exécuteurs associés. Le `random-suffix` n'est présent que si la [politique de relance est activée](#retry-config) pour la tâche ; dans le cas contraire, le `random-suffix` est absent.

Pour plus d'informations sur la manière de configurer les tâches avec la configuration de surveillance pour la journalisation, consultez [Exécution d'une application Spark](getting-started.md#getting-started-run-spark-app).

# Utilisation de la rotation des journaux des événements Spark
<a name="emr-eks-log-rotation"></a>

Avec Amazon EMR en version 6.3.0 et ultérieure, vous pouvez activer la fonctionnalité de rotation des journaux des événements Spark pour Amazon EMR on EKS. Au lieu de générer un seul fichier journal des événements, cette fonctionnalité effectue la rotation des fichiers en fonction de l'intervalle de temps configuré et supprime les fichiers journaux des événements les plus anciens.

La rotation des journaux des événements Spark peut vous aider à éviter les problèmes potentiels liés à un fichier journal des événements Spark volumineux généré par des tâches de longue durée ou des tâches en streaming. Par exemple, vous démarrez une tâche Spark de longue durée avec un journal des événements activé avec le paramètre `persistentAppUI`. Le pilote Spark génère un fichier journal des événements. Si la tâche s'exécute pendant des heures ou des jours et que l'espace disque sur le nœud Kubernetes est limité, le fichier journal des événements peut consommer tout l'espace disque disponible. L'activation de la fonctionnalité de rotation des journaux des événements Spark résout le problème en divisant le fichier journal en plusieurs fichiers et en supprimant les fichiers les plus anciens.

**Note**  
Cette fonctionnalité n'est disponible qu'avec Amazon EMR on EKS. Amazon EMR exécuté sur Amazon EC2 ne prend pas en charge la rotation du journal des événements Spark.

Pour activer la fonctionnalité de rotation des journaux des événements Spark, configurez les paramètres Spark suivants :
+ `spark.eventLog.rotation.enabled` : active la rotation des journaux. Ce paramètre est désactivé par défaut dans le fichier de configuration de Spark. Réglez-le sur « true » pour activer cette fonctionnalité. 
+ `spark.eventLog.rotation.interval` : indique l'intervalle de temps pour la rotation des journaux. La valeur minimale est 60 secondes. La valeur par défaut est de 300 secondes. 
+ `spark.eventLog.rotation.minFileSize` : indique une taille de fichier minimale pour la rotation du fichier journal. La valeur minimale et par défaut est de 1 Mo. 
+ `spark.eventLog.rotation.maxFilesToRetain` : indique le nombre de fichiers journaux en rotation à conserver pendant le nettoyage. La plage valide est comprise entre 1 et 10. La valeur par défaut est 2. 

Vous pouvez indiquer ces paramètres dans la section `sparkSubmitParameters` de l'API [`StartJobRun`](emr-eks-jobs-submit.md), comme le montre l'exemple ci-dessous.

```
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi --conf spark.eventLog.rotation.enabled=true --conf spark.eventLog.rotation.interval=300 --conf spark.eventLog.rotation.minFileSize=1m --conf spark.eventLog.rotation.maxFilesToRetain=2"
```

# Utilisation de la rotation des journaux des conteneurs Spark
<a name="emr-eks-log-rotation-container"></a>

Avec Amazon EMR en version 6.11.0 et ultérieure, vous pouvez activer la fonctionnalité de rotation des journaux des conteneurs Spark pour Amazon EMR on EKS. Au lieu de générer un seul fichier journal `stdout` ou `stderr`, cette fonctionnalité effectue une rotation des fichiers en fonction de la taille de rotation configurée et supprime les fichiers journaux les plus anciens du conteneur.

La rotation des journaux des conteneurs Spark peut vous aider à éviter les problèmes potentiels liés aux fichiers journaux Spark volumineux générés pour les tâches de longue durée ou en streaming. Par exemple, vous pouvez démarrer une tâche Spark de longue durée et le pilote Spark génère un fichier journal du conteneur. Si la tâche s'exécute pendant des heures ou des jours et que l'espace disque sur le nœud Kubernetes est limité, le fichier journal du conteneur peut consommer tout l'espace disque disponible. Lorsque vous activez la rotation des journaux des conteneurs Spark, vous divisez le fichier journal en plusieurs fichiers et vous supprimez les fichiers les plus anciens.

Pour activer la fonctionnalité de rotation des journaux des conteneurs Spark, configurez les paramètres Spark suivants :

**`containerLogRotationConfiguration`**  
Incluez ce paramètre dans `monitoringConfiguration` pour activer la rotation des journaux. Ce paramètre est désactivé par défaut. Vous devez utiliser `containerLogRotationConfiguration` en plus de `s3MonitoringConfiguration`.

**`rotationSize`**  
Le paramètre `rotationSize` indique la taille du fichier pour la rotation des journaux. La plage de valeurs possibles est comprise entre `2KB` et `2GB`. La partie unitaire numérique du paramètre `rotationSize` est transmise sous forme d'entier. Les valeurs décimales n'étant pas prises en charge, vous pouvez indiquer une taille de rotation de 1,5 Go, par exemple, avec la valeur `1500MB`.

**`maxFilesToKeep`**  
Le paramètre `maxFilesToKeep` indique le nombre maximum de fichiers à retenir dans le conteneur après la rotation. La valeur minimale est 1 et la valeur maximale est 50.

Vous pouvez indiquer ces paramètres dans la section `monitoringConfiguration` de l'API `StartJobRun`, comme le montre l'exemple ci-dessous. Dans cet exemple, avec `rotationSize = "10 MB"` et `maxFilesToKeep = 3`, Amazon EMR on EKS effectue une rotation de vos journaux à 10 Mo, génère un nouveau fichier journal, puis purge le fichier journal le plus ancien une fois que le nombre de fichiers journaux atteint 3.

```
{
  "name": "my-long-running-job", 
  "virtualClusterId": "123456",  
  "executionRoleArn": "iam_role_name_for_job_execution", 
  "releaseLabel": "emr-6.11.0-latest", 
  "jobDriver": {
    "sparkSubmitJobDriver": {
      "entryPoint": "entryPoint_location",
      "entryPointArguments": ["argument1", "argument2", ...],  
       "sparkSubmitParameters": "--class main_class --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"
    }
  }, 
  "configurationOverrides": {
    "applicationConfiguration": [
      {
        "classification": "spark-defaults", 
        "properties": {
          "spark.driver.memory":"2G"
         }
      }
    ], 
    "monitoringConfiguration": {
      "persistentAppUI": "ENABLED", 
      "cloudWatchMonitoringConfiguration": {
        "logGroupName": "my_log_group", 
        "logStreamNamePrefix": "log_stream_prefix"
      }, 
      "s3MonitoringConfiguration": {
        "logUri": "s3://my_s3_log_location"
      },
      "containerLogRotationConfiguration": {
        "rotationSize":"10MB",
        "maxFilesToKeep":"3"
      }
    }
  }
}
```

Pour démarrer une exécution de tâche avec la rotation des journaux des conteneurs Spark, incluez dans la commande [`StartJobRun`](emr-eks-jobs-submit.md) un chemin d'accès au fichier JSON que vous avez configuré avec ces paramètres.

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

# Utilisation de la mise à l'échelle automatique verticale avec les tâches Spark sur Amazon EMR
<a name="jobruns-vas"></a>

La mise à l'échelle automatique verticale d'Amazon EMR on EKS permet d'adapter automatiquement les ressources de mémoire et de CPU aux besoins de la charge de travail que vous fournissez aux applications Spark sur Amazon EMR. Cela simplifie la gestion des ressources.

[Pour suivre l'utilisation des ressources de vos applications Spark sur Amazon EMR, aussi bien en temps réel qu'historiquement, la mise à l'échelle verticale automatique utilise l'outil Vertical Pod Autoscaler (VPA)](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) de Kubernetes. La capacité de mise à l'échelle automatique verticale utilise les données collectées par VPA pour ajuster automatiquement les ressources de mémoire et de CPU attribuées à vos applications Spark. Ce processus simplifié améliore la fiabilité et optimise les coûts.

**Topics**
+ [Configuration](jobruns-vas-setup.md)
+ [Prise en main](jobruns-vas-gs.md)
+ [Configuration](jobruns-vas-configure.md)
+ [Surveillance des recommandations](jobruns-vas-monitor.md)
+ [Désinstallation](jobruns-vas-uninstall-operator.md)

# Configuration de la mise à l'échelle automatique verticale pour Amazon EMR on EKS
<a name="jobruns-vas-setup"></a>

Cette rubrique vous aide à préparer votre cluster Amazon EKS à soumettre des tâches Spark Amazon EMR avec mise à l'échelle automatique verticale. Le processus de configuration nécessite que vous confirmiez ou effectuiez les tâches décrites dans les sections suivantes :

**Topics**
+ [Conditions préalables](#jobruns-vas-prereqs)
+ [Installation d'Operator Lifecycle Manager (OLM) sur votre cluster Amazon EKS](#jobruns-vas-install-olm)
+ [Installation de l'opérateur de mise à l'échelle automatique verticale d'Amazon EMR on EKS](#jobruns-vas-install-operator)

## Conditions préalables
<a name="jobruns-vas-prereqs"></a>

Effectuez les tâches ci-dessous avant d'installer l'opérateur Kubernetes de mise à l'échelle automatique verticale sur votre cluster. Si vous avez déjà rempli l'une des conditions préalables, vous pouvez l'ignorer et passer à la suivante.
+ **[Installation ou mise à jour vers la dernière version du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)** — Si vous avez déjà installé le AWS CLI, vérifiez que vous disposez de la dernière version.
+ **[Installer kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)** – kubectl est un outil de ligne de commande que vous utilisez pour communiquer avec le serveur d'API Kubernetes. Vous avez besoin de kubectl pour installer et surveiller les artefacts liés à la mise à l'échelle automatique verticale sur votre cluster Amazon EKS.
+ **[Installer le kit SDK de l'opérateur](https://sdk.operatorframework.io/docs/installation/)** – Amazon EMR on EKS utilise le kit SDK de l'opérateur en tant que gestionnaire de packages pour la durée de vie de l'opérateur de mise à l'échelle automatique verticale que vous installez sur votre cluster.
+ **[Installer Docker](https://docs.docker.com/get-docker/)** – Vous devez accéder à la CLI Docker pour vous authentifier et récupérer les images Docker relatives à la mise à l'échelle automatique verticale à installer sur votre cluster Amazon EKS.
+ **[Installation du serveur Kubernetes Metrics : vous devez d'abord installer le serveur](https://docs.aws.amazon.com/eks/latest/userguide/metrics-server.html)** de métriques afin que l'autoscaler vertical du pod puisse récupérer les métriques depuis le serveur d'API Kubernetes.
+ **[Commencez avec Amazon EKS — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) (version 1.24 ou supérieure)** — La mise à l'échelle automatique verticale est prise en charge par les versions 1.24 et supérieures d'Amazon EKS. Une fois le cluster créé, [enregistrez-le pour l'utiliser avec Amazon EMR](setting-up-registration.md).
+ **[Sélectionner l'URI d'une image de base Amazon EMR](docker-custom-images-tag.md) (version 6.10.0 ou supérieure)** – La mise à l'échelle automatique verticale est prise en charge par Amazon EMR à partir de la version 6.10.0.

## Installation d'Operator Lifecycle Manager (OLM) sur votre cluster Amazon EKS
<a name="jobruns-vas-install-olm"></a>

Utilisez l'interface CLI du kit SDK de l'opérateur pour installer Operator Lifecycle Manager (OLM) sur le cluster Amazon EMR on EKS où vous souhaitez configurer la mise à l'échelle automatique verticale, comme indiqué dans l'exemple ci-dessous. Une fois que vous l'avez configuré, vous pouvez utiliser OLM pour installer et gérer le cycle de vie de [l'opérateur de mise à l'échelle automatique verticale d'Amazon EMR](#jobruns-vas-install-operator).

```
operator-sdk olm install
```

Pour valider l'installation, exécutez la commande `olm status` :

```
operator-sdk olm status
```

Vérifiez que la commande renvoie un résultat positif, similaire à l'exemple ci-dessous :

```
INFO[0007] Successfully got OLM status for version X.XX
```

Si votre installation échoue, consultez [Résolution des problèmes de mise à l'échelle automatique verticale d'Amazon EMR on EKS](troubleshooting-vas.md).

## Installation de l'opérateur de mise à l'échelle automatique verticale d'Amazon EMR on EKS
<a name="jobruns-vas-install-operator"></a>

Suivez les étapes ci-dessous pour installer l'opérateur de mise à l'échelle automatique verticale sur votre cluster Amazon EKS :

1. Configurez les variables d'environnement ci-dessous que vous utiliserez pour terminer l'installation :
   + **`$REGION`** renvoie à la Région AWS correspondant à votre cluster. Par exemple, `us-west-2`.
   + **`$ACCOUNT_ID`** renvoie à l'identifiant du compte Amazon ECR de votre région. Pour de plus amples informations, veuillez consulter [Comptes de registre Amazon ECR par région](docker-custom-images-tag.md#docker-custom-images-ECR).
   + **`$RELEASE`** renvoie à la version Amazon EMR que vous souhaitez utiliser pour votre cluster. Avec la mise à l'échelle automatique verticale, vous devez utiliser Amazon EMR en version 6.10.0 ou supérieure.

1. Ensuite, obtenez jetons d'authentification pour le [registre Amazon ECR](docker-custom-images-tag.md#docker-custom-images-ECR) destiné à l'opérateur.

   ```
   aws ecr get-login-password \
    --region region-id | docker login \
    --username AWS \
    --password-stdin $ACCOUNT_ID.dkr.ecr.region-id.amazonaws.com
   ```

1. Installez l'opérateur de mise à l'échelle automatique verticale d'Amazon EMR on EKS à l'aide de la commande suivante :

   ```
   ECR_URL=$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com && \
   REPO_DEST=dynamic-sizing-k8s-operator-olm-bundle && \
   BUNDLE_IMG=emr-$RELEASE-dynamic-sizing-k8s-operator && \
   operator-sdk run bundle \
   $ECR_URL/$REPO_DEST/$BUNDLE_IMG\:latest
   ```

   Cela créera une version de l'opérateur de mise à l'échelle automatique verticale dans l'espace de noms par défaut de votre cluster Amazon EKS. Utilisez cette commande pour effectuer l'installation dans un autre espace de noms :

   ```
   operator-sdk run bundle \
   $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/dynamic-sizing-k8s-operator-olm-bundle/emr-$RELEASE-dynamic-sizing-k8s-operator:latest \
   -n operator-namespace
   ```
**Note**  
Si l'espace de noms que vous avez spécifié n'existe pas, OLM n'installera pas l'opérateur. Pour de plus amples informations, veuillez consulter [L'espace de noms Kubernetes est introuvable](troubleshooting-vas.md).

1. Vérifiez que vous avez bien installé l'opérateur à l'aide de l'outil de ligne de commande kubectl de Kubernetes.

   ```
   kubectl get csv -n operator-namespace
   ```

   La commande `kubectl` doit renvoyer votre opérateur de mise à l'échelle automatique verticale nouvellement déployé avec un état de **phase** indiquant **Réussi**. Si vous rencontrez des difficultés lors de l'installation ou de la configuration, consultez [Résolution des problèmes de mise à l'échelle automatique verticale d'Amazon EMR on EKS](troubleshooting-vas.md).

# Les premiers pas avec la mise à l'échelle automatique verticale pour Amazon EMR on EKS
<a name="jobruns-vas-gs"></a>

Utilisez l'autoscaling vertical pour Amazon EMR sur EKS lorsque vous souhaitez régler automatiquement la mémoire et les ressources du processeur afin de les adapter à la charge de travail de votre application Amazon EMR Spark. Pour plus d'informations, consultez la section [Utilisation de la mise à l'échelle automatique verticale avec les tâches Amazon EMR](jobruns-vas.html) Spark.

## Soumission d'une tâche Spark avec mise à l'échelle automatique verticale
<a name="jobruns-vas-spark-submit"></a>

Lorsque vous soumettez une tâche via l'[StartJobRun](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_StartJobRun.html)API, ajoutez les deux configurations suivantes au pilote de votre tâche Spark afin d'activer la mise à l'échelle automatique verticale :

```
"spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing":"true",
"spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.signature":"YOUR_JOB_SIGNATURE"
```

Dans le code ci-dessus, la première ligne active la fonctionnalité de mise à l'échelle automatique verticale. La ligne suivante est une configuration de signature obligatoire qui vous permet de choisir une signature pour votre tâche.

Pour plus d'informations sur ces configurations et les valeurs de paramètres acceptables, consultez [Configuration de la mise à l'échelle automatique verticale pour Amazon EMR on EKS](jobruns-vas-configure.md). Par défaut, votre tâche est soumise en mode **Désactivé**, réservé à la surveillance uniquement, de la mise à l'échelle automatique verticale. Cet état de surveillance vous permet de calculer et de consulter les recommandations en matière de ressources sans procéder à la mise à l'échelle automatique. Pour de plus amples informations, veuillez consulter [Modes de mise à l'échelle automatique verticale](jobruns-vas-configure.md#jobruns-vas-parameters-opt-mode).

L'exemple suivant montre comment exécuter un exemple de commande `start-job-run` avec la mise à l'échelle automatique verticale :

```
aws emr-containers start-job-run \
--virtual-cluster-id $VIRTUAL_CLUSTER_ID \
--name $JOB_NAME \
--execution-role-arn $EMR_ROLE_ARN \
--release-label emr-6.10.0-latest \
--job-driver '{
  "sparkSubmitJobDriver": {
     "entryPoint": "local:///usr/lib/spark/examples/src/main/python/pi.py"
   }
 }' \
--configuration-overrides '{
    "applicationConfiguration": [{
        "classification": "spark-defaults",
        "properties": {
          "spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing": "true",
          "spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.signature": "test-signature"
        }
    }]
  }'
```

## Vérification de la fonctionnalité de mise à l'échelle automatique verticale
<a name="jobruns-vas-verify"></a>

Pour vérifier que la mise à l'échelle automatique verticale fonctionne correctement pour la tâche soumise, utilisez kubectl pour obtenir la ressource personnalisée `verticalpodautoscaler` et consulter vos recommandations de mise à l'échelle. Par exemple, la commande suivante demande des recommandations sur l'exemple de tâche à partir de la section [Soumission d'une tâche Spark avec mise à l'échelle automatique verticale](#jobruns-vas-spark-submit) :

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

Le résultat de cette requête devrait ressembler à ce qui suit :

```
NAME                                                          MODE   CPU         MEM PROVIDED   AGE
ds-jceyefkxnhrvdzw6djum3naf2abm6o63a6dvjkkedqtkhlrf25eq-vpa   Off    3304504865  True           87m
```

Si votre résultat ne ressemble pas à cela ou contient un code d'erreur, consultez [Résolution des problèmes de mise à l'échelle automatique verticale d'Amazon EMR on EKS](troubleshooting-vas.md) pour des étapes permettant de résoudre le problème.

# Configuration de la mise à l'échelle automatique verticale pour Amazon EMR on EKS
<a name="jobruns-vas-configure"></a>

Vous pouvez configurer l'autoscaling vertical lorsque vous soumettez des tâches Amazon EMR Spark via [StartJobRun](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_StartJobRun.html)l'API. Définissez les paramètres de configuration liés à la mise à l'échelle automatique sur le pod du pilote Spark, comme indiqué dans l'exemple [Soumission d'une tâche Spark avec mise à l'échelle automatique verticale](jobruns-vas-gs.md#jobruns-vas-spark-submit).

L'opérateur de mise à l'échelle automatique verticale d'Amazon EMR on EKS écoute les pods de pilotes équipés de la fonctionnalité de mise à l'échelle automatique. Il assure ensuite l'intégration avec Vertical Pod Autoscaler (VPA) de Kubernetes en se basant sur les paramètres de ces pods de pilotes. Cela facilite le suivi des ressources et la mise à l'échelle automatique des pods d'exécuteurs Spark.

Les sections suivantes décrivent les paramètres que vous pouvez utiliser lorsque vous configurez la mise à l'échelle automatique verticale pour votre cluster Amazon EKS.

**Note**  
Configurez le paramètre de basculement de fonctionnalité sous forme d'étiquette et définissez les autres paramètres sous forme d'annotations sur le pod du pilote Spark. Les paramètres de mise à l'échelle automatique appartiennent au domaine `emr-containers.amazonaws.com/` et portent le préfixe `dynamic.sizing`.

## Paramètres requis
<a name="jobruns-vas-parameters-req"></a>

Vous devez inclure les deux paramètres ci-dessous dans le pilote de tâche Spark lorsque vous soumettez votre tâche :


| Clé | Description | Valeurs acceptées | Valeur par défaut | Type | Paramètre Spark1 | 
| --- | --- | --- | --- | --- | --- | 
|  `dynamic.sizing`  |  Basculement de fonctionnalité  |  `true`, `false`  |  non défini  |  étiquette  |  `spark.kubernetes.driver.label.emr-containers.amazonaws.com/dynamic.sizing`  | 
|  `dynamic.sizing.signature`  |  Signature de la tâche  |  *string*  |  non défini  |  annotation  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.signature`  | 

1 Utilisez ce paramètre en tant que `SparkSubmitParameter` ou `ConfigurationOverride` dans l'API `StartJobRun`.
+ **`dynamic.sizing`** – Vous pouvez activer ou désactiver la mise à l'échelle automatique verticale à l'aide de l'étiquette `dynamic.sizing`. Pour activer la mise à l'échelle automatique verticale, attribuez à `dynamic.sizing` la valeur `true` sur le pod du pilote Spark. Si vous omettez cette étiquette ou si vous lui attribuez une valeur autre que `true`, la mise à l'échelle automatique verticale est désactivée.
+ **`dynamic.sizing.signature`** – Définissez la signature de la tâche à l'aide de l'annotation `dynamic.sizing.signature` sur le pod du pilote. La mise à l'échelle automatique verticale compile les données d'utilisation des ressources sur diverses exécutions de tâches Spark d'Amazon EMR afin de fournir des recommandations concernant les ressources. Vous fournissez l'identifiant unique pour relier les tâches entre elles.

  
**Note**  
Si votre tâche se reproduit à un intervalle fixe, par exemple tous les jours ou toutes les semaines, la signature de votre tâche doit rester la même pour chaque nouvelle instance de la tâche. Cela garantit que la mise à l'échelle automatique verticale peut calculer et agréger les recommandations au cours des différentes étapes de la tâche.

1 Utilisez ce paramètre en tant que `SparkSubmitParameter` ou `ConfigurationOverride` dans l'API `StartJobRun`.

## Paramètres facultatifs
<a name="jobruns-vas-parameters-opt"></a>

La mise à l'échelle automatique verticale prend également en charge les paramètres facultatifs ci-dessous. Définissez-les sous forme d'annotations sur le pod du pilote.


| Clé | Description | Valeurs acceptées | Valeur par défaut | Type | Paramètre Spark1 | 
| --- | --- | --- | --- | --- | --- | 
|  `dynamic.sizing.mode`  |  Mode de mise à l'échelle automatique verticale  |  `Off`, `Initial`, `Auto`  |  `Off`  |  annotation  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.mode`  | 
|  `dynamic.sizing.scale.memory`  |  Permet la mise à l'échelle de la mémoire  |  *`true`, `false`*  |  `true`  |  annotation  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.memory`  | 
|  `dynamic.sizing.scale.cpu`  |  Activer ou désactiver la mise à l'échelle de la CPU  |  *`true`, `false`*  |  `false`  |  annotation  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.cpu`  | 
|  `dynamic.sizing.scale.memory.min`  |  Limite minimale de la mise à l'échelle de la mémoire  | chaîne, [quantité de ressources K8s](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), p. ex. : 1G |  non défini  |  annotation  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.memory.min | 
|  `dynamic.sizing.scale.memory.max`  |  Limite maximale de mise à l'échelle de la mémoire  | chaîne, [quantité de ressources K8s](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), p. ex. : 4G |  non défini  |  annotation  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.memory.max | 
|  `dynamic.sizing.scale.cpu.min`  |  Limite minimale de la mise à l'échelle de la CPU  | chaîne, [quantité de ressources K8s](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), p. ex. : 1 |  non défini  |  annotation  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.cpu.min | 
|  `dynamic.sizing.scale.cpu.max`  |  Limite maximale de la mise à l'échelle de la CPU  | chaîne, [quantité de ressources K8s](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), p. ex. : 2 |  non défini  |  annotation  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.cpu.max | 

### Modes de mise à l'échelle automatique verticale
<a name="jobruns-vas-parameters-opt-mode"></a>

Le paramètre `mode` correspond aux différents modes de mise à l'échelle automatique pris en charge par VPA. Utilisez l'annotation `dynamic.sizing.mode` sur le pod du pilote pour définir le mode. Les valeurs suivantes sont prises en charge pour ce paramètre :
+ **Désactivé** – Mode de simulation où vous pouvez consulter les recommandations, mais la mise à l'échelle automatique n'est pas effectuée. Il s'agit du mode par défaut pour la mise à l'échelle automatique verticale. Dans ce mode, la ressource Vertical Pod Autoscaler associée calcule les recommandations, et vous pouvez consulter ces recommandations à l'aide d'outils tels que kubectl, Prometheus et Grafana.
+ **Initial** – Dans ce mode, VPA redimensionne automatiquement les ressources au démarrage de la tâche si des recommandations sont disponibles sur la base de l'historique des exécutions de la tâche, comme dans le cas d'une tâche récurrente.
+ **Automatique** – Dans ce mode, VPA expulse les pods d'exécuteurs Spark et les met automatiquement à l'échelle avec les paramètres de ressources recommandés lorsque le pod du pilote Spark les redémarre. VPA expulse parfois les pods d'exécuteurs Spark en cours d'exécution, ce qui peut entraîner une latence supplémentaire lorsqu'il réessaie l'exécuteur interrompu.

### Mise à l'échelle des ressources
<a name="jobruns-vas-parameters-opt-rs"></a>

Lorsque vous configurez la mise à l'échelle automatique verticale, vous pouvez choisir de mettre à l'échelle les ressources de CPU et de mémoire. Définissez les annotations `dynamic.sizing.scale.cpu` et `dynamic.sizing.scale.memory` sur `true` ou `false`. Par défaut, la mise à l'échelle de la CPU est définie sur `false`, et la mise à l'échelle de la mémoire est définie sur `true`.

### Ressources minimales et maximales (limites)
<a name="jobruns-vas-parameters-opt-bounds"></a>

En option, vous pouvez également définir des limites pour les ressources de CPU et de mémoire. Choisissez une valeur minimale et maximale pour ces ressources avec les annotations `dynamic.sizing.[memory/cpu].[min/max]` lorsque vous activez la mise à l'échelle automatique. Par défaut, les ressources ne sont pas limitées. Définissez les annotations sous forme de chaînes représentant une quantité de ressources Kubernetes. Par exemple, définissez `dynamic.sizing.memory.max` sur `4G` pour représenter 4 Go.

# Surveillance de la mise à l'échelle automatique verticale pour Amazon EMR on EKS
<a name="jobruns-vas-monitor"></a>

Vous pouvez utiliser l'outil de ligne de commande **kubectl** Kubernetes pour répertorier les recommandations actives et verticales liées à l'autoscaling sur votre cluster. Vous pouvez également consulter les signatures de vos tâches suivies et purger les ressources inutiles associées aux signatures.



## Liste des recommandations de mise à l'échelle automatique verticale pour votre cluster
<a name="jobruns-vas-monitor-list"></a>

Utilisez kubectl pour obtenir la ressource `verticalpodautoscaler` et en afficher l'état actuel et les recommandations. L'exemple de requête ci-dessous renvoie toutes les ressources actives de votre cluster Amazon EKS.

```
kubectl get verticalpodautoscalers \
-o custom-columns="NAME:.metadata.name,"\
"SIGNATURE:.metadata.labels.emr-containers\.amazonaws\.com/dynamic\.sizing\.signature,"\
"MODE:.spec.updatePolicy.updateMode,"\
"MEM:.status.recommendation.containerRecommendations[0].target.memory" \
--all-namespaces
```

Le résultat de cette requête ressemble à ce qui suit :

```
NAME                  SIGNATURE                MODE      MEM
ds-example-id-1-vpa   job-signature-1          Off       none
ds-example-id-2-vpa   job-signature-2          Initial   12936384283
```

## Interrogation et suppression des recommandations de mise à l'échelle automatique verticale pour votre cluster
<a name="jobruns-vas-monitor-query"></a>

Lorsque vous supprimez une ressource d'exécution de tâches à mise à l'échelle automatique verticale Amazon EMR, l'objet VPA associé qui suit et stocke les recommandations est automatiquement effacé.

L'exemple ci-dessous utilise kubectl pour purger les recommandations pour une tâche identifiée par une signature :

```
kubectl delete jobrun -n emr -l=emr-containers\.amazonaws\.com/dynamic\.sizing\.signature=integ-test
jobrun.dynamicsizing.emr.services.k8s.aws "ds-job-signature" deleted
```

Si vous ne connaissez pas la signature spécifique de la tâche ou si vous souhaitez purger toutes les ressources du cluster, vous pouvez utiliser `--all` ou `--all-namespaces` dans votre commande au lieu de l'identifiant unique de la tâche, comme le montre l'exemple ci-dessous :

```
kubectl delete jobruns --all --all-namespaces
jobrun.dynamicsizing.emr.services.k8s.aws "ds-example-id" deleted
```

# Désinstallation de l'opérateur de mise à l'échelle automatique verticale d'Amazon EMR on EKS
<a name="jobruns-vas-uninstall-operator"></a>

Si vous souhaitez supprimer l'opérateur de mise à l'échelle automatique verticale de votre cluster Amazon EKS, utilisez la commande `cleanup` avec l'interface CLI du kit SDK de l'opérateur, comme indiqué dans l'exemple ci-dessous. Cette opération supprime également les dépendances en amont qui ont été installées avec l'opérateur, comme Vertical Pod Autoscaler.

```
operator-sdk cleanup emr-dynamic-sizing
```

Si des tâches sont en cours d'exécution sur le cluster lorsque vous supprimez l'opérateur, elles continuent de s'exécuter sans mise à l'échelle automatique verticale. [Si vous soumettez des tâches sur le cluster après avoir supprimé l'opérateur, Amazon EMR on EKS ignorera tous les paramètres liés à la mise à l'échelle automatique verticale que vous auriez définis lors de la configuration.](jobruns-vas-configure.md)