Uso de modelos de pod

A partir das versões 5.33.0 ou 6.3.0 do Amazon EMR, o Amazon EMR no EKS oferece suporte ao recurso de modelo de pod do Spark. Um pod corresponde a um grupo de um ou mais contêineres, com recursos de rede e armazenamento compartilhados, e uma especificação de como executar os contêineres. Os modelos de pod são especificações que determinam como ocorrerá a execução de cada pod. É possível usar arquivos de modelo de pod para definir as configurações de pods de drivers ou de executores para as quais as configurações do Spark não oferecem suporte. Para obter mais informações sobre o recurso de modelo de pod do Spark, consulte Pod Template.

Cenários comuns

Você pode definir como executar trabalhos do Spark em clusters do EKS compartilhados ao usar modelos de pod com o Amazon EMR no EKS, e economizar custos e aprimorar a utilização e a performance dos recursos.

Por exemplo, o arquivo de modelo de pod a seguir demonstra um cenário de uso comum.

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>
  

O modelo de pod conclui as seguintes tarefas:

Habilitação de modelos de pod com o Amazon EMR no EKS

Para habilitar o recurso de modelo de pod com o Amazon EMR no EKS, configure as propriedades do Spark spark.kubernetes.driver.podTemplateFile e spark.kubernetes.executor.podTemplateFile para direcionar aos arquivos de modelo de pod no Amazon S3. O Spark fará download do arquivo de modelo de pod e o usará para estruturar pods de drivers e de executores.

Você pode usar SparkSubmitParameters para especificar o caminho do Amazon S3 para o modelo de pod, como demonstra o arquivo JSON de execução de trabalho a seguir.

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

Como alternativa, você pode usar configurationOverrides para especificar o caminho do Amazon S3 para o modelo de pod, como demonstra o arquivo JSON de execução de trabalho a seguir.

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

Campos do modelo de pod

Considere as restrições para campos apresentadas a seguir ao configurar um modelo de pod com o Amazon EMR no EKS.

Considerações sobre contêineres sidecar

O Amazon EMR controla o ciclo de vida dos pods provisionados pelo Amazon EMR no EKS. Os contêineres sidecar devem seguir um ciclo de vida semelhante ao do contêiner principal do Spark. Se você injetar contêineres sidecar adicionais em seus pods, recomendamos a integração com o gerenciamento do ciclo de vida do pod definido pelo Amazon EMR para que o contêiner sidecar possa ser interrompido sozinho quando o contêiner principal do Spark sair.

Para reduzir custos, recomendamos implementar um processo que impeça que pods de drivers com contêineres sidecar continuem em execução após a conclusão do seu trabalho. O driver do Spark exclui os pods de executores quando o executor é encerrado. No entanto, quando um programa de driver é concluído, os contêineres sidecar adicionais continuam em execução. O pod é faturado até que o Amazon EMR no EKS limpe o pod do driver. Geralmente, isso ocorre menos de um minuto após a conclusão do contêiner principal do driver do Spark. Para reduzir custos, você pode integrar os contêineres sidecar adicionais ao mecanismo de gerenciamento do ciclo de vida que o Amazon EMR no EKS define para os pods de drivers e de executores, conforme descrito na seção a seguir.

O contêiner principal do Spark nos pods de drivers e de executores envia heartbeat para um arquivo /var/log/fluentd/main-container-terminated a cada dois segundos. Ao adicionar a montagem de volume emr-container-communicate definida previamente do Amazon EMR ao contêiner sidecar, você pode definir um subprocesso do contêiner sidecar para monitorar periodicamente o horário da última modificação desse arquivo. O subprocesso é interrompido sozinho caso descubra que o contêiner principal do Spark interrompeu a heartbeat por um período mais longo.

O exemplo apresentado a seguir demonstra um subprocesso que rastreia o arquivo de pulsação e é interrompido sozinho. Substitua your_volume_mount pelo caminho no qual você monta o volume definido previamente. O script é empacotado dentro da imagem usada pelo contêiner sidecar. Em um arquivo de modelo de pod, você pode especificar um contêiner sidecar com os seguintes comandos: sub_process_script.sh e main_command.

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