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.
# Verwalten von Aufgabenausführungen von Amazon EMR in EKS
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
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
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
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
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
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
```
## Eine Aufgabenausführung beschreiben
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
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
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 | Variablenersetzung zur Anwendung auf Hive-Befehle, zum Beispiel -hivevar A=B |
| -hiveconf | 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
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
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
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"
}
}]
}
```