KubernetesPodOperator verwenden.

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

Auf dieser Seite wird beschrieben, wie Sie mit dem KubernetesPodOperator Kubernetes-Pods von Cloud Composer in die Google Kubernetes Engine Cluster, der zu Ihrer Cloud Composer-Umgebung gehört.

KubernetesPodOperator startet Kubernetes-Pods im Cluster Ihrer Umgebung. Im Vergleich dazu Mit Google Kubernetes Engine-Operatoren werden Kubernetes-Pods in einer bestimmten Cluster, der ein separater Cluster sein kann, der nicht mit Ihrem zu verbessern. Sie können Cluster auch mit Google Kubernetes Engine-Operatoren erstellen und löschen.

KubernetesPodOperator ist eine gute Option, wenn Sie Folgendes benötigen:

• Benutzerdefinierte Python-Abhängigkeiten, die nicht über das öffentliche PyPI-Repository verfügbar sind.
• Binäre Abhängigkeiten, die im Cloud Composer-Worker-Image nicht verfügbar sind.

Hinweis: Weitere Informationen zur Installation Pakete, die in einem privaten Paket-Repository gehostet werden, oder zusätzliche Optionen Abhängigkeiten zu verwalten, siehe Python-Abhängigkeiten installieren

Hinweis

• Wenn Version 5.0.0 des CNCF-Kubernetes-Anbieters verwendet wird, folgen Sie der Anleitung Abschnitt zu CNCF-Kubernetes-Anbietern.

• Die Pod-Affinitätskonfiguration ist in Cloud Composer 2 nicht verfügbar. Wenn Sie die Pod-Affinität verwenden möchten, starten Sie Pods stattdessen mit den GKE-Operatoren in einem anderen Cluster.

KubernetesPodOperator in Cloud Composer 2

In diesem Abschnitt wird beschrieben, wie KubernetesPodOperator in Cloud Composer 2 funktioniert.

Ressourcennutzung

In Cloud Composer 2 wird der Cluster Ihrer Umgebung automatisch skaliert. Zusätzliche Arbeitslasten, die Sie ausführen mit KubernetesPodOperator unabhängig von Ihrer Umgebung skalieren.

Ihre Umgebung ist nicht von der erhöhten Ressourcennachfrage betroffen, aber der Cluster Ihrer Umgebung wird je nach Ressourcenbedarf skaliert.

Die Preise für die zusätzlichen Arbeitslasten, die Sie in Ihrem und der Cluster der Umgebung Cloud Composer 2-Preismodell und verwendet Compute-SKUs für Cloud Composer.

Cloud Composer 2 verwendet Autopilot-Cluster, die das Konzept einführen von Compute-Klassen:

• Cloud Composer unterstützt nur die Compute-Klasse general-purpose.

• Wenn keine Klasse ausgewählt ist, wird standardmäßig die Klasse general-purpose verwendet, wenn Sie Pods mit KubernetesPodOperator erstellen.

• Jede Klasse ist mit bestimmten Eigenschaften und Ressourcenlimits verknüpft. Weitere Informationen finden Sie in der Autopilot-Dokumentation. Pods, die in der general-purpose-Klasse ausgeführt werden, können beispielsweise bis zu 110 GiB Arbeitsspeicher verbrauchen.

Zugriff auf die Ressourcen des Projekts

Cloud Composer 2 verwendet GKE-Cluster mit Workload Identity Federation for GKE. Pods, die im Namespace composer-user-workloads ausgeführt werden, können ohne zusätzliche Konfiguration auf Google Cloud-Ressourcen in Ihrem Projekt zugreifen. Der Zugriff auf diese Ressourcen erfolgt über das Dienstkonto Ihrer Umgebung.

Wenn Sie einen benutzerdefinierten Namespace verwenden möchten, müssen Kubernetes-Dienstkonten die mit diesem Namespace verknüpft sind, muss dem Google Cloud-Dienst zugeordnet werden -Konten, um die Dienstidentitätsautorisierung für Anfragen an Google APIs zu aktivieren und anderen Diensten. Wenn Sie Pods in einem benutzerdefinierten Namespace im und dann IAM-Bindungen zwischen Kubernetes und Google Cloud-Dienstkonten werden nicht erstellt und diese Pods können auch nicht Zugriff auf Ressourcen Ihres Google Cloud-Projekts.

