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-Jobs mit Amazon EMR auf EKS ausführen
<a name="job-runs-main"></a>

Eine *Auftragsausführung* ist eine Arbeitseinheit, z. B. eine Spark-Jar-, PySpark Skript- oder SparkSQL-Abfrage, die Sie an Amazon EMR auf EKS senden. Dieses Thema bietet einen Überblick über die Verwaltung von Auftragsausführungen mit der AWS CLI, die Anzeige von Auftragsausführungen mit der Amazon EMR-Konsole und die Behebung häufiger Fehler bei der Auftragsausführung.

Beachten Sie, dass Sie IPv6 Spark-Jobs auf Amazon EMR auf EKS nicht ausführen können.

**Anmerkung**  
Bevor Sie einen Auftrag einreichen, der mit Amazon EMR in EKS ausgeführt wird, müssen Sie die unter aufgeführten Schritte in [Einrichten von Amazon EMR in EKS](setting-up.md) ausführen.

**Topics**
+ [Spark-Aufträge ausführen mit `StartJobRun`](job-runs.md)
+ [Spark-Aufträge mit dem Spark-Operator ausführen](spark-operator.md)
+ [Ausführen von Spark-Aufträgen mit spark-submit](spark-submit.md)
+ [Verwenden von Apache Livy mit Amazon EMR auf EKS](job-runs-apache-livy.md)
+ [Verwalten von Aufgabenausführungen von Amazon EMR in EKS](emr-eks-jobs-manage.md)
+ [Verwenden von Aufgabenvorlagen](job-templates.md)
+ [Verwenden von Pod-Vorlagen](pod-templates.md)
+ [Verwenden von Richtlinien für die Wiederholung von Aufträgen](jobruns-using-retry-policies.md)
+ [Verwenden der Rotation des Spark-Ereignisprotokolls](emr-eks-log-rotation.md)
+ [Verwenden der Spark-Container-Protokoll-Rotation](emr-eks-log-rotation-container.md)
+ [Verwenden von vertikalem Auto Scaling mit Amazon-EMR-Spark-Aufträgen](jobruns-vas.md)

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

# Spark-Aufträge mit dem Spark-Operator ausführen
<a name="spark-operator"></a>

Amazon-EMR-Versionen 6.10.0 und höher unterstützen den Kubernetes-Operator für Apache Spark oder *den Spark-Operator* als Aufgabeneinreichungsmodell für Amazon EMR in EKS. Mit dem Spark-Operator können Sie Spark-Anwendungen mit der Amazon-EMR-Release-Laufzeit auf Ihren eigenen Amazon-EKS-Clustern bereitstellen und verwalten. Sobald Sie den Spark Operator in Ihrem Amazon-EKS-Cluster bereitgestellt haben, können Sie Spark-Anwendungen direkt beim Operator einreichen. Der Operator verwaltet den Lebenszyklus von Spark-Anwendungen.

**Anmerkung**  
Amazon EMR berechnet die Preise für Amazon EKS auf der Grundlage des vCPU- und Speicherverbrauchs. Diese Berechnung gilt für Treiber- und Executor-Pods. Diese Berechnung beginnt mit dem Herunterladen Ihres Amazon EMR-Anwendungsabbilds, bis der Amazon EKS-Pod endet und auf die nächste Sekunde gerundet wird.

**Topics**
+ [Einrichten des Spark-Operators für Amazon EMR in EKS](spark-operator-setup.md)
+ [Erste Schritte mit dem Spark-Operator für Amazon EMR in EKS](spark-operator-gs.md)
+ [Verwenden Sie vertikale Autoskalierung mit dem Spark-Operator für Amazon EMR auf EKS](spark-operator-vas.md)
+ [Deinstallieren des Spark-Operators für Amazon EMR in EKS](spark-operator-uninstall.md)
+ [Verwenden der Überwachungskonfiguration zur Überwachung des Spark-Kubernetes-Operators und der Spark-Jobs](spark-operator-monitoring-configuration.md)
+ [Sicherheit und der Spark-Operator mit Amazon EMR in EKS](spark-operator-security.md)

# Einrichten des Spark-Operators für Amazon EMR in EKS
<a name="spark-operator-setup"></a>

Führen Sie zum Einrichten des Spark-Operator auf Amazon 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. Führen Sie zum Einrichten von Amazon Spark Operator die folgenden Schritte auf Amazon EKS aus. Wenn Sie bereits eine der Voraussetzungen erfüllt haben, können Sie diese überspringen und mit der nächsten fortfahren.
+ **[Installieren oder aktualisieren Sie auf die neueste Version von AWS CLI— Falls Sie die](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)** bereits installiert haben, vergewissern Sie sich AWS CLI, dass Sie über die neueste Version verfügen.
+ **[Richten Sie kubectl und eksctl ein — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)** ist ein Befehlszeilentool, das Sie für die Kommunikation mit Amazon EKS verwenden.
+ **[Helm installieren](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)** – Der Helm-Paketmanager für Kubernetes unterstützt Sie bei der Installation und Verwaltung von Anwendungen in Ihrem Kubernetes-Cluster. 
+ **[Erste Schritte mit Amazon EKS — eksctl —](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)** Folgen Sie den Schritten, um einen neuen Kubernetes-Cluster mit Knoten in Amazon EKS zu erstellen.
+ **[Eine Amazon-EMR-Basis-Image-URI auswählen](docker-custom-images-tag.md) (Version 6.10.0 oder höher)** aus – der Spark-Operator wird von Amazon-EMR-Versionen 6.10.0 und höher unterstützt.

# Erste Schritte mit dem Spark-Operator für Amazon EMR in EKS
<a name="spark-operator-gs"></a>

Dieses Thema hilft Ihnen beim Einstieg in die Verwendung des Spark-Operators in Amazon EKS, indem Sie eine Spark-Anwendung und eine Schedule-Spark-Anwendung bereitstellen.

## Den Spark-Operator installieren
<a name="spark-operator-install"></a>

Gehen Sie wie folgt vor, um den Kubernetes-Operator für Apache Spark zu installieren.

1. Sofern noch nicht geschehen, führen die Schritte unter [Einrichten des Spark-Operators für Amazon EMR in EKS](spark-operator-setup.md) aus.

