Imágenes de contenedor personalizadas de Dataproc en GKE

Puedes especificar una imagen de contenedor personalizada para usar con Dataproc en GKE. Tu imagen de contenedor personalizado debe usar una de las imágenes base de Spark de Dataproc en GKE.

Usa una imagen de contenedor personalizada

Para usar una imagen de contenedor personalizada de Dataproc on GKE, configura la spark.kubernetes.container.image property cuando Crea un clúster virtual de Dataproc on GKE o enviar un trabajo de Spark al clúster.

  • Ejemplo de creación de clústeres de gcloud CLI: 
    gcloud dataproc clusters gke create "${DP_CLUSTER}" \
    --properties=spark:spark.kubernetes.container.image=custom-image \
    ... other args ...
  • Ejemplo de envío de trabajos con la CLI de gcloud: 
    gcloud dataproc jobs submit spark \
    --properties=spark.kubernetes.container.image=custom-image \
    ... other args ...

Requisitos y configuración de la imagen de contenedor personalizado

Imágenes base

Puedes usar herramientas de docker para compilar un Docker personalizado basado en una de las imágenes base de Spark de Dataproc publicadas en GKE.

Usuario del contenedor

Dataproc en GKE ejecuta contenedores de Spark como el usuario spark de Linux con un UID 1099 y un GID 1099. Usa el UID y el GID para los permisos del sistema de archivos. Por ejemplo, si agregas un archivo JAR en /opt/spark/jars/my-lib.jar en la imagen como una dependencia de carga de trabajo, debes otorgarle al usuario spark permiso de lectura en el archivo.