Wenn Sie einen benutzerdefinierten Namespace verwenden und möchten, dass Ihre Pods Zugriff auf Google Cloud-Ressourcen, dann Folgen Sie der Anleitung in der Identitätsföderation von Arbeitslasten für GKE und richten Sie die Bindungen für einen benutzerdefinierten Namespace ein:

1. Erstellen Sie einen separaten Namespace im Cluster Ihrer Umgebung.
2. Erstellen Sie eine Bindung zwischen dem Kubernetes-Dienstkonto des benutzerdefinierten Namespace und dem Dienstkonto Ihrer Umgebung.
3. Fügen Sie dem Kubernetes-Dienstkonto die Dienstkontoannotation Ihrer Umgebung hinzu.
4. Wenn Sie KubernetesPodOperator verwenden, geben Sie den Namespace und das Kubernetes-Dienstkonto in den Parametern namespace und service_account_name an.

Hinweis: Es dauert einige Sekunden, bis der GKE-Metadatenserver Anfragen für einen neu erstellten Pod akzeptiert. Daher wird versucht, mit der Identitätsföderation von Arbeitslasten für GKE innerhalb der ersten Sekunden Die Lebensdauer des Pods kann fehlschlagen. Wiederholen Sie den Aufruf, um das Problem zu beheben. Weitere Informationen zu dieser Einschränkung finden Sie unter Einschränkungen der Identitätsföderation von Arbeitslasten für GKE.

Minimalkonfiguration

Zum Erstellen eines KubernetesPodOperator sind nur die Pod-Parameter name, image und task_id erforderlich. Die /home/airflow/composer_kube_config enthält Anmeldedaten für die Authentifizierung bei GKE.

kubernetes_min_pod = KubernetesPodOperator(
    # The ID specified for the task.
    task_id="pod-ex-minimum",
    # Name of task you want to run, used to generate Pod ID.
    name="pod-ex-minimum",
    # Entrypoint of the container, if not specified the Docker container's
    # entrypoint is used. The cmds parameter is templated.
    cmds=["echo"],
    # The namespace to run within Kubernetes. In Composer 2 environments
    # after December 2022, the default namespace is
    # `composer-user-workloads`. Always use the
    # `composer-user-workloads` namespace with Composer 3.
    namespace="composer-user-workloads",
    # Docker image specified. Defaults to hub.docker.com, but any fully
    # qualified URLs will point to a custom repository. Supports private
    # gcr.io images if the Composer Environment is under the same
    # project-id as the gcr.io images and the service account that Composer
    # uses has permission to access the Google Container Registry
    # (the default service account has permission)
    image="gcr.io/gcp-runtimes/ubuntu_20_0_4",
    # Specifies path to kubernetes config. The config_file is templated.
    config_file="/home/airflow/composer_kube_config",
    # Identifier of connection that should be used
    kubernetes_conn_id="kubernetes_default",
)

Zusätzliche Konfiguration

In diesem Beispiel werden zusätzliche Parameter gezeigt, die Sie im KubernetesPodOperator konfigurieren können.

Weitere Informationen zu Parametern finden Sie in der Airflow-Referenz für KubernetesPodOperator. Informationen zur Verwendung von Kubernetes-Secrets und ConfigMaps finden Sie unter Kubernetes-Secrets und ConfigMaps verwenden. Für Informationen zur Verwendung von Jinja-Vorlagen mit KubernetesPodOperator finden Sie unter Jinja-Vorlagen verwenden

