View a markdown version of this page

Verwendung der Amazon EMR-Container-Standardklassifizierung - Amazon EMR
-ÜbersichtBeispiele

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.

Verwendung der Amazon EMR-Container-Standardklassifizierung

-Übersicht

Die folgenden Einstellungen sind im Rahmen der emr-containers-defaults Klassifizierung verfügbar:

job-start-timeout

Standardmäßig läuft ein Job ab, wenn er nicht gestartet werden kann, und er wartet 15 Minuten in diesem SUBMITTED Status. Diese Konfiguration ändert die Anzahl der Sekunden, die gewartet werden müssen, bis der Job das Zeitlimit überschreitet.

executor.logging

Aktiviert oder deaktiviert die Protokollierung auf den Executor-Pods. Wenn diese Option auf gesetzt ist, wird DISABLED der Logging-Container aus den Executor-Pods entfernt, wodurch jegliche Protokollierung für diese in der angegebenen Pods deaktiviert wird, z. B. oder. monitoringConfiguration 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 Image 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 in CPU-Einheiten für den Logging-Container auf den Treiber- und Executor-Pods fest. Standardmäßig ist dieser Wert nicht festgelegt.

logging.request.memory

Legt einen benutzerdefinierten Wert für die Speichermenge in Byte für den Logging-Container auf den Treiber- und Executor-Pods fest. In der Standardeinstellung ist dieser Wert auf 512 Mi festgelegt. Ein Mebibyte ist eine Maßeinheit, die einem Megabyte ähnlich ist.

logging.eventLog.dir

Verwenden Sie diese Konfiguration, um die persistente App-Benutzeroberfläche zu aktivieren und Spark-Ereignisprotokolle an Ihrem eigenen S3-Speicherort zu speichern. Stellen Sie logging.eventLog.dir den S3-Pfad für Ihre Ereignisprotokolle ein. Stellen Sie im monitoringConfiguration persistentAppUI aufENABLED. Legen Sie diese Option nicht festspark.eventLog.dir, wenn Sie sie verwendenlogging.eventLog.dir. Diese beiden Konfigurationen sind nicht kompatibel. Wenn spark.eventLog.dir gesetzt, hat diese Konfiguration Priorität und der Logging-Container kann Spark-Ereignisprotokolle nicht replizieren. Das bedeutet, dass Ihr von angegebener S3-Standort logging.eventLog.dir keine Ereignisprotokolle empfängt und die Persistent App-Benutzeroberfläche ebenfalls nicht funktioniert.

logging.nativeSidecar

Wenn Sie diese Eigenschaft auf ENABLED Amazon EMR Version 6.8.0 oder höher setzen, konfiguriert Amazon EMR den Logging-Container auf Ihren Spark-Treiber- und Executor-Pods als Kubernetes nativen Sidecar-Container (siehe Details auf der Kubernetes Website) statt als regulären Container. Das bedeutet, dass der Logging-Container bei einem Ausfall automatisch neu gestartet wird und Logging-Container-Fehler nicht dazu führen, dass der Pod ausfällt.

Anforderung an die Node-Version

Auf Ihren Amazon EKS-Knoten muss Kubernetes Version 1.29 oder höher ausgeführt werden. Ihre EKS-Cluster-Version kann von Ihrer Knotenversion abweichen. Wenn auf Ihren Knoten eine Version unter 1.29 ausgeführt wird, wird die native Sidecar-Funktion Kubernetes nicht aktiviert und der Logging-Container verhindert, dass der Treiber gestartet wird, was zu Job-Timeouts führt.

Beispiele für die Klassifizierung von Auftragseinreichern

StartJobRunAnfrage mit benutzerdefiniertem Job-Timeout

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

StartJobRunAnfrage mit deaktivierter Protokollierung für Executor-Pods

"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-containers-defaults", 
      "properties": {
        "executor.logging": "DISABLED"
      }
    }
  ], 
  "monitoringConfiguration": {
    "cloudWatchMonitoringConfiguration": {
      "logGroupName": "/emr-containers/jobs", 
      "logStreamNamePrefix": "demo"
    }, 
    "s3MonitoringConfiguration": {
      "logUri": "s3://joblogs"
    }
  }
}

StartJobRunAnfrage mit benutzerdefiniertem Logging-Container-Image, CPU und Speicher für die Treiber- und Executor-Pods

"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"
    }
  }
}
Anmerkung

Wenn im Fluentd-Logging-Container ein OOM-Fehler (OOM) auftritt, erhöhen Sie den Wert. logging.request.memory Stellen Sie ihn beispielsweise auf ein, 1Gi um dem Logging-Container mehr Speicher zuzuweisen und OOM-Probleme zu vermeiden.

StartJobRunAnfrage mit Spark-Ereignisprotokoll, Amazon S3-Ziel

Im folgenden Beispiel werden Spark-Ereignisprotokolle in Ihrem eigenen Amazon S3-Bucket gespeichert und gleichzeitig die Persistent App UI aktiviert. Die persistentAppUI Einstellung ist ENABLED standardmäßig.

"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-containers-defaults", 
      "properties": {
        "logging.eventLog.dir": "s3://my-bucket/event-logs/"
      }
    }
  ], 
  "monitoringConfiguration": {
    "persistentAppUI": "ENABLED"
  }
}
Anmerkung

Legen Sie die spark-defaults Klassifizierung nicht festspark.eventLog.dir, wenn Sie sie verwendenlogging.eventLog.dir. Diese beiden Konfigurationen sind nicht kompatibel. Wenn spark.eventLog.dir gesetzt, hat diese Konfiguration Priorität und der Logging-Container kann Spark-Ereignisprotokolle nicht replizieren. Das bedeutet, dass Ihr von angegebener S3-Standort logging.eventLog.dir keine Ereignisprotokolle empfängt und die Persistent App-Benutzeroberfläche ebenfalls nicht funktioniert.

StartJobRunAnfrage mit nativer Sidecar-Protokollierung

Das folgende Beispiel aktiviert den nativen Sidecar-Modus für den Logging-Container auf den Spark-Treiber- und Executor-Pods. Wenn diese Option aktiviert ist, wird der Logging-Container als Kubernetes nativer Sidecar ausgeführt, der bei einem Ausfall automatisch neu gestartet wird und den Zustand Ihrer Spark-Pods nicht beeinträchtigt.

"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-containers-defaults", 
      "properties": {
        "logging.nativeSidecar": "ENABLED"
      }
    }
  ], 
  "monitoringConfiguration": {
    "s3MonitoringConfiguration": {
      "logUri": "s3://my-bucket/logs/"
    }
  }
}
Anforderung an die Node-Version

Auf Ihren Amazon EKS-Knoten muss Kubernetes Version 1.29 oder höher ausgeführt werden. Ihre EKS-Cluster-Version kann von Ihrer Knotenversion abweichen. Wenn auf Ihren Knoten eine Version unter 1.29 ausgeführt wird, wird die native Sidecar-Funktion Kubernetes nicht aktiviert und der Logging-Container verhindert, dass der Treiber gestartet wird, was zu Job-Timeouts führt.