1. Authentifizieren Ihren Helm-Client in Ihrer Amazon-ECR-Registry. Ersetzen Sie im folgenden Befehl die *region-id* Werte durch Ihre bevorzugten AWS-Region Werte und den entsprechenden *ECR-registry-account* Wert für die Region auf der Seite. [Amazon-ECR-Registrierungskonten nach Regionen](docker-custom-images-tag.md#docker-custom-images-ECR)

   ```
   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. Installieren Sie den Spark-Operator mit dem folgenden Befehl.

   Verwenden Sie für den `--version`-Helm-Chart-Parameter Ihre Amazon-EMR-Versionskennung, wobei das `emr-`-Präfix und das Datumssuffix entfernt wurden. Geben Sie beispielsweise `emr-6.12.0-java17-latest` bei der Version `6.12.0-java17` an. Das Beispiel im folgenden Befehl verwendet die `emr-7.12.0-latest` Version, also gibt sie `7.12.0` für das Helm-Chart `--version` an.

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

   Standardmäßig erstellt der Befehl ein Servicekonto `emr-containers-sa-spark-operator` für den Spark-Operator. Um ein anderes Servicekonto zu verwenden, geben Sie das Argument `serviceAccounts.sparkoperator.name` an. Beispiel:

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

   Wenn Sie das [vertikale Auto Scaling mit dem Spark-Operator verwenden]() möchten, fügen Sie dem Installationsbefehl die folgende Zeile hinzu, um Webhooks für den Operator zuzulassen:

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

1. Vergewissern Sie sich, dass Sie das Helm-Chart mit dem folgenden `helm list`-Befehl installiert haben:

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

   Der `helm list`-Befehl sollte Ihre neu bereitgestellten Helm-Chart-Versionsinformationen zurückgeben:

   ```
   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. Schließen Sie die Installation mit allen zusätzlichen Optionen ab, die Sie benötigen. Weitere Informationen finden Sie in der [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)Dokumentation zu GitHub.

## Eine Spark-Anwendung ausführen
<a name="spark-operator-run"></a>

Der Spark-Operator wird mit Amazon EMR 6.10.0 oder höher unterstützt. Wenn Sie den Spark-Operator installieren, erstellt er standardmäßig das Servicekonto `emr-containers-sa-spark` für die Ausführung von Spark-Anwendungen. Gehen Sie wie folgt vor, um eine Spark-Anwendung mit dem Spark-Operator auf Amazon EMR in EKS 6.10.0 oder höher auszuführen.

1. Bevor Sie eine Spark-Anwendung mit dem Spark-Operator ausführen können, führen Sie die Schritte unter [Einrichten des Spark-Operators für Amazon EMR in EKS](spark-operator-setup.md) und [Den Spark-Operator installieren](#spark-operator-install) durch. 

1. Erstellen Sie eine `SparkApplication`-Aufgabendefinitions-Datei `spark-pi.yaml` mit dem folgenden Beispielinhalt: 

   ```
   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. Senden Sie jetzt die Spark-Anwendung mit dem folgenden Befehl. Dadurch wird auch ein `SparkApplication`-Objekt mit dem `spark-pi`-Namen erstellt:

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

1. Überprüfen Sie die Ereignisse für das `SparkApplication`-Objekt mit dem folgenden Befehl: 

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

Weitere Informationen zum Einreichen von Anwendungen an Spark über den Spark-Operator finden Sie unter [Verwenden von a `SparkApplication`](https://www.kubeflow.org/docs/components/spark-operator/user-guide/using-sparkapplication/) in der `spark-on-k8s-operator` Dokumentation zu GitHub.

## Amazon S3 als Speicher verwenden
<a name="spark-operator-s3-storage"></a>

Um Amazon S3 als Dateispeicheroption zu verwenden, fügen Sie Ihrer YAML-Datei die folgenden Konfigurationen hinzu.

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

 Wenn Sie Amazon EMR-Versionen 7.2.0 und höher verwenden, sind die Konfigurationen standardmäßig enthalten. In diesem Fall können Sie den Dateipfad auf `s3://<bucket_name>/<file_path>` statt auf `local://<file_path>` in der YAML-Datei der Spark-Anwendung festlegen. 

Reichen Sie dann die Spark-Anwendung wie gewohnt ein.

# Verwenden Sie vertikale Autoskalierung mit dem Spark-Operator für Amazon EMR auf EKS
<a name="spark-operator-vas"></a>

Ab Amazon EMR 7.0 können Sie Amazon EMR auf der vertikalen automatischen Skalierung von EKS verwenden, um das Ressourcenmanagement zu vereinfachen. Die Speicher- und CPU-Ressourcen werden automatisch an die Anforderungen der Workload angepasst, die Sie für Amazon-EMR-Spark-Anwendungen bereitstellen. Weitere Informationen finden Sie unter [Verwenden von vertikalem Auto Scaling mit Amazon-EMR-Spark-Aufträgen](jobruns-vas.md).

In diesem Abschnitt wird beschrieben, wie Sie den Spark-Operator für die Verwendung des vertikalen Auto Scalings konfigurieren.

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

Bevor Sie die Überwachung konfigurieren, stellen Sie sicher, dass Sie die folgenden Einrichtungsaufgaben abgeschlossen haben:
+ Führen Sie die Schritte unter [Einrichten des Spark-Operators für Amazon EMR in EKS](spark-operator-setup.md) aus.
+ (optional) Wenn Sie zuvor eine ältere Version des Spark-Operators installiert haben, löschen Sie die SparkApplication/ScheduledSparkApplication CRD.

  ```
  kubectl delete crd sparkApplication
  kubectl delete crd scheduledSparkApplication
  ```
+ Führen Sie die Schritte unter [Den Spark-Operator installieren](spark-operator-gs.md#spark-operator-install) aus. Fügen Sie in Schritt 3 dem Installationsbefehl die folgende Zeile hinzu, um Webhooks für den Operator zuzulassen:

  ```
  --set webhook.enable=true
  ```
+ Führen Sie die Schritte unter [Einrichten des vertikalen Auto Scalings für Amazon EMR in EKS](jobruns-vas-setup.md) aus.
+ Gewähren Sie Zugriff auf die Dateien an Ihrem Amazon S3 S3-Standort:

  1. Kommentieren Sie Ihr Fahrer- und Betreiber-Servicekonto mit dem`JobExecutionRole`, das über S3-Berechtigungen verfügt.

     ```
     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. Aktualisieren Sie die Vertrauensrichtlinie Ihrer Jobausführungsrolle in diesem Namespace.

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

  1. Bearbeiten Sie die IAM-Rollen-Vertrauensrichtlinie Ihrer Jobausführungsrolle und aktualisieren Sie das Feld `serviceaccount` von bis`emr-containers-sa-spark-*-*-xxxx`. `emr-containers-sa-*`

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

  1. Wenn Sie Amazon S3 als Dateispeicher verwenden, fügen Sie Ihrer Yaml-Datei die folgenden Standardeinstellungen hinzu.

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

## Einen Auftrag mit vertikalem Auto Scaling auf dem Spark-Operator ausführen
<a name="spark-operator-vas-run"></a>

Bevor Sie eine Spark-Anwendung mit dem Spark-Operator ausführen können, führen Sie die Schritte unter [Voraussetzungen](#spark-operator-vas-prereqs) durch. 

Um vertikales Autoscaling mit dem Spark-Operator zu verwenden, fügen Sie dem Treiber für Ihre Spark-Anwendungsspezifikation die folgende Konfiguration hinzu, um das vertikale Autoscaling zu aktivieren:

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

Diese Konfiguration ermöglicht vertikales Autoscaling und ist eine erforderliche Signaturkonfiguration, mit der Sie eine Signatur für Ihren Job auswählen können.

Weitere Informationen zu den Konfigurationen und Parameterwerten finden Sie unter [Konfiguration der vertikalen Autoskalierung für Amazon EMR auf](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/jobruns-vas-configure.html) EKS. Standardmäßig wird Ihr Auftrag beim vertikalen Auto Scaling im Modus Nur für Überwachung **aus** gesendet. In diesem Überwachungsstatus können Sie Ressourcenempfehlungen berechnen und anzeigen, ohne ein Auto Scaling durchführen zu müssen. Weitere Informationen finden Sie unter [Vertikale Autoscaling-Modi](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/jobruns-vas-configure.html#jobruns-vas-parameters-opt-mode).

Im Folgenden finden Sie eine `SparkApplication` Beispieldefinitionsdatei `spark-pi.yaml` mit dem Namen der erforderlichen Konfigurationen für die Verwendung der vertikalen Autoskalierung.

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

Senden Sie jetzt die Spark-Anwendung mit dem folgenden Befehl. Dadurch wird auch ein `SparkApplication`-Objekt mit dem `spark-pi`-Namen erstellt:

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

Weitere Informationen zum Einreichen von Anwendungen an Spark über den Spark-Operator finden Sie unter [Using a `SparkApplication`](https://www.kubeflow.org/docs/components/spark-operator/user-guide/using-sparkapplication/) in der `spark-on-k8s-operator` Dokumentation zu GitHub.

## Überprüfen der vertikalen Auto-Scaling-Funktionalität
<a name="spark-operator-vas-verify"></a>

Um zu überprüfen, ob das vertikale Auto Scaling für den eingereichten Auftrag korrekt funktioniert, rufen Sie mit kubectl die benutzerdefinierte `verticalpodautoscaler`-Ressource ab und sehen Sie sich Ihre Skalierungsempfehlungen an.

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

Die Ausgabe dieser Abfrage sollte wie folgt aussehen:

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

Wenn Ihre Ausgabe nicht ähnlich aussieht oder einen Fehlercode enthält, finden Sie weitere Schritte zur Behebung des Problems in [Fehlerbehebung von Amazon EMR im vertikalen Auto Scaling von EKS](troubleshooting-vas.md).

Führen Sie den folgenden Befehl aus, um die Pods und Anwendungen zu entfernen:

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

# Deinstallieren des Spark-Operators für Amazon EMR in EKS
<a name="spark-operator-uninstall"></a>

Gehen Sie wie folgt vor, um den Spark-Operator zu deinstallieren.

1. Löschen Sie den Spark-Operator mit dem richtigen Namespace. In diesem Beispiel lautet der Namespace `spark-operator-demo`.

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

1. Das Spark-Operator-Servicekonto löschen:

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

1. Löschen Sie den Spark-Operator `CustomResourceDefinitions` (CRDs):

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

# Verwenden der Überwachungskonfiguration zur Überwachung des Spark-Kubernetes-Operators und der Spark-Jobs
<a name="spark-operator-monitoring-configuration"></a>

Mit der Überwachungskonfiguration können Sie ganz einfach die Protokollarchivierung Ihrer Spark-Anwendung und Ihrer Bedienerprotokolle in Amazon S3 oder auf einrichten Amazon CloudWatch. Sie können eines oder beide auswählen. Dadurch wird ein Log-Agent-Sidecar zu Ihren Spark-Operator-Pods, -Treibern und Executor-Pods hinzugefügt und anschließend werden die Logs dieser Komponenten an Ihre konfigurierten Senken weitergeleitet.

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

Bevor Sie die Überwachung konfigurieren, stellen Sie sicher, dass Sie die folgenden Einrichtungsaufgaben abgeschlossen haben:

1. (Optional) Wenn Sie zuvor eine ältere Version des Spark-Operators installiert haben, löschen Sie die ScheduledSparkApplication CRD *SparkApplication/*.

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

1. Erstellen Sie eine operator/job Ausführungsrolle in IAM, falls Sie noch keine haben.

1. Führen Sie den folgenden Befehl aus, um die Vertrauensrichtlinie der gerade erstellten operator/job Ausführungsrolle zu aktualisieren:

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

1. Bearbeiten Sie die IAM-Rollen-Vertrauensrichtlinie Ihrer operator/job Ausführungsrolle wie folgt:

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

1. Erstellen Sie in *IAM eine MonitoringConfiguration-Richtlinie* mit den folgenden Berechtigungen:

------
#### [ 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. Fügen Sie die obige Richtlinie Ihrer Ausführungsrolle hinzu. operator/job 

# Spark-Operator-Protokolle
<a name="spark-operator-monitoring-configuration-logs"></a>

Dabei können Sie die Überwachungskonfiguration auf folgende Weise definieren`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
```

**Konfiguration der Überwachung**

Im Folgenden sind die verfügbaren Konfigurationsoptionen unter **MonitoringConfiguration** aufgeführt.
+ **Bild** (optional) — Die Bild-URL des Agenten protokollieren. Wird abgerufen, emrReleaseLabel falls nicht angegeben.
+ **s3 MonitoringConfiguration** — Stellen Sie diese Option ein, um auf Amazon S3 zu archivieren.
  + **logURI** — (erforderlich) — Der Amazon S3 S3-Bucket-Pfad, in dem Sie Ihre Protokolle speichern möchten.
  + Im Folgenden finden Sie Beispielformate für die Amazon S3 S3-Bucket-Pfade, nachdem die Protokolle hochgeladen wurden. Das erste Beispiel zeigt, dass keine Protokollrotation aktiviert ist.

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

    Die Protokollrotation ist standardmäßig aktiviert. Sie können sowohl eine rotierte Datei mit einem inkrementierenden Index als auch eine aktuelle Datei sehen, die mit dem vorherigen Beispiel identisch ist.

    ```
    s3://${logUri}/${POD NAME}/operator/stdout_YYYYMMDD_index.gz
    s3://${logUri}/${POD NAME}/operator/stderr_YYYYMMDD_index.gz
    ```
+ **cloudWatchMonitoringKonfiguration** — Der Konfigurationsschlüssel, zu dem die Weiterleitung eingerichtet werden soll Amazon CloudWatch.
  + **logGroupName**(erforderlich) — Name der Amazon CloudWatch Protokollgruppe, an die Sie Protokolle senden möchten. Die Gruppe wird automatisch erstellt, wenn sie noch nicht vorhanden ist.
  + **logStreamNamePräfix** (optional) — Name des Log-Streams, in den Sie Logs senden möchten. Der Standardwert ist eine leere Zeichenfolge. Das Format in Amazon CloudWatch lautet wie folgt:

    ```
    ${logStreamNamePrefix}/${POD NAME}/STDOUT or STDERR
    ```
+ **sideCarResources**(optional) — Der Konfigurationsschlüssel zum Festlegen von Ressourcenlimits für den gestarteten Fluentd-Sidecar-Container.
  + **memoryLimit (optional) — Das Speicherlimit**. Passen Sie ihn entsprechend Ihren Anforderungen an. Der Standardwert ist 512 Mi.
  + **cpuLimit** (optional) — Das CPU-Limit. Passen Sie ihn entsprechend Ihren Anforderungen an. Die Standardeinstellung ist 500 m.
+ **containerLogRotationKonfiguration** (optional) — Steuert das Rotationsverhalten des Container-Logs. Sie ist standardmäßig aktiviert.
  + **RotationSize** (erforderlich) — Gibt die Dateigröße für die Protokollrotation an. Der Bereich der möglichen Werte ist von 2 KB bis 2 GB. Die numerische Einheit des rotationSize-Parameters wird als Ganzzahl übergeben. Da Dezimalwerte nicht unterstützt werden, können Sie mit dem Wert 1 500 MB beispielsweise eine Rotationsgröße von 1,5 GB angeben. Der Standardwert ist 2 GB.
  + **maxFilesToKeep** (erforderlich) — Gibt die maximale Anzahl von Dateien an, die nach der Rotation im Container aufbewahrt werden sollen. Der kleinste Wert ist 1 und der größte Wert ist 50. Der Standardwert ist 10.

Nach der Konfiguration der *MonitoringConfiguration* sollten Sie in der Lage sein, die Spot-Logs des Spark-Operators in einem Amazon S3 S3-Bucket oder Amazon CloudWatch in beiden zu überprüfen. Bei einem Amazon S3 S3-Bucket müssen Sie 2 Minuten warten, bis die erste Protokolldatei geleert wurde.

**Um die Logs zu finden Amazon CloudWatch, können Sie wie folgt navigieren: **CloudWatch**> **Protokollgruppen > > ***Log group name***/operator/stderr** *Pod name***

****Oder Sie können zu: **CloudWatch**> Protokollgruppen > > /operator/stdout navigieren ***Log group name****Pod name*****

# Spark-Anwendungsprotokolle
<a name="spark-operator-monitoring-application-logs"></a>

Sie können diese Konfiguration folgendermaßen definieren.

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

Im Folgenden sind die verfügbaren Konfigurationsoptionen unter **MonitoringConfiguration** aufgeführt.
+ **Bild** (optional) — Die Bild-URL des Agenten protokollieren. Wird abgerufen, emrReleaseLabel falls nicht angegeben.
+ **s3 MonitoringConfiguration** — Stellen Sie diese Option ein, um auf Amazon S3 zu archivieren.
  + **logURI** (erforderlich) — Der Amazon S3 S3-Bucket-Pfad, in dem Sie Ihre Protokolle speichern möchten. Das erste Beispiel zeigt, dass keine Protokollrotation aktiviert ist:

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

    Die Protokollrotation ist standardmäßig aktiviert. Sie können sowohl eine rotierte Datei (mit inkrementierendem Index) als auch eine aktuelle Datei (eine Datei ohne Datumsstempel) verwenden.

    ```
    s3://${logUri}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stdout_YYYYMMDD_index.gz
    s3://${logUri}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stderr_YYYYMMDD_index.gz
    ```
+ **cloudWatchMonitoringKonfiguration** — Der Konfigurationsschlüssel, zu dem die Weiterleitung eingerichtet werden soll Amazon CloudWatch.
  + **logGroupName**(erforderlich) — Der Name der Cloudwatch-Protokollgruppe, an die Sie Protokolle senden möchten. Die Gruppe wird automatisch erstellt, falls sie nicht existiert.
  + **logStreamNamePräfix** (optional) — Der Name des Log-Streams, in den Sie Logs senden möchten. Der Standardwert ist eine leere Zeichenfolge. Das Format in CloudWatch lautet wie folgt:

    ```
    ${logStreamNamePrefix}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stdout
    ${logStreamNamePrefix}/${APPLICATION NAME}-${APPLICATION UID}/${POD NAME}/stderr
    ```
+ **sideCarResources**(optional) — Der Konfigurationsschlüssel zum Festlegen von Ressourcenlimits für den gestarteten Fluentd-Sidecar-Container.
  + **memoryLimit (optional) — Das Speicherlimit**. Passen Sie ihn entsprechend Ihren Anforderungen an. Die Standardeinstellung ist 250 Mi.
  + **cpuLimit — Das CPU-Limit**. Passen Sie ihn entsprechend Ihren Anforderungen an. Die Standardeinstellung ist 500 m.
+ **containerLogRotationKonfiguration** (optional) — Steuert das Rotationsverhalten des Container-Logs. Sie ist standardmäßig aktiviert.
  + **RotationSize** (erforderlich) — Gibt die Dateigröße für die Protokollrotation an. Der Bereich der möglichen Werte ist von 2 KB bis 2 GB. Die numerische Einheit des rotationSize-Parameters wird als Ganzzahl übergeben. Da Dezimalwerte nicht unterstützt werden, können Sie mit dem Wert 1 500 MB beispielsweise eine Rotationsgröße von 1,5 GB angeben. Der Standardwert ist 2 GB.
  + **maxFilesToKeep** (erforderlich) — Gibt die maximale Anzahl von Dateien an, die nach der Rotation im Container aufbewahrt werden sollen. Der minimale Wert beträgt 1. Der Höchstwert ist 50. Der Standardwert ist 10.

Nach der Konfiguration von MonitoringConfiguration sollten Sie in der Lage sein, Ihre Spark-Anwendungstreiber- und Executor-Protokolle in einem Amazon S3 S3-Bucket oder in beiden zu überprüfen. CloudWatch Bei einem Amazon S3 S3-Bucket müssen Sie 2 Minuten warten, bis die erste Protokolldatei geleert ist. In Amazon S3 sieht der Bucket-Pfad beispielsweise wie folgt aus:

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

Oder:

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

 CloudWatchIn sieht der Pfad wie folgt aus:

**CloudWatch**> **Protokollgruppen** > ***Log group name***>*Spark application name - UUID*/*Pod name***/stderr**

Oder:

**CloudWatch****> **Protokollgruppen** > >/***Log group name***/stdout *Spark application name - UUID* *Pod name***

# Sicherheit und der Spark-Operator mit Amazon EMR in EKS
<a name="spark-operator-security"></a>

Es gibt verschiedene Möglichkeiten, Cluster-Zugriffsberechtigungen einzurichten, wenn Sie den Spark-Operator verwenden. Die erste Möglichkeit besteht darin, die rollenbasierte Zugriffskontrolle zu verwenden. Die rollenbasierte Zugriffskontrolle (RBAC) schränkt den Zugriff auf der Grundlage der Rolle einer Person innerhalb einer Organisation ein. Sie ist zu einer der wichtigsten Methoden zur Verwaltung des Zugriffs geworden. Die zweite Zugriffsmethode besteht darin, eine AWS Identity and Access Management Rolle zu übernehmen, die den Zugriff auf Ressourcen mithilfe bestimmter zugewiesener Berechtigungen ermöglicht.

**Topics**
+ [Einrichten der Cluster-Zugriffskontrolle mit rollenbasierter Zugriffskontrolle (RBAC)](spark-operator-security-rbac.md)
+ [Einrichten von Cluster-Zugriffsberechtigungen mit IAM-Rollen für Servicekonten (IRSA)](spark-operator-security-irsa.md)

# Einrichten der Cluster-Zugriffskontrolle mit rollenbasierter Zugriffskontrolle (RBAC)
<a name="spark-operator-security-rbac"></a>

Um den Spark-Operator bereitzustellen, erstellt Amazon EMR in EKS zwei Rollen und Servicekonten für den Spark-Operator und die Spark-Anwendungen.

**Topics**
+ [Servicekonto und Rolle des Operators](#spark-operator-sa-oper)
+ [Spark-Servicekonto und Rolle](#spark-operator-sa-spark)

## Servicekonto und Rolle des Operators
<a name="spark-operator-sa-oper"></a>

Amazon EMR in EKS erstellt das **Operator-Servicekonto und die Rolle**, um `SparkApplications` für Spark-Aufträge und andere Ressourcen wie Services zu verwalten.

Der Standardname für dieses Servicekonto lautet `emr-containers-sa-spark-operator`.

Es gelten die folgenden Regeln für diese Servicerolle: 

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

## Spark-Servicekonto und Rolle
<a name="spark-operator-sa-spark"></a>

Ein Spark-Treiber-Pod benötigt ein Kubernetes-Servicekonto im selben Namespace wie der Pod. Dieses Servicekonto benötigt Berechtigungen zum Erstellen, Abrufen, Auflisten, Patchen und Löschen von Ausführer-Pods sowie zum Erstellen eines Kubernetes-Headless-Services für den Treiber. Der Treiber schlägt fehl und wird ohne das Servicekonto beendet, sofern das Standardservicekonto im Namespace des Pods nicht über die erforderlichen Berechtigungen verfügt.

Der Standardname für dieses Servicekonto lautet `emr-containers-sa-spark`.

Es gelten die folgenden Regeln für diese Servicerolle: 

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

# Einrichten von Cluster-Zugriffsberechtigungen mit IAM-Rollen für Servicekonten (IRSA)
<a name="spark-operator-security-irsa"></a>

In diesem Abschnitt wird anhand eines Beispiels veranschaulicht, wie ein Kubernetes-Dienstkonto so konfiguriert wird, dass es eine AWS Identity and Access Management Rolle übernimmt. Pods, die das Dienstkonto verwenden, können dann auf jeden AWS Dienst zugreifen, für den die Rolle Zugriffsberechtigungen besitzt.

Im folgenden Beispiel wird eine Spark-Anwendung ausgeführt, um die Wörter aus einer Datei in Amazon S3 zu zählen. Zu diesem Zweck können Sie IAM-Rollen für Servicekonten (IRSA) einrichten, um Kubernetes-Servicekonten zu authentifizieren und zu autorisieren.

**Anmerkung**  
In diesem Beispiel wird der Namespace „spark-operator“ für den Spark-Operator und für den Namespace verwendet, in den Sie die Spark-Anwendung einreichen.

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

Führen Sie die folgenden Voraussetzungen aus, bevor Sie das Beispiel auf dieser Seite ausführen:
+ [Richten Sie den Spark-Operator ein]().
+ [Den Spark-Operator installieren](spark-operator-gs.md#spark-operator-install).
+ [Erstellen Sie einen Amazon-S3-Bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html).
+ Speichern Sie Ihr Lieblingsgedicht in einer Textdatei mit dem Namen `poem.txt` und laden Sie die Datei in Ihren S3-Bucket hoch. Die Spark-Anwendung, die Sie auf dieser Seite erstellen, liest den Inhalt der Textdatei. Weiter Anleitungen zum Hinzufügen von Dateien in S3 finden Sie unter [Upload eines Objekts zu Ihrem Bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-an-object-bucket.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*.

## Ein Kubernetes-Servicekonto zur Übernahme einer IAM-Rolle konfigurieren
<a name="spark-operator-security-irsa-config"></a>

Gehen Sie wie folgt vor, um ein Kubernetes-Dienstkonto so zu konfigurieren, dass es eine IAM-Rolle annimmt, mit der Pods auf AWS Dienste zugreifen können, für die die Rolle über Zugriffsberechtigungen verfügt.

1. Verwenden Sie nach Abschluss des die[Voraussetzungen](#spark-operator-security-irsa-prereqs), AWS Command Line Interface um eine `example-policy.json` Datei zu erstellen, die nur Lesezugriff auf die Datei ermöglicht, die Sie auf Amazon S3 hochgeladen haben:

   ```
   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. Dann erstellen Sie eine IAM-Richtlinie `example-policy`:

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

1. Erstellen Sie als Nächstes eine IAM-Rolle `example-role` und verknüpfen Sie sie mit einem Kubernetes-Servicekonto für den Spark-Treiber:

   ```
   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. Erstellen Sie eine Yaml-Datei mit den Cluster-Rollenbindungen, die für das Spark-Treiberservicekonto erforderlich sind:

   ```
   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. Die Konfigurationen für die Cluster-Rollenbindung anwenden:

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

Der Befehl kubectl sollte die erfolgreiche Erstellung des Kontos bestätigen:

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

## Ausführen einer Anwendung über den Spark-Operator
<a name="spark-operator-security-irsa-run"></a>

Nachdem Sie [das Kubernetes-Servicekonto konfiguriert]() haben, können Sie eine Spark-Anwendung ausführen, die die Anzahl der Wörter in der Textdatei zählt, die Sie als Teil von [Voraussetzungen](#spark-operator-security-irsa-prereqs) hochgeladen haben.

1. Erstellen Sie eine neue Datei `word-count.yaml` mit einer `SparkApplication` Definition für Ihre Wortzählanwendung, die auf Amazon EMR Version 6 basiert.

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

   Wenn Sie den Spark-Operator mit einer Version von Version 7 verwenden, passen Sie einige der Konfigurationswerte an:

   ```
   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. Reichen Sie die Spark-Anwendung ein.

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

   Der Befehl kubectl sollte eine Bestätigung zurückgeben, dass Sie erfolgreich ein `SparkApplication`-Objekt namens `word-count` erstellt haben.

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

1. Überprüfen Sie die Ereignisse für das `SparkApplication`-Objekt mit dem folgenden Befehl:

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

   Der Befehl kubectl sollte die Beschreibung des `SparkApplication` mit den Ereignissen zurückgeben:

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

Die Anwendung zählt jetzt die Wörter in Ihrer S3-Datei. Die Anzahl der Wörter finden Sie in den Protokolldateien Ihres Fahrers:

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

Der Befehl kubectl sollte den Inhalt der Protokolldatei mit den Ergebnissen Ihrer Anwendung zur Wortzählung zurückgeben.

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

Weitere Informationen zum Einreichen von Anwendungen an Spark über den Spark-Operator finden Sie unter [Using a SparkApplication](https://www.kubeflow.org/docs/components/spark-operator/user-guide/using-sparkapplication/) in der Dokumentation zum *Kubernetes-Operator für Apache Spark (spark-on-k8s-operator*) unter. GitHub

# Ausführen von Spark-Aufträgen mit spark-submit
<a name="spark-submit"></a>

Amazon-EMR-Versionen 6.10.0 und höher unterstützen `spark-submit` als Befehlszeilentool, mit dem Sie Spark-Anwendungen an einen Amazon EMR in EKS-Cluster senden und ausführen können.

**Anmerkung**  
Amazon EMR berechnet die Preise für Amazon EKS auf der Grundlage des vCPU- und Speicherverbrauchs. Diese Berechnung gilt für Treiber- und Executor-Pods. Diese Berechnung beginnt mit dem Herunterladen Ihres Amazon EMR-Anwendungsabbilds, bis der Amazon EKS-Pod endet und auf die nächste Sekunde gerundet wird.

**Topics**
+ [Einrichten von spark-submit für Amazon EMR in EKS](spark-submit-setup.md)
+ [Erste Schritte mit spark-submit für Amazon EMR in EKS](spark-submit-gs.md)
+ [Überprüfen Sie die Sicherheitsanforderungen für das Spark-Treiberdienstkonto für Spark-Submit](spark-submit-security.md)

# Einrichten von spark-submit für Amazon EMR in EKS
<a name="spark-submit-setup"></a>

Führen Sie die folgenden Aufgaben aus, um eine Anwendung mit spark-submit in Amazon EMR in EKS ausführen zu können. 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. Wenn Sie bereits eine der Voraussetzungen erfüllt haben, können Sie diese überspringen und mit der nächsten fortfahren.
+ **[Installieren oder aktualisieren Sie auf die neueste Version von AWS CLI— Falls Sie die](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)** bereits installiert haben, vergewissern Sie sich AWS CLI, dass Sie über die neueste Version verfügen.
+ **[Richten Sie kubectl und eksctl ein — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)** ist ein Befehlszeilentool, das Sie für die Kommunikation mit Amazon EKS verwenden.
+ **[Erste Schritte mit Amazon EKS — eksctl —](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)** Folgen Sie den Schritten, um einen neuen Kubernetes-Cluster mit Knoten in Amazon EKS zu erstellen.
+ **[Eine EMR-Basis-Image-URI von Amazon auswählen](docker-custom-images-tag.md) (Version 6.10.0 oder höher)** aus – der `spark-submit`-Befehl wird von Amazon-EMR-Versionen 6.10.0 und höher unterstützt.
+ Bestätigen Sie, dass das Treiberservicekonto über die entsprechenden Berechtigungen zum Erstellen und Überwachen von Executor-Pods verfügt. Weitere Informationen finden Sie unter [Überprüfen Sie die Sicherheitsanforderungen für das Spark-Treiberdienstkonto für Spark-Submit](spark-submit-security.md).
+ Richten Sie Ihr lokales [AWS -Anmeldeinformationsprofil ein](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html).
+ Wählen Sie in der Amazon EKS-Konsole Ihren EKS-Cluster aus und suchen Sie dann den EKS-Cluster-Endpunkt unter **Übersicht**, **Details** und dann **API-Serverendpunkt**.

# Erste Schritte mit spark-submit für Amazon EMR in EKS
<a name="spark-submit-gs"></a>

Amazon EMR 6.10.0 und höher unterstützt Spark-Submit für die Ausführung von Spark-Anwendungen auf einem Amazon-EKS-Cluster. Der folgende Abschnitt zeigt Ihnen, wie Sie einen Befehl für eine Spark-Anwendung einreichen.

## Eine Spark-Anwendung ausführen
<a name="spark-submit-run"></a>

Führen Sie die folgenden Schritte aus, um die Spark-Anwendung auszuführen:

1. Bevor Sie eine Spark-Anwendung mit dem `spark-submit`-Befehl ausführen können, führen Sie die Schritte unter [Einrichten von spark-submit für Amazon EMR in EKS](spark-submit-setup.md) durch. 

1. Führen Sie einen Container mit einem Amazon EMR auf dem EKS-Basis-Image aus. Weitere Informationen finden Sie unter [So wählen Sie einen Basis-Image-URI](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html) aus.

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

1. Legen Sie die Werte der folgenden Umgebungsvariablen fest:

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

1. Senden Sie jetzt die Spark-Anwendung mit dem folgenden Befehl:

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

Weitere Informationen zum Senden von Anwendungen an Spark finden Sie im Thema [Anwendungen senden](https://spark.apache.org/docs/latest/submitting-applications.html) in der Apache-Spark-Dokumentation.

**Wichtig**  
`spark-submit` unterstützt nur den Cluster-Modus als Einreichungsmechanismus.

# Überprüfen Sie die Sicherheitsanforderungen für das Spark-Treiberdienstkonto für Spark-Submit
<a name="spark-submit-security"></a>

Der Spark-Treiber-Pod verwendet ein Kubernetes-Servicekonto, um auf den Kubernetes-API-Server zuzugreifen und Executor-Pods zu erstellen und zu überwachen. Das Treiber-Servicekonto muss über die entsprechenden Berechtigungen verfügen, um Pods in Ihrem Cluster aufzulisten, zu erstellen, zu bearbeiten, zu patchen und zu löschen. Sie können überprüfen, ob Sie diese Ressourcen auflisten können, indem Sie den folgenden Befehl ausführen:

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

Stellen Sie sicher, dass Sie über die erforderlichen Berechtigungen verfügen, indem Sie jeden Befehl ausführen.

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

Es gelten die folgenden Regeln für diese Servicerolle: 

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

# Einrichtung von IAM-Rollen für Dienstkonten (IRSA) für Spark-Submit
<a name="spark-submit-security-irsa"></a>

In den folgenden Abschnitten wird erklärt, wie Sie IAM-Rollen für Service Accounts (IRSA) einrichten, um Kubernetes-Dienstkonten zu authentifizieren und zu autorisieren, sodass Sie in Amazon S3 gespeicherte Spark-Anwendungen ausführen können.

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

Bevor Sie eines der Beispiele in dieser Dokumentation ausprobieren, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllt haben:
+ [Die Einrichtung von Spark-Submit ist abgeschlossen](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/spark-submit-setup.html)
+ [Es wurde ein S3-Bucket erstellt](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html) und das Spark-Anwendungs-JAR [hochgeladen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-an-object-bucket.html)

## Konfiguration eines Kubernetes-Dienstkontos für die Übernahme einer IAM-Rolle
<a name="spark-submit-security-irsa-configure-kubernetes"></a>

In den folgenden Schritten wird beschrieben, wie Sie ein Kubernetes-Dienstkonto so konfigurieren, dass es eine AWS Identity and Access Management (IAM-) Rolle annimmt. Nachdem Sie die Pods für die Verwendung des Dienstkontos konfiguriert haben, können sie auf alle Pods zugreifen, für die AWS-Service die Rolle über Zugriffsberechtigungen verfügt.

1. [Erstellen Sie eine Richtliniendatei, um den schreibgeschützten Zugriff auf das Amazon S3 S3-Objekt zu ermöglichen, das Sie hochgeladen haben:](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. Erstellen Sie die IAM-Richtlinie.

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

1. Erstellen Sie eine IAM-Rolle und verknüpfen Sie sie mit einem Kubernetes-Dienstkonto für den Spark-Treiber

   ```
   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. Erstellen Sie eine YAML-Datei mit den erforderlichen [Berechtigungen](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/spark-submit-security.html) für das Spark-Treiberdienstkonto:

   ```
   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. Wenden Sie die Bindungskonfigurationen für die Clusterrolle an.

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

1. Der `kubectl` Befehl sollte die Bestätigung des erstellten Kontos zurückgeben.

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

## Die Spark-Anwendung ausführen
<a name="spark-submit-security-irsa-app-run"></a>

Amazon EMR 6.10.0 und höher unterstützt Spark-Submit für die Ausführung von Spark-Anwendungen auf einem Amazon-EKS-Cluster. Führen Sie die folgenden Schritte aus, um die Spark-Anwendung auszuführen:

1. Stellen Sie sicher, dass Sie die Schritte unter [Spark-Submit für Amazon EMR auf EKS einrichten](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/spark-submit-setup.html) abgeschlossen haben.

1. Legen Sie die Werte der folgenden Umgebungsvariablen fest:

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

1. Senden Sie jetzt die Spark-Anwendung mit dem folgenden Befehl:

   ```
   $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. Nachdem der Spark-Treiber den Spark-Job abgeschlossen hat, sollten Sie am Ende der Einreichung eine Protokollzeile sehen, die angibt, dass der Spark-Job abgeschlossen ist.

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

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

Wenn Sie mit der Ausführung Ihrer Anwendungen fertig sind, können Sie die Bereinigung mit dem folgenden Befehl durchführen.

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

# Verwenden von Apache Livy mit Amazon EMR auf EKS
<a name="job-runs-apache-livy"></a>

Mit Amazon EMR-Versionen 7.1.0 und höher können Sie Apache Livy verwenden, um Jobs auf Amazon EMR auf EKS einzureichen. Mit Apache Livy können Sie Ihren eigenen Apache Livy REST-Endpunkt einrichten und ihn verwenden, um Spark-Anwendungen auf Ihren Amazon EKS-Clustern bereitzustellen und zu verwalten. Nachdem Sie Livy in Ihrem Amazon EKS-Cluster installiert haben, können Sie den Livy-Endpunkt verwenden, um Spark-Anwendungen an Ihren Livy-Server zu senden. Der Server verwaltet den Lebenszyklus der Spark-Anwendungen.

**Anmerkung**  
Amazon EMR berechnet die Preise für Amazon EKS auf der Grundlage des vCPU- und Speicherverbrauchs. Diese Berechnung gilt für Treiber- und Executor-Pods. Diese Berechnung beginnt mit dem Herunterladen Ihres Amazon EMR-Anwendungsabbilds, bis der Amazon EKS-Pod endet und auf die nächste Sekunde gerundet wird.

**Topics**
+ [Apache Livy für Amazon EMR auf EKS einrichten](job-runs-apache-livy-setup.md)
+ [Erste Schritte mit Apache Livy auf Amazon EMR auf EKS](job-runs-apache-livy-install.md)
+ [Ausführen einer Spark-Anwendung mit Apache Livy für Amazon EMR auf EKS](job-runs-apache-livy-run-spark.md)
+ [Deinstallation von Apache Livy mit Amazon EMR auf EKS](job-runs-apache-livy-uninstall.md)
+ [Sicherheit für Apache Livy mit Amazon EMR auf EKS](job-runs-apache-livy-security.md)
+ [Installationseigenschaften für Apache Livy auf Amazon EMR auf EKS-Versionen](job-runs-apache-livy-installation-properties.md)
+ [Beheben Sie häufig auftretende Formatfehler bei Umgebungsvariablen](job-runs-apache-livy-troubleshooting.md)

# Apache Livy für Amazon EMR auf EKS einrichten
<a name="job-runs-apache-livy-setup"></a>

Bevor Sie Apache Livy auf Ihrem Amazon EKS-Cluster installieren können, müssen Sie eine Reihe von erforderlichen Tools installieren und konfigurieren. Dazu gehören der AWS CLI, ein grundlegendes Befehlszeilentool für die Arbeit mit AWS Ressourcen, Befehlszeilentools für die Arbeit mit Amazon EKS und ein Controller, der in diesem Anwendungsfall verwendet wird, um Ihre Cluster-Anwendung im Internet verfügbar zu machen und den Netzwerkverkehr weiterzuleiten.
+ **[Installation oder Aktualisierung auf die neueste Version von AWS CLI— Falls Sie die](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)** bereits installiert haben, vergewissern Sie sich AWS CLI, dass Sie über die neueste Version verfügen.
+ **[Richten Sie kubectl und eksctl ein — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)** ist ein Befehlszeilentool, das Sie für die Kommunikation mit Amazon EKS verwenden.
+ **[Helm installieren](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)** – Der Helm-Paketmanager für Kubernetes unterstützt Sie bei der Installation und Verwaltung von Anwendungen in Ihrem Kubernetes-Cluster. 
+ **[Erste Schritte mit Amazon EKS — eksctl —](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)** Folgen Sie den Schritten, um einen neuen Kubernetes-Cluster mit Knoten in Amazon EKS zu erstellen.
+ **[Wählen Sie ein Amazon EMR-Release-Label](docker-custom-images-tag.md)** aus — Apache Livy wird von Amazon EMR-Versionen 7.1.0 und höher unterstützt.
+ **[Installieren Sie den ALB-Controller](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html)** — Der ALB-Controller verwaltet AWS Elastic Load Balancing für Kubernetes-Cluster. Es erstellt einen AWS Network Load Balancer (NLB), wenn Sie bei der Einrichtung von Apache Livy einen Kubernetes-Ingress erstellen.

# Erste Schritte mit Apache Livy auf Amazon EMR auf EKS
<a name="job-runs-apache-livy-install"></a>

Gehen Sie wie folgt vor, um Apache Livy zu installieren. Dazu gehören die Konfiguration des Paketmanagers, die Erstellung eines Namespaces für die Ausführung von Spark-Workloads, die Installation von Livy, die Einrichtung des Lastenausgleichs und die Schritte zur Überprüfung. Sie müssen diese Schritte ausführen, um einen Batch-Job mit Spark auszuführen.

1. Falls Sie es noch nicht getan haben, richten Sie [Apache Livy für Amazon EMR auf](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html) EKS ein.

1. Authentifizieren Ihren Helm-Client in Ihrer Amazon-ECR-Registry. Sie können den entsprechenden `ECR-registry-account` Wert für Ihre AWS-Region [Amazon ECR-Registrierungskonten nach Regionen](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html#docker-custom-images-ECR) suchen.

   ```
   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. Durch die Einrichtung von Livy wird ein Dienstkonto für den Livy-Server und ein weiteres Konto für die Spark-Anwendung erstellt. Informationen zum Einrichten von IRSA für die Dienstkonten finden Sie unter [Einrichten von Zugriffsberechtigungen mit IAM-Rollen für Dienstkonten](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-irsa.html) (IRSA). 

1. Erstellen Sie einen Namespace, um Ihre Spark-Workloads auszuführen.

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

1. Verwenden Sie den folgenden Befehl, um Livy zu installieren.

   Dieser Livy-Endpunkt ist nur intern für die VPC im EKS-Cluster verfügbar. Um den Zugriff über die VPC hinaus zu ermöglichen, geben Sie `—-set loadbalancer.internal=false` Ihren Helm-Installationsbefehl ein.
**Anmerkung**  
Standardmäßig ist SSL in diesem Livy-Endpunkt nicht aktiviert und der Endpunkt ist nur innerhalb der VPC des EKS-Clusters sichtbar. Wenn Sie `loadbalancer.internal=false` und festlegen`ssl.enabled=false`, setzen Sie einen unsicheren Endpunkt außerhalb Ihrer VPC offen. Informationen zum Einrichten eines sicheren Livy-Endpunkts finden Sie unter [Konfiguration eines sicheren Apache Livy-Endpunkts mit 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
   ```

   Die Ausgabe sollte folgendermaßen aussehen.

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

   Die Standardnamen der Dienstkonten für den Livy-Server und die Spark-Sitzung lauten und. `emr-containers-sa-livy` `emr-containers-sa-spark-livy` Um benutzerdefinierte Namen zu verwenden, verwenden Sie die `sparkServiceAccount.name` Parameter `serviceAccounts.name` und.

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

1. Stellen Sie sicher, dass Sie das Helm-Diagramm installiert haben.

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

   Der `helm list` Befehl sollte Informationen über Ihr neues Helm-Diagramm zurückgeben.

   ```
   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. Stellen Sie sicher, dass der Network Load Balancer aktiv ist.

   ```
   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. Stellen Sie nun sicher, dass die Zielgruppe im Network Load Balancer fehlerfrei ist.

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

   Im Folgenden finden Sie eine Beispielausgabe, die den Status der Zielgruppe zeigt:

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

   Sobald der Status Ihrer NLB den `active` Status Ihrer Zielgruppe erreicht hat`healthy`, können Sie fortfahren. Dies kann ein paar Minuten dauern.

1. Rufen Sie den Livy-Endpunkt aus der Helm-Installation ab. Ob Ihr Livy-Endpunkt sicher ist oder nicht, hängt davon ab, ob Sie SSL aktiviert haben.

   ```
   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. Rufen Sie das Spark-Dienstkonto aus der Helm-Installation ab

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

   Die Ausgabe sollte der folgenden Ausgabe ähneln:

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

1. Wenn Sie `internalALB=true` den Zugriff von außerhalb Ihrer VPC aktivieren möchten, erstellen Sie eine EC2 Amazon-Instance und stellen Sie sicher, dass der Network Load Balancer Netzwerkverkehr von der EC2 Instance zulässt. Sie müssen dies tun, damit die Instance Zugriff auf Ihren Livy-Endpunkt hat. Weitere Informationen zur sicheren Bereitstellung Ihres Endpunkts außerhalb Ihrer VPC finden Sie unter [Einrichtung eines sicheren Apache Livy-Endpunkts mit](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-secure-endpoint.html) TLS/SSL.

1. Durch die Installation von Livy wird das Dienstkonto für die Ausführung von Spark-Anwendungen erstellt. `emr-containers-sa-spark` Wenn Ihre Spark-Anwendung AWS Ressourcen wie S3 verwendet oder AWS API- oder CLI-Operationen aufruft, müssen Sie eine IAM-Rolle mit den erforderlichen Berechtigungen mit Ihrem Spark-Dienstkonto verknüpfen. Weitere Informationen finden Sie unter [Einrichten von Zugriffsberechtigungen mit IAM-Rollen für Dienstkonten (IRSA](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-irsa.html)).

Apache Livy unterstützt zusätzliche Konfigurationen, die Sie bei der Installation von Livy verwenden können. Weitere Informationen finden Sie unter Installationseigenschaften für Apache Livy auf Amazon EMR auf EKS-Versionen.

# Ausführen einer Spark-Anwendung mit Apache Livy für Amazon EMR auf EKS
<a name="job-runs-apache-livy-run-spark"></a>

Bevor Sie eine Spark-Anwendung mit Apache Livy ausführen können, stellen Sie sicher, dass Sie die Schritte unter [Apache Livy für Amazon EMR auf EKS einrichten](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html) und [Erste Schritte mit Apache Livy für Amazon](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-install.html) EMR auf EKS ausgeführt haben.

Sie können Apache Livy verwenden, um zwei Arten von Anwendungen auszuführen:
+ Batch-Sitzungen — eine Art von Livy-Workload zum Senden von Spark-Batch-Jobs.
+ Interaktive Sitzungen — eine Art von Livy-Workload, der eine programmatische und visuelle Oberfläche zur Ausführung von Spark-Abfragen bietet.

**Anmerkung**  
Treiber- und Executor-Pods aus verschiedenen Sitzungen können miteinander kommunizieren. Namespaces garantieren keine Sicherheit zwischen Pods. Kubernetes erlaubt keine selektiven Berechtigungen für eine Teilmenge von Pods innerhalb eines bestimmten Namespace.

## Batch-Sitzungen ausführen
<a name="job-runs-apache-livy-run-spark-batch"></a>

Verwenden Sie den folgenden Befehl, um einen Batch-Job zu senden.

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

Verwenden Sie den folgenden Befehl, um Ihren Batch-Job zu überwachen.

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

## Interaktive Sitzungen ausführen
<a name="job-runs-apache-livy-run-spark-interactive"></a>

Gehen Sie wie folgt vor, um interaktive Sitzungen mit Apache Livy auszuführen.

1. Stellen Sie sicher, dass Sie Zugriff auf ein selbst gehostetes oder ein verwaltetes Jupyter-Notebook haben, z. B. ein KI-Jupyter-Notebook. SageMaker [Auf Ihrem Jupyter-Notebook muss Sparkmagic installiert sein.](https://github.com/jupyter-incubator/sparkmagic/blob/master/README.md)

1. Erstellen Sie einen Bucket für die Spark-Konfiguration. `spark.kubernetes.file.upload.path` Stellen Sie sicher, dass das Spark-Dienstkonto Lese- und Schreibzugriff auf den Bucket hat. Weitere Informationen zur Konfiguration Ihres Spark-Dienstkontos finden Sie unter Einrichten von Zugriffsberechtigungen mit IAM-Rollen für Dienstkonten (IRSA)

1. Laden Sie sparkmagic mit dem Befehl in das Jupyter-Notebook. `%load_ext sparkmagic.magics`

1. Führen Sie den Befehl aus`%manage_spark`, um Ihren Livy-Endpunkt mit dem Jupyter-Notebook einzurichten. **Wählen Sie die Registerkarte **Endpunkte hinzufügen**, wählen Sie den konfigurierten Authentifizierungstyp aus, fügen Sie den Livy-Endpunkt zum Notizbuch hinzu und wählen Sie dann Endpunkt hinzufügen.**

1. **Führen Sie den `%manage_spark` Vorgang erneut aus, um den Spark-Kontext zu erstellen, und wechseln Sie dann zur Sitzung erstellen.** Wählen Sie den Livy-Endpunkt, geben Sie einen eindeutigen Sitzungsnamen an, wählen Sie eine Sprache und fügen Sie dann die folgenden Eigenschaften hinzu.

   ```
   {
     "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. Reichen Sie die Anwendung ein und warten Sie, bis sie den Spark-Kontext erstellt hat.

1. Führen Sie den folgenden Befehl aus, um den Status der interaktiven Sitzung zu überwachen.

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

## Überwachung von Spark-Anwendungen
<a name="job-runs-apache-livy-run-ui"></a>

Verwenden Sie den Link`http://<livy-endpoint>/ui`, um den Fortschritt Ihrer Spark-Anwendungen mit der Livy-Benutzeroberfläche zu überwachen.

# Deinstallation von Apache Livy mit Amazon EMR auf EKS
<a name="job-runs-apache-livy-uninstall"></a>

Gehen Sie wie folgt vor, um Apache Livy zu deinstallieren.

1. Löschen Sie das Livy-Setup mit den Namen Ihres Namespaces und des Anwendungsnamens. In diesem Beispiel lautet der Anwendungsname `livy-demo` und der Namespace ist. `livy-ns`

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

1. Bei der Deinstallation löscht Amazon EMR on EKS den Kubernetes-Service in Livy, die AWS Load Balancer und die Zielgruppen, die Sie während der Installation erstellt haben. Das Löschen von Ressourcen kann einige Minuten dauern. Stellen Sie sicher, dass die Ressourcen gelöscht wurden, bevor Sie Livy erneut im Namespace installieren.

1. Löschen Sie den Spark-Namespace.

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

# Sicherheit für Apache Livy mit Amazon EMR auf EKS
<a name="job-runs-apache-livy-security"></a>

In den folgenden Themen erfahren Sie mehr über die Konfiguration der Sicherheit für Apache Livy mit Amazon EMR auf EKS. Zu diesen Optionen gehören die Verwendung von Transportschichtsicherheit, die rollenbasierte Zugriffskontrolle, bei der der Zugriff auf der Rolle einer Person innerhalb einer Organisation basiert, und die Verwendung von IAM-Rollen, die den Zugriff auf Ressourcen auf der Grundlage erteilter Berechtigungen ermöglichen.

**Topics**
+ [Einrichtung eines sicheren Apache Livy-Endpunkts mit TLS/SSL](job-runs-apache-livy-secure-endpoint.md)
+ [Einrichtung der Anwendungsberechtigungen für Apache Livy und Spark mit rollenbasierter Zugriffskontrolle (RBAC)](job-runs-apache-livy-rbac.md)
+ [Einrichtung von Zugriffsberechtigungen mit IAM-Rollen für Dienstkonten (IRSA)](job-runs-apache-livy-irsa.md)

# Einrichtung eines sicheren Apache Livy-Endpunkts mit TLS/SSL
<a name="job-runs-apache-livy-secure-endpoint"></a>

In den folgenden Abschnitten erfahren Sie mehr über die Einrichtung von Apache Livy für Amazon EMR auf EKS mit end-to-end TLS- und SSL-Verschlüsselung.

## Einrichtung der TLS- und SSL-Verschlüsselung
<a name="job-runs-apache-livy-security-tls"></a>

Gehen Sie folgendermaßen vor, um die SSL-Verschlüsselung auf Ihrem Apache Livy-Endpunkt einzurichten.
+ [Installieren Sie den Secrets Store CSI-Treiber und den AWS Secrets and Configuration Provider (ASCP)](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html) — der Secrets Store CSI-Treiber und ASCP speichern sicher die JKS-Zertifikate und Passwörter von Livy, die der Livy-Server-Pod benötigt, um SSL zu aktivieren. Sie können auch nur den Secrets Store CSI-Treiber installieren und jeden anderen unterstützten Secrets-Anbieter verwenden.
+ [Erstellen Sie ein ACM-Zertifikat](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) — dieses Zertifikat ist erforderlich, um die Verbindung zwischen dem Client und dem ALB-Endpunkt zu sichern.
+ Richten Sie ein JKS-Zertifikat, ein Schlüsselkennwort und ein Keystore-Passwort für ein AWS Secrets Manager — erforderlich, um die Verbindung zwischen dem ALB-Endpunkt und dem Livy-Server zu sichern.
+ Fügen Sie dem Livy-Dienstkonto Berechtigungen zum Abrufen von Geheimnissen hinzu AWS Secrets Manager — der Livy-Server benötigt diese Berechtigungen, um Geheimnisse von ASCP abzurufen und die Livy-Konfigurationen hinzuzufügen, um den Livy-Server zu sichern. Informationen zum Hinzufügen von IAM-Berechtigungen zu einem Dienstkonto finden Sie unter Einrichten von Zugriffsberechtigungen mit IAM-Rollen für Dienstkonten (IRSA).

### Einrichten eines JKS-Zertifikats mit einem Schlüssel und einem Keystore-Passwort für AWS Secrets Manager
<a name="job-runs-apache-livy-jks-certificate"></a>

Gehen Sie wie folgt vor, um ein JKS-Zertifikat mit einem Schlüssel und einem Keystore-Passwort einzurichten.

1. Generieren Sie eine Keystore-Datei für den Livy-Server.

   ```
   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. Erstellen Sie ein Zertifikat.

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

1. Erstellen Sie eine Truststore-Datei.

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

1. Speichern Sie das JKS-Zertifikat in. AWS Secrets Manager`livy-jks-secret`Ersetzen Sie es durch Ihr Geheimnis und `fileb://mykeystore.jks` durch den Pfad zu Ihrem Keystore-JKS-Zertifikat.

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

1. Speichern Sie den Keystore und das Schlüsselkennwort in Secrets Manager. Stellen Sie sicher, dass Sie Ihre eigenen Parameter verwenden.

   ```
   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. Erstellen Sie mit dem folgenden Befehl einen Livy-Server-Namespace.

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

1. Erstellen Sie das `ServiceProviderClass` Objekt für den Livy-Server, der über das JKS-Zertifikat und die Passwörter verfügt.

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

## Erste Schritte mit dem SSL-fähigen Apache Livy
<a name="job-runs-apache-livy-ssl-enabled-getting-started"></a>

Nachdem Sie SSL auf Ihrem Livy-Server aktiviert haben, müssen Sie das einrichten, um Zugriff auf die und `serviceAccount` Secrets auf zu haben. `keyStore` `keyPasswords` AWS Secrets Manager

1. Erstellen Sie den Livy-Server-Namespace.

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

1. Richten Sie das Livy-Dienstkonto ein, um Zugriff auf die Geheimnisse im Secrets Manager zu haben. Weitere Informationen zur Einrichtung von IRSA finden Sie unter [IRSA während der Installation von Apache Livy einrichten](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. Installieren Sie Livy. Verwenden Sie für den Parameter Helm chart --version Ihr Amazon EMR-Release-Label, z. B. `7.1.0` Sie müssen auch die Amazon ECR-Registrierungskonto-ID und die Region-ID durch Ihre eigene IDs ersetzen. Sie können den entsprechenden `ECR-registry-account` Wert für Ihre AWS-Region [Amazon ECR-Registrierungskonten nach Regionen](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html#docker-custom-images-ECR) suchen.

   ```
   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. Fahren Sie mit Schritt 5 der [Installation von Apache Livy auf Amazon EMR auf](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html#job-runs-apache-livy-install) EKS fort.

# Einrichtung der Anwendungsberechtigungen für Apache Livy und Spark mit rollenbasierter Zugriffskontrolle (RBAC)
<a name="job-runs-apache-livy-rbac"></a>

Um Livy bereitzustellen, erstellt Amazon EMR auf EKS ein Serverdienstkonto und eine Serverdienstrolle sowie ein Spark-Servicekonto und eine Rolle. Diese Rollen müssen über die erforderlichen RBAC-Berechtigungen verfügen, um die Einrichtung abzuschließen und Spark-Anwendungen auszuführen.

**RBAC-Berechtigungen für das Serverdienstkonto und die Serverrolle**

Amazon EMR on EKS erstellt das Livy-Serverdienstkonto und die Rolle zur Verwaltung von Livy-Sitzungen für Spark-Jobs und zur Weiterleitung von Datenverkehr zu und von den Eingangs- und anderen Ressourcen.

Der Standardname für dieses Servicekonto lautet `emr-containers-sa-livy`. Es muss über die folgenden Berechtigungen verfügen.

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

**RBAC-Berechtigungen für das Spark-Dienstkonto und die Spark-Rolle**

Ein Spark-Treiber-Pod benötigt ein Kubernetes-Servicekonto im selben Namespace wie der Pod. Dieses Dienstkonto benötigt Berechtigungen zur Verwaltung von Executor-Pods und allen Ressourcen, die für den Treiber-Pod benötigt werden. Sofern das Standarddienstkonto im Namespace nicht über die erforderlichen Berechtigungen verfügt, schlägt der Treiber fehl und wird beendet. Die folgenden RBAC-Berechtigungen sind erforderlich.

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

# Einrichtung von Zugriffsberechtigungen mit IAM-Rollen für Dienstkonten (IRSA)
<a name="job-runs-apache-livy-irsa"></a>

Standardmäßig haben der Livy-Server und die Treiber und Executoren der Spark-Anwendung keinen Zugriff auf Ressourcen. AWS Das Serverdienstkonto und das Spark-Dienstkonto steuern den Zugriff auf AWS Ressourcen für den Livy-Server und die Pods der Spark-Anwendung. Um Zugriff zu gewähren, müssen Sie die Dienstkonten einer IAM-Rolle zuordnen, die über die erforderlichen AWS Berechtigungen verfügt.

Sie können die IRSA-Zuordnung vor der Installation von Apache Livy, während der Installation oder nach Abschluss der Installation einrichten.

## IRSA während der Installation von Apache Livy einrichten (für ein Serverdienstkonto)
<a name="job-runs-apache-livy-irsa"></a>

**Anmerkung**  
Diese Zuordnung wird nur für das Serverdienstkonto unterstützt.

1. Stellen Sie sicher, dass Sie die [Einrichtung von Apache Livy für Amazon EMR auf EKS abgeschlossen haben und gerade](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html) dabei sind, [Apache Livy mit Amazon EMR auf EKS zu installieren](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-install.html). 

1. Erstellen Sie einen Kubernetes-Namespace für den Livy-Server. In diesem Beispiel lautet der Name des Namespaces. `livy-ns`

1. Erstellen Sie eine IAM-Richtlinie, die die Berechtigungen AWS-Services für die enthält, auf die Ihre Pods zugreifen sollen. Im folgenden Beispiel wird eine IAM-Richtlinie zum Abrufen von Amazon S3 S3-Ressourcen für den Spark-Einstiegspunkt erstellt.

   ```
   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. Verwenden Sie den folgenden Befehl, um Ihre AWS-Konto ID auf eine Variable festzulegen.

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

1. Setzen Sie den OpenID Connect (OIDC) -Identitätsanbieter Ihres Clusters auf eine Umgebungsvariable.

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

1. Legen Sie Variablen für den Namespace und den Namen des Servicekontos fest. Achten Sie darauf, Ihre eigenen Werte zu verwenden.

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

1. Erstellen Sie mit dem folgenden Befehl eine Vertrauensrichtliniendatei. Wenn Sie allen Dienstkonten in einem Namespace Zugriff auf die Rolle gewähren möchten, kopieren Sie den folgenden Befehl und ersetzen Sie ihn durch `StringLike` und `StringEquals` `$service_account` ersetzen `*` Sie ihn durch.

   ```
   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. Erstellen Sie die Rolle.

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

1. Verwenden Sie den folgenden Helm-Installationsbefehl, um die IRSA `serviceAccount.executionRoleArn` auf die Zuordnung festzulegen. Das Folgende ist ein Beispiel für den Befehl Helm install. Sie können den entsprechenden `ECR-registry-account` Wert für Ihre AWS-Region [Amazon ECR-Registrierungskonten nach Regionen](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html#docker-custom-images-ECR) suchen.

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

## Zuordnung von IRSA zu einem Spark-Dienstkonto
<a name="job-runs-apache-livy-irsa-spark"></a>

Bevor Sie IRSA einem Spark-Dienstkonto zuordnen, stellen Sie sicher, dass Sie die folgenden Schritte abgeschlossen haben:
+ Stellen Sie sicher, dass Sie die [Einrichtung von Apache Livy für Amazon EMR auf EKS abgeschlossen haben und gerade](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-setup.html) dabei sind, [Apache Livy mit Amazon EMR auf EKS zu installieren](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-install.html). 
+ Sie müssen über einen vorhandenen IAM OpenID Connect (OIDC) -Anbieter für Ihren Cluster verfügen. Informationen darüber, ob Sie bereits einen haben oder wie Sie einen erstellen, finden Sie unter [Erstellen eines IAM-OIDC-Anbieters](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html) für Ihren Cluster.
+ Stellen Sie sicher, dass Sie Version 0.171.0 oder höher der `eksctl` CLI installiert haben oder. AWS CloudShell Informationen zur Installation oder Aktualisierung `eksctl` finden Sie unter [Installation](https://eksctl.io/installation/) der `eksctl` Dokumentation.

Gehen Sie wie folgt vor, um IRSA Ihrem Spark-Dienstkonto zuzuordnen:

1. Verwenden Sie den folgenden Befehl, um das Spark-Dienstkonto abzurufen.

   ```
   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. Legen Sie Ihre Variablen für den Namespace und den Namen des Dienstkontos fest.

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

1. Verwenden Sie den folgenden Befehl, um eine Vertrauensrichtliniendatei für die IAM-Rolle zu erstellen. Das folgende Beispiel erteilt allen Dienstkonten innerhalb des Namespace die Erlaubnis, die Rolle zu verwenden. Ersetzen Sie dazu durch `StringLike` und `StringEquals` ersetzen Sie es `$service_account` durch \$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. Erstellen Sie die Rolle.

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

1. Ordnen Sie das Server- oder Spark-Dienstkonto mit dem folgenden `eksctl` Befehl zu. Stellen Sie sicher, dass Sie Ihre eigenen Werte verwenden.

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

# Installationseigenschaften für Apache Livy auf Amazon EMR auf EKS-Versionen
<a name="job-runs-apache-livy-installation-properties"></a>

Bei der Installation von Apache Livy können Sie eine Version des Livy Helm-Diagramms auswählen. Das Helm-Diagramm bietet eine Vielzahl von Eigenschaften, mit denen Sie Ihr Installations- und Einrichtungserlebnis individuell anpassen können. Diese Eigenschaften werden für Amazon EMR auf EKS-Versionen 7.1.0 und höher unterstützt.

**Topics**
+ [Amazon EMR 7.1.0-Installationseigenschaften](#job-runs-apache-livy-installation-properties-710)

## Amazon EMR 7.1.0-Installationseigenschaften
<a name="job-runs-apache-livy-installation-properties-710"></a>

In der folgenden Tabelle werden alle unterstützten Livy-Eigenschaften beschrieben. Bei der Installation von Apache Livy können Sie die Livy Helm-Diagrammversion wählen. Verwenden Sie den Befehl, um während der Installation eine Eigenschaft festzulegen. `--set <property>=<value>`


| Property (Eigenschaft) | Description (Beschreibung) | Standard | 
| --- | --- | --- | 
| Abbild | Die Amazon EMR-Release-URI des Livy-Servers. Dies ist eine erforderliche Konfiguration. | "" | 
| Spark-Namespace | Namespace zum Ausführen von Livy Spark-Sitzungen. Geben Sie beispielsweise „Livy“ an. Dies ist eine erforderliche Konfiguration. | "" | 
| NameOverride | Geben Sie einen Namen anstelle von livy ein. Der Name wird als Bezeichnung für alle Livy-Ressourcen festgelegt | „Livy“ | 
| Vollständiger Name überschreiben | Geben Sie einen Namen an, der anstelle der vollständigen Namen der Ressourcen verwendet werden soll. | "" | 
| ssl.aktiviert | Aktiviert end-to-end SSL vom Livy-Endpunkt zum Livy-Server. | FALSE | 
| SSL.CertificateN | Wenn SSL aktiviert ist, ist dies der vom Dienst erstellte ACM-Zertifikat-ARN für den NLB. | "" | 
| ssl. secretProviderClassName | Wenn SSL aktiviert ist, ist dies der geheime Anbieter-Klassenname zur Sicherung von NLB für die Livy-Serververbindung mit SSL. | "" | 
| ssl. keyStoreObjectName | Wenn SSL aktiviert ist, der Objektname für das Keystore-Zertifikat in der Secret-Provider-Klasse. | "" | 
| ssl. keyPasswordsObjectName | Wenn SSL aktiviert ist, der Objektname für das Geheimnis, das den Keystore und das Schlüsselkennwort enthält. | "" | 
| rbac.create | Falls wahr, werden RBAC-Ressourcen erstellt. | FALSE | 
| ServiceAccount.Create | Falls wahr, wird ein Livy-Dienstkonto erstellt. | TRUE | 
| ServiceAccount.Name | Der Name des Dienstkontos, das für Livy verwendet werden soll. Wenn Sie diese Eigenschaft nicht festlegen und ein Servicekonto erstellen, generiert Amazon EMR auf EKS automatisch einen Namen mithilfe der fullname Override-Eigenschaft. | "emr-containers-sa-livy" | 
| Servicekonto. executionRoleArn | Der ARN für die Ausführungsrolle des Livy-Dienstkontos. | "" | 
| sparkServiceAccount.erstellen | FALLS wahr, erstellt das Spark-Dienstkonto in .Release.Namespace | TRUE | 
| sparkServiceAccount.name | Der Name des Dienstkontos, das für Spark verwendet werden soll. Wenn Sie diese Eigenschaft nicht festlegen und ein Spark-Servicekonto erstellen, generiert Amazon EMR auf EKS automatisch einen Namen mit der fullnameOverride Eigenschaft mit -spark-livy Suffix. | „-livy“ emr-containers-sa-spark | 
| Dienstname | Name des Livy-Dienstes | "emr-containers-livy" | 
| service.annotations | Anmerkungen zum Livy-Service | \$1\$1 | 
| loadbalancer.enabled | Ob ein Load Balancer für den Livy-Service erstellt werden soll, der verwendet wird, um den Livy-Endpunkt außerhalb des Amazon EKS-Clusters verfügbar zu machen. | FALSE | 
| loadbalancer.internal | Ob der Livy-Endpunkt als intern in der VPC oder extern konfiguriert werden soll. Wenn Sie diese Eigenschaft auf setzen`FALSE`, wird der Endpunkt Quellen außerhalb der VPC zugänglich gemacht. Wir empfehlen, Ihren Endpunkt mit TLS/SSL zu sichern. Weitere Informationen finden Sie unter [TLS- und SSL-Verschlüsselung einrichten](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 | Die Liste der imagePullSecret Namen, die verwendet werden sollen, um das Livy-Image aus privaten Repositorys abzurufen. | [] | 
| Ressourcen | Die Ressourcenanforderungen und Grenzwerte für Livy-Container. | \$1\$1 | 
| nodeSelector | Die Knoten, für die Livy-Pods geplant werden sollen. | \$1\$1 | 
| Toleranzen | Eine Liste mit den zu definierenden Toleranzen für Livy-Pods. | [] | 
| Affinität | Die Affinitätsregeln der Livy Pods. | \$1\$1 | 
| Persistenz.aktiviert | Wenn der Wert true ist, wird die Persistenz für Sitzungsverzeichnisse aktiviert. | FALSE | 
| persistence.subPath | Der PVC-Unterpfad, der in Sitzungsverzeichnisse eingebunden werden soll. | "" | 
| Persistence.ExistingClaim | Das PVC, das verwendet werden soll, anstatt ein neues zu erstellen. | \$1\$1 | 
| persistence.storageClass | Die zu verwendende Speicherklasse. Verwenden Sie das Format, um diesen Parameter zu definierenstorageClassName: <storageClass>. Wenn Sie diesen Parameter auf einstellen, wird die dynamische Bereitstellung "-" deaktiviert. Wenn Sie diesen Parameter auf Null setzen oder nichts angeben, legt Amazon EMR on EKS keinen Wert fest storageClassName und verwendet den Standard-Provisioner. | "" | 
| persistence.AccessMode | Der PVC-Zugriffsmodus. | ReadWriteOnce | 
| persistence.size | Die PVC-Größe. | 20 Gi | 
| Persistenz. Anmerkungen | Zusätzliche Anmerkungen für das PVC. | \$1\$1 | 
| Umgebung. \$1 | Zusätzliche Umgebungen, die auf den Livy-Container gesetzt werden sollen. Weitere Informationen finden Sie unter [Eingabe Ihrer eigenen Livy- und Spark-Konfigurationen während der Installation von Livy](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/job-runs-apache-livy-troubleshooting.html). | \$1\$1 | 
| Umgebung von. \$1 | Zusätzliche Umgebungen, die aus einer Kubernetes-Konfigurationsmap oder einem Secret auf Livy gesetzt werden können. | [] | 
| LivyConf. \$1 | Zusätzliche livy.conf-Einträge, die aus einer bereitgestellten Kubernetes-Konfigurationsübersicht oder einem geheimen Schlüssel gesetzt werden können. | \$1\$1 | 
| sparkDefaultsConf.\$1 | Zusätzliche spark-defaults.conf Einträge, die aus einer bereitgestellten Kubernetes-Konfigurationsübersicht oder einem geheimen Schlüssel gesetzt werden können. | \$1\$1 | 

# Beheben Sie häufig auftretende Formatfehler bei Umgebungsvariablen
<a name="job-runs-apache-livy-troubleshooting"></a>

Wenn Sie Livy- und Spark-Konfigurationen eingeben, gibt es Formate mit Umgebungsvariablen, die nicht unterstützt werden und Fehler verursachen können. Das Verfahren führt Sie durch eine Reihe von Schritten, um sicherzustellen, dass Sie die richtigen Formate verwenden.

**Geben Sie bei der Installation von Livy Ihre eigenen Livy- und Spark-Konfigurationen ein**

Sie können jede Apache Livy- oder Apache Spark-Umgebungsvariable mit der Helm-Eigenschaft konfigurieren. `env.*` Gehen Sie wie folgt vor, um die Beispielkonfiguration in ein unterstütztes Umgebungsvariablenformat `example.config.with-dash.withUppercase` zu konvertieren.

1. Ersetzen Sie Großbuchstaben durch eine 1 und einen Kleinbuchstaben des Buchstabens. Beispielsweise wird `example.config.with-dash.withUppercase` zu `example.config.with-dash.with1uppercase`.

1. Ersetzen Sie Bindestriche (-) durch 0. Zum Beispiel wird `example.config.with-dash.with1uppercase` `example.config.with0dash.with1uppercase`

1. Ersetzt Punkte (.) durch Unterstriche (\$1). Beispielsweise wird `example.config.with0dash.with1uppercase` zu `example_config_with0dash_with1uppercase`.

1. Ersetze alle Kleinbuchstaben durch Großbuchstaben.

1. Fügen Sie dem Variablennamen `LIVY_` das Präfix hinzu.

1. Verwenden Sie die Variable bei der Installation von Livy über das Helmchart im Format --set env. *YOUR\$1VARIABLE\$1NAME*.value= *yourvalue*

Um beispielsweise die Livy- und Spark-Konfigurationen festzulegen und diese `livy.server.recovery.state-store = filesystem` Helm-Eigenschaften `spark.kubernetes.executor.podNamePrefix = my-prefix` zu verwenden:

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

# Verwalten von Aufgabenausführungen von Amazon EMR in EKS
<a name="emr-eks-jobs-manage"></a>

In den folgenden Abschnitten werden Themen behandelt, die Sie bei der Verwaltung Ihrer Aufgabenausführungen in Amazon EMR in EKS unterstützen. Dazu gehören die Konfiguration von Job-Ausführungsparametern bei der Verwendung von AWS CLI, die Konfiguration der Speicherung Ihrer Protokolldaten, das Ausführen von Spark-SQL-Skripts zur Ausführung von Abfragen, das Verständnis der Job-Ausführungsstatus und das Wissen, wie Jobs überwacht werden. Sie können diese Themen in der Regel der Reihe nach durcharbeiten, wenn Sie einen Job zur Verarbeitung von Daten einrichten und abschließen möchten.

**Topics**
+ [Die Verwaltung von Jobläufen erfolgt mit dem AWS CLI](emr-eks-jobs-CLI.md)
+ [StartJobRun Spark-SQL-Skripts über die API ausführen](emr-eks-jobs-spark-sql-parameters.md)
+ [Status von Aufgabenausführungen](emr-eks-jobs-states.md)
+ [Aufträge in der Amazon-EMR-Konsole anzeigen](emr-eks-jobs-console.md)
+ [Häufige Fehler beim Ausführen von Aufträgen](emr-eks-jobs-error.md)

# Die Verwaltung von Jobläufen erfolgt mit dem AWS CLI
<a name="emr-eks-jobs-CLI"></a>

In diesem Thema wird beschrieben, wie Jobläufe mit dem AWS Command Line Interface (AWS CLI) verwaltet werden. Es geht detailliert auf Eigenschaften wie Sicherheitsparameter, den Treiber und verschiedene Override-Einstellungen ein. Es enthält auch Unterthemen, die verschiedene Möglichkeiten zur Konfiguration der Protokollierung behandeln.

**Topics**
+ [Optionen für die Konfiguration einer Aufgabenausführung](#emr-eks-jobs-parameters)
+ [Eine Aufgabenausführung für die Verwendung von Amazon-S3-Protokollen konfigurieren](emr-eks-jobs-s3.md)
+ [Einen Joblauf für die Verwendung von Amazon CloudWatch Logs konfigurieren](emr-eks-jobs-cloudwatch.md)
+ [Aufgabenausführungen auflisten](#emr-eks-jobs-list)
+ [Eine Aufgabenausführung beschreiben](#emr-eks-jobs-describe)
+ [Eine Aufgabenausführung abbrechen](#emr-eks-jobs-cancel)

## Optionen für die Konfiguration einer Aufgabenausführung
<a name="emr-eks-jobs-parameters"></a>

Verwenden Sie die folgenden Optionen, um die Aufgaben-Ausführungsparameter zu konfigurieren:
+ `--execution-role-arn`: Sie müssen eine IAM-Rolle angeben, die für die Ausführung von Aufgaben verwendet wird. Weitere Informationen finden Sie unter [Auftragausführungsrollen mit Amazon EMR in EKS verwenden](iam-execution-role.md). 
+ `--release-label`: Sie können Amazon EMR in EKS mit den Amazon-EMR-Versionen 5.32.0 und 6.2.0 und höher bereitstellen. Amazon EMR in EKS wird in früheren Amazon-EMR-Release-Versionen nicht unterstützt. Weitere Informationen finden Sie unter [Versionen von Amazon EMR in EKS](emr-eks-releases.md). 
+ `--job-driver`: Der Auftrag-Treiber wird verwendet, um Eingaben für die Hauptaufgabe bereitzustellen. Dies ist ein Feld vom Typ Union, in das Sie nur einen der Werte für den Aufgabentyp übergeben können, den Sie ausführen möchten. Unterstützte Aufgabentypen sind:
  + Spark-Submit-Aufgaben - Wird verwendet, um einen Befehl über Spark-Submit auszuführen. Sie können diesen Jobtyp verwenden, um Scala, SparkR PySpark, SparkSQL und alle anderen unterstützten Jobs über Spark Submit auszuführen. Dieser Aufgabentyp hat die folgenden Parameter:
    + Entrypoint — Dies ist der HCFS-Verweis (Hadoop Compatible File System) auf die Hauptdatei, die Sie ausführen möchten. jar/py 
    + EntryPointArguments - Dies ist eine Reihe von Argumenten, die Sie an Ihre Hauptdatei übergeben möchten. jar/py Sie sollten das Lesen dieser Parameter mit Ihrem Einstiegspunkt-Code regeln. Jedes Argument im Array sollte durch ein Komma getrennt werden. EntryPointArguments darf keine Klammern oder Klammern enthalten, z. B. (), \$1\$1 oder []. 
    + SparkSubmitParameters - Dies sind die zusätzlichen Spark-Parameter, die Sie an den Job senden möchten. Verwenden Sie diesen Parameter, um Spark-Standardeigenschaften wie Treiberspeicher oder Anzahl der Ausführer wie -conf oder -class zu überschreiben. Weitere Informationen finden Sie unter [Starten von Anwendungen mit Spark-Submit](https://spark.apache.org/docs/latest/submitting-applications.html#launching-applications-with-spark-submit).
  + Spark-SQL-Aufträge – Wird verwendet, um eine SQL-Abfragedatei über Spark SQL auszuführen. Sie können diesen Auftragtyp verwenden, um SparkSQL-Aufträge auszuführen. Dieser Aufgabentyp hat die folgenden Parameter:
    + Einstiegspunkt – Dies ist der HCFS-Verweis (Hadoop Compatible File System) auf die SQL-Abfragedatei, die Sie ausführen möchten.

      Eine Liste zusätzlicher Spark-Parameter, die Sie für einen Spark-SQL-Auftrag verwenden können, finden Sie unter [StartJobRun Spark-SQL-Skripts über die API ausführen](emr-eks-jobs-spark-sql-parameters.md).
+ `--configuration-overrides`: Sie können die Standardkonfigurationen für die Anwendungen überschreiben, indem Sie ein Konfigurationsobjekt angeben. Sie können eine Syntax-Kurznotation verwenden, um die Konfiguration anzugeben oder Sie können auf die Konfiguration in einer JSON-Datei zu verweisen. Konfigurationsobjekte bestehen aus einer Klassifizierung, Eigenschaften und optionalen verschachtelten Konfigurationen. Eigenschaften bestehen aus den Einstellungen, die Sie in dieser Datei überschreiben möchten. Sie können mehrere Klassifizierungen für mehrere Anwendungen in einem einzigen JSON-Objekt angeben. Die verfügbaren Konfigurationsklassifizierungen variieren je nach Amazon-EMR-Version. Eine Liste der Konfigurationsklassifizierungen, die für jede Version von Amazon EMR verfügbar sind, finden Sie unter [Versionen von Amazon EMR in EKS](emr-eks-releases.md).

  Wenn Sie dieselbe Konfiguration in einer Anwendungsüberschreibung und in den Spark-Submit-Parametern übergeben, haben die Spark-Submit-Parameter Vorrang. Es folgt die vollständige Liste der Konfigurationsprioritäten, in der Reihenfolge von höchster Priorität bis niedrigster Priorität.
  + Konfiguration, die bei der Erstellung von `SparkSession` angegeben wurde.
  + Die Konfiguration wurde im Rahmen der `sparkSubmitParameters` unter `—conf`-Verwendung bereitgestellt.
  + Konfiguration, die im Rahmen von Anwendungsüberschreibungen bereitgestellt wird.
  + Optimierte Konfigurationen, die von Amazon EMR für die Veröffentlichung ausgewählt wurden.
  + Open-Source-Standardkonfigurationen für die Anwendung.

  Um Auftragsausführungen mit Amazon CloudWatch oder Amazon S3 zu überwachen, müssen Sie die Konfigurationsdetails für angeben CloudWatch. Weitere Informationen erhalten Sie unter [Eine Aufgabenausführung für die Verwendung von Amazon-S3-Protokollen konfigurieren](emr-eks-jobs-s3.md) und [Einen Joblauf für die Verwendung von Amazon CloudWatch Logs konfigurieren](emr-eks-jobs-cloudwatch.md). Wenn der S3-Bucket oder die CloudWatch Protokollgruppe nicht existiert, erstellt Amazon EMR sie, bevor die Protokolle in den Bucket hochgeladen werden.
+ Eine zusätzliche Liste der Kubernetes-Konfigurationsoptionen finden Sie unter [Spark-Eigenschaften auf Kubernetes.](https://spark.apache.org/docs/latest/running-on-kubernetes.html#configuration) 

  Die folgenden Spark-Konfigurationen werden nicht unterstützt.
  + `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`
**Anmerkung**  
Sie können `spark.kubernetes.container.image` für benutzerdefinierte Docker-Images verwenden. Weitere Informationen finden Sie unter [Anpassen von Docker-Images für Amazon EMR in EKS](docker-custom-images.md).

# Eine Aufgabenausführung für die Verwendung von Amazon-S3-Protokollen konfigurieren
<a name="emr-eks-jobs-s3"></a>

Um den Auftragsfortschritt überwachen und Fehler beheben zu können, müssen Sie Ihre Jobs so konfigurieren, dass Protokollinformationen an Amazon S3, Amazon CloudWatch Logs oder beide gesendet werden. Dieses Thema hilft Ihnen bei den ersten Schritten beim Veröffentlichen von Anwendungsprotokollen in Amazon S3 für Ihre Aufträge, die mit Amazon EMR in EKS gestartet wurden.

**S3 protokolliert die IAM-Richtlinie**

Bevor Ihre Aufträge Protokolldaten an Amazon S3 senden können, müssen die folgenden Berechtigungen in der Berechtigungsrichtlinie für die Auftragausführungsrolle enthalten sein. *amzn-s3-demo-logging-bucket*Ersetzen Sie es durch den Namen Ihres Logging-Buckets.

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

------

**Anmerkung**  
Amazon EMR in EKS kann auch einen Amazon-S3-Bucket erstellen. Wenn ein Amazon-S3-Bucket nicht verfügbar ist, nehmen Sie die `“s3:CreateBucket”`-Erlaubnis in die IAM-Richtlinie auf.

Nachdem Sie Ihrer Ausführungsrolle die entsprechenden Berechtigungen zum Senden von Protokollen an Amazon S3 erteilt haben, werden Ihre Protokolldaten an die folgenden Amazon-S3-Speicherorte gesendet, wenn `s3MonitoringConfiguration` im `monitoringConfiguration` Abschnitt einer `start-job-run`-Anforderung übergeben werden, wie unter [Die Verwaltung von Jobläufen erfolgt mit dem AWS CLI](emr-eks-jobs-CLI.md) beschrieben.
+ Protokolle des Absenders —//*virtual-cluster-id*/jobs/ /containers/*logUri*/(stderr.gz/stdout.gz*job-id*) *pod-name*
+ Treiberprotokolle -//*logUri**virtual-cluster-id*/jobs/ *job-id* /containers/ /spark- *spark-application-id* -driver/ *job-id* (stderr.gz/stdout.gz)
+ Ausführungsprotokolle -/*logUri*/*virtual-cluster-id*/jobs/ *job-id* /containers//*executor-pod-name*/(*spark-application-id*stderr.gz/stdout.gz)

# Einen Joblauf für die Verwendung von Amazon CloudWatch Logs konfigurieren
<a name="emr-eks-jobs-cloudwatch"></a>

Um den Auftragsfortschritt zu überwachen und Fehler zu beheben, müssen Sie Ihre Jobs so konfigurieren, dass Protokollinformationen an Amazon S3, Amazon CloudWatch Logs oder beide gesendet werden. Dieses Thema hilft Ihnen bei den ersten Schritten mit der Verwendung von CloudWatch Logs für Ihre Jobs, die mit Amazon EMR auf EKS gestartet werden. Weitere Informationen zu CloudWatch Protokollen finden Sie unter [Überwachung von Protokolldateien](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) im CloudWatch Amazon-Benutzerhandbuch.

**CloudWatch Protokolliert die IAM-Richtlinie**

Damit Ihre Jobs Protokolldaten an CloudWatch Logs senden können, müssen die folgenden Berechtigungen in der Berechtigungsrichtlinie für die Jobausführungsrolle enthalten sein. Ersetzen Sie *my\$1log\$1group\$1name* und *my\$1log\$1stream\$1prefix* durch die Namen Ihrer CloudWatch Protokollgruppe bzw. die Namen der Protokolldatenströme. Amazon EMR in EKS erstellt die Protokollgruppe und den Protokollstream, falls sie nicht existieren, solange der ARN für die Ausführungsrolle über die entsprechenden Berechtigungen verfügt. 

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

------

**Anmerkung**  
Amazon EMR in EKS kann auch einen Protokollstream erstellen. Wenn kein Protokollstream vorhanden ist, sollte die IAM-Richtlinie die `"logs:CreateLogGroup"` Genehmigung enthalten.

Nachdem Sie Ihrer Ausführungsrolle die entsprechenden Berechtigungen erteilt haben, sendet Ihre Anwendung ihre Protokolldaten an CloudWatch Logs, wenn sie `cloudWatchMonitoringConfiguration` im `monitoringConfiguration` Abschnitt einer `start-job-run` Anforderung übergeben werden, wie unter beschrieben[Die Verwaltung von Jobläufen erfolgt mit dem AWS CLI](emr-eks-jobs-CLI.md).

In der `StartJobRun` API *log\$1group\$1name * ist dies der Name der Protokollgruppe für CloudWatch und *log\$1stream\$1prefix* das Präfix für den Protokollstreamnamen CloudWatch. Sie können diese Protokolle in der AWS-Managementkonsole anzeigen und durchsuchen.
+ Protokolle des Absenders —*logGroup*//*virtual-cluster-id*/jobs/ *logStreamPrefix* /containers//(stderr/stdout*job-id*) *pod-name*
+ Treiberprotokolle -*logGroup*//*logStreamPrefix**virtual-cluster-id*/jobs/ *job-id* /containers/ /spark- *spark-application-id* *job-id* -driver/ (stderrstdout)
+ Ausführungsprotokolle -*logGroup*/*logStreamPrefix*/*virtual-cluster-id*/jobs/ *job-id* /containers//*executor-pod-name*/*spark-application-id*(stderr/stdout)

## Aufgabenausführungen auflisten
<a name="emr-eks-jobs-list"></a>

Sie können `list-job-run` ausführen, um den Status der Aufgabenausführungen anzuzeigen, wie das folgende Beispiel zeigt. 

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

## Eine Aufgabenausführung beschreiben
<a name="emr-eks-jobs-describe"></a>

Sie können `describe-job-run` ausführen, um weitere Informationen über die Aufgabe abzurufen, z. B. den Status, die Statusdetails und den Aufgabennamen, wie das folgende Beispiel zeigt. 

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

## Eine Aufgabenausführung abbrechen
<a name="emr-eks-jobs-cancel"></a>

Sie können `cancel-job-run` ausführen, um laufende Aufträge abzubrechen, wie das folgende Beispiel zeigt.

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

# StartJobRun Spark-SQL-Skripts über die API ausführen
<a name="emr-eks-jobs-spark-sql-parameters"></a>

Die Versionen 6.7.0 und höher von Amazon EMR in EKS enthalten einen Spark-SQL-Auftrag-Treiber, sodass Sie Spark-SQL-Skripts über die `StartJobRun`-API ausführen können. Sie können SQL-Einstiegspunktdateien bereitstellen, um Spark-SQL-Abfragen direkt auf Amazon EMR in EKS mit der `StartJobRun`-API auszuführen, ohne Änderungen an vorhandenen Spark-SQL-Skripts vornehmen zu müssen. In der folgenden Tabelle sind Spark-Parameter aufgeführt, die für die Spark-SQL-Jobs über die StartJobRun API unterstützt werden.

Sie können aus den folgenden Spark-Parametern wählen, um sie an einen Spark-SQL-Auftrag zu senden. Verwenden Sie diese Parameter, um die Spark-Standardeigenschaften zu überschreiben.


| Option | Description | 
| --- | --- | 
|  --Name NAME  | Anwendungsname | 
| --jars JARS | Durch Kommas getrennte Liste von JAR-Dateien, die in den Klassenpfad des Treibers und der Ausführung aufgenommen werden sollen. | 
| --packages | Durch Kommas getrennte Liste der Maven-Koordinaten von JAR-Dateien, die in die Klassenpfade des Treibers und des Ausführers aufgenommen werden sollen. | 
| --exclude-packages | Durch Kommas getrennte Liste von groupID:artifactId, die beim Auflösen der in –packages angegebenen Abhängigkeiten ausgeschlossen werden sollen, um Abhängigkeitskonflikte zu vermeiden. | 
| --repositories | Kommagetrennte Liste zusätzlicher Remote-Repositorys, um nach den mit –packages angegebenen Maven-Koordinaten zu suchen. | 
| --files FILES | Durch Kommas getrennte Liste von Dateien, die im Arbeitsverzeichnis jedes Ausführers abgelegt werden sollen. | 
| --conf PROP=VALUE | Spark-Konfigurationseigenschaft. | 
| --properties-file FILE | Pfad zu einer Datei, aus der zusätzliche Eigenschaften geladen werden sollen. | 
| --driver-memory MEM | Arbeitsspeicher für den Treiber. Standard 1 024 MB. | 
| --driver-java-options | Zusätzliche Java-Optionen, die an den Treiber übergeben werden. | 
| --driver-library-path | Zusätzliche Bibliothekspfadeinträge, die an den Treiber übergeben werden. | 
| --driver-class-path | Zusätzliche Klassenpfadeinträge, die an den Treiber übergeben werden. | 
| --executor-memory MEM | Arbeitsspeicher pro Ausführer. Standard: 1 GB. | 
| --driver-cores NUM | Anzahl der vom Treiber verwendeten Kerne. | 
| -- total-executor-cores ZAHL | Gesamtzahl der Kerne für alle Ausführer. | 
| --executor-cores NUM | Anzahl der von jedem Ausführer verwendeten Kerne. | 
| --num-executors NUM | Anzahl der zu startenden Ausführer. | 
| -hivevar <key=value> | Variablenersetzung zur Anwendung auf Hive-Befehle, zum Beispiel -hivevar A=B | 
| -hiveconf <property=value> | Wert, der für die angegebene Eigenschaft verwendet werden soll. | 

Erstellen Sie für einen Spark-SQL-Job eine start-job-run-request .json-Datei und geben Sie die erforderlichen Parameter für Ihre Jobausführung an, wie im folgenden Beispiel:

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

# Status von Aufgabenausführungen
<a name="emr-eks-jobs-states"></a>

Wenn Sie eine Aufgabe an eine Aufgabenwarteschlange von Amazon EMR in EKS übergeben, geht die Aufgabe in den `PENDING`-Status über. Danach durchläuft er die folgenden Zustände, bis er erfolgreich ist (Abschluss mit Code `0`) oder fehlschlägt (Abschluss mit einem Code ungleich null). 

Aufträge können die folgenden Status haben:
+ `PENDING` – Der anfängliche Aufgabenstatus, wenn die Aufgabenausführung an Amazon EMR in EKS übermittelt wird. Der Auftrag wartet darauf, an den virtuellen Cluster übermittelt zu werden, und Amazon EMR in EKS arbeitet daran, diesen Auftrag zu senden.
+ `SUBMITTED` – Eine Aufgabenausführung, die erfolgreich an den virtuellen Cluster übermittelt wurde. Der Cluster-Scheduler versucht dann, diesen Auftrag auf dem Cluster auszuführen.
+ `RUNNING` – Ein Auftrag, der im virtuellen Cluster ausgeführt wird. In Spark-Anwendungen bedeutet dies, dass sich der Spark-Treiberprozess im `running`-Status befindet.
+ `FAILED` – Eine Aufgabenausführung, die nicht an den virtuellen Cluster übermittelt werden konnte oder die erfolglos abgeschlossen wurde. Weitere Informationen StateDetails FailureReason zu diesem Auftragsfehler finden Sie unter und.
+ `COMPLETED` – Eine Aufgabenausführung, die erfolgreich abgeschlossen wurde.
+ `CANCEL_PENDING` – Ein Auftragslauf wurde zur Stornierung angefordert. Amazon EMR in EKS versucht, den Auftrag auf dem virtuellen Cluster abzubrechen.
+ `CANCELLED` – Eine Aufgabenausführung, die erfolgreich abgebrochen wurde.

# Aufträge in der Amazon-EMR-Konsole anzeigen
<a name="emr-eks-jobs-console"></a>

Die Daten zur Auftragsausführung können angezeigt werden, sodass Sie jeden Job überwachen können, während er die einzelnen Status durchläuft. Gehen Sie wie folgt vor, um Aufträge in der Amazon-EMR-Konsole anzuzeigen.

1. Wählen Sie im linken Menü der Amazon-EMR-Konsole unter Amazon EMR in EKS die Option **Virtuelle Cluster** aus.

1. Wählen Sie in der Liste der virtuellen Cluster den virtuellen Cluster aus, für den Sie die Aufträge anzeigen möchten.

1. Wählen Sie in der Tabelle **Aufgabenausführungen** die Option **Protokolle anzeigen** aus, um die Details einer Aufgabenausführung anzuzeigen.

**Anmerkung**  
Die Support für das Ein-Klick-Erlebnis ist standardmäßig aktiviert. Sie kann deaktiviert werden, indem `persistentAppUI` während der Aufgabenübermittlung in `DISABLED` auf `monitoringConfiguration` gesetzt wird. Weitere Informationen finden Sie unter [Anzeigen von persistenten Anwendungsbenutzeroberflächen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html).

# Häufige Fehler beim Ausführen von Aufträgen
<a name="emr-eks-jobs-error"></a>

Beim Ausführen der `StartJobRun`-API können folgende Fehler auftreten. In der Tabelle sind die einzelnen Fehler aufgeführt und es werden Schritte zur Problembehebung aufgeführt, sodass Sie Probleme schnell beheben können.


| Fehlermeldung | Fehlerbedingung | Empfohlene nächste Schritte | 
| --- | --- | --- | 
|  Fehler: Argument -- *argument* ist erforderlich  | Erforderliche Parameter fehlen. | Fügen Sie der API-Anfrage die fehlenden Argumente hinzu. | 
| Beim Aufrufen der StartJobRun Operation ist ein Fehler aufgetreten (AccessDeniedException): User: ARN is not authorized to perform: emr-containers: StartJobRun | Die Ausführungsrolle fehlt. | Siehe Verwenden von [Auftragausführungsrollen mit Amazon EMR in EKS verwenden](iam-execution-role.md).  | 
|  Beim Aufrufen der StartJobRun Operation ist ein Fehler aufgetreten (AccessDeniedException): User: *ARN* is not authorized to perform: emr-containers: StartJobRun  |  Der Aufrufer hat keine Zugriffsrechte für die Ausführungsrolle [gültiges/nicht gültiges Format] über Bedingungsschlüssel.  | Siehe [Auftragausführungsrollen mit Amazon EMR in EKS verwenden](iam-execution-role.md).  | 
|  Beim Aufrufen der StartJobRun Operation ist ein Fehler aufgetreten (AccessDeniedException): User: *ARN* is not authorized to perform: emr-containers: StartJobRun  |  Der ARN für den Auftragsabsender und die Ausführungsrolle stammen von unterschiedlichen Konten.  | Stellen Sie sicher, dass der Auftragsabsender und der ARN für die Ausführungsrolle aus demselben AWS -Konto stammen. | 
|  1 Validierungsfehler erkannt: Der Wert *Role* bei 'executionRoleArn' konnte das ARN-Muster für reguläre Ausdrücke nicht erfüllen: ^arn :( aws [a-Za-Z0-9-] \$1) :iam: :(\$1 d \$112\$1)? : (Rolle ((\$1 u002F) \$1 (\$1 u002F [\$1 u0021-\$1 u007F] \$1\$1 u002F)) [\$1 w\$1=, .@-] \$1)  |  Der Aufrufer hat über Bedingungsschlüssel Berechtigungen für die Ausführungsrolle, aber die Rolle erfüllt nicht die Einschränkungen des ARN-Formats.  | Geben Sie die Ausführungsrolle im ARN-Format an. Siehe [Auftragausführungsrollen mit Amazon EMR in EKS verwenden](iam-execution-role.md).  | 
|  Beim ResourceNotFoundException Aufrufen des StartJobRun Vorgangs *Virtual Cluster ID* ist ein Fehler aufgetreten (): Virtueller Cluster existiert nicht.  |  Die virtuelle Cluster-ID wurde nicht gefunden.  | Geben Sie eine virtuelle Cluster-ID an, die bei Amazon EMR in EKS registriert ist. | 
|  Beim Aufrufen des StartJobRun Vorgangs ist ein Fehler aufgetreten (ValidationException): Der Status des virtuellen Clusters *state* ist nicht gültig, um eine Ressource zu erstellen JobRun.  |  Der virtuelle Cluster ist nicht bereit, den Auftrag auszuführen.  | Siehe [Status des virtuellen Clusters](virtual-cluster.md#virtual-cluster-states).  | 
|  Beim Aufrufen des StartJobRun Vorgangs ist ein Fehler aufgetreten (ResourceNotFoundException): Release *RELEASE* existiert nicht.  |  Die in der Auftragsübermittlung angegebene Version ist falsch.  | Siehe [Versionen von Amazon EMR in EKS](emr-eks-releases.md).  | 
|  Beim Aufrufen der StartJobRun Operation ist ein Fehler aufgetreten (AccessDeniedException): User: *ARN* is not authorized to perform: emr-containers: StartJobRun on resource: *ARN* with a explicit deny. Beim Aufrufen der StartJobRun Operation ist ein Fehler aufgetreten (AccessDeniedException): User: *ARN* is not authorized to perform: emr-containers: on resource: StartJobRun *ARN*  | Der Benutzer ist nicht zum Anrufen berechtigt. StartJobRun | Siehe [Auftragausführungsrollen mit Amazon EMR in EKS verwenden](iam-execution-role.md).  | 
|  Beim Aufrufen des StartJobRun Vorgangs ist ein Fehler aufgetreten (ValidationException): ConfigurationOverrides.MonitoringConfiguration.s3 MonitoringConfiguration .logURI konnte die Einschränkung nicht erfüllen: %s  |  Die S3-Pfad-URI-Syntax ist nicht gültig.  | logUri sollte das Format s3://… haben  | 

Die folgenden Fehler können auftreten, wenn Sie die `DescribeJobRun`-API ausführen, bevor der Auftrag ausgeführt wird.


| Fehlermeldung | Fehlerbedingung | Empfohlene nächste Schritte | 
| --- | --- | --- | 
|   JobRun StateDetails: Die Übermittlung ist fehlgeschlagen.  Die Klassifizierung *classification* wird nicht unterstützt. failureReason: VALIDATION\$1ERROR state: FAILED.  | Die Parameter in StartJobRun sind nicht gültig. | Siehe [Versionen von Amazon EMR in EKS](emr-eks-releases.md).  | 
|  Statusdetails: Der Cluster ist *EKS Cluster ID* nicht vorhanden. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  | Der EKS-Cluster ist nicht verfügbar. | Überprüfen Sie, ob der EKS-Cluster existiert und über die richtigen Berechtigungen verfügt. Weitere Informationen finden Sie unter [Einrichten von Amazon EMR in EKS](setting-up.md). | 
|  StateDetails: Der Cluster *EKS Cluster ID* verfügt nicht über ausreichende Berechtigungen. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  |  Amazon EMR verfügt nicht über Berechtigungen für den Zugriff auf den EKS-Cluster.  | Stellen Sie sicher, dass die Berechtigungen für Amazon EMR für den registrierten Namespace eingerichtet sind. Weitere Informationen finden Sie unter [Einrichten von Amazon EMR in EKS](setting-up.md). | 
|  Statusdetails: Der Cluster ist derzeit nicht erreichbar. *EKS Cluster ID* failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  |  Der EKS-Cluster ist nicht erreichbar.  | Überprüfen Sie, ob der EKS-Cluster existiert und über die richtigen Berechtigungen verfügt. Weitere Informationen finden Sie unter [Einrichten von Amazon EMR in EKS](setting-up.md). | 
|  StateDetails: Die JobRun Übermittlung ist aufgrund eines internen Fehlers fehlgeschlagen. failureReason: INTERNAL\$1ERROR state: FAILED  |  Es ist ein interner Fehler im EKS-Cluster aufgetreten.  | – | 
|  Statusdetails: Der Cluster *EKS Cluster ID* verfügt nicht über ausreichende Ressourcen. failureReason: USER\$1ERROR state: FAILED  |  Im EKS-Cluster sind nicht genügend Ressourcen vorhanden, um den Auftrag auszuführen.  | Fügen Sie der EKS-Knotengruppe mehr Kapazität hinzu oder richten Sie EKS Autoscaler ein. Weitere Informationen finden Sie unter [Cluster-Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html). | 

Die folgenden Fehler können auftreten, wenn Sie die `DescribeJobRun`-API ausführen, nachdem der Auftrag ausgeführt wurde.


| Fehlermeldung | Fehlerbedingung | Empfohlene nächste Schritte | 
| --- | --- | --- | 
|  StateDetails: Probleme bei der Überwachung Ihres. JobRun  Der Cluster ist *EKS Cluster ID* nicht vorhanden. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  | Der EKS-Cluster ist nicht vorhanden. | Überprüfen Sie, ob der EKS-Cluster existiert und über die richtigen Berechtigungen verfügt. Weitere Informationen finden Sie unter [Einrichten von Amazon EMR in EKS](setting-up.md). | 
|  Statusdetails: Probleme bei der Überwachung Ihres. JobRun *EKS Cluster ID*Der Cluster verfügt nicht über ausreichende Berechtigungen. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  | Amazon EMR verfügt nicht über Berechtigungen für den Zugriff auf den EKS-Cluster. | Stellen Sie sicher, dass die Berechtigungen für Amazon EMR für den registrierten Namespace eingerichtet sind. Weitere Informationen finden Sie unter [Einrichten von Amazon EMR in EKS](setting-up.md). | 
|  Statusdetails: Probleme bei der Überwachung Ihres. JobRun *EKS Cluster ID*Der Cluster ist derzeit nicht erreichbar. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED  |  Der EKS-Cluster ist nicht erreichbar.  | Überprüfen Sie, ob der EKS-Cluster existiert und über die richtigen Berechtigungen verfügt. Weitere Informationen finden Sie unter [Einrichten von Amazon EMR in EKS](setting-up.md). | 
|  StateDetails: JobRun Aufgrund eines internen Fehlers ist bei der Überwachung Ihres Computers ein Fehler aufgetreten failureReason: INTERNAL\$1ERROR state: FAILED  |  Ein interner Fehler ist aufgetreten und verhindert die Überwachung. JobRun   | – | 

Der folgende Fehler kann auftreten, wenn ein Auftrag nicht gestartet werden kann und der Auftrag 15 Minuten im Status SUBMITTED wartet. Die Ursache können fehlende Clusterressourcen sein.


| Fehlermeldung | Fehlerbedingung | Empfohlene nächste Schritte | 
| --- | --- | --- | 
|  Cluster-Timeout  | Der Auftrag befindet sich seit mindestens 15 Minuten im Status SUBMITTED. | Sie können die Standardeinstellung von 15 Minuten für diesen Parameter mit der unten gezeigten Konfigurationsüberschreibung überschreiben.  | 

Verwenden Sie die folgende Konfiguration, um die Einstellung für das Cluster-Timeout auf 30 Minuten zu ändern. Beachten Sie, dass Sie den neuen `job-start-timeout`-Wert in Sekunden angeben:

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

# Verwenden von Aufgabenvorlagen
<a name="job-templates"></a>

In einer Auftragvorlage werden Werte gespeichert, die beim Starten eines Auftraglaufs von allen `StartJobRun`-API-Aufrufen gemeinsam genutzt werden können. Sie unterstützt zwei Anwendungsfälle:
+ Um zu verhindern, dass sich wiederholende `StartJobRun`-API-Anforderungswerte auftreten.
+ Um eine Regel durchzusetzen, nach der bestimmte Werte über `StartJobRun`-API-Anfragen bereitgestellt werden müssen.

Auftrag Auftragvorlagen können Sie eine wiederverwendbare Vorlage für Auftragläufe definieren, um zusätzliche Anpassungen vorzunehmen, zum Beispiel:
+ Konfigurieren der Rechenkapazität für Executor und Treiber
+ Einstellen von Sicherheits- und Governance-Eigenschaften wie IAM-Rollen
+ Anpassen eines Docker-Images für die Verwendung in mehreren Anwendungen und Daten-Pipelines

Die folgenden Themen enthalten detaillierte Informationen zur Verwendung von Vorlagen, einschließlich der Verwendung dieser Vorlagen zum Starten einer Auftragsausführung und zum Ändern von Vorlagenparametern.

**Topics**
+ [Eine Auftragsvorlage erstellen und verwenden, um eine Auftragsausführung zu starten](create-job-template.md)
+ [Definieren von Aufgabenvorlagenparametern](use-job-template-parameters.md)
+ [Steuern des Zugriffs auf Aufgabenvorlagen](iam-job-template.md)

# Eine Auftragsvorlage erstellen und verwenden, um eine Auftragsausführung zu starten
<a name="create-job-template"></a>

In diesem Abschnitt wird beschrieben, wie Sie eine Jobvorlage erstellen und die Vorlage verwenden, um eine Jobausführung mit dem AWS Command Line Interface (AWS CLI) zu starten.

**So erstellen Sie eine neue Aufgabenvorlage**

1. Erstellen Sie eine `create-job-template-request.json`-Datei und geben Sie die erforderlichen Parameter für Ihre Aufgabenvorlage an, wie in der folgenden JSON-Beispieldatei gezeigt. Informationen zu allen verfügbaren Parametern finden Sie in der [CreateJobTemplate](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/Welcome.html)API.

   Die meisten Werte, die für die `StartJobRun`-API erforderlich sind, sind auch für `jobTemplateData` erforderlich. Wenn Sie Platzhalter für Parameter verwenden und Werte angeben möchten, wenn Sie StartJobRun mit einer Jobvorlage aufrufen, lesen Sie bitte den nächsten Abschnitt über Jobvorlagenparameter.

   ```
   {
      "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. Verwenden Sie den `create-job-template`-Befehl mit einem Pfad zu der lokal gespeicherten `create-job-template-request.json`-Datei.

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

**So starten Sie eine Auftragsausführung mit einer Auftragsvorlage**

Geben Sie die virtuelle Cluster-ID, die Aufgabenvorlagen-ID und den Aufgabennamen im `StartJobRun`-Befehl an, wie im folgenden Beispiel veranschaulicht.

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

# Definieren von Aufgabenvorlagenparametern
<a name="use-job-template-parameters"></a>

Mit Auftragvorlagenparametern können Sie Variablen in der Auftragvorlage angeben. Werte für diese Parametervariablen müssen angegeben werden, wenn eine Aufgabenausführung mit dieser Aufgabenvorlage gestartet wird. Auftragsvorlagenparameter werden im `${parameterName}`-Format angegeben. Sie können einen beliebigen Wert in einem `jobTemplateData`-Feld als Aufgabenvorlagenparameter angeben. Geben Sie für jede der Parametervariablen der Aufgabenvorlage ihren Datentyp (`STRING` oder `NUMBER`) und optional einen Standardwert an. Das folgende Beispiel zeigt, wie Sie Aufgabenvorlagenparameter für Einstiegspunktposition, Hauptklasse und S3-Protokollspeicherort angeben können.

**Um den Standort des Einstiegspunkts, die Hauptklasse und den Speicherort des Amazon-S3-Protokolls als Parameter für die Aufgabenvorlage anzugeben**

1. Erstellen Sie eine `create-job-template-request.json`-Datei und geben Sie die erforderlichen Parameter für Ihre Aufgabenvorlage an, wie in der folgenden JSON-Beispieldatei gezeigt. Weitere Informationen zu den Parametern finden Sie in der [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. Verwenden Sie den `create-job-template`-Befehl mit einem Pfad zu der lokal gespeicherten `create-job-template-request.json`-Datei in Amazon S3.

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

**Um eine Aufgabe zu starten, verwenden Sie eine Aufgabenvorlage mit Aufgabenvorlagenparametern**

Um eine Aufgabenausführung mit einer Aufgabenvorlage zu starten, die Aufgabenvorlagenparameter enthält, geben Sie die Aufgabenvorlagen-ID sowie Werte für die Aufgabenvorlagenparameter in der `StartJobRun`-API-Anfrage an, wie unten gezeigt.

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

# Steuern des Zugriffs auf Aufgabenvorlagen
<a name="iam-job-template"></a>

Mit der `StartJobRun`-Richtlinie können Sie erzwingen, dass ein Benutzer oder eine Rolle nur Aufträge mit von Ihnen angegebenen Aufgabenvorlagen ausführen kann und keine `StartJobRun`-Operationen ausführen kann, ohne die angegebenen Aufgabenvorlagen zu verwenden. Um dies zu erreichen, stellen Sie zunächst sicher, dass Sie dem Benutzer oder der Rolle eine Leseberechtigung für die angegebenen Aufgabenvorlagen erteilen, wie unten dargestellt.

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

------

Um sicherzustellen, dass ein Benutzer oder eine Rolle nur dann einen `StartJobRun`-Vorgang aufrufen kann, wenn er bestimmte Aufgabenvorlagen verwendet, können Sie einem bestimmten Benutzer oder einer bestimmten Rolle die folgende `StartJobRun`-Richtlinienberechtigung zuweisen.

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

------

Wenn die Aufgabenvorlage einen Aufgabenvorlagenparameter innerhalb des ARN-Felds der Ausführungsrolle angibt, kann der Benutzer einen Wert für diesen Parameter angeben und somit `StartJobRun` mit einer beliebigen Ausführungsrolle aufrufen. Informationen zur Einschränkung der Ausführungsrollen, die der Benutzer bereitstellen kann, finden Sie unter **Steuern des Zugriffs auf die Ausführungsrolle** in [Auftragausführungsrollen mit Amazon EMR in EKS verwenden](iam-execution-role.md). 

Wenn in der obigen `StartJobRun`-Aktionsrichtlinie für einen bestimmten Benutzer oder eine Rolle keine Bedingung angegeben ist, darf der Benutzer oder die Rolle mithilfe einer beliebigen Aufgabenvorlage, auf die er Lesezugriff hat, oder mithilfe einer beliebigen Ausführungsrolle `StartJobRun`-Aktionen auf dem angegebenen virtuellen Cluster aufrufen.

# Verwenden von Pod-Vorlagen
<a name="pod-templates"></a>

Ab den Amazon-EMR-Versionen 5.33.0 oder 6.3.0 unterstützt Amazon EMR in EKS das Pod-Vorlagenfeature von Spark. Ein Pod ist eine Gruppe von einem oder mehreren Containern mit gemeinsam genutzten Speicher- und Netzwerkressourcen und einer Spezifikation für die Ausführung der Container. Pod-Vorlagen sind Spezifikationen, die bestimmen, wie jeder Pod ausgeführt wird. Sie können Pod-Vorlagendateien verwenden, um die Treiber- oder Executor-Pod-Konfigurationen zu definieren, die Spark-Konfigurationen nicht unterstützen. Weitere Informationen zum Pod-Vorlagenfeature von Spark finden Sie unter [Pod-Vorlage](https://spark.apache.org/docs/latest/running-on-kubernetes.html#pod-template). 

**Anmerkung**  
Das Pod-Vorlagenfeature funktioniert nur mit Treiber- und Executor-Pods. Sie können Pods für Stellenabsender nicht mithilfe der Pod-Vorlage konfigurieren.

## Gängige Szenarien
<a name="pod-template-use-cases"></a>

Sie können definieren, wie Spark-Aufträge auf gemeinsam genutzten EKS-Clustern ausgeführt werden, indem Sie Pod-Vorlagen mit Amazon EMR in EKS verwenden. So können Sie Kosten sparen und die Ressourcennutzung und Leistung verbessern.
+ Um die Kosten zu senken, können Sie Spark-Treiberaufgaben so planen, dass sie auf Amazon EC2 On-Demand-Instances ausgeführt werden, und gleichzeitig Spark-Executor-Aufgaben für die Ausführung auf Amazon EC2 Spot-Instances planen. 
+ Um die Ressourcennutzung zu erhöhen, können Sie mehrere Teams dabei unterstützen, ihre Workloads auf demselben EKS-Cluster auszuführen. Jedes Team erhält eine bestimmte EC2 Amazon-Knotengruppe, auf der es seine Workloads ausführen kann. Sie können Pod-Vorlagen verwenden, um eine entsprechende Toleranz auf ihren Workload anzuwenden. 
+ Um die Überwachung zu verbessern, können Sie einen separaten Protokollierungs-Container ausführen, um Protokolle an Ihre bestehende Überwachungsanwendung weiterzuleiten. 

Die folgende Pod-Vorlagendatei veranschaulicht beispielsweise ein gängiges Nutzungsszenario. 

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

Die Pod-Vorlage führt die folgenden Aufgaben aus:
+ Fügen Sie einen neuen [Init-Container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) hinzu, der ausgeführt wird, bevor der Spark-Hauptcontainer gestartet wird. Der Init-Container teilt sich das aufgerufene [EmptyDirVolume](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) `source-data-volume` mit dem Spark-Hauptcontainer. Sie können Ihren Init-Container Initialisierungsschritte wie das Herunterladen von Abhängigkeiten oder das Generieren von Eingabedaten ausführen lassen. Dann verbraucht der Spark-Hauptcontainer die Daten.
+ Fügen Sie einen weiteren [Sidecar-Container](https://kubernetes.io/docs/concepts/workloads/pods/#how-pods-manage-multiple-containers) hinzu, der zusammen mit dem Spark-Hauptcontainer ausgeführt wird. Die beiden Container teilen sich ein weiteres `EmptyDir`-Volume namens `metrics-files-volume`. Ihr Spark-Auftrag kann Metriken wie Prometheus-Metriken generieren. Dann kann der Spark-Auftrag die Metriken in eine Datei schreiben und den Sidecar-Container die Dateien zur zukünfigen Analyse in Ihr eigenes BI-System hochladen lassen.
+ Fügen Sie dem Spark-Hauptcontainer eine neue Umgebungsvariable hinzu. Sie können festlegen, dass Ihr Auftrag die Umgebungsvariable verwendet.
+ Definieren Sie eine [Knotenauswahl](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/), sodass der Pod nur für die `emr-containers-nodegroup`-Knotengruppe geplant ist. Dies hilft dabei, Rechenressourcen für verschiedene Aufträge und Teams zu isolieren.

## Aktivieren von Pod-Vorlagen mit Amazon EMR in EKS
<a name="use-pod-templates"></a>

Um das Pod-Vorlagenfeature mit Amazon EMR in EKS zu aktivieren, konfigurieren Sie die Spark-Eigenschaften `spark.kubernetes.driver.podTemplateFile` und `spark.kubernetes.executor.podTemplateFile` verweisen Sie auf die Pod-Vorlagendateien in Amazon S3. Spark lädt dann die Pod-Vorlagendatei herunter und verwendet sie, um Treiber- und Executor-Pods zu erstellen.

**Anmerkung**  
Spark verwendet die Auftragausführungsrolle, um die Pod-Vorlage zu laden, sodass die Auftragausführungsrolle über Zugriffsberechtigungen für Amazon S3 verfügen muss, um die Pod-Vorlagen zu laden. Weitere Informationen finden Sie unter [Erstellen einer Aufgabenausführungsrolle](creating-job-execution-role.md).

Sie können `SparkSubmitParameters` verwenden, um den Amazon-S3-Pfad zur Pod-Vorlage anzugeben, wie die folgende JSON-Datei mit der Auftragausführung zeigt.

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

Alternativ können Sie den `configurationOverrides` verwenden, um den Amazon-S3-Pfad zur Pod-Vorlage anzugeben, wie die folgende JSON-Datei mit der Auftragausführung zeigt.

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

**Anmerkung**  
Sie müssen die Sicherheitsrichtlinien befolgen, wenn Sie das Pod-Vorlagenfeature mit Amazon EMR in EKS verwenden, z. B. das Isolieren von nicht vertrauenswürdigem Anwendungscode. Weitere Informationen finden Sie unter [Bewährte Methoden für Sicherheit in Amazon EMR in EKS](security-best-practices.md).
Sie können die Namen der Spark-Hauptcontainer nicht mit `spark.kubernetes.driver.podTemplateContainerName` und `spark.kubernetes.executor.podTemplateContainerName` ändern, da diese Namen als `spark-kubernetes-driver` und `spark-kubernetes-executors` fest codiert sind. Wenn Sie den Spark-Hauptcontainer anpassen möchten, müssen Sie den Container in einer Pod-Vorlage mit diesen hartcodierten Namen angeben.

## Pod-Vorlagenfelder
<a name="pod-templates-fields"></a>

Beachten Sie die folgenden Feldeinschränkungen, wenn Sie eine Pod-Vorlage mit Amazon EMR in EKS konfigurieren.
+ Amazon EMR in EKS erlaubt nur die folgenden Felder in einer Pod-Vorlage, um eine korrekte Aufgabenplanung zu ermöglichen.

  Dies sind die zulässigen Felder auf Pod-Ebene:
  + `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`

  Dies sind die zulässigen Felder auf Spark-Hauptcontainerebene:
  + `env`
  + `envFrom`
  + `name`
  + `lifecycle`
  + `livenessProbe`
  + `readinessProbe`
  + `resources`
  + `startupProbe`
  + `stdin`
  + `stdinOnce`
  + `terminationMessagePath`
  + `terminationMessagePolicy`
  + `tty`
  + `volumeDevices`
  + `volumeMounts`
  + `workingDir`

  Wenn Sie unzulässige Felder in der Pod-Vorlage verwenden, löst Spark eine Ausnahme aus und der Auftrag schlägt fehl. Das folgende Beispiel zeigt eine Fehlermeldung im Spark-Controller-Protokoll, die auf unzulässige Felder zurückzuführen ist. 

  ```
  Executor pod template validation failed.
  Field container.command in Spark main container not allowed but specified.
  ```
+  Amazon EMR in EKS definiert die folgenden Parameter in einer Pod-Vorlage vordefiniert. Die Felder, die Sie in einer Pod-Vorlage angeben, dürfen sich nicht mit diesen Feldern überschneiden. 

  Dies sind die vordefinierten Volume-Namen:
  + `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`

  Dies sind die vordefinierten Volume-Mounts, die nur für den Spark-Hauptcontainer gelten:
  + Name:`emr-container-communicate`; MountPath: `/var/log/fluentd`
  + Name:`emr-container-application-log-dir`; MountPath: `/var/log/spark/user`
  + Name:`emr-container-event-log-dir`; MountPath: `/var/log/spark/apps`
  + Name:`mnt-dir`; MountPath: `/mnt`
  + Name:`temp-data-dir`; MountPath: `/tmp`
  + Name:`home-dir`; MountPath: `/home/hadoop`

  Dies sind die vordefinierten Umgebungsvariablen, die nur für den Spark-Hauptcontainer gelten:
  + `SPARK_CONTAINER_ID`
  + `K8S_SPARK_LOG_URL_STDERR`
  + `K8S_SPARK_LOG_URL_STDOUT`
  + `SIDECAR_SIGNAL_FILE`
**Anmerkung**  
Sie können diese vordefinierten Volumes weiterhin verwenden und sie in Ihre zusätzlichen Sidecar-Container einbinden. Sie können beispielsweise `emr-container-application-log-dir` verwenden und in Ihrem eigenen Sidecar-Container bereitstellen, der in der Pod-Vorlage definiert ist.

  Wenn die von Ihnen angegebenen Felder mit einem der vordefinierten Felder in der Pod-Vorlage in Konflikt stehen, löst Spark eine Ausnahme aus und der Auftrag schlägt fehl. Das folgende Beispiel zeigt eine Fehlermeldung im Spark-Anwendungsprotokoll aufgrund von Konflikten mit den vordefinierten Feldern. 

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

## Überlegungen zu Sidecarcontainern
<a name="pod-template-sidecar"></a>

Amazon EMR steuert den Lebenszyklus der Pods, die von Amazon EMR in EKS bereitgestellt werden. Die Sidecar-Container sollten dem gleichen Lebenszyklus folgen wie der Spark-Hauptcontainer. Wenn Sie zusätzliche Sidecar-Container in Ihre Pods einbauen, empfehlen wir Ihnen, das Pod-Lifecycle-Management, das Amazon EMR definiert, zu integrieren, sodass sich der Sidecar-Container selbst stoppen kann, wenn der Spark-Hauptcontainer verlassen wird.

Um die Kosten zu senken, empfehlen wir Ihnen, einen Prozess zu implementieren, der verhindert, dass Treiber-Pods mit Sidecar-Containern nach Abschluss Ihres Aufträge weiter ausgeführt werden. Der Spark-Treiber löscht Ausführer-Pods, wenn der Ausführer fertig ist. Wenn ein Treiberprogramm abgeschlossen ist, werden die zusätzlichen Sidecar-Container jedoch weiter ausgeführt. Der Pod wird in Rechnung gestellt, bis Amazon EMR in EKS den Treiber-Pod bereinigt hat, normalerweise weniger als eine Minute, nachdem der Treiber-Spark-Hauptcontainer abgeschlossen ist. Um die Kosten zu senken, können Sie Ihre zusätzlichen Sidecar-Container in den Lebenszyklus-Management-Mechanismus integrieren, den Amazon EMR in EKS sowohl für Treiber- als auch für Ausführer-Pods definiert, wie im folgenden Abschnitt beschrieben.

Der Spark-Hauptcontainer in den Treiber- und Ausführer-Pods sendet `heartbeat` alle zwei Sekunden an eine `/var/log/fluentd/main-container-terminated`-Datei. Indem Sie den vordefinierten `emr-container-communicate`-Amazon-EMR-Volume-Mount zu Ihrem Sidecar-Container hinzufügen, können Sie einen Unterprozess Ihres Sidecar-Containers definieren, der regelmäßig den Zeitpunkt der letzten Änderung für diese Datei verfolgt. Der Unterprozess stoppt sich dann selbst, wenn er feststellt, dass der Spark-Hauptcontainer den `heartbeat` für einen längeren Zeitraum stoppt. 

Das folgende Beispiel zeigt einen Unterprozess, der die Heartbeat-Datei verfolgt und sich selbst stoppt. *your\$1volume\$1mount*Ersetzen Sie es durch den Pfad, in dem Sie das vordefinierte Volume mounten. Das Skript ist in dem Image gebündelt, das vom Sidecar-Container verwendet wird. In einer Pod-Vorlagendatei können Sie einen Sidecar-Container mit den folgenden Befehlen `sub_process_script.sh` und `main_command` angeben.

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

# Verwenden von Richtlinien für die Wiederholung von Aufträgen
<a name="jobruns-using-retry-policies"></a>

In Amazon EMR in EKS-Versionen 6.9.0 und höher können Sie eine Wiederholungsrichtlinie für Ihre Aufgabenausführungen festlegen. Richtlinien für Wiederholungen bewirken, dass ein Auftrags-Treiber-Pod automatisch neu gestartet wird, wenn er fehlschlägt oder gelöscht wird. Dies macht Spark-Streaming-Aufträge mit langer Laufzeit widerstandsfähiger gegenüber Ausfällen.

## Festlegen einer Wiederholungsrichtlinie für einen Auftrag
<a name="setting-retry-policy"></a>

Um eine Wiederholungsrichtlinie zu konfigurieren, stellen Sie mithilfe der [StartJobRun](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_StartJobRun.html)API ein `RetryPolicyConfiguration` Feld bereit. Eine Beispiel-`retryPolicyConfiguration` wird hier gezeigt:

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

**Anmerkung**  
`retryPolicyConfiguration`ist erst ab Version AWS CLI 1.27.68 verfügbar. Informationen zur Aktualisierung AWS CLI auf die neueste Version finden Sie unter [Installation oder Aktualisierung der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)

Konfigurieren Sie das `maxAttempts`-Feld so, wie oft der Aufgaben-Treiber-Pod maximal neu gestartet werden soll, wenn er ausfällt oder gelöscht wird. Das Ausführungsintervall zwischen zwei Wiederholungsversuchen des Auftrag-Treibers ist ein exponentielles Wiederholungsintervall von (10 Sekunden, 20 Sekunden, 40 Sekunden …), das auf 6 Minuten begrenzt ist, wie in der [Kubernetes-Dokumentation](https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-backoff-failure-policy) beschrieben.

**Anmerkung**  
Jede weitere Ausführung des Aufgabentreibers wird als weitere Aufgabenausführung in Rechnung gestellt und unterliegt den Preisen von [Amazon EMR in EKS](https://aws.amazon.com/emr/pricing/#Amazon_EMR_on_Amazon_EKS).

### Wiederholungsrichtlinien-Konfigurationswerte
<a name="retry-config"></a>
+ **Standard-Wiederholungsrichtlinie für einen Auftrag:** `StartJobRun` beinhaltet eine Wiederholungsrichtlinie, die standardmäßig auf einen maximalen Versuch festgelegt ist. Sie können die Wiederholungs-Richtlinie wie gewünscht konfigurieren.
**Anmerkung**  
Wenn `maxAttempts` der `retryPolicyConfiguration` auf 1 gesetzt ist, bedeutet dies, dass bei einem Fehler keine erneuten Versuche unternommen werden, den Treiber-Pod aufzurufen.
+ **Wiederholungsrichtlinie für einen Job deaktivieren: Um eine** Wiederholungsrichtlinie zu deaktivieren, setzen Sie den Wert für maximale Versuche auf 1. retryPolicyConfiguration 

  ```
  "retryPolicyConfiguration": {
      "maxAttempts": 1
  }
  ```
+ **Setzen Sie maxAttempts für einen Auftrag innerhalb des gültigen Bereichs:** Der `StartJobRun`-Aufruf schlägt fehl, wenn der `maxAttempts`-Wert außerhalb des gültigen Bereichs liegt. Der gültige `maxAttempts`-Bereich liegt zwischen 1 und 2.147.483.647 (32-Bit-Ganzzahl), dem Bereich, der für die `backOffLimit`-Konfigurationseinstellung von Kubernetes unterstützt wird. Weitere Informationen finden Sie unter [Pod-Backoff-Fehlerrichtlinie](https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-backoff-failure-policy) in der Kubernetes-Dokumentation. Falls der `maxAttempts`-Wert ungültig ist, wird folgende Fehlermeldung zurückgegeben:

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

## Abrufen eines Status einer Wiederholungsrichtlinie für einen Auftrag
<a name="retrieve-policy"></a>

Sie können den Status der Wiederholungsversuche für einen Job mit dem und anzeigen. [https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_ListJobRuns.html](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_ListJobRuns.html) APIs Sobald Sie einen Auftrag mit aktivierter Konfiguration der Wiederholungsrichtlinie anfordern, enthalten die `ListJobRun`- und `DescribeJobRun`-Antworten und den Status der Wiederholungsrichtlinie im `RetryPolicyExecution`-Feld. Darüber hinaus enthält die `DescribeJobRun`-Antwort die Angaben `RetryPolicyConfiguration`, die in der `StartJobRun`-Anfrage für den Auftrag eingegeben wurden.

**Beispielantworten**

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

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

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

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

------

Diese Felder sind nicht sichtbar, wenn die Wiederholungsrichtlinie für den Auftrag deaktiviert ist, wie weiter unten in [Wiederholungsrichtlinien-Konfigurationswerte](#retry-config) beschrieben. 

## Überwachen eines Auftrags mit einer Wiederholungsrichtlinie
<a name="monitoring-retry"></a>

Wenn Sie eine Wiederholungsrichtlinie aktivieren, wird für jeden erstellten Jobtreiber ein CloudWatch Ereignis generiert. Um diese Ereignisse zu abonnieren, richten Sie mit dem folgenden Befehl eine CloudWatch Ereignisregel ein:

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

Das Ereignis gibt Informationen zu den Auftragstreibern `newDriverPodName`, `newDriverCreatedAt` dem `previousDriverFailureMessage`-Zeitstempel und den `currentAttemptCount`-Auftragstreibern zurück. Diese Ereignisse werden nicht erzeugt, wenn die Wiederholungsrichtlinie deaktiviert ist.

Weitere Informationen darüber, wie Sie Ihren Job mithilfe von CloudWatch Ereignissen überwachen können, finden Sie unter[Überwachen Sie Jobs mit Amazon CloudWatch Events](monitoring.md#monitoring-cloudwatch-events).

## Suchen nach Protokollen für Treiber und Ausführer
<a name="finding-logs"></a>

Die Namen der Treiber-Pods folgen dem Format `spark-<job id>-driver-<random-suffix>`. Dasselbe `random-suffix` wird zu den Namen der Ausführer-Pods hinzugefügt, die der Treiber erzeugt. Wenn Sie `random-suffix` verwenden, können Sie Protokolle für einen Treiber und die zugehörigen Ausführer finden. Der `random-suffix` ist nur vorhanden, wenn die [Wiederholungsrichtlinie für den Auftrag aktiviert ist](#retry-config); andernfalls fehlt `random-suffix`.

Weitere Informationen zur Konfiguration von Aufträgen mit Überwachungskonfiguration für die Protokollierung finden Sie unter [Eine Spark-Anwendung ausführen](getting-started.md#getting-started-run-spark-app).

# Verwenden der Rotation des Spark-Ereignisprotokolls
<a name="emr-eks-log-rotation"></a>

Mit Amazon EMR 6.3.0 und höher können Sie das Feature zur Rotation des Spark-Ereignisprotokolls für Amazon EMR in EKS aktivieren. Anstatt eine einzelne Ereignisprotokolldatei zu generieren, rotiert dieses Feature die Datei auf der Grundlage Ihres konfigurierten Zeitintervalls und entfernt die ältesten Ereignisprotokolldateien.

Durch das Rotieren von Spark-Ereignisprotokollen können Sie potenzielle Probleme mit einer großen Spark-Ereignisprotokolldatei vermeiden, die für Aufträge mit langer Laufzeit oder Streaming-Aufträge generiert wird. Sie starten beispielsweise einen Spark-Auftrag mit langer Laufzeit und einem mit dem `persistentAppUI`-Parameter aktivierten Ereignisprotokoll. Der Spark-Treiber generiert eine Ereignisprotokolldatei. Wenn der Auftrag stunden- oder tagelang ausgeführt wird und der Speicherplatz auf dem Kubernetes-Knoten begrenzt ist, kann die Ereignisprotokolldatei den gesamten verfügbaren Speicherplatz beanspruchen. Das Aktivieren des Spark-Features zur Rotation des Ereignisprotokolls löst das Problem, indem die Protokolldatei in mehrere Dateien aufgeteilt und die ältesten Dateien entfernt werden.

**Anmerkung**  
Dieses Feature funktioniert nur mit Amazon EMR in EKS. Amazon EMR, das auf Amazon ausgeführt wird, unterstützt die Rotation des Spark-Ereignisprotokolls EC2 nicht.

Um das Feature zur Rotation des Spark-Ereignisprotokolls zu aktivieren, konfigurieren Sie die folgenden Spark-Parameter:
+ `spark.eventLog.rotation.enabled` – aktiviert die Protokoll-Rotation. Standardmäßig ist die Rückverfolgungsverwaltung in der Spark-Konfigurationsdatei deaktiviert. Stellen Sie diese auf true ein, um dieses Feature zu aktivieren. 
+ `spark.eventLog.rotation.interval` – gibt das Zeitintervall für die Protokollrotation an. Der Mindestwert beträgt 60 Sekunden. Der Standardwert beträgt 300 Sekunden. 
+ `spark.eventLog.rotation.minFileSize` – gibt eine Mindestdateigröße für die Rotation der Protokolldatei an. Der Mindest- und Standardwert beträgt 1 MB. 
+ `spark.eventLog.rotation.maxFilesToRetain` – gibt an, wie viele rotierte Protokolldateien während der Bereinigung beibehalten werden sollen. Der gültige Bereich ist 1 bis 10. Der Standardwert lautet 2. 

Sie können diese Parameter im `sparkSubmitParameters`-Abschnitt der [`StartJobRun`](emr-eks-jobs-submit.md)-API angeben, wie das folgende Beispiel zeigt.

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

# Verwenden der Spark-Container-Protokoll-Rotation
<a name="emr-eks-log-rotation-container"></a>

Mit Amazon EMR 6.11.0 und höher können Sie das Spark-Container-Protokoll-Rotationsfeature unktion für Amazon EMR in EKS aktivieren. Anstatt eine einzelne `stdout`- oder `stderr`-Protokolldatei zu generieren, rotiert dieses Feature die Datei auf der Grundlage Ihrer konfigurierten Rotationsgröße und entfernt die ältesten Protokolldateien aus dem Container.

Durch das Rotieren von Spark-Container-Protokolle können Sie potenzielle Probleme mit großen Spark-Protokolldateien vermeiden, die für lang laufende Aufträge oder Streaming-Aufträge generiert wurden. Sie könnten beispielsweise einen Spark-Auftrag mit langer Laufzeit starten und der Spark-Treiber generiert eine Container-Protokolldatei. Wenn der Auftrag stunden- oder tagelang ausgeführt wird und der Speicherplatz auf dem Kubernetes-Knoten begrenzt ist, kann die Container-Protokolldatei den gesamten verfügbaren Festplattenspeicher beanspruchen. Wenn Sie die Spark-Container-Protokollrotation aktivieren, teilen Sie die Protokolldatei in mehrere Dateien auf und entfernen die ältesten Dateien.

Um das Feature zur Rotation von Spark-Container-Protokollen zu aktivieren, konfigurieren Sie die folgenden Spark-Parameter:

**`containerLogRotationConfiguration`**  
Fügen Sie diesen Parameter `monitoringConfiguration` hinzu, um die Protokoll-Rotation zu aktivieren. Standardmäßig ist die Rückverfolgung deaktiviert. Sie müssen `containerLogRotationConfiguration` zusätzlich zu `s3MonitoringConfiguration` verwenden.

**`rotationSize`**  
Der `rotationSize`-Parameter gibt die Dateigröße für die Protokollrotation an. Der Bereich der möglichen Werte ist von `2KB` bis `2GB`. Die numerische Einheit des `rotationSize`-Parameters wird als Ganzzahl übergeben. Da Dezimalwerte nicht unterstützt werden, können Sie mit dem Wert `1500MB` beispielsweise eine Rotationsgröße von 1,5 GB angeben.

**`maxFilesToKeep`**  
Der `maxFilesToKeep`-Parameter gibt die maximale Anzahl von Dateien an, die nach der Rotation im Container aufbewahrt werden sollen. Der kleinste Wert ist 1 und der größte Wert ist 50.

Sie können diese Parameter im `monitoringConfiguration`-Abschnitt der `StartJobRun`-API angeben, wie das folgende Beispiel zeigt. In diesem Beispiel rotiert Amazon EMR in EKS Ihre Protokolle mit `rotationSize = "10 MB"` und `maxFilesToKeep = 3` um 10 MB, generiert eine neue Protokolldatei und löscht dann die älteste Protokolldatei, sobald die Anzahl der Protokolldateien 3 erreicht.

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

Um eine Auftragsausführung mit der Spark-Container-Protokollrotation zu starten, geben Sie im Befehl einen Pfad zu der JSON-Datei an, die Sie mit diesen Parametern in [`StartJobRun`](emr-eks-jobs-submit.md) konfiguriert haben.

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

# Verwenden von vertikalem Auto Scaling mit Amazon-EMR-Spark-Aufträgen
<a name="jobruns-vas"></a>

Das vertikale Auto Scaling von Amazon EMR in EKS passt die Speicher- und CPU-Ressourcen automatisch an die Anforderungen des Workloads an, die Sie für Amazon-EMR-Spark-Anwendungen bereitstellen. Dies vereinfacht das Ressourcenmanagement.

Vertikales Auto Scaling nutzt den Kubernetes [Vertical Pod Autoscaler (VPA),](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) um die Echtzeit- und historische Ressourcennutzung Ihrer Amazon-EMR-Spark-Anwendungen zu verfolgen. Die Funktion des vertikalen Auto Scalings verwendet die von VPA gesammelten Daten, um die Speicher- und CPU-Ressourcen, die Ihren Spark-Anwendungen zugewiesen sind, automatisch zu optimieren. Dieser vereinfachte Prozess erhöht die Zuverlässigkeit und optimiert die Kosten.

**Topics**
+ [Einrichtung](jobruns-vas-setup.md)
+ [Erste Schritte](jobruns-vas-gs.md)
+ [Konfiguration](jobruns-vas-configure.md)
+ [Überwachen der Empfehlungen](jobruns-vas-monitor.md)
+ [Deinstallieren](jobruns-vas-uninstall-operator.md)

# Einrichten des vertikalen Auto Scalings für Amazon EMR in EKS
<a name="jobruns-vas-setup"></a>

Dieses Thema hilft Ihnen dabei, Ihren Amazon-EKS-Cluster für die Übermittlung von Amazon-EMR-Spark-Aufträgen mit vertikalem Auto Scaling vorzubereiten. Für den Einrichtungsvorgang müssen Sie die Aufgaben in den folgenden Abschnitten bestätigen oder abschließen:

**Topics**
+ [Voraussetzungen](#jobruns-vas-prereqs)
+ [Den Operator Lifecycle Manager (OLM) auf Ihrem Amazon-EKS-Cluster installieren](#jobruns-vas-install-olm)
+ [Den vertikalen Auto-Scaling-Operator für Amazon EMR in EKS installieren](#jobruns-vas-install-operator)

## Voraussetzungen
<a name="jobruns-vas-prereqs"></a>

Führen Sie die folgenden Aufgaben aus, bevor Sie den Kubernetes-Operator für vertikales Auto Scaling auf Ihrem Cluster installieren. Wenn Sie bereits eine der Voraussetzungen erfüllt haben, können Sie diese überspringen und mit der nächsten fortfahren.
+ **[Installieren oder aktualisieren Sie auf die neueste Version von AWS CLI— Wenn Sie die](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)** bereits installiert haben, vergewissern Sie sich AWS CLI, dass Sie über die neueste Version verfügen.
+ **[kubectl installieren](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)** – kubectl ist ein Befehlszeilen-Tool, mit dem Sie mit dem API-Server kommunizieren. Sie benötigen kubectl, um Artefakte im Zusammenhang mit vertikalem Auto Scaling auf Ihrem Amazon-EKS-Cluster zu installieren und zu überwachen.
+ **[Das Operator-SDK installieren](https://sdk.operatorframework.io/docs/installation/)** – Amazon EMR in EKS verwendet das Operator-SDK als Paketmanager für die gesamte Lebensdauer des vertikalen Auto-Scaling-Operators, den Sie auf Ihrem Cluster installieren.
+ **[Docker installieren](https://docs.docker.com/get-docker/)** – Sie benötigen Zugriff auf die Docker-CLI, um die Docker-Images für vertikales Auto Scaling zu authentifizieren und abzurufen, um sie auf Ihrem Amazon-EKS-Cluster zu installieren.
+ **[Installieren Sie den Kubernetes Metrics-Server](https://docs.aws.amazon.com/eks/latest/userguide/metrics-server.html)** — Sie müssen zuerst den Metrics-Server installieren, damit der vertikale Pod-Autoscaler Metriken vom Kubernetes-API-Server abrufen kann.
+ **[Erste Schritte mit Amazon EKS — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) (Version 1.24 oder höher)** — Vertikales Autoscaling wird mit Amazon EKS-Versionen 1.24 und höher unterstützt. Nachdem Sie den Cluster erstellt haben, [registrieren Sie ihn für die Verwendung mit Amazon EMR.](setting-up-registration.md)
+ **[Eine Amazon-EMR-Basis-Image-URI auswählen](docker-custom-images-tag.md) (Version 6.10.0 oder höher)** – Vertikales Auto Scaling wird mit Amazon-EMR-Versionen 6.10.0 und höher unterstützt.

## Den Operator Lifecycle Manager (OLM) auf Ihrem Amazon-EKS-Cluster installieren
<a name="jobruns-vas-install-olm"></a>

Verwenden Sie die Operator-SDK-CLI, um den Operator Lifecycle Manager (OLM) auf dem Amazon EMR in EKS-Cluster zu installieren, auf dem Sie vertikales Auto Scaling einrichten möchten, wie im folgenden Beispiel gezeigt. Sobald Sie es eingerichtet haben, können Sie OLM verwenden, um den Lebenszyklus des [vertikalen Auto-Scaling-Operators von Amazon EMR](#jobruns-vas-install-operator) zu installieren und zu verwalten.

```
operator-sdk olm install
```

Führen Sie den folgenden `olm status`-Befehl aus, um die Installation zu validieren:

```
operator-sdk olm status
```

Wenn der Befehl ausgeführt wird, gibt er eine Ausgabe ähnlich wie folgt zurück:

```
INFO[0007] Successfully got OLM status for version X.XX
```

Wenn Ihre Installation nicht erfolgreich ist, lesen Sie [Fehlerbehebung von Amazon EMR im vertikalen Auto Scaling von EKS](troubleshooting-vas.md).

## Den vertikalen Auto-Scaling-Operator für Amazon EMR in EKS installieren
<a name="jobruns-vas-install-operator"></a>

Verwenden Sie die folgenden Schritte, um den vertikalen Auto-Scaling-Operator auf Ihrem Amazon-EKS-Cluster zu installieren:

1. Richten Sie die folgenden Umgebungsvariablen ein, die Sie verwenden werden, um die Installation abzuschließen:
   + **`$REGION`** verweist auf AWS-Region für Ihren Cluster. Beispiel, `us-west-2`.
   + **`$ACCOUNT_ID`** verweist auf die Amazon-ECR-Konto-ID für Ihre Region. Weitere Informationen finden Sie unter [Amazon-ECR-Registrierungskonten nach Regionen](docker-custom-images-tag.md#docker-custom-images-ECR).
   + **`$RELEASE`** verweist auf die Amazon-EMR-Version, die Sie für Ihren Cluster verwenden möchten. Beim vertikalen Auto Scaling müssen Sie Amazon-EMR-Version 6.10.0 oder höher verwenden.

1. Als Nächstes müssen Sie Authentifizierungstoken für den Operator in der [Amazon-ECR-Registrierung](docker-custom-images-tag.md#docker-custom-images-ECR) abrufen.

   ```
   aws ecr get-login-password \
    --region region-id | docker login \
    --username AWS \
    --password-stdin $ACCOUNT_ID.dkr.ecr.region-id.amazonaws.com
   ```

1. Installieren Sie den vertikalen Auto-Scaling-Operator von Amazon EMR in EKS mit dem folgenden Befehl:

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

   Dadurch wird eine Version des vertikalen Auto-Scaling-Operators im Standard-Namespace Ihres Amazon-EKS-Clusters erstellt. Verwenden Sie diesen Befehl, um in einem anderen Namespace zu installieren:

   ```
   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
   ```
**Anmerkung**  
Wenn der von Ihnen angegebene Namespace nicht vorhanden ist, installiert OLM den Operator nicht. Weitere Informationen finden Sie unter [Kubernetes-Namespace nicht gefunden](troubleshooting-vas.md).

1. Stellen Sie sicher, dass Sie den Operator erfolgreich mit dem kubectl Kubernetes-Befehlszeilentool installiert haben.

   ```
   kubectl get csv -n operator-namespace
   ```

   **Der `kubectl`-Befehl sollte Ihren neu bereitgestellten vertikalen Auto-Scaling-Operator mit dem **Phasen**status Erfolgreich** zurückgeben. Falls Sie Probleme mit der Installation oder Einrichtung haben, finden Sie weitere Informationen unter [Fehlerbehebung von Amazon EMR im vertikalen Auto Scaling von EKS](troubleshooting-vas.md).

# Erste Schritte mit dem vertikalen Auto Scaling für Amazon EMR in EKS
<a name="jobruns-vas-gs"></a>

Verwenden Sie vertikale Autoskalierung für Amazon EMR auf EKS, wenn Sie eine automatische Optimierung der Speicher- und CPU-Ressourcen wünschen, um sie an die Arbeitslast Ihrer Amazon EMR Spark-Anwendung anzupassen. Weitere Informationen finden Sie unter [Verwenden der vertikalen Autoskalierung mit Amazon EMR Spark-Jobs](jobruns-vas.html).

## Einreichen eines Spark-Auftrags mit vertikalem Auto Scaling
<a name="jobruns-vas-spark-submit"></a>

Wenn Sie einen Job über die [StartJobRun](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_StartJobRun.html)API einreichen, fügen Sie dem Treiber für Ihren Spark-Job die folgenden beiden Konfigurationen hinzu, um die vertikale Autoskalierung zu aktivieren:

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

Im obigen Code aktiviert die erste Zeile die vertikale Auto-Scaling-Funktion. Die nächste Zeile ist eine erforderliche Signaturkonfiguration, mit der Sie eine Signatur für Ihren Auftrag auswählen können.

Weitere Informationen zu diesen Konfigurationen und akzeptablen Parameterwerten finden Sie unter [Konfigurieren des vertikalen Auto Scalings für Amazon EMR in EKS](jobruns-vas-configure.md). Standardmäßig wird Ihr Auftrag beim vertikalen Auto Scaling im Modus Nur für Überwachung **aus** gesendet. In diesem Überwachungsstatus können Sie Ressourcenempfehlungen berechnen und anzeigen, ohne ein Auto Scaling durchführen zu müssen. Weitere Informationen finden Sie unter [Modi für vertikales Auto Scaling](jobruns-vas-configure.md#jobruns-vas-parameters-opt-mode).

Das folgende Beispiel veranschaulicht, wie Sie einen `start-job-run`-Beispiel-Befehl mit vertikalem Auto Scaling abschließen:

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

## Überprüfen der vertikalen Auto-Scaling-Funktionalität
<a name="jobruns-vas-verify"></a>

Um zu überprüfen, ob das vertikale Auto Scaling für den eingereichten Auftrag korrekt funktioniert, rufen Sie mit kubectl die benutzerdefinierte `verticalpodautoscaler`-Ressource ab und sehen Sie sich Ihre Skalierungsempfehlungen an. Mit dem folgenden Befehl werden beispielsweise Empfehlungen für den Beispielauftrag aus dem Abschnitt [Einreichen eines Spark-Auftrags mit vertikalem Auto Scaling](#jobruns-vas-spark-submit) abgefragt:

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

Die Ausgabe dieser Abfrage sollte wie folgt aussehen:

```
NAME                                                          MODE   CPU         MEM PROVIDED   AGE
ds-jceyefkxnhrvdzw6djum3naf2abm6o63a6dvjkkedqtkhlrf25eq-vpa   Off    3304504865  True           87m
```

Wenn Ihre Ausgabe nicht ähnlich aussieht oder einen Fehlercode enthält, finden Sie weitere Schritte zur Behebung des Problems in [Fehlerbehebung von Amazon EMR im vertikalen Auto Scaling von EKS](troubleshooting-vas.md).

# Konfigurieren des vertikalen Auto Scalings für Amazon EMR in EKS
<a name="jobruns-vas-configure"></a>

Sie können vertikale Autoskalierung konfigurieren, wenn Sie Amazon EMR Spark-Jobs über die [StartJobRun](https://docs.aws.amazon.com/emr-on-eks/latest/APIReference/API_StartJobRun.html)API einreichen. Stellen Sie die Konfigurationsparameter für Auto Scaling auf dem Spark-Treiber-Pod ein, wie im Beispiel unter [Einreichen eines Spark-Auftrags mit vertikalem Auto Scaling](jobruns-vas-gs.md#jobruns-vas-spark-submit) gezeigt.

Der vertikale Auto-Scaling-Operator von Amazon EMR in EKS hört Treiber-Pods mit Auto Scaling ab und richtet dann die Integration mit dem vertikalen Kubernetes-Pod-Autoscaler (VPA) mit den Einstellungen auf dem Treiber-Pod ein. Dies erleichtert die Ressourcenverfolgung und Auto Scaling von Spark-Ausführer-Pods.

In den folgenden Abschnitten werden die Parameter beschrieben, die Sie bei der Konfiguration des vertikalen Auto Scalings für Ihren Amazon-EKS-Cluster verwenden können.

**Anmerkung**  
Konfigurieren Sie den Feature-Toggle-Parameter als Label und konfigurieren Sie die übrigen Parameter als Anmerkungen auf dem Spark-Treiber-Pod. Die Auto-Scaling-Parameter gehören zur `emr-containers.amazonaws.com/`-Domain und haben das Präfix `dynamic.sizing`.

## Erforderliche Parameter
<a name="jobruns-vas-parameters-req"></a>

Sie müssen die folgenden beiden Parameter in den Spark-Auftrag-Treiber aufnehmen, wenn Sie Ihren Auftrag einreichen:


| Key (Schlüssel) | Description | Akzeptierte Werte | Standardwert | Typ | Spark-Parameter1 | 
| --- | --- | --- | --- | --- | --- | 
|  `dynamic.sizing`  |  Feature einschalten  |  `true`, `false`  |  nicht gesetzt  |  Bezeichnung  |  `spark.kubernetes.driver.label.emr-containers.amazonaws.com/dynamic.sizing`  | 
|  `dynamic.sizing.signature`  |  Auftrag-Signatur  |  *string*  |  nicht gesetzt  |  Anmerkung  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.signature`  | 

1 Verwenden Sie diesen Parameter als `SparkSubmitParameter` oder `ConfigurationOverride` in der `StartJobRun`-API.
+ **`dynamic.sizing`** – Sie können das vertikale Auto Scaling mit dem `dynamic.sizing`-Label ein- und ausschalten. Um das vertikale Auto Scaling zu aktivieren, stellen Sie auf dem Spark-Treiber-Pod die Option `dynamic.sizing` auf `true` ein. Wenn Sie diese Bezeichnung weglassen oder sie auf einen anderen Wert als `true` festlegen, ist das vertikale Auto Scaling ausgeschaltet.
+ **`dynamic.sizing.signature`** – Legen Sie die Aufgabensignatur mit der Anmerkung `dynamic.sizing.signature` auf dem Treiber-Pod fest. Vertikales Auto Scaling aggregiert Ihre Ressourcennutzungsdaten über verschiedene Ausführungen von Amazon-EMR-Spark-Aufträge hinweg, um Ressourcenempfehlungen abzuleiten. Sie geben die eindeutige Kennung an, um die Aufträge miteinander zu verknüpfen.

  
**Anmerkung**  
Wenn sich Ihre Aufgabe in einem festen Intervall wiederholt, z. B. täglich oder wöchentlich, sollte Ihre Aufgabensignatur für jede neue Instance der Aufgabe gleich bleiben. Dadurch wird sichergestellt, dass mit vertikalem Auto Scaling Empfehlungen für verschiedene Ausführungen des Aufträge berechnet und aggregiert werden können.

1 Verwenden Sie diesen Parameter als `SparkSubmitParameter` oder `ConfigurationOverride` in der `StartJobRun`-API.

## Optionale Parameter
<a name="jobruns-vas-parameters-opt"></a>

Vertikales Auto Scaling unterstützt auch die folgenden optionalen-Parameter. Legen Sie sie als Anmerkungen auf dem Treiber-Pod fest.


| Key (Schlüssel) | Description | Akzeptierte Werte | Standardwert | Typ | Spark-Parameter1 | 
| --- | --- | --- | --- | --- | --- | 
|  `dynamic.sizing.mode`  |  Modus für vertikales Auto Scaling  |  `Off`, `Initial`, `Auto`  |  `Off`  |  Anmerkung  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.mode`  | 
|  `dynamic.sizing.scale.memory`  |  Aktiviert die Speicherskalierung  |  *`true`, `false`*  |  `true`  |  Anmerkung  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.memory`  | 
|  `dynamic.sizing.scale.cpu`  |  CPU-Skalierung ein- oder ausschalten  |  *`true`, `false`*  |  `false`  |  Anmerkung  |  `spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.cpu`  | 
|  `dynamic.sizing.scale.memory.min`  |  Mindestlimit für die Speicherskalierung  | Zeichenfolge, [Ressourcenmenge K8s](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), z. B.: 1G |  nicht gesetzt  |  Anmerkung  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.memory.min | 
|  `dynamic.sizing.scale.memory.max`  |  Höchstgrenze für die Speicherskalierung  | Zeichenfolge, [Ressourcenmenge K8s](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), z. B.: 4G |  nicht gesetzt  |  Anmerkung  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.memory.max | 
|  `dynamic.sizing.scale.cpu.min`  |  Mindestlimit für die CPU-Skalierung  | Zeichenfolge, [Ressourcenmenge K8s](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), z. B.: 1 |  nicht gesetzt  |  Anmerkung  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.cpu.min | 
|  `dynamic.sizing.scale.cpu.max`  |  Höchstgrenze für die CPU-Skalierung  | Zeichenfolge, [Ressourcenmenge K8s](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity), z. B.: 2 |  nicht gesetzt  |  Anmerkung  | spark.kubernetes.driver.annotation.emr-containers.amazonaws.com/dynamic.sizing.scale.cpu.max | 

### Modi für vertikales Auto Scaling
<a name="jobruns-vas-parameters-opt-mode"></a>

Der `mode`-Parameter ist den verschiedenen Auto-Scaling-Modi zugeordnet, die der VPA unterstützt. Verwenden Sie die `dynamic.sizing.mode`-Anmerkung auf dem Treiber-Pod, um den Modus einzustellen. Folgende Werte werden für diesen Parameter unterstützt:
+ **Aus** – Ein Probelaufmodus, in dem Sie zwar Empfehlungen überwachen können, das Auto Scaling jedoch nicht durchgeführt wird. Dies ist der Standardmodus für das vertikale Auto Scaling. In diesem Modus berechnet die zugehörige vertikale Pod-Autoscaler-Ressource Empfehlungen, und Sie können die Empfehlungen mit Tools wie kubectl, Prometheus und Grafana überwachen.
+ **Anfänglich** – In diesem Modus skaliert VPA Ressourcen beim Start des Aufträge automatisch, sofern Empfehlungen auf der Grundlage historischer Ausführungen des Aufträge verfügbar sind, z. B. im Fall eines wiederkehrenden Aufträge.
+ **Automatisch** – In diesem Modus entfernt VPA die Spark-Ausführer-Pods und skaliert sie automatisch mit den empfohlenen Ressourceneinstellungen, wenn der Spark-Treiber-Pod sie neu startet. Manchmal entfernt die VPA laufende Spark-Ausführer-Pods, sodass es zu zusätzlicher Latenz kommen kann, wenn der unterbrochene Ausführer erneut versucht wird.

### Skalierung von Ressourcen
<a name="jobruns-vas-parameters-opt-rs"></a>

Wenn Sie das vertikale Auto Scaling einrichten, können Sie auswählen, ob die CPU- und die Speicherressourcen skaliert werden sollen. Stellen Sie die Anmerkungen `dynamic.sizing.scale.cpu` und `dynamic.sizing.scale.memory` auf `true` oder `false` ein. Standardmäßig ist die CPU-Skalierung auf `false` und die Speicherskalierung auf `true` eingestellt.

### Mindest- und Höchstwerte für Ressourcen (Grenzen)
<a name="jobruns-vas-parameters-opt-bounds"></a>

Optional können Sie auch Grenzen für die CPU- und Speicherressourcen festlegen. Wählen Sie einen Mindest- und Höchstwert für diese Ressourcen mit den `dynamic.sizing.[memory/cpu].[min/max]`-Anmerkungen, wenn Sie das Auto Scaling aktivieren. In der Standardeinstellung haben die Ressourcen keine Einschränkungen. Legen Sie die Anmerkungen als Zeichenkettenwerte fest, die eine Kubernetes-Ressourcenmenge darstellen. Stellen Sie beispielsweise `dynamic.sizing.memory.max` auf `4G` ein, um 4 GB darzustellen.

# Überwachen des vertikalen Auto Scalings für Amazon EMR in EKS
<a name="jobruns-vas-monitor"></a>

Sie können das **kubectl Kubernetes-Befehlszeilentool** verwenden, um die aktiven, vertikalen Autoscaling-Empfehlungen in Ihrem Cluster aufzulisten. Sie können auch Ihre verfolgten Aufgabensignaturen einsehen und alle nicht benötigten Ressourcen löschen, die mit den Signaturen verknüpft sind.



## Führen Sie die Empfehlungen für vertikales Auto Scaling für Ihren Cluster auf
<a name="jobruns-vas-monitor-list"></a>

Verwenden Sie kubectl, um die `verticalpodautoscaler`-Ressource abzurufen und den aktuellen Status und die Empfehlungen einzusehen. Die folgende Beispielabfrage gibt alle aktiven Ressourcen in Ihrem Amazon-EKS-Cluster zurück.

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

Die Ausgabe dieser Abfrage ähnelt der folgenden:

```
NAME                  SIGNATURE                MODE      MEM
ds-example-id-1-vpa   job-signature-1          Off       none
ds-example-id-2-vpa   job-signature-2          Initial   12936384283
```

## Die Empfehlungen für vertikales Auto Scaling für Ihren Cluster abfragen und löschen
<a name="jobruns-vas-monitor-query"></a>

Wenn Sie eine Amazon-EMR-Ressource mit vertikaler Auto-Scaling-Auftragausführung löschen, wird automatisch das zugehörige VPA-Objekt gelöscht, das Empfehlungen verfolgt und speichert.

Im folgenden Beispiel wird kubectl verwendet, um Empfehlungen für einen Auftrag zu löschen, der durch eine Signatur identifiziert wird:

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

Wenn Sie die spezifische Aufgabensignatur nicht kennen oder alle Ressourcen im Cluster löschen möchten, können Sie in Ihrem Befehl `--all` oder `--all-namespaces` anstelle der eindeutigen Aufgaben-ID verwenden, wie im folgenden Beispiel gezeigt:

```
kubectl delete jobruns --all --all-namespaces
jobrun.dynamicsizing.emr.services.k8s.aws "ds-example-id" deleted
```

# Deinstallieren Sie den vertikalen Auto-Scaling-Operator von Amazon EMR in EKS
<a name="jobruns-vas-uninstall-operator"></a>

Wenn Sie den vertikalen Auto-Scaling-Operator aus Ihrem Amazon-EKS-Cluster entfernen möchten, verwenden Sie den `cleanup`-Befehl mit der Operator-SDK-CLI, wie im folgenden Beispiel gezeigt. Dadurch werden auch Upstream-Abhängigkeiten gelöscht, die mit dem Operator installiert wurden, wie z. B. der vertikale Pod-Autoscaler.

```
operator-sdk cleanup emr-dynamic-sizing
```

Wenn Sie den Operator löschen, laufende Aufträge auf dem Cluster befinden, werden diese Aufträge ohne vertikales Auto Scaling weiter ausgeführt. Wenn Sie Aufträge auf dem Cluster einreichen, nachdem Sie den Operator gelöscht haben, ignoriert Amazon EMR in EKS alle vertikalen Auto-Scaling-Parameter, die Sie möglicherweise während der [Konfiguration](jobruns-vas-configure.md) definiert haben.