kubernetes_full_pod = KubernetesPodOperator(
    task_id="ex-all-configs",
    name="pi",
    namespace="composer-user-workloads",
    image="perl:5.34.0",
    # Entrypoint of the container, if not specified the Docker container's
    # entrypoint is used. The cmds parameter is templated.
    cmds=["perl"],
    # Arguments to the entrypoint. The Docker image's CMD is used if this
    # is not provided. The arguments parameter is templated.
    arguments=["-Mbignum=bpi", "-wle", "print bpi(2000)"],
    # The secrets to pass to Pod, the Pod will fail to create if the
    # secrets you specify in a Secret object do not exist in Kubernetes.
    secrets=[],
    # Labels to apply to the Pod.
    labels={"pod-label": "label-name"},
    # Timeout to start up the Pod, default is 600.
    startup_timeout_seconds=600,
    # The environment variables to be initialized in the container.
    # The env_vars parameter is templated.
    env_vars={"EXAMPLE_VAR": "/example/value"},
    # If true, logs stdout output of container. Defaults to True.
    get_logs=True,
    # Determines when to pull a fresh image, if 'IfNotPresent' will cause
    # the Kubelet to skip pulling an image if it already exists. If you
    # want to always pull a new image, set it to 'Always'.
    image_pull_policy="Always",
    # Annotations are non-identifying metadata you can attach to the Pod.
    # Can be a large range of data, and can include characters that are not
    # permitted by labels.
    annotations={"key1": "value1"},
    # Optional resource specifications for Pod, this will allow you to
    # set both cpu and memory limits and requirements.
    # Prior to Airflow 2.3 and the cncf providers package 5.0.0
    # resources were passed as a dictionary. This change was made in
    # https://github.com/apache/airflow/pull/27197
    # Additionally, "memory" and "cpu" were previously named
    # "limit_memory" and "limit_cpu"
    # resources={'limit_memory': "250M", 'limit_cpu': "100m"},
    container_resources=k8s_models.V1ResourceRequirements(
        requests={"cpu": "1000m", "memory": "10G", "ephemeral-storage": "10G"},
        limits={"cpu": "1000m", "memory": "10G", "ephemeral-storage": "10G"},
    ),
    # Specifies path to kubernetes config. The config_file is templated.
    config_file="/home/airflow/composer_kube_config",
    # If true, the content of /airflow/xcom/return.json from container will
    # also be pushed to an XCom when the container ends.
    do_xcom_push=False,
    # List of Volume objects to pass to the Pod.
    volumes=[],
    # List of VolumeMount objects to pass to the Pod.
    volume_mounts=[],
    # Identifier of connection that should be used
    kubernetes_conn_id="kubernetes_default",
    # Affinity determines which nodes the Pod can run on based on the
    # config. For more information see:
    # https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
    # Pod affinity with the KubernetesPodOperator
    # is not supported with Composer 2
    # instead, create a cluster and use the GKEStartPodOperator
    # https://cloud.google.com/composer/docs/using-gke-operator
    affinity={},
)

Jinja-Vorlagen verwenden

Airflow unterstützt Jinja-Vorlagen in DAGs.

Sie müssen die erforderlichen Airflow-Parameter (task_id, name und image) durch den Operator. Wie im folgenden Beispiel gezeigt, können Sie alle anderen Parameter mit Jinja als Vorlage verwenden, z. B. cmds, arguments, env_vars und config_file.

Der Parameter env_vars in diesem Beispiel wird von einem Airflow-Variable mit dem Namen my_value. Der Beispiel-DAG bezieht seinen Wert aus der Vorlagenvariablen vars in Airflow. Airflow bietet mehr Variablen, die Zugriff auf verschiedene Arten von Informationen ermöglichen. Beispiel: können Sie die Vorlagenvariable conf verwenden, um auf Werte von Airflow-Konfigurationsoptionen. Weitere Informationen und die Liste der in Airflow verfügbaren Variablen finden Sie unter Vorlagenreferenz in Airflow Dokumentation.

Ohne den DAG zu ändern oder die Variable env_vars zu erstellen, schlägt die Aufgabe ex-kube-templates im Beispiel fehl, da die Variable nicht vorhanden ist. Erstellen Sie diese Variable in der Airflow-UI oder mit der Google Cloud CLI:

Airflow-UI

1. Rufen Sie die Airflow-UI auf.

2. Klicken Sie in der Symbolleiste auf Verwaltung > Variablen.

3. Klicken Sie auf der Seite Listenvariable auf Neuen Eintrag hinzufügen.

4. Geben Sie auf der Seite Add Variable (Variable hinzufügen) die folgenden Informationen ein:

   • Key: my_value
   • Val: example_value

5. Klicken Sie auf Speichern.

gcloud

Geben Sie den folgenden Befehl ein:

gcloud composer environments run ENVIRONMENT \
    --location LOCATION \
    variables set -- \
    my_value example_value

Ersetzen Sie:

• ENVIRONMENT durch den Namen der Umgebung.
• LOCATION durch die Region, in der sich die Umgebung befindet.

Das folgende Beispiel zeigt, wie Jinja-Vorlagen mit KubernetesPodOperator:

