Benutzerdefinierte Container-Images für Dataproc auf GKE

Sie können ein benutzerdefiniertes Container-Image für die Verwendung mit Dataproc auf GKE angeben . Für Ihr benutzerdefiniertes Container-Image muss eines der Basis-Spark-Images für Dataproc in GKE verwendet werden.

Benutzerdefiniertes Container-Image verwenden

Wenn Sie ein benutzerdefiniertes Dataproc-Container-Image in GKE verwenden möchten, legen Sie die spark.kubernetes.container.image property fest, wenn Sie einen virtuellen Dataproc-Cluster in GKE erstellen oder einen Spark-Job für den Cluster einreichen.

  • Beispiel für die Clustererstellung mit der gcloud CLI: 
    gcloud dataproc clusters gke create "${DP_CLUSTER}" \
    --properties=spark:spark.kubernetes.container.image=custom-image \
    ... other args ...
  • Beispiel für das Einreichen eines Jobs mit der gcloud CLI: 
    gcloud dataproc jobs submit spark \
    --properties=spark.kubernetes.container.image=custom-image \
    ... other args ...

Anforderungen und Einstellungen für benutzerdefinierte Container-Images

Basis-Images

Sie können docker-Tools verwenden, um benutzerdefinierte Docker-Images basierend auf einem der veröffentlichten Basis-Spark-Images für Dataproc auf GKE zu erstellen.

Container-Nutzer

In Dataproc in GKE werden Spark-Container als Linux-Nutzer spark mit einer 1099-UID und einer 1099-GID ausgeführt. Verwenden Sie die UID und GID für Dateisystemberechtigungen. Wenn Sie beispielsweise eine JAR-Datei unter /opt/spark/jars/my-lib.jar im Image als Arbeitslastabhängigkeit hinzufügen, müssen Sie dem Nutzer spark die Leseberechtigung für die Datei erteilen.

Komponenten

  • Java:Die Umgebungsvariable JAVA_HOME verweist auf den Speicherort der Java-Installation. Der aktuelle Standardwert ist /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64. Dieser kann sich jedoch ändern. Aktuelle Informationen finden Sie in den Dataproc-Versionshinweisen.

    • Wenn Sie die Java-Umgebung anpassen, muss JAVA_HOME auf den richtigen Speicherort festgelegt sein und PATH den Pfad zu Binärdateien enthalten.

  • Python:In den Basis-Spark-Images für Dataproc auf GKE ist Miniconda3 unter /opt/conda installiert. CONDA_HOME verweist auf diesen Ort, ${CONDA_HOME}/bin ist in PATH enthalten und PYSPARK_PYTHON ist auf ${CONDA_HOME}/python festgelegt.

    • Wenn Sie Conda anpassen, achten Sie darauf ,dass CONDA_HOME auf das Conda-Basisverzeichnis verweist, ${CONDA_HOME}/bin in PATH enthalten ist und PYSPARK_PYTHON auf ${CONDA_HOME}/python. festgelegt ist.

    • Sie können Pakete in der Standardbasisumgebung installieren, entfernen und aktualisieren oder eine neue Umgebung erstellen. Es wird jedoch dringend empfohlen, dass die Umgebung alle Pakete enthält, die in der Basisumgebung des Basis-Container-Images installiert sind.

    • Wenn Sie dem Container-Image Python-Module hinzufügen, z. B. ein Python-Skript mit Hilfsfunktionen, fügen Sie die Modulverzeichnisse in PYTHONPATH ein.

  • Spark:Spark ist in /usr/lib/spark installiert und SPARK_HOME verweist auf diesen Speicherort. Spark kann nicht angepasst werden. Wenn es geändert wird, wird das Container-Image abgelehnt oder funktioniert nicht richtig.

    • Jobs: Sie können Spark-Jobabhängigkeiten anpassen. SPARK_EXTRA_CLASSPATH definiert den zusätzlichen Klassenpfad für Spark-JVM-Prozesse. Empfehlung: Legen Sie die JAR-Dateien unter /opt/spark/jars ab und setzen Sie SPARK_EXTRA_CLASSPATH auf /opt/spark/jars/*.

      Wenn Sie das Job-JAR in das Image einbetten, ist das empfohlene Verzeichnis /opt/spark/job. Wenn Sie den Job senden, können Sie mit einem lokalen Pfad darauf verweisen, z. B. file:///opt/spark/job/my-spark-job.jar.

    • Cloud Storage-Connector:Der Cloud Storage-Connector ist unter /usr/lib/spark/jars installiert.

    • Dienstprogramme: Die Dienstprogramm-Pakete procps und tini sind für die Ausführung von Spark erforderlich. Diese Dienstprogramme sind in den Spark-Basis-Images enthalten, sodass sie in benutzerdefinierten Images nicht neu installiert werden müssen.

    • Einstiegspunkt:Dataproc on GKE ignoriert alle Änderungen, die an den Primitiven ENTRYPOINT und CMD im Container-Image vorgenommen wurden.

    • Initialisierungsskripte:Sie können unter /opt/init-script.sh ein optionales Initialisierungsskript hinzufügen. Ein Initialisierungsskript kann Dateien aus Cloud Storage herunterladen, einen Proxy im Container starten, andere Skripts aufrufen und andere Startaufgaben ausführen.

      Das Einstiegspunkt-Skript ruft das Initialisierungsskript mit allen Befehlszeilenargumenten ($@) auf, bevor der Spark-Treiber, der Spark-Executor und andere Prozesse gestartet werden. Im Initialisierungsskript kann der Typ des Spark-Prozesses anhand des ersten Arguments ($1) ausgewählt werden. Mögliche Werte sind spark-submit für Treibercontainer und executor für Executor-Container.

  • Konfigurationen:Spark-Konfigurationen befinden sich unter /etc/spark/conf. Die Umgebungsvariable SPARK_CONF_DIR verweist auf diesen Speicherort.

    Passen Sie die Spark-Konfigurationen nicht im Container-Image an. Reichen Sie stattdessen alle Attribute über die Dataproc on GKE API ein. Das hat folgende Gründe:

    • Einige Eigenschaften, z. B. die Größe des Executor-Arbeitsspeichers, werden zur Laufzeit und nicht beim Erstellen des Container-Images festgelegt. Sie müssen von Dataproc in GKE eingefügt werden.
    • Bei Dataproc auf GKE gelten Einschränkungen für die von Nutzern angegebenen Eigenschaften. Bei Dataproc on GKE werden Konfigurationen aus configMap in /etc/spark/conf im Container eingebunden. Dadurch werden im Image eingebettete Einstellungen überschrieben.

Spark-Basis-Images

Dataproc unterstützt die folgenden Spark-Basis-Container-Images:

  • Spark 3.5: ${REGION}-docker.pkg.dev/cloud-dataproc/spark/dataproc_2.2

Beispiel für das Erstellen eines benutzerdefinierten Container-Images

Beispiel-Dockerfile

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

Container-Image erstellen

Führen Sie die folgenden Befehle im Dockerfile-Verzeichnis aus.

  1. Legen Sie das Image fest (z. B. us-central1-docker.pkg.dev/my-project/spark/spark-test-image:latest) und wechseln Sie zum Build-Verzeichnis. 
    IMAGE=custom container image \
    BUILD_DIR=$(mktemp -d) \
    cd "${BUILD_DIR}"

  2. Laden Sie den BigQuery-Connector herunter. 

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

  3. Erstellen Sie eine Python-Beispieldatei. 

    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. Beispiel-Init-Skript erstellen 

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

  5. Erstellen Sie das Image und übertragen Sie es per Push. 

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