Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Spark-Aufträge ausführen mit `StartJobRun`
<a name="job-runs"></a>

Dieser Abschnitt enthält detaillierte Einrichtungsschritte, um Ihre Umgebung für die Ausführung von Spark-Jobs vorzubereiten. Anschließend finden Sie step-by-step Anweisungen zum Senden einer Jobausführung mit bestimmten Parametern.

**Topics**
+ [Einrichten von Amazon EMR in EKS](setting-up.md)
+ [Reichen Sie einen Auftrag ein, der ausgeführt wird mit `StartJobRun`](emr-eks-jobs-submit.md)
+ [Verwenden der Auftragserteilung](emr-eks-job-submitter.md)
+ [Verwendung der Standardklassifizierung von Amazon EMR-Containern](emr-eks-job-submitter-container-defaults.md)

# Einrichten von Amazon EMR in EKS
<a name="setting-up"></a>

Führen Sie zum Einrichten von Amazon EMR in EKS die folgenden Schritte aus. Wenn Sie bereits für Amazon Web Services (AWS) registriert sind und Amazon EKS schon verwendet haben, müssen Sie nur wenige Schritte ausführen, um Amazon EMR in EKS nutzen zu können. Überspringen Sie alle Aufgaben, die Sie bereits abgeschlossen haben.