kubernetes_template_ex = KubernetesPodOperator(
    task_id="ex-kube-templates",
    name="ex-kube-templates",
    namespace="composer-user-workloads",
    image="bash",
    # All parameters below can be templated with Jinja. For more information
    # and the list of variables available in Airflow, see
    # the Airflow templates reference:
    # https://airflow.apache.org/docs/apache-airflow/stable/templates-ref.html
    # Entrypoint of the container, if not specified the Docker container's
    # entrypoint is used. The cmds parameter is templated.
    cmds=["echo"],
    # DS in Jinja is the execution date as YYYY-MM-DD, this Docker image
    # will echo the execution date. Arguments to the entrypoint. The Docker
    # image's CMD is used if this is not provided. The arguments parameter
    # is templated.
    arguments=["{{ ds }}"],
    # The var template variable allows you to access variables defined in
    # Airflow UI. In this case we are getting the value of my_value and
    # setting the environment variable `MY_VALUE`. The pod will fail if
    # `my_value` is not set in the Airflow UI. The env_vars parameter
    # is templated.
    env_vars={"MY_VALUE": "{{ var.value.my_value }}"},
    # Specifies path to Kubernetes config. The config_file is templated.
    config_file="/home/airflow/composer_kube_config",
    # Identifier of connection that should be used
    kubernetes_conn_id="kubernetes_default",
)

Kubernetes-Secrets und ConfigMaps verwenden

Ein Kubernetes-Secret ist ein Objekt, das sensible Daten enthält. Eine Kubernetes-ConfigMap ist ein Objekt, das nicht vertrauliche Daten in Schlüssel/Wert-Paaren enthält.

In Cloud Composer 2 können Sie Secrets und ConfigMaps mit folgendem Befehl erstellen: Google Cloud CLI, API oder Terraform verwenden und von dort aus auf KubernetesPodOperator.

YAML-Konfigurationsdateien

Wenn Sie ein Kubernetes-Secret oder eine ConfigMap mithilfe der Google Cloud CLI und API können Sie eine Datei im YAML-Format bereitstellen. Diese Datei muss den gleichen das von Kubernetes Secrets und ConfigMaps verwendet wird. Die Kubernetes-Dokumentation enthält viele Codebeispiele für ConfigMaps und Secrets. Sehen Sie sich als Erstes die Seite Anmeldedaten mit Secrets sicher verteilen und ConfigMaps an.

Wie in Kubernetes Secrets, Base64 verwenden wenn Sie Werte in Secrets definieren.

Achtung: Base64-codierte Werte sind nicht verschlüsselt, sondern nur unkenntlich gemacht. Der ursprüngliche Wert kann aus seiner Base64-Darstellung wiederhergestellt werden.

Zum Codieren eines Werts können Sie den folgenden Befehl verwenden. Dies ist eine von vielen Möglichkeiten, um einen base64-codierten Wert zu erhalten):

echo "postgresql+psycopg2://root:example-password@127.0.0.1:3306/example-db" -n | base64

Ausgabe:

cG9zdGdyZXNxbCtwc3ljb3BnMjovL3Jvb3Q6ZXhhbXBsZS1wYXNzd29yZEAxMjcuMC4wLjE6MzMwNi9leGFtcGxlLWRiIC1uCg==

Die folgenden beiden YAML-Dateibeispiele werden später in diesem Leitfaden in Beispielen verwendet. Beispiel für eine YAML-Konfigurationsdatei für ein Kubernetes-Secret:

apiVersion: v1
kind: Secret
metadata:
  name: airflow-secrets
data:
  sql_alchemy_conn: cG9zdGdyZXNxbCtwc3ljb3BnMjovL3Jvb3Q6ZXhhbXBsZS1wYXNzd29yZEAxMjcuMC4wLjE6MzMwNi9leGFtcGxlLWRiIC1uCg==

Ein weiteres Beispiel, das zeigt, wie Dateien eingefügt werden. Wie im vorherigen Beispiel: Codieren Sie zuerst den Inhalt einer Datei (cat ./key.json | base64) und geben Sie diesen Wert dann in der YAML-Datei an:

apiVersion: v1
kind: Secret
metadata:
  name: service-account
data:
  service-account.json: |
    ewogICJ0eXBl...mdzZXJ2aWNlYWNjb3VudC5jb20iCn0K

Beispiel für eine YAML-Konfigurationsdatei für eine ConfigMap. Sie müssen die Base64-Darstellung in ConfigMaps nicht verwenden:

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-configmap
data:
  example_key: example_value

