Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Utilisation de la classification par défaut des conteneurs Amazon EMR
Présentation de
Les paramètres suivants sont disponibles dans la emr-containers-defaults classification :
-
job-start-timeout -
Par défaut, une tâche expire si elle ne peut pas démarrer et si elle reste dans
SUBMITTEDcet état pendant 15 minutes. Cette configuration modifie le nombre de secondes à attendre avant l'expiration de la tâche. -
executor.logging -
Active ou désactive la journalisation sur les pods d'exécution. Lorsque ce paramètre est défini sur,
DISABLEDle conteneur de journalisation est supprimé des pods d'exécution, ce qui désactivera toute journalisation pour ces espaces spécifiés dans lemonitoringConfiguration, tel ques3MonitoringConfigurationoucloudWatchMonitoringConfiguration. Lorsque ce paramètre n'est pas défini ou qu'il est défini sur une autre valeur, la journalisation sur les pods d'exécution est activée. -
logging.image -
Définit une image personnalisée à utiliser pour le conteneur de journalisation sur les pods du pilote et de l'exécuteur.
-
logging.request.cores -
Définit une valeur personnalisée pour le nombre de processeurs, en unités de processeur, pour le conteneur de journalisation sur les pods du pilote et de l'exécuteur. Par défaut, ce paramètre n'est pas défini.
-
logging.request.memory -
Définit une valeur personnalisée pour la quantité de mémoire, en octets, pour le conteneur de journalisation sur les pods du pilote et de l'exécuteur. Par défaut, cette valeur est réglée sur 512 Mo. Le mébioctet est une unité de mesure similaire à un mégaoctet.
-
logging.eventLog.dir -
Utilisez cette configuration pour activer l'interface utilisateur persistante de l'application et enregistrer les journaux d'événements Spark dans votre propre emplacement S3. Définissez
logging.eventLog.dirle chemin S3 pour vos journaux d'événements. Dans lemonitoringConfiguration, réglezpersistentAppUIsurENABLED. Ne le définissez passpark.eventLog.dirlorsque vous l'utilisezlogging.eventLog.dir; ces deux configurations ne sont pas compatibles. Si ellespark.eventLog.direst définie, cette configuration est prioritaire et le conteneur de journalisation ne peut pas répliquer les journaux d'événements Spark. Cela signifie que votre position S3 spécifiée parlogging.eventLog.dirne recevra pas de journaux d'événements et que l'interface utilisateur persistante de l'application ne fonctionnera pas non plus. -
logging.nativeSidecar -
Lorsque vous définissez cette propriété
ENABLEDpour Amazon EMR version 6.8.0 ou supérieure, Amazon EMR configure le conteneur de journalisation sur vos pods de pilote et d'exécuteur Spark en tant que conteneur sidecar Kubernetes natif (voir les détails sur le Kubernetes site Web) au lieu d'un conteneur normal. Cela signifie que le conteneur de journalisation redémarre automatiquement en cas de panne et que les défaillances du conteneur de journalisation n'entraîneront pas la défaillance du pod. Configuration requise pour la version du nœud
Vos nœuds Amazon EKS doivent exécuter Kubernetes la version 1.29 ou supérieure. La version de votre cluster EKS peut être différente de la version de votre nœud. Si vos nœuds exécutent une version inférieure à 1.29, n'active Kubernetes pas la fonction de sidecar native et si le conteneur de journalisation empêche le démarrage du pilote, ce qui entraîne des délais d'exécution des tâches.
Exemples de classification des soumissionnaires de tâches
Dans cette section
StartJobRundemande avec délai d'expiration de la tâche personnalisé
{ "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" } } } }
StartJobRunrequête avec journalisation désactivée pour les pods d'exécution
"configurationOverrides": { "applicationConfiguration": [ { "classification": "emr-containers-defaults", "properties": { "executor.logging": "DISABLED" } } ], "monitoringConfiguration": { "cloudWatchMonitoringConfiguration": { "logGroupName": "/emr-containers/jobs", "logStreamNamePrefix": "demo" }, "s3MonitoringConfiguration": { "logUri": "s3://joblogs" } } }
StartJobRunrequête avec image de conteneur de journalisation personnalisée, processeur et mémoire pour les pods du pilote et de l'exécuteur
"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" } } }
Note
Si le conteneur de journalisation Fluentd rencontre une erreur de mémoire insuffisante (OOM), augmentez la valeur. logging.request.memory Par exemple, configurez-le pour 1Gi allouer plus de mémoire au conteneur de journalisation et éviter les problèmes OOM.
StartJobRundemande avec le journal des événements Spark, destination Amazon S3
L'exemple suivant enregistre les journaux d'événements Spark dans votre propre compartiment Amazon S3 tout en activant l'interface utilisateur persistante des applications. Le persistentAppUI réglage est défini ENABLED par défaut.
"configurationOverrides": { "applicationConfiguration": [ { "classification": "emr-containers-defaults", "properties": { "logging.eventLog.dir": "s3://my-bucket/event-logs/" } } ], "monitoringConfiguration": { "persistentAppUI": "ENABLED" } }
Note
Ne définissez pas spark.eventLog.dir la spark-defaults classification lorsque vous l'utilisezlogging.eventLog.dir. Ces deux configurations ne sont pas compatibles. Si elle spark.eventLog.dir est définie, cette configuration est prioritaire et le conteneur de journalisation ne peut pas répliquer les journaux d'événements Spark. Cela signifie que votre position S3 spécifiée par logging.eventLog.dir ne recevra pas de journaux d'événements et que l'interface utilisateur persistante de l'application ne fonctionnera pas non plus.
StartJobRunrequête avec journalisation native du side-car
L'exemple suivant active le mode sidecar natif pour le conteneur de journalisation sur les pods du pilote et de l'exécuteur Spark. Lorsqu'il est activé, le conteneur de journalisation fonctionne comme un side-car Kubernetes natif qui redémarre automatiquement en cas de panne et n'affecte pas l'état de vos pods Spark.
"configurationOverrides": { "applicationConfiguration": [ { "classification": "emr-containers-defaults", "properties": { "logging.nativeSidecar": "ENABLED" } } ], "monitoringConfiguration": { "s3MonitoringConfiguration": { "logUri": "s3://my-bucket/logs/" } } }
Configuration requise pour la version du nœud
Vos nœuds Amazon EKS doivent exécuter Kubernetes la version 1.29 ou supérieure. La version de votre cluster EKS peut être différente de la version de votre nœud. Si vos nœuds exécutent une version inférieure à 1.29, n'active Kubernetes pas la fonction de sidecar native et si le conteneur de journalisation empêche le démarrage du pilote, ce qui entraîne des délais d'exécution des tâches.