**Anmerkung**  
Sie können auch dem [Amazon EMR in EKS-Workshop](https://emr-on-eks.workshop.aws/amazon-emr-eks-workshop.html) folgen, um alle Ressourcen einzurichten, die für die Ausführung von Spark-Jobs auf Amazon EMR in EKS erforderlich sind. Der Workshop bietet auch Automatisierung, indem CloudFormation Vorlagen verwendet werden, um die Ressourcen zu erstellen, die Sie für den Einstieg benötigen. Weitere Vorlagen und Best Practices finden Sie in unserem [EMR Containers Best Practices Guide](https://aws.github.io/aws-emr-containers-best-practices/) unter GitHub.

1. [Installieren oder aktualisieren Sie auf die neueste Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)

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

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

1. [Clusterzugriff für Amazon EMR auf EKS aktivieren](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html)

1. [Aktivieren Sie IAM-Rollen für den EKS-Cluster](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM-roles.html)

1. [Gewähren Sie Benutzern Zugriff auf Amazon EMR in EKS](setting-up-iam.md)

1. [Den Amazon-EKS-Cluster mit Amazon EMR registrieren](setting-up-registration.md)

# Gewähren eines Clusterzugriff für Amazon EMR in EKS
<a name="setting-up-cluster-access"></a>

In den folgenden Abschnitten werden einige Möglichkeiten zum Aktivieren des Clusterzugriffs beschrieben. Die erste Methode verwendet Amazon EKS Cluster Access Management (CAM) und die zweite zeigt, wie manuelle Schritte unternommen werden, um den Cluster-Zugriff zu aktivieren.

## Aktivieren Sie den Clusterzugriff mithilfe von EKS Access Entry (empfohlen)
<a name="setting-up-cluster-access-cam-integration"></a>

**Anmerkung**  
Der `aws-auth` ConfigMap ist veraltet. Die empfohlene Methode zur Verwaltung des Zugriffs auf Kubernetes APIs ist [Access](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) Entries.

Amazon EMR ist in [Amazon EKS Cluster Access Management (CAM)](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) integriert, sodass Sie die Konfiguration der erforderlichen AuthN- und AuthZ-Richtlinien automatisieren können, um Amazon EMR Spark-Jobs in Namespaces von Amazon EKS-Clustern auszuführen. Wenn Sie einen virtuellen Cluster aus einem Amazon EKS-Cluster-Namespace erstellen, konfiguriert Amazon EMR automatisch alle erforderlichen Berechtigungen, sodass Sie Ihren aktuellen Workflows keine zusätzlichen Schritte hinzufügen müssen.

**Anmerkung**  
Die Amazon EMR-Integration mit Amazon EKS CAM wird nur für neue Amazon EMR auf virtuellen EKS-Clustern unterstützt. Sie können bestehende virtuelle Cluster nicht migrieren, um diese Integration zu nutzen.

### Voraussetzungen
<a name="setting-up-cluster-access-cam-integration-prereqs"></a>
+ Stellen Sie sicher, dass Sie Version 2.15.3 oder höher von ausführen AWS CLI
+ Ihr Amazon EKS-Cluster muss Version 1.23 oder höher haben.

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

Um die Integration zwischen Amazon EMR und den AccessEntry API-Vorgängen von Amazon EKS einzurichten, stellen Sie sicher, dass Sie die folgenden Punkte abgeschlossen haben:
+ Stellen Sie sicher, dass `authenticationMode` Ihr Amazon EKS-Cluster auf eingestellt ist`API_AND_CONFIG_MAP`.

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

  Falls dies noch nicht der Fall ist, stellen Sie es `authenticationMode` auf ein`API_AND_CONFIG_MAP`.

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

  Weitere Informationen zu Authentifizierungsmodi finden Sie unter [Cluster-Authentifizierungsmodi](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html#authentication-modes).
+ Stellen Sie sicher, dass die [IAM-Rolle](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html), die Sie zum Ausführen der `CreateVirtualCluster` und `DeleteVirtualCluster` API-Operationen verwenden, auch über die folgenden Berechtigungen verfügt:

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

### Konzepte und Terminologie
<a name="setting-up-cluster-access-cam-integration-concepts"></a>

Im Folgenden finden Sie eine Liste von Terminologien und Konzepten im Zusammenhang mit Amazon EKS CAM.
+ Virtueller Cluster (VC) — logische Darstellung des in Amazon EKS erstellten Namespaces. Es ist ein 1:1 -Link zu einem Amazon EKS-Cluster-Namespace. Sie können es verwenden, um Amazon EMR-Workloads auf einem Amazon EKS-Cluster innerhalb des angegebenen Namespace auszuführen.
+ Namespace — Mechanismus zum Isolieren von Ressourcengruppen innerhalb eines einzelnen EKS-Clusters.
+ Zugriffsrichtlinie — Berechtigungen, die einer IAM-Rolle innerhalb eines EKS-Clusters Zugriff und Aktionen gewähren.
+ Zugriffseintrag — ein Eintrag, der mit einer Rolle arn erstellt wurde. Sie können den Zugriffseintrag mit einer Zugriffsrichtlinie verknüpfen, um bestimmte Berechtigungen im Amazon EKS-Cluster zuzuweisen.
+ Integrierter virtueller EKS-Zugangscluster — der virtuelle Cluster, der mithilfe von [API-Vorgängen für die Zugriffseingabe](https://docs.aws.amazon.com/eks/latest/APIReference/API_Operations_Amazon_Elastic_Kubernetes_Service.html) von Amazon EKS erstellt wurde.

## Aktivieren Sie den Clusterzugriff mit `aws-auth`
<a name="setting-up-cluster-access-aws-auth"></a>

Sie müssen Amazon EMR in EKS Zugriff auf einen bestimmten Namespace in Ihrem Cluster gewähren, indem Sie die folgenden Aktionen ausführen: eine Kubernetes-Rolle erstellen, die Rolle an einen Kubernetes-Benutzer binden und den Kubernetes-Benutzer der serviceverknüpften Rolle [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) zuordnen. Diese Aktionen werden in `eksctl` automatisiert, wenn der IAM-Befehl zur Identitätszuweisung zusammen mit `emr-containers` als Servicenamen verwendet wird. Sie können diese Vorgänge einfach durchführen, indem Sie den folgenden Befehl verwenden.

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

*my\$1eks\$1cluster*Ersetzen Sie es durch den Namen Ihres Amazon EKS-Clusters und *kubernetes\$1namespace* ersetzen Sie es durch den Kubernetes-Namespace, der für die Ausführung von Amazon EMR-Workloads erstellt wurde. 

**Wichtig**  
Sie müssen die neueste Version von eksctl mithilfe des vorherigen Schritts herunterladen. [Richten Sie kubectl und eksctl ein, um diese Funktionalität nutzen zu](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) können. 

### Manuelle Schritte zur Aktivierung des Clusterzugriffs für Amazon EMR in EKS
<a name="setting-up-cluster-access-manual"></a>

Sie können auch die folgenden manuellen Schritte verwenden, um den Clusterzugriff für Amazon EMR in EKS zu aktivieren.

1. **Erstellen Sie eine Kubernetes-Rolle in einem bestimmten Namespace**

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

   Führen Sie mit Amazon EKS 1.22 — 1.29 den folgenden Befehl aus, um eine Kubernetes-Rolle in einem bestimmten Namespace zu erstellen. Diese Rolle gewährt Amazon EMR in EKS die erforderlichen RBAC-Berechtigungen.

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

   Führen Sie bei Amazon EKS 1.21 und niedriger den folgenden Befehl aus, um eine Kubernetes-Rolle in einem bestimmten Namespace zu erstellen. Diese Rolle gewährt Amazon EMR in EKS die erforderlichen RBAC-Berechtigungen.

   ```
   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. **Eine Kubernetes-Rollenbindung mit Gültigkeitsbereich für den Namespace erstellen**

   Führen Sie den folgenden Befehl aus, um eine Kubernetes-Rollenbindung im angegebenen Namespace zu erstellen. Diese Rollenbindung gewährt einem Benutzer mit dem Namen `emr-containers` die in der im vorherigen Schritt erstellten Rolle definierten Berechtigungen. Dieser Benutzer identifiziert [serviceverknüpfte Rollen für Amazon EMR in EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html) und ermöglicht somit Amazon EMR in EKS, Aktionen auszuführen, die in der von Ihnen erstellten Rolle definiert sind.

   ```
   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. **Aktualisieren Sie die `aws-auth`-Kubernetes-Konfigurationsübersicht **

   Sie können eine der folgenden Optionen verwenden, um die serviceverknüpfte Rolle Amazon EMR in EKS dem `emr-containers`-Benutzer zuzuordnen, der im vorherigen Schritt an die Kubernetes-Rolle gebunden war.

   **Option 1: Verwenden von `eksctl`**

   Führen Sie den folgenden `eksctl`-Befehl aus, um die serviceverknüpfte Rolle Amazon EMR in EKS dem `emr-containers`-Benutzer zuzuordnen.

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

   **Option 2: Ohne eksctl zu verwenden**

   1. Führen Sie den folgenden Befehl aus, um die `aws-auth`-Konfigurationsübersicht im Texteditor zu öffnen. 

      ```
      kubectl edit -n kube-system configmap/aws-auth
      ```
**Anmerkung**  
Wenn Sie eine Fehlermeldung erhalten`Error from server (NotFound): configmaps "aws-auth" not found`, lesen Sie die Schritte unter [Benutzerrollen hinzufügen](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) im Amazon EKS-Benutzerhandbuch, um den Bestand anzuwenden ConfigMap. 

   1. Fügen Sie die mit dem Service verknüpften Rollendetails von Amazon EMR in EKS zum `mapRoles`-Abschnitt von `ConfigMap` unter `data` hinzu. Fügen Sie diesen Abschnitt hinzu, wenn er nicht bereits in der Datei vorhanden sind. Der aktualisierte `mapRoles`-Abschnitt unter Daten sieht wie das folgende Beispiel aus.

      ```
      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. Speichern Sie die Datei und beenden Sie den Text-Editor.

# Aktivieren Sie IAM-Rollen für den EKS-Cluster
<a name="setting-up-enable-IAM-roles"></a>

In den folgenden Themen werden die Optionen für die Aktivierung von IAM-Rollen detailliert beschrieben.

**Topics**
+ [Option 1: Aktivieren Sie EKS Pod Identity auf dem EKS-Cluster](setting-up-enable-IAM.md)
+ [Option 2: Aktivieren Sie IAM-Rollen für Service Accounts (IRSA) auf dem EKS-Cluster](setting-up-enable-IAM-service-accounts.md)

# Option 1: Aktivieren Sie EKS Pod Identity auf dem EKS-Cluster
<a name="setting-up-enable-IAM"></a>

Amazon-EKS-Pod-Identity-Zuordnungen bieten die Möglichkeit, Anmeldeinformationen für Ihre Anwendungen zu verwalten, ähnlich wie Amazon-EC2-Instance-Profile Anmeldeinformationen für Amazon-EC2-Instances bereitstellen. Amazon EKS Pod Identity bietet Anmeldeinformationen für Ihre Workloads mit einer zusätzlichen EKS-Auth-API und einem Agent-Pod, der auf jedem Knoten ausgeführt wird.

Amazon EMR on EKS unterstützt seit der Version emr-7.3.0 die EKS-Pod-Identität für das Einreichungsmodell. StartJobRun 

Weitere Informationen zu EKS-Pod-Identitäten finden Sie unter Grundlegendes zur [Funktionsweise](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html) von EKS Pod Identity.

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

Im Rahmen des EMR-Setups muss die Job Execution Role Vertrauensgrenzen zwischen einer IAM-Rolle und Dienstkonten in einem bestimmten Namespace (von virtuellen EMR-Clustern) einrichten. Mit IRSA wurde dies durch die Aktualisierung der Vertrauensrichtlinie der EMR Job Execution Role erreicht. Aufgrund der festen Begrenzung der Länge der IAM-Vertrauensrichtlinie auf 4096 Zeichen bestand jedoch die Einschränkung, eine einzelne IAM-Rolle für die Ausführung von Job auf maximal zwölf (12) EKS-Clustern gemeinsam zu nutzen.

Da EMR Pod-Identitäten unterstützt, wird die Vertrauensgrenze zwischen IAM-Rollen und Dienstkonten nun vom EKS-Team über die Verknüpfung von EKS Pod Identities verwaltet. APIs

**Anmerkung**  
Die Sicherheitsgrenze für die EKS-Pod-Identität liegt immer noch auf der Ebene der Dienstkonten, nicht auf der Pod-Ebene.

## Überlegungen zur Pod-Identität
<a name="setting-up-enable-IAM-pod-identity-consider"></a>

Informationen zu den Einschränkungen der Pod-Identität finden Sie unter [Überlegungen zur EKS Pod-Identität](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations).

## Bereiten Sie die EKS-Pod-Identität im EKS-Cluster vor
<a name="setting-up-enable-IAM-pod-eks-cluster"></a>

### Überprüfen Sie, ob die erforderliche Berechtigung in vorhanden ist NodeInstanceRole
<a name="setting-up-enable-IAM-pod-eks-cluster-permission"></a>

Die Knotenrolle `NodeInstanceRole` benötigt eine Berechtigung, damit der Agent die `AssumeRoleForPodIdentity` Aktion in der EKS Auth API ausführen kann. Sie können dem [Amazon EKSWorkerNodePolicy, das im Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy) EKS-Benutzerhandbuch definiert ist, Folgendes hinzufügen oder eine benutzerdefinierte Richtlinie verwenden.

Wenn Ihr EKS-Cluster mit einer eksctl-Version höher als **0.181.0** erstellt wurde, wird Amazon EKSWorkerNodePolicy, einschließlich der erforderlichen `AssumeRoleForPodIdentity` Berechtigungen, automatisch an die Knotenrolle angehängt. Wenn die Berechtigung nicht vorhanden ist, fügen Sie Amazon manuell die folgende Berechtigung hinzu, mit der Sie eine Rolle für EKSWorker NodePolicy die Pod-Identität übernehmen können. Diese Berechtigung wird vom EKS-Pod-Identity-Agenten benötigt, um Anmeldeinformationen für Pods abzurufen.

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

****  

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

------

### Erstellen Sie das EKS-Pod-Identity-Agent-Add-On
<a name="setting-up-enable-IAM-pod-eks-cluster-agent"></a>

Verwenden Sie den folgenden Befehl, um das EKS Pod Identity Agent-Add-On mit der neuesten Version zu erstellen:

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

Gehen Sie wie folgt vor, um das EKS Pod Identity Agent-Add-On von der Amazon EKS-Konsole aus zu erstellen:

1. Öffnen Sie die Amazon EKS-Konsole: [Amazon EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).

1. Wählen Sie im linken Navigationsbereich **Cluster** aus. Wählen Sie anschließend den Namen des Clusters aus, für den Sie das Add-on „EKS Pod Identity Agent“ konfigurieren möchten.

1. Wählen Sie die Registerkarte **Add-ons**.

1. Wählen Sie **Weitere Add-Ons erhalten**.

1. Wählen Sie das Kästchen oben rechts im Add-on-Bereich für EKS Pod Identity Agent aus und gehen Sie dann auf **Bearbeiten**.

1. Wählen Sie auf der Seite **„Ausgewählte Add-Ons konfigurieren**“ eine beliebige Version in der Dropdownliste **Version** aus.

1. (Optional) Erweitern Sie **Optionale Konfigurationseinstellungen**, um eine zusätzliche Konfiguration einzugeben. Sie können beispielsweise einen alternativen Speicherort für das Container-Image und `ImagePullSecrets` angeben. Das JSON-Schema mit den akzeptierten Schlüsseln wird im **Add-On-Konfigurationsschema** angezeigt.

   Geben Sie die Konfigurationsschlüssel und Werte in das Feld **Konfigurationswerte** ein

1. Wählen Sie **Weiter** aus.

1. Vergewissern Sie sich über die CLI, dass die Agent-Pods auf Ihrem Cluster ausgeführt werden.

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

Eine Beispielausgabe sieht wie folgt aus:

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

Dadurch wird ein neues DaemonSet im `kube-system` Namespace eingerichtet. Der Amazon EKS Pod Identity Agent, der auf jedem EKS-Knoten ausgeführt wird, verwendet die [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)Aktion, um temporäre Anmeldeinformationen von der EKS Auth API abzurufen. Diese Anmeldeinformationen werden dann für die AWS SDKs , die Sie in Ihren Containern ausführen, zur Verfügung gestellt.

Weitere Informationen finden Sie in den Voraussetzungen im öffentlichen Dokument: [Richten Sie den Amazon EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) Agent ein.

## Eine Jobausführungsrolle erstellen
<a name="setting-up-enable-IAM-pod-create-job-role"></a>

### Erstellen oder aktualisieren Sie die Jobausführungsrolle, die EKS Pod Identity ermöglicht
<a name="setting-up-enable-IAM-pod-create-job-role-update"></a>

Um Workloads mit Amazon EMR auf EKS auszuführen, müssen Sie eine IAM-Rolle erstellen. In dieser Dokumentation wird diese Rolle als Auftragsausführungsrolle bezeichnet. Weitere Informationen zum Erstellen der IAM-Rolle finden Sie unter [Erstellen von IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) im Benutzerhandbuch.

Darüber hinaus müssen Sie eine IAM-Richtlinie erstellen, die die erforderlichen Berechtigungen für die Jobausführungsrolle festlegt, und diese Richtlinie dann an die Rolle anhängen, um EKS Pod Identity zu aktivieren.

Sie haben beispielsweise die folgende Jobausführungsrolle. Weitere Informationen finden Sie unter [Erstellen einer Jobausführungsrolle](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html).

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

**Wichtig**  
Amazon EMR on EKS erstellt automatisch Kubernetes-Servicekonten auf der Grundlage Ihres Rollennamens für die Auftragsausführung. Stellen Sie sicher, dass der Rollenname nicht zu lang ist, da Ihr Job möglicherweise fehlschlägt, wenn die Kombination aus `cluster_name``pod_name`, und die `service_account_name` Längenbeschränkung überschreitet.

**Konfiguration der Jobausführungsrolle** — Stellen Sie sicher, dass die Jobausführungsrolle mit der unten angegebenen Vertrauensberechtigung für EKS Pod Identity erstellt wurde. Um eine bestehende Jobausführungsrolle zu aktualisieren, konfigurieren Sie sie so, dass sie dem folgenden EKS-Dienstprinzipal als zusätzliche Berechtigung in der Vertrauensrichtlinie vertraut. Diese Vertrauensberechtigung kann zusammen mit bestehenden IRSA-Vertrauensrichtlinien verwendet werden.

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

**Benutzerberechtigung**: Benutzer benötigen die `iam:PassRole` Erlaubnis, `StartJobRun` API-Aufrufe auszuführen oder Jobs einzureichen. Diese Berechtigung ermöglicht es Benutzern, die Jobausführungsrolle an EMR auf EKS zu übergeben. Jobadministratoren sollten standardmäßig über die entsprechende Berechtigung verfügen.

Im Folgenden finden Sie die für einen Benutzer erforderlichen Berechtigungen:

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

Um den Benutzerzugriff auf bestimmte EKS-Cluster weiter einzuschränken, fügen Sie den AssociatedResourceArn Attributfilter zur IAM-Richtlinie hinzu. Dadurch wird die Rollenübernahme auf autorisierte EKS-Cluster beschränkt, wodurch Ihre Sicherheitskontrollen auf Ressourcenebene verstärkt werden.

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

## Richten Sie EKS-Pod-Identitätszuordnungen ein
<a name="setting-up-enable-IAM-pod-identity-asociations"></a>

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

Stellen Sie sicher, dass die IAM-Identität, die die Pod-Identitätszuordnung erstellt, z. B. ein EKS-Administratorbenutzer, über die Berechtigung `eks:CreatePodIdentityAssociation` und `iam:PassRole` verfügt.

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

------

### Zuordnungen für die Rolle und das EMR-Dienstkonto erstellen
<a name="setting-up-enable-IAM-pod-identity-asociations-emr-service"></a>

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

Wenn Sie einen Job an einen Kubernetes-Namespace senden, muss ein Administrator Verknüpfungen zwischen der Jobausführungsrolle und der Identität des EMR-verwalteten Dienstkontos erstellen. Beachten Sie, dass das EMR-verwaltete Servicekonto bei der Aufgabenübermittlung automatisch erstellt wird und auf den Namespace beschränkt ist, in dem die Aufgabe eingereicht wird.

Führen Sie mit der AWS CLI (älteren Version 2.24.0) den folgenden Befehl aus, um Rollenzuordnungen mit der Pod-Identität zu erstellen.

Führen Sie den folgenden Befehl aus, um Rollenzuordnungen mit der Pod-Identität zu erstellen:

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

Hinweis:
+ Jeder Cluster kann ein Limit von 1.000 Verknüpfungen haben. Für jede Rolle zur Auftragsausführung — die Namespace-Zuordnung — sind drei Zuordnungen für die Pods für den Job-Absender, den Treiber und den Executor erforderlich.
+ Sie können nur Rollen zuordnen, die sich in demselben Konto wie AWS der Cluster befinden. Sie können den Zugriff von einem anderen Konto auf die Rolle in diesem Konto delegieren, die Sie für die Verwendung durch EKS-Pod-Identitäten konfigurieren. Ein Tutorial zum Delegieren von Zugriff und `AssumeRole` finden Sie unter [IAM-Tutorial: AWS Kontoübergreifendes Delegieren des Zugriffs mithilfe von](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) IAM-Rollen.

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

EMR erstellt ein Dienstkonto mit einem bestimmten Benennungsmuster, wenn ein Job eingereicht wird. Gehen Sie folgendermaßen vor, um manuelle Verknüpfungen vorzunehmen oder diesen Workflow in das AWS SDK zu integrieren:

Dienstkontonamen erstellen:

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

In den folgenden Beispielen werden Rollenzuordnungen für eine Beispielrolle zur Jobausführung erstellt JobExecutionRoleIRSAv2.

**Beispiele für Rollenzuordnungen:**

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

**Beispiel für einen CLI-Befehl:**

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

------

Nachdem Sie alle für die EKS-Pod-Identität erforderlichen Schritte abgeschlossen haben, können Sie die folgenden Schritte für die IRSA-Einrichtung überspringen:
+ [Aktivieren Sie IAM-Rollen für Dienstkonten (IRSA) auf dem EKS-Cluster](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html)
+ [Erstellen Sie eine Rolle für die Auftragsausführung](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)
+ [Aktualisieren Sie die Vertrauensrichtlinie der Jobausführungsrolle](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html)

Sie können direkt mit dem folgenden Schritt fortfahren: [Benutzern Zugriff auf Amazon EMR auf EKS gewähren](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html)

## Rollenzuordnungen löschen
<a name="setting-up-enable-IAM-pod-identity-asociations-delete-associations"></a>

Immer wenn Sie einen virtuellen Cluster oder eine Jobausführungsrolle löschen und den zugehörigen Dienstkonten keinen Zugriff mehr auf EMR gewähren möchten, sollten Sie die Zuordnungen für die Rolle löschen. Das liegt daran, dass EKS Verknüpfungen mit nicht vorhandenen Ressourcen (Namespace und Dienstkonto) zulässt. Amazon EMR on EKS empfiehlt, die Verknüpfungen zu löschen, wenn der Namespace gelöscht wird oder die Rolle nicht mehr verwendet wird, um Speicherplatz für andere Zuordnungen freizugeben.

**Anmerkung**  
Die verbleibenden Verknüpfungen könnten sich möglicherweise auf Ihre Skalierbarkeit auswirken, wenn Sie sie nicht löschen, da bei EKS die Anzahl der Verknüpfungen, die Sie erstellen können, begrenzt ist (Soft-Limit: 1000 Verknüpfungen pro Cluster). Sie können Pod-Identitätszuordnungen in einem bestimmten Namespace auflisten, um zu überprüfen, ob Sie noch bestehende Assoziationen haben, die bereinigt werden müssen:

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

Führen Sie mit AWS CLI (Version 2.24.0 oder höher) den folgenden Befehl emr-containers aus, um die Rollenzuordnungen von EMR zu löschen:

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

## Automatisches Migrieren vorhandener IRSA zu Pod Identity
<a name="setting-up-enable-IAM-pod-identity-auto-migrate"></a>

Sie können das Tool eksctl verwenden, um bestehende IAM-Rollen für Dienstkonten (IRSA) zu Pod-Identitätszuordnungen zu migrieren:

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

Wenn Sie den Befehl ohne das `--approve` Kennzeichen ausführen, wird nur ein Plan ausgegeben, der die Migrationsschritte widerspiegelt, und es findet keine tatsächliche Migration statt.

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

### Mein Job ist mit NoClassDefinitionFound oder ClassNotFound Exception for Credentials Provider fehlgeschlagen, oder der Credentials Provider konnte nicht abgerufen werden.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-no-class"></a>

EKS Pod Identity verwendet den Container Credentials Provider, um die erforderlichen Anmeldeinformationen abzurufen. Wenn Sie einen Anbieter für benutzerdefinierte Anmeldeinformationen angegeben haben, stellen Sie sicher, dass dieser ordnungsgemäß funktioniert. Stellen Sie alternativ sicher, dass Sie eine korrekte AWS SDK-Version verwenden, die die EKS Pod Identity unterstützt. Weitere Informationen finden Sie unter [Erste Schritte mit Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

### Der Job schlug fehl und im eks-pod-identity-agent Protokoll wurde der Fehler „Anmeldeinformationen konnten aufgrund von [x] Größenbeschränkung nicht abgerufen werden“ angezeigt.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds"></a>

EMR on EKS erstellt Kubernetes-Dienstkonten auf der Grundlage des Namens der Jobausführungsrolle. Wenn der Rollenname zu lang ist, kann EKS Auth die Anmeldeinformationen nicht abrufen, da die Kombination aus `cluster_name``pod_name`, und die Längenbeschränkung `service_account_name` überschreitet. Identifizieren Sie, welche Komponente den meisten Platz beansprucht, und passen Sie die Größe entsprechend an.

### Der Job schlug fehl, und im eks-pod-identity Protokoll wurde der Fehler „Anmeldeinformationen nicht abgerufen xxx“ angezeigt.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds-error"></a>

Eine mögliche Ursache für dieses Problem könnte sein, dass der EKS-Cluster in privaten Subnetzen konfiguriert ist, ohne dass er PrivateLink für den Cluster korrekt konfiguriert wurde. Überprüfen Sie, ob sich Ihr Cluster in einem privaten Netzwerk befindet, und konfigurieren Sie ihn AWS PrivateLink , um das Problem zu beheben. Eine ausführliche Anleitung finden Sie unter [Erste Schritte mit Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

# Option 2: Aktivieren Sie IAM-Rollen für Service Accounts (IRSA) auf dem EKS-Cluster
<a name="setting-up-enable-IAM-service-accounts"></a>

Das Feature IAM-Rollen für Servicekonten ist auf der neuen Amazon-EKS-Version 1.14 und höher und auf EKS Clustern verfügbar, die am oder nach dem 3. September 2019 auf die Version 1.13 oder höher aktualisiert wurden. Um dieses Feature zu nutzen, können Sie vorhandene EKS-Cluster auf Version 1.14 oder höher aktualisieren. Weitere Informationen finden Sie unter [Aktualisieren einer Amazon-EKS-Cluster-Kubernetes-Version](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).

Wenn Ihr Cluster IAM-Rollen für Servicekonten unterstützt, ist ihm eine [OpenID-Connect](https://openid.net/connect/)-Aussteller-URL zugeordnet. Sie können diese URL in der Amazon EKS-Konsole anzeigen oder den folgenden AWS CLI Befehl verwenden, um sie abzurufen.

**Wichtig**  
Sie müssen die neueste Version von verwenden AWS CLI , um die korrekte Ausgabe dieses Befehls zu erhalten.

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

Die erwartete Ausgabe sieht wie folgt aus.

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

Um IAM-Rollen für Servicekonten in Ihrem Cluster zu verwenden, müssen Sie einen OIDC-Identitätsanbieter entweder mit [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) oder [AWS-Managementkonsole](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console) erstellen.

## So erstellen Sie einen IAM-OIDC-Identitätsanbieter für Ihren Cluster mit `eksctl`
<a name="setting-up-OIDC-eksctl"></a>

Sie können Ihre `eksctl`-Version mit dem folgenden Befehl überprüfen. Bei diesem Verfahren wird davon ausgegangen, dass Sie `eksctl` installiert haben und dass Ihre `eksctl`-Version mindestens 0.32.0 oder höher ist.

```
eksctl version
```

Weitere Informationen über die Installation oder Aktualisierung von eksctl finden Sie unter [Installieren oder Aktualisieren von eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl).

Erstellen Sie Ihren OIDC-Identitätsanbieter für Ihren Cluster mit dem folgenden Befehl. Ersetzen Sie *cluster\$1name* durch Ihren eigenen Wert.

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

## Um einen IAM-OIDC-Identitätsanbieter für Ihren Cluster mit dem zu erstellen AWS-Managementkonsole
<a name="setting-up-OIDC-console"></a>

Rufen Sie die OIDC-Aussteller-URL aus der Amazon EKS-Konsolenbeschreibung Ihres Clusters ab, oder verwenden Sie den folgenden Befehl. AWS CLI 

Verwenden Sie den folgenden Befehl, um die OIDC-Aussteller-URL aus der AWS CLI abzurufen.

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

Führen Sie die folgenden Schritte aus, um die OIDC-Aussteller-URL von der Amazon-EKS-Konsole abzurufen. 

1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

1. Wählen Sie im Navigationsbereich **Identitätsanbieter** und dann **Anbieter erstellen** aus.

   1. Wählen Sie für **Provider Type (Anbietertyp)** die Option **Choose a provider type (Anbietertyp auswählen)** und dann **OpenID Connect** aus.

   1. Fügen Sie unter **Provider URL (Anbieter-URL)** die OIDC-Aussteller-URL für Ihren Cluster ein.

   1. Geben Sie für Zielgruppe sts.amazonaws.com ein und wählen Sie **Nächster Schritt** aus.

1. Überprüfen Sie, ob die Anbieterinformationen korrekt sind, und wählen Sie dann **Create (Erstellen)** aus, um Ihren Identitätsanbieter zu erstellen.

# Erstellen einer Aufgabenausführungsrolle
<a name="creating-job-execution-role"></a>

Um Workloads auf Amazon EMR in EKS auszuführen, müssen Sie eine IAM-Rolle erstellen. In dieser Dokumentation wird diese Rolle als *Auftragsausführungsrolle* bezeichnet. Weitere Informationen zum Erstellen von IAM-Rollen finden Sie unter [Erstellen von IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) im IAM-Benutzerhandbuch. 

Sie müssen außerdem eine IAM-Richtlinie erstellen, die die Berechtigungen für die Auftragsausführungsrolle festlegt, und dann die IAM-Richtlinie an die Auftragsausführungsrolle anhängen. 

Die folgende Richtlinie für die Jobausführungsrolle ermöglicht den Zugriff auf Ressourcenziele, Amazon S3 und CloudWatch. Diese Berechtigungen sind erforderlich, um Aufträge und Zugriffsprotokolle zu überwachen. Um dem gleichen Prozess zu folgen, verwenden Sie AWS CLI: 

IAM-Rolle für die Jobausführung erstellen: Lassen Sie uns die Rolle erstellen, die EMR für die Jobausführung verwenden wird. Dies ist die Rolle, die EMR-Jobs übernehmen, wenn sie auf EKS ausgeführt werden.

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

Als Nächstes müssen wir der Rolle die erforderlichen IAM-Richtlinien hinzufügen, damit sie Protokolle in S3 und Cloudwatch schreiben kann.

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

**Anmerkung**  
Der Zugriff sollte angemessen begrenzt sein und nicht allen S3-Objekten in der Rolle Aufgabenausführung gewährt werden.

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

------

Weitere Informationen finden Sie unter [Verwenden von Rollen zur Jobausführung](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html), [Konfigurieren eines Joblaufs für die Verwendung von S3-Protokollen](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) und [Konfigurieren eines Joblaufs für die Verwendung CloudWatch ](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch) von Logs.

# Die Vertrauensrichtlinie der Auftragsausführungsrolle aktualisieren
<a name="setting-up-trust-policy"></a>

Wenn Sie IAM-Rollen für Servicekonten (IRSA) verwenden, um Aufträge in einem Kubernetes-Namespace auszuführen, muss ein Administrator eine Vertrauensbeziehung zwischen der Auftragsausführungsrolle und der Identität des EMR-verwalteten Servicekontos einrichten. Die Vertrauensbeziehung kann hergestellt werden, indem die Vertrauensrichtlinie der Auftragsausführungsrolle aktualisiert wird. Beachten Sie, dass das EMR-verwaltete Servicekonto bei der Aufgabenübermittlung automatisch erstellt wird und auf den Namespace beschränkt ist, in dem die Aufgabe eingereicht wird.

Um die Vertrauensrichtlinie zu aktualisieren, führen Sie den folgenden Befehl aus.

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

Weitere Informationen finden Sie unter [Auftragausführungsrollen mit Amazon EMR in EKS verwenden](iam-execution-role.md).

**Wichtig**  
Der Operator, der den obigen Befehl ausführt, muss über die folgenden Berechtigungen verfügen: `eks:DescribeCluster` `iam:GetRole` `iam:UpdateAssumeRolePolicy`.

# Gewähren Sie Benutzern Zugriff auf Amazon EMR in EKS
<a name="setting-up-iam"></a>

Für alle Aktionen, die Sie auf Amazon EMR in EKS ausführen, benötigen Sie eine entsprechende IAM-Berechtigung für diese Aktion. Sie müssen eine IAM-Richtlinie erstellen, die es Ihnen ermöglicht, Amazon EMR in EKS durchzuführen, und die Richtlinie an den IAM-Benutzer oder die IAM-Rolle anfügen, die Sie verwenden. 

Dieses Thema enthält Schritte zum Erstellen einer neuen Richtlinie und zum Anhängen dieser an einen Benutzer. Es behandelt auch die grundlegenden Berechtigungen, die Sie für die Einrichtung Ihrer Umgebung von Amazon EMR in EKS benötigen. Wir empfehlen Ihnen, die Berechtigungen für bestimmte Ressourcen nach Möglichkeit an Ihre Geschäftsanforderungen anzupassen.

## Eine neue IAM-Richtlinie erstellen und sie einem Benutzer in der IAM-Konsole zuordnen
<a name="setting-up-iam-console"></a>

**Eine neue IAM-Richtlinie erstellen**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Wählen Sie im linken Navigationsbereich der IAM-Konsole **Richtlinien** aus.

1. Wählen Sie auf der Seite **Policies** (Richtlinien) die Option **Create a policy** (Richtlinie erstellen).

1. Navigieren Sie im Fenster **Richtlinie erstellen** zur Registerkarte **JSON bearbeiten**. Erstellen Sie ein Richtliniendokument mit einer oder mehreren JSON-Anweisungen, wie in den Beispielen nach diesem Verfahren gezeigt. Wählen Sie als Nächstes die Option **Richtlinie überprüfen** aus.

1. Geben Sie auf Bildschirm **Review Policy (Richtlinie überprüfen)** Ihren **Policy Name (Richtlinienname)** ein, z. B. `AmazonEMROnEKSPolicy`. Geben Sie eine optionale Beschreibung für Ihre Richtlinie ein und wählen Sie dann **Richtlinie erstellen** aus. 

**Die Richtlinie an einen Benutzer oder eine Rolle anhängen**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 

1. Wählen Sie im Navigationsbereich **Richtlinien**.

1. Aktivieren Sie in der Liste der Richtlinien das Kontrollkästchen neben der im vorherigen Abschnitt erstellten Richtlinie. Über das Menü **Filter** und das Suchfeld können Sie die Richtlinienliste filtern. 

1. Klicken Sie auf **Policy actions** und anschließend auf **Attach**.

1. Wählen Sie den Benutzer oder die Rolle aus, an den Sie die Richtlinie anfügen möchten. Über das Menü **Filter** und das Suchfeld können Sie die Liste der Prinzipal-Entitäten filtern. Nachdem Sie den Benutzer oder die Rolle zum Anfügen der Richtlinie ausgewählt haben, klicken Sie auf **Richtlinie anfügen**.

## Berechtigungen zum Verwalten virtueller Cluster
<a name="permissions-virtual-cluster"></a>

Um virtuelle Cluster in Ihrem AWS Konto zu verwalten, erstellen Sie eine IAM-Richtlinie mit den folgenden Berechtigungen. Mit diesen Berechtigungen können Sie virtuelle Cluster in Ihrem AWS Konto erstellen, auflisten, beschreiben und löschen.

------
#### [ 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 ist in Amazon EKS Cluster Access Management (CAM) integriert, sodass Sie die Konfiguration der erforderlichen AuthN- und AuthZ-Richtlinien automatisieren können, um Amazon EMR Spark-Jobs in Namespaces von Amazon EKS-Clustern auszuführen. Dazu benötigen Sie die folgenden Berechtigungen:

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

Weitere Informationen finden Sie unter [Automatisieren der Aktivierung des Clusterzugriffs für Amazon EMR auf EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-cam-integration).

Wenn der `CreateVirtualCluster` Vorgang zum ersten Mal von einem AWS Konto aus aufgerufen wird, benötigen Sie auch die `CreateServiceLinkedRole` Berechtigungen, um die serviceverknüpfte Rolle für Amazon EMR auf EKS zu erstellen. Weitere Informationen finden Sie unter [Verwendung von serviceverknüpften Rollen für Amazon EMR in EKS](using-service-linked-roles.md). 

## Berechtigungen für das Einreichen von Aufträge
<a name="permissions-submitting-jobs"></a>

Um Jobs auf den virtuellen Clustern in Ihrem AWS Konto einzureichen, erstellen Sie eine IAM-Richtlinie mit den folgenden Berechtigungen. Mit diesen Berechtigungen können Sie Auftragsausführungen für alle virtuellen Cluster in Ihrem Konto starten, auflisten, beschreiben und abbrechen. Sie sollten in Betracht ziehen, Berechtigungen hinzuzufügen, um virtuelle Cluster aufzulisten oder zu beschreiben, sodass Sie den Status des virtuellen Clusters überprüfen können, bevor Sie Aufträge einreichen.

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

****  

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

------

## Berechtigungen für das Debuggen und Überwachen
<a name="permissions-debugging-monitoring"></a>

Um Zugriff auf an Amazon S3 übertragene Protokolle zu erhalten oder um Anwendungsereignisprotokolle in der Amazon EMR-Konsole anzuzeigen, erstellen Sie eine IAM-Richtlinie mit den folgenden Berechtigungen. CloudWatch Wir empfehlen Ihnen, die Berechtigungen für bestimmte Ressourcen nach Möglichkeit an Ihre Geschäftsanforderungen anzupassen.

**Wichtig**  
Wenn Sie keinen Amazon-S3-Bucket erstellt haben, müssen Sie der Richtlinienerklärung `s3:CreateBucket`-Berechtigungen hinzufügen. Wenn Sie keine Protokollgruppe erstellt haben, müssen Sie `logs:CreateLogGroup` der Richtlinienerklärung hinzufügen.

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

------

Weitere Informationen zur Konfiguration einer Auftragsausführung für die Übertragung von Protokollen an Amazon S3 finden [Sie unter Konfiguration einer Auftragsausführung zur Verwendung von S3-Protokollen](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) und [Konfiguration einer Auftragsausführung zur Verwendung von CloudWatch Protokollen](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch). CloudWatch

# Den Amazon-EKS-Cluster mit Amazon EMR registrieren
<a name="setting-up-registration"></a>

Die Registrierung Ihres Clusters ist der letzte erforderliche Schritt, um Amazon EMR in EKS für die Ausführung von Workloads einzurichten.

Verwenden Sie den folgenden Befehl, um einen virtuellen Cluster mit einem Namen Ihrer Wahl für den Amazon-EKS-Cluster und den Namespace zu erstellen, die Sie in den vorherigen Schritten eingerichtet haben.

**Anmerkung**  
Jeder virtuelle Cluster muss in allen EKS-Clustern einen eindeutigen Namen haben. Wenn zwei virtuelle Cluster denselben Namen haben, schlägt der Bereitstellungsprozess fehl, auch wenn die beiden virtuellen Cluster zu unterschiedlichen EKS-Clustern gehören. 

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

Alternativ können Sie eine JSON-Datei erstellen, die die erforderlichen Parameter für den virtuellen Cluster enthält, und dann den `create-virtual-cluster`-Befehl mit dem Pfad zur JSON-Datei ausführen. Weitere Informationen finden Sie unter [Verwaltung virtueller Cluster](virtual-cluster.md).

**Anmerkung**  
Um die erfolgreiche Erstellung eines virtuellen Clusters zu überprüfen, zeigen Sie den Status der virtuellen Cluster an, indem Sie den Vorgang `list-virtual-clusters` verwenden oder die Seite **Virtuelle Cluster** in der Amazon-EMR-Konsole aufrufen. 

# Reichen Sie einen Auftrag ein, der ausgeführt wird mit `StartJobRun`
<a name="emr-eks-jobs-submit"></a>

**Um einen Auftrag einzureichen, führen Sie ihn mit einer JSON-Datei mit angegebenen Parametern aus**

1. Erstellen Sie eine `start-job-run-request.json`-Datei und geben Sie die erforderlichen Parameter für Ihre Auftragausführung an, wie die folgende JSON-Beispieldatei zeigt. Weitere Informationen zu den Parametern finden Sie unter [Optionen für die Konfiguration einer Aufgabenausführung](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. Verwenden Sie den `start-job-run`-Befehl mit einem Pfad zu der lokal gespeicherten `start-job-run-request.json`-Datei.

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

**So starten Sie eine Auftragsausführung mithilfe des `start-job-run`-Befehls**

1. Geben Sie alle angegebenen Parameter im `StartJobRun`-Befehl an, wie das folgende Beispiel zeigt.

   ```
   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. Geben Sie für Spark SQL alle angegebenen Parameter im `StartJobRun`-Befehl an, wie das folgende Beispiel zeigt.

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

# Verwenden der Auftragserteilung
<a name="emr-eks-job-submitter"></a>

## -Übersicht
<a name="emr-eks-job-submitter-overview"></a>

Die Amazon EMR in EKS-`StartJobRun`-Anfrage erstellt einen *Auftrag-Submitter-Pod* (auch *Auftrag-Runner-Pod* genannt), um den Spark-Treiber zu starten. Sie können die `emr-job-submitter` Klassifizierung verwenden, um Knotenselektoren zu konfigurieren, Toleranzen hinzuzufügen, die Protokollierung anzupassen und andere Änderungen am Job Submitter-Pod vorzunehmen.

Die folgenden Einstellungen sind unter der Klassifizierung verfügbar: `emr-job-submitter`

** `jobsubmitter.node.selector.[selectorKey]` **  
Fügt der Knotenauswahl des Pods, in dem der Job eingereicht wurde, hinzu, wobei der Schlüssel *selectorKey* und der Wert als Konfigurationswert verwendet werden. Sie können beispielsweise festlegen` jobsubmitter.node.selector.identifier`, dass der Pod für den Auftragseinreicher über eine Knotenauswahl mit einem Schlüssel `myIdentifier` und einem Wert verfügt. `identifier` `myIdentifier` Dies kann verwendet werden, um anzugeben, auf welchen Knoten der Pod des Auftragseinreichers platziert werden kann. Um mehrere Knotenauswahltasten hinzuzufügen, legen Sie mehrere Konfigurationen mit diesem Präfix fest.

** `jobsubmitter.label.[labelKey]` **  
Fügt den Beschriftungen des Pods des Auftragseinreichers hinzu, wobei der Schlüssel *labelKey* und der Wert als Konfigurationswert verwendet werden. Um mehrere Labels hinzuzufügen, legen Sie mehrere Konfigurationen mit diesem Präfix fest.

** `jobsubmitter.annotation.[annotationKey]` **  
Fügt den Anmerkungen im Pod des Jobeinreichers hinzu, wobei der Schlüssel *annotationKey* und der Wert als Konfigurationswert verwendet werden. Um mehrere Anmerkungen hinzuzufügen, legen Sie mehrere Konfigurationen mit diesem Präfix fest.

** `jobsubmitter.node.toleration.[tolerationKey]` **  
Fügt dem [Pod des Stelleneinreichers Toleranzen](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) hinzu. Standardmäßig werden dem Pod keine Toleranzen hinzugefügt. Der Schlüssel der Toleranz ist *tolerationKey* und der Wert der Toleranz wird der Konfigurationswert sein. Wenn der Konfigurationswert auf eine nicht leere Zeichenfolge gesetzt ist, gilt dies auch für den Operator. `Equals` Wenn der Konfigurationswert auf gesetzt ist`""`, dann ist der Operator. `Exists`

** `jobsubmitter.node.toleration.[tolerationKey].[effect]` **  
Fügt dem *tolerationKey* Präfix einen Toleranzeffekt hinzu. Dieses Feld ist beim Hinzufügen von Toleranzen erforderlich. Die zulässigen Werte für das Effektfeld sind ` NoExecute``NoSchedule`, und`PreferNoSchedule`.

** `jobsubmitter.node.toleration.[tolerationKey].[tolerationSeconds]` **  
Fügt dem Präfix TolerationSeconds hinzu. *tolerationKey* Optionales Feld. Gilt nur, wenn der Effekt ist. `NoExecute`

** `jobsubmitter.scheduler.name` **  
Legt einen benutzerdefinierten SchedulerName für den Pod des Auftragseinreichers fest.

** `jobsubmitter.logging` **  
Aktiviert oder deaktiviert die Protokollierung im Pod des Auftragseinreichers. Wenn diese Option aktiviert ist, wird ` DISABLED` der Logging-Container aus dem Pod des Auftragseinreichers entfernt, wodurch jegliche Protokollierung für diesen Pod deaktiviert wird, die `monitoringConfiguration` im angegeben ist, z. B. oder. `s3MonitoringConfiguration` `cloudWatchMonitoringConfiguration` Wenn diese Einstellung nicht oder auf einen anderen Wert gesetzt ist, ist die Protokollierung im Pod des Auftragseinreichers aktiviert.

** `jobsubmitter.logging.image` **  
Legt ein benutzerdefiniertes Bild fest, das für den Logging-Container im Pod des Auftragseinreichers verwendet werden soll.

** `jobsubmitter.logging.request.cores` **  
Legt einen benutzerdefinierten Wert für die Anzahl der CPUs Logging-Container im Pod des Auftragseinreichers in CPU-Einheiten fest. **Standardmäßig ist dieser Wert auf 100 m festgelegt.**

** `jobsubmitter.logging.request.memory` **  
Legt einen benutzerdefinierten Wert für die Speichergröße (in Byte) für den Logging-Container im Pod des Auftragseinreichers fest. **Standardmäßig ist dieser Wert auf 200 Mi festgelegt.** Ein Mebibyte ist eine Maßeinheit, die einem Megabyte ähnelt.

** `jobsubmitter.container.image` **  
Legt ein benutzerdefiniertes Bild für den Container des Pods des Auftragseinreichers fest. `job-runner`

** `jobsubmitter.container.image.pullPolicy` **  
Legt die Container [imagePullPolicy](https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy)für den Pod des Jobeinreichers fest.

Wir empfehlen, die Pods der Stellenabsender auf On-Demand-Instances zu platzieren. Das Platzieren von Pods für Job-Absender auf Spot-Instances kann zu einem Job-Fehlschlag führen, wenn die Instance, auf der der Pod für den Job-Absender ausgeführt wird, von einer Spot-Instance-Unterbrechung betroffen ist. Sie können den [Pod des Auftragseinreichers auch in einer einzigen Availability Zone platzieren oder beliebige Kubernetes-Labels verwenden](#emr-eks-job-submitter-ex-ec2), die auf die Knoten angewendet werden.

## Beispiele für die Klassifizierung von Auftragseinreichern
<a name="emr-eks-job-submitter-examples"></a>

**Topics**
+ [`StartJobRun`-Anfrage mit On-Demand-Knotenplatzierung für den Pod des Auftrageinreichers](#emr-eks-job-submitter-ex-od)
+ [`StartJobRun`Anfrage mit Single-AZ-Knotenplatzierung und Amazon EC2 EC2-Instance-Typ-Platzierung für den Job Submitter-Pod](#emr-eks-job-submitter-ex-ec2)
+ [`StartJobRun`Anfrage mit Bezeichnungen, Anmerkungen und einem benutzerdefinierten Scheduler für den Pod des Jobeinreichers](#emr-eks-job-submitter-label-annotation-scheduler)
+ [`StartJobRun`Anfrage mit einer Toleranz, die auf den Pod des Job-Absenders mit Schlüssel`dedicated`, Wert `graviton_machines``NoExecute`, Effekt und einer Dauer von 60 Sekunden angewendet wurde `tolerationSeconds`](#emr-eks-job-submitter-tolerations)
+ [`StartJobRun`Anfrage mit deaktivierter Protokollierung für den Job Submitter-Pod](#emr-eks-job-submitter-logging-disabled)
+ [`StartJobRun`Anfrage mit benutzerdefiniertem Logging-Container-Image, CPU und Speicher für den Pod des Jobeinreichers](#emr-eks-job-submitter-custom)
+ [`StartJobRun`Anfrage mit einem benutzerdefinierten Container-Image für den Job-Absender und einer Pull-Richtlinie](#emr-eks-job-submitter-custom-container)

### `StartJobRun`-Anfrage mit On-Demand-Knotenplatzierung für den Pod des Auftrageinreichers
<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`Anfrage mit Single-AZ-Knotenplatzierung und Amazon EC2 EC2-Instance-Typ-Platzierung für den Job Submitter-Pod
<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`Anfrage mit Bezeichnungen, Anmerkungen und einem benutzerdefinierten Scheduler für den Pod des Jobeinreichers
<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`Anfrage mit einer Toleranz, die auf den Pod des Job-Absenders mit Schlüssel`dedicated`, Wert `graviton_machines``NoExecute`, Effekt und einer Dauer von 60 Sekunden angewendet wurde `tolerationSeconds`
<a name="emr-eks-job-submitter-tolerations"></a>

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

### `StartJobRun`Anfrage mit deaktivierter Protokollierung für den Job Submitter-Pod
<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`Anfrage mit benutzerdefiniertem Logging-Container-Image, CPU und Speicher für den Pod des Jobeinreichers
<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`Anfrage mit einem benutzerdefinierten Container-Image für den Job-Absender und einer Pull-Richtlinie
<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"
      }
    }
  ]
}
```

# Verwendung der Standardklassifizierung von Amazon EMR-Containern
<a name="emr-eks-job-submitter-container-defaults"></a>

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

Die folgenden Einstellungen sind unter der `emr-containers-defaults` Klassifizierung verfügbar:

** `job-start-timeout` **  
Standardmäßig wird bei einem Job ein Timeout ausgelöst, wenn er nicht gestartet werden kann, und er wartet 15 Minuten im ` SUBMITTED` Status. Diese Konfiguration ändert die Anzahl der Sekunden, die gewartet werden sollen, bis das Zeitlimit für den Job überschritten wird.

** `executor.logging` **  
Aktiviert oder deaktiviert die Protokollierung auf den Executor-Pods. Wenn diese Option aktiviert ist, wird ` DISABLED` der Logging-Container aus den Executor-Pods entfernt, wodurch jegliche Protokollierung für diese Pods deaktiviert wird, die `monitoringConfiguration` im angegeben sind, z. B. oder. `s3MonitoringConfiguration` `cloudWatchMonitoringConfiguration` Wenn diese Einstellung nicht oder auf einen anderen Wert gesetzt ist, ist die Protokollierung auf den Executor-Pods aktiviert.

** `logging.image` **  
Legt ein benutzerdefiniertes Bild fest, das für den Logging-Container auf den Treiber- und Executor-Pods verwendet werden soll.

** `logging.request.cores` **  
Legt einen benutzerdefinierten Wert für die Anzahl der CPUs Logging-Container auf den Treiber- und Executor-Pods in CPU-Einheiten fest. Standardmäßig ist dieser Wert nicht festgelegt.

** `logging.request.memory` **  
Legt einen benutzerdefinierten Wert für die Speichergröße in Byte für den Logging-Container auf den Treiber- und Executor-Pods fest. **Standardmäßig ist dieser Wert auf 512 Mi festgelegt.** Ein Mebibyte ist eine Maßeinheit, die einem Megabyte ähnelt.

## Beispiele für die Klassifizierung von Auftragseinreichern
<a name="emr-eks-job-submitter-container-examples"></a>

**Topics**
+ [`StartJobRun`Anfrage mit benutzerdefiniertem Job-Timeout](#emr-eks-job-submitter-container-custom-timeout)
+ [`StartJobRun`Anfrage mit deaktivierter Protokollierung für Executor-Pods](#emr-eks-executor-logging-disabled)
+ [`StartJobRun`Anfrage mit benutzerdefiniertem Logging-Container-Image, CPU und Speicher für die Treiber- und Executor-Pods](#emr-eks-job-submitter-container-custom-image-cpu)

### `StartJobRun`Anfrage mit benutzerdefiniertem Job-Timeout
<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`Anfrage mit deaktivierter Protokollierung für Executor-Pods
<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`Anfrage mit benutzerdefiniertem Logging-Container-Image, CPU und Speicher für die Treiber- und Executor-Pods
<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"
    }
  }
}
```