Kubernetes-Secrets verwalten

In Cloud Composer 2 erstellen Sie Secrets mit der Google Cloud CLI und kubectl:

1. Rufen Sie Informationen zum Cluster Ihrer Umgebung ab:

   1. Führen Sie dazu diesen Befehl aus:

      gcloud composer environments describe ENVIRONMENT \
          --location LOCATION \
          --format="value(config.gkeCluster)"
      

      Ersetzen Sie:

      • ENVIRONMENT durch den Namen Ihrer Umgebung.
      • LOCATION durch die Region, in der sich die Cloud Composer-Umgebung befindet.

      Die Ausgabe dieses Befehls hat das folgende Format: projects/<your-project-id>/locations/<location-of-composer-env>/clusters/<your-cluster-id>.

   2. Zum Abrufen der GKE-Cluster-ID kopieren Sie die Ausgabe nach /clusters/ (endet auf -gke).

2. Stellen Sie mit folgendem Befehl eine Verbindung zu Ihrem GKE-Cluster her: Befehl:

   gcloud container clusters get-credentials CLUSTER_ID \
     --project PROJECT \
     --region LOCATION
   

   Ersetzen Sie Folgendes:

   • CLUSTER_ID: die Cluster-ID der Umgebung.
   • PROJECT_ID: die Projekt-ID.
   • LOCATION: die Region, in der sich die Umgebung befindet.

3. Erstellen Sie Kubernetes-Secrets:

   Hinweis: Siehe Secrets mit kubectl verwalten für zum Bearbeiten und Löschen von Secrets.

   Die folgenden Befehle zeigen zwei verschiedene Ansätze zum Erstellen Kubernetes-Secrets Der Ansatz --from-literal verwendet Schlüssel/Wert-Paare. Beim --from-file-Ansatz werden Dateiinhalte verwendet.

   • Führen Sie den folgenden Befehl aus, um ein Kubernetes-Secret mithilfe von Schlüssel/Wert-Paaren zu erstellen. In diesem Beispiel wird ein Secret namens airflow-secrets mit dem Feld sql_alchemy_conn mit dem Wert von test_value

     kubectl create secret generic airflow-secrets \
       --from-literal sql_alchemy_conn=test_value -n composer-user-workloads
     

   • Führen Sie den Befehl folgenden Befehl. In diesem Beispiel wird ein Secret mit dem Namen service-account erstellt, das das Feld service-account.json mit dem Wert aus dem Inhalt einer lokalen ./key.json-Datei enthält.

     kubectl create secret generic service-account \
       --from-file service-account.json=./key.json -n composer-user-workloads
     

Kubernetes-Secrets in DAGs verwenden

In diesem Beispiel werden zwei Möglichkeiten zur Verwendung von Kubernetes Secrets gezeigt: als Umgebung und als vom Pod bereitgestelltes Volume.

Das erste Secret, airflow-secrets, ist auf eine Kubernetes-Umgebungsvariable namens SQL_CONN festgelegt (nicht auf eine Airflow- oder Cloud Composer-Umgebungsvariable).

Das zweite Secret, service-account, stellt service-account.json, eine Datei, bereit durch ein Dienstkonto-Token auf /var/secrets/google.

Die Secret-Objekte sehen so aus:

secret_env = Secret(
    # Expose the secret as environment variable.
    deploy_type="env",
    # The name of the environment variable, since deploy_type is `env` rather
    # than `volume`.
    deploy_target="SQL_CONN",
    # Name of the Kubernetes Secret
    secret="airflow-secrets",
    # Key of a secret stored in this Secret object
    key="sql_alchemy_conn",
)
secret_volume = Secret(
    deploy_type="volume",
    # Path where we mount the secret as volume
    deploy_target="/var/secrets/google",
    # Name of Kubernetes Secret
    secret="service-account",
    # Key in the form of service account file name
    key="service-account.json",
)

Der Name des ersten Kubernetes-Secrets wird in der Variablen secret_env definiert. Dieses Secret heißt airflow-secrets. Der Parameter deploy_type gibt an, dass sie als Umgebungsvariable bereitgestellt werden muss. Der Wert der Umgebungsvariablen Der Name lautet SQL_CONN, wie im Parameter deploy_target angegeben. Die Funktion Der Wert der Umgebungsvariable SQL_CONN wird auf den Wert der sql_alchemy_conn-Taste.

