View a markdown version of this page

Utilisation de la classification par défaut des conteneurs Amazon EMR - Amazon EMR

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 SUBMITTED cet é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, DISABLED le 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 que s3MonitoringConfiguration oucloudWatchMonitoringConfiguration. 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.dir le chemin S3 pour vos journaux d'événements. Dans lemonitoringConfiguration, réglez persistentAppUI surENABLED. Ne le définissez pas spark.eventLog.dir lorsque vous l'utilisez logging.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.

logging.nativeSidecar

Lorsque vous définissez cette propriété ENABLED pour 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

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.