Componentes

  • Java: La variable de entorno JAVA_HOME apunta a la ubicación de la instalación de Java. El valor predeterminado actual es /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64, que está sujeto a cambios (consulta el Notas de la versión de Dataproc para actualizaciones información).

    • Si personalizas el entorno de Java, asegúrate de que JAVA_HOME esté configurado en la ubicación correcta y de que PATH incluya la ruta de acceso a los objetos binarios.

  • Python: Las imágenes de Spark básicas de Dataproc en GKE tienen Miniconda3 instalado en /opt/conda. CONDA_HOME puntos para esto ubicación, ${CONDA_HOME}/bin se incluye en PATH y PYSPARK_PYTHON se establece en ${CONDA_HOME}/python.

    • Si personalizas Conda, asegúrate de que CONDA_HOME apunte a la El directorio principal de Conda ,${CONDA_HOME}/bin, se incluye en PATH. El valor de PYSPARK_PYTHON se estableció en ${CONDA_HOME}/python.

    • Puedes instalar, quitar y actualizar paquetes en el entorno base predeterminado o crear uno nuevo, pero se recomienda que el entorno incluya todos los paquetes instalados en el entorno base de la imagen de contenedor base.

    • Si agregas módulos de Python, como una secuencia de comandos de Python con funciones de utilidad, a la imagen del contenedor, incluye los directorios de los módulos en PYTHONPATH.

  • Spark: Spark se instala en /usr/lib/spark y SPARK_HOME apunta a esta ubicación. Spark no se puede personalizar. Si se cambia, la imagen del contenedor se rechazará o no funcionará correctamente.

    • Trabajos: Puedes personalizar las dependencias de un trabajo de Spark. SPARK_EXTRA_CLASSPATH define la ruta de clase adicional para los procesos de JVM de Spark. Recomendación: Coloca los frascos en /opt/spark/jars y establece SPARK_EXTRA_CLASSPATH en /opt/spark/jars/*.

      Si incorporas el archivo jar del trabajo en la imagen, el directorio recomendado es /opt/spark/job Cuando envíes el trabajo, puedes hacer referencia a él con una ruta de acceso local, por ejemplo, file:///opt/spark/job/my-spark-job.jar.

    • Conector de Cloud Storage: El conector de Cloud Storage. está instalada en /usr/lib/spark/jars.

    • Utilidades: Los paquetes de utilidades procps y tini son necesarios para ejecutar Spark. Estas utilidades se incluyen en el imágenes base de Spark, por lo que las imágenes personalizadas no necesitan volver a instalarlos.

    • Punto de entrada: Dataproc en GKE ignora cualquier cambios realizados en las primitivas ENTRYPOINT y CMD en el imagen de contenedor.

    • Secuencias de comandos de inicialización: Puedes agregar una secuencia de comandos de inicialización opcional en /opt/init-script.sh. Una secuencia de comandos de inicialización puede descargar archivos de Cloud Storage, iniciar un proxy dentro del contenedor, llamar a otras secuencias de comandos y realizar otras tareas de inicio.

      La secuencia de comandos de entrada llama a la secuencia de comandos de inicialización con todos los argumentos de línea de comandos ($@) antes de iniciar el controlador de Spark, el ejecutor de Spark y otros procesos. La secuencia de comandos de inicialización Puedes seleccionar el tipo de proceso de Spark según el primer argumento ($1): los valores posibles incluyen spark-submit para contenedores de controladores y executor para contenedores ejecutores.

  • Configuración: Los parámetros de configuración de Spark se encuentran en /etc/spark/conf. La variable de entorno SPARK_CONF_DIR apunta a esta ubicación.

    No personalices las configuraciones de Spark en la imagen del contenedor. Más bien, enviar cualquier propiedad a través de la API de Dataproc on GKE para por los siguientes motivos:

    • Algunas propiedades, como el tamaño de la memoria del ejecutor, se determinan en el tiempo de ejecución, no en el tiempo de compilación de la imagen del contenedor. Dataproc debe insertarlas en GKE.
    • Dataproc en GKE establece restricciones en las propiedades que proporcionan los usuarios. Dataproc en GKE activa la configuración de configMap en /etc/spark/conf en el contenedor y anula la configuración incorporada en la imagen.

Imágenes base de Spark

Dataproc admite las siguientes imágenes de contenedor de Spark base:

  • Spark 2.4: ${REGION}-docker.pkg.dev/cloud-dataproc/spark/dataproc_1.5
  • Spark 3.1: ${REGION}-docker.pkg.dev/cloud-dataproc/spark/dataproc_2.0

Ejemplo de compilación de imagen de contenedor personalizada

Dockerfile de muestra

FROM us-central1-docker.pkg.dev/cloud-dataproc/spark/dataproc_2.0:latest

# Change to root temporarily so that it has permissions to create dirs and copy
# files.
USER root

# Add a BigQuery connector jar.
ENV SPARK_EXTRA_JARS_DIR=/opt/spark/jars/
ENV SPARK_EXTRA_CLASSPATH='/opt/spark/jars/*'
RUN mkdir -p "${SPARK_EXTRA_JARS_DIR}" \
    && chown spark:spark "${SPARK_EXTRA_JARS_DIR}"
COPY --chown=spark:spark \
    spark-bigquery-with-dependencies_2.12-0.22.2.jar "${SPARK_EXTRA_JARS_DIR}"

# Install Cloud Storage client Conda package.
RUN "${CONDA_HOME}/bin/conda" install google-cloud-storage

# Add a custom Python file.
ENV PYTHONPATH=/opt/python/packages
RUN mkdir -p "${PYTHONPATH}"
COPY test_util.py "${PYTHONPATH}"

# Add an init script.
COPY --chown=spark:spark init-script.sh /opt/init-script.sh

# (Optional) Set user back to `spark`.
USER spark

Compila la imagen del contenedor

Ejecuta los siguientes comandos en el directorio de Dockerfile

  1. Configurar imagen (ejemplo: us-central1-docker.pkg.dev/my-project/spark/spark-test-image:latest) y cambiamos al directorio de compilación. 
    IMAGE=custom container image \
    BUILD_DIR=$(mktemp -d) \
    cd "${BUILD_DIR}"

  2. Descarga el conector de BigQuery. 

    gcloud storage cp \
    gs://spark-lib/bigquery/spark-bigquery-with-dependencies_2.12-0.22.2.jar .

  3. Crea un archivo de ejemplo de Python. 

    cat >test_util.py <<'EOF'
def hello(name):
  print("hello {}".format(name))
    
def read_lines(path):
  with open(path) as f:
    return f.readlines()
EOF

  4. Crea una secuencia de comandos init de ejemplo. 

    cat >init-script.sh <<EOF
echo "hello world" >/tmp/init-script.out
EOF

  5. Compila y envía la imagen. 

    docker build -t "${IMAGE}" . && docker push "${IMAGE}"