Der Name des zweiten Kubernetes-Secrets wird in der Variablen secret_volume definiert. Dieses Secret heißt service-account. Sie wird als Lautstärke, wie im Parameter deploy_type angegeben. Der Pfad der Datei zu Bereitstellung (deploy_target) ist /var/secrets/google. Schließlich lautet der key des Secrets, das in deploy_target gespeichert ist, service-account.json.

Die Operatorkonfiguration sieht so aus:

kubernetes_secret_vars_ex = KubernetesPodOperator(
    task_id="ex-kube-secrets",
    name="ex-kube-secrets",
    namespace="composer-user-workloads",
    image="gcr.io/gcp-runtimes/ubuntu_20_0_4",
    startup_timeout_seconds=300,
    # The secrets to pass to Pod, the Pod will fail to create if the
    # secrets you specify in a Secret object do not exist in Kubernetes.
    secrets=[secret_env, secret_volume],
    # Entrypoint of the container, if not specified the Docker container's
    # entrypoint is used. The cmds parameter is templated.
    cmds=["echo"],
    # env_vars allows you to specify environment variables for your
    # container to use. The env_vars parameter is templated.
    env_vars={
        "EXAMPLE_VAR": "/example/value",
        "GOOGLE_APPLICATION_CREDENTIALS": "/var/secrets/google/service-account.json",
    },
    # Specifies path to kubernetes config. The config_file is templated.
    config_file="/home/airflow/composer_kube_config",
    # Identifier of connection that should be used
    kubernetes_conn_id="kubernetes_default",
)

Informationen zum CNCF-Kubernetes-Anbieter

KubernetesPodOperator ist im apache-airflow-providers-cncf-kubernetes-Anbieter implementiert.

Detaillierte Versionshinweise für den CNCF-Kubernetes-Anbieter finden Sie unter Website des CNCF-Kubernetes-Anbieters

Version 6.0.0

In Version 6.0.0 des CNCF Kubernetes-Anbieterpakets wird die kubernetes_default-Verbindung standardmäßig in KubernetesPodOperator verwendet.

Wenn Sie in Version 5.0.0 eine benutzerdefinierte Verbindung angegeben haben, wird diese vom Betreiber weiterhin verwendet. Wenn Sie wieder zur kubernetes_default-Verbindung zurückkehren möchten, sollten Sie Ihre DAGs entsprechend anpassen.

Version 5.0.0

Diese Version führt im Vergleich zu Version 4.4.0 einige nicht abwärtskompatible Änderungen ein. Die wichtigsten betreffen die kubernetes_default-Verbindung, die in Version 5.0.0 nicht verwendet wird.

Wichtig: Anpassungen in DAGs mit KubernetesPodOperator sind erforderlich, wenn Sie von einer Cloud Composer-Version mit der Version 4.4.0 oder niedriger des Anbieters auf eine Cloud Composer-Version mit der Version 5.0.0 umstellen.

• Die kubernetes_default-Verbindung muss geändert werden. Der Kubernetes-Konfigurationspfad muss auf /home/airflow/composer_kube_config festgelegt sein (wie in der folgenden Abbildung dargestellt). Alternativ muss config_file der KubernetesPodOperator-Konfiguration hinzugefügt werden (wie in der im folgenden Codebeispiel).

Abbildung 1. Airflow-UI, Ändern der kubernetes_default-Verbindung (zum Vergrößern klicken)

• Ändern Sie den Code einer Aufgabe mit KubernetesPodOperator so:

KubernetesPodOperator(
  # config_file parameter - can be skipped if connection contains this setting
  config_file="/home/airflow/composer_kube_config",
  # definition of connection to be used by the operator
  kubernetes_conn_id='kubernetes_default',
  ...
)

Weitere Informationen zu Version 5.0.0 finden Sie unter Versionshinweise für CNCF-Kubernetes-Anbieter

Fehlerbehebung

Dieser Abschnitt enthält Tipps zur Fehlerbehebung bei gängigen KubernetesPodOperator Probleme:

Logs ansehen

Bei der Fehlerbehebung können Sie Protokolle in der folgenden Reihenfolge überprüfen:

1. Airflow-Aufgabenlogs:

   1. Rufen Sie in der Google Cloud Console die Seite Umgebungen auf.

      Zur Seite Umgebungen

   2. Klicken Sie in der Liste der Umgebungen auf den Namen Ihrer Umgebung. Die Seite Umgebungsdetails wird geöffnet.

   3. Rufen Sie den Tab DAGs auf.

   4. Klicken Sie auf den Namen des DAG und dann auf die DAG-Ausführung, um die Details und Protokolle aufzurufen.

2. Airflow-Planer-Logs:

   1. Rufen Sie die Seite Umgebungsdetails auf.

   2. Rufen Sie den Tab Logs auf.

   3. Prüfen Sie die Logs des Airflow-Planers.

3. Pod-Logs in der Google Cloud Console unter GKE Arbeitsbelastungen. Diese Logs enthalten die YAML-Datei für die Pod-Definition, Pod-Ereignisse und Pod-Details.

Rückgabecodes ungleich null

Wenn Sie den KubernetesPodOperator (und GKEStartPodOperator) verwenden, gibt den Einstiegspunkt des Containers an, ob die Aufgabe ob sie erfolgreich sind oder nicht. Rückgabecodes mit einem Wert ungleich null weisen auf einen Fehler hin.

Ein gängiges Muster besteht darin, ein Shell-Script als Container-Einstiegspunkt auszuführen, um mehrere Vorgänge innerhalb des Containers zusammenzufassen.

Wenn Sie ein solches Skript schreiben, sollten Sie den Befehl set -e oben im Skript einfügen, sodass fehlgeschlagene Befehle im Skript das Skript beenden und den Fehler an die Airflow-Aufgabeninstanz weiterleiten.

Pod-Zeitüberschreitungen

Das Standardzeitlimit für KubernetesPodOperator beträgt 120 Sekunden, kann zu Zeitüberschreitungen führen, bevor größere Bilder heruntergeladen werden. Sie können das Zeitlimit erhöhen, indem Sie den Parameter startup_timeout_seconds ändern, wenn erstellen Sie den KubernetesPodOperator.

Wenn eine Pod-Zeitüberschreitung auftritt, ist das aufgabenspezifische Log in der Airflow-UI verfügbar. Beispiel:

Executing <Task(KubernetesPodOperator): ex-all-configs> on 2018-07-23 19:06:58.133811
Running: ['bash', '-c', u'airflow run kubernetes-pod-example ex-all-configs 2018-07-23T19:06:58.133811 --job_id 726 --raw -sd DAGS_FOLDER/kubernetes_pod_operator_sample.py']
Event: pod-name-9a8e9d06 had an event of type Pending
...
...
Event: pod-name-9a8e9d06 had an event of type Pending
Traceback (most recent call last):
  File "/usr/local/bin/airflow", line 27, in <module>
    args.func(args)
  File "/usr/local/lib/python2.7/site-packages/airflow/bin/cli.py", line 392, in run
    pool=args.pool,
  File "/usr/local/lib/python2.7/site-packages/airflow/utils/db.py", line 50, in wrapper
    result = func(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/airflow/models.py", line 1492, in _run_raw_task
    result = task_copy.execute(context=context)
  File "/usr/local/lib/python2.7/site-packages/airflow/contrib/operators/kubernetes_pod_operator.py", line 123, in execute
    raise AirflowException('Pod Launching failed: {error}'.format(error=ex))
airflow.exceptions.AirflowException: Pod Launching failed: Pod took too long to start

Pod-Zeitüberschreitungen können auch auftreten, wenn Cloud Composer-Dienstkonto nicht über die erforderlichen IAM-Berechtigungen verfügt, um die Aufgabe am Hand. Überprüfen Sie dies, indem Sie sich Fehler auf Pod-Ebene mithilfe der Methode GKE-Dashboards zum Ansehen der Logs für Ihre oder Cloud Logging verwenden.

Neue Verbindung konnte nicht hergestellt werden

Automatische Upgrades sind in GKE-Clustern standardmäßig aktiviert. Wenn sich ein Knotenpool in einem Cluster befindet, für den gerade ein Upgrade durchgeführt wird, sehen Sie möglicherweise die folgende Fehlermeldung:

<Task(KubernetesPodOperator): gke-upgrade> Failed to establish a new
connection: [Errno 111] Connection refused

Wenn Sie prüfen möchten, ob der Cluster aktualisiert wird, rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf und suchen nach dem Ladesymbol neben dem Clusternamen Ihrer Umgebung.

Nächste Schritte

• GKE-Operatoren verwenden
• Kubernetes-Grundlagen