Bekannte Probleme

Managed Airflow (Gen 3) | Managed Airflow (Gen 2) | Managed Airflow (Legacy Gen 1)

Auf dieser Seite sind bekannte Probleme mit Managed Airflow aufgeführt. Informationen zu Fehlerbehebungen finden Sie in den Versionshinweisen.

Einige Probleme betreffen frühere Versionen und können durch ein Upgrade Ihrer Umgebung behoben werden.

Adressen außerhalb des RFC 1918-Bereichs werden für Pods und Dienste teilweise unterstützt

Managed Airflow ist auf GKE angewiesen, um Unterstützung für Adressen außerhalb des RFC 1918-Bereichs für Pods und Services zu bieten. In Managed Airflow wird nur die folgende Liste von Bereichen außerhalb von RFC 1918 unterstützt:

  • 100.64.0.0/10
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 240.0.0.0/4

Umgebungslabels, die während eines Updates hinzugefügt wurden, werden nicht vollständig weitergegeben

Wenn Sie Umgebungslabels aktualisieren, werden sie nicht auf Compute Engine-VMs im Cluster der Umgebung angewendet. Als Behelfslösung können Sie die Labels manuell anwenden.

Managed Airflow-Umgebungen können nicht erstellt werden, wenn die Einschränkung „constraints/compute.disableSerialPortLogging“ der Organisationsrichtlinie erzwungen wird

Das Erstellen einer Managed Airflow-Umgebung schlägt fehl, wenn die Organisationsrichtlinie constraints/compute.disableSerialPortLogging für das Zielprojekt erzwungen wird.

Diagnose

So ermitteln Sie, ob Sie von diesem Problem betroffen sind:

Rufen Sie in derGoogle Cloud Console das GKE-Menü auf. Zum GKE-Menü

Wählen Sie anschließend den neu erstellten Cluster aus. Suchen Sie nach folgendem Fehler:

Not all instances running in IGM after 123.45s.
Expect <number of desired instances in IGM>. Current errors:
[CONDITION_NOT_MET]: Instance '<generated instance name>' creation failed:
Constraint constraints/compute.disableSerialPortLogging violated for
project <target project number>.

Problemumgehungen:

  1. Deaktivieren Sie die Organisationsrichtlinie für das Projekt, in dem die Managed Airflow-Umgebung erstellt werden soll.

    Eine Organisationsrichtlinie kann jederzeit auf Projektebene deaktiviert werden, auch wenn sie von den übergeordneten Ressourcen (Organisation oder Ordner) aktiviert ist. Weitere Informationen finden Sie auf der Seite Richtlinien für boolesche Einschränkungen anpassen.

  2. Ausschlussfilter verwenden

    Durch Verwendung eines Ausschlussfilters für serielle Portlogs wird das gleiche Ziel wie das Deaktivieren der Organisationsrichtlinie verwendet, da es in Logging serielle Konsolenlogs gibt. Weitere Informationen finden Sie auf der Seite Ausschlussfilter.

Verwendung von Deployment Manager zum Verwalten von Google Cloud -Ressourcen, die durch VPC Service Controls geschützt sind

In Managed Airflow (Legacy Gen 1) und Managed Airflow (Gen 2) Version 2.0.x wird Deployment Manager verwendet, um Komponenten von Managed Airflow-Umgebungen zu erstellen.

Im Dezember 2020 haben Sie möglicherweise Informationen erhalten, dass Sie eventuell zusätzliche VPC Service Controls-Konfigurationen vornehmen müssen, um Deployment Manager zum Verwalten von Ressourcen verwenden zu können, die durch VPC Service Controls geschützt sind.

Wir möchten klarstellen, dass Sie nichts unternehmen müssen, wenn Sie Managed Airflow verwenden und Deployment Manager nicht direkt zur Verwaltung der in der Deployment Manager-Ankündigung erwähnten Google Cloud -Ressourcen nutzen.

Deployment Manager zeigt Informationen zu einer nicht unterstützten Funktion an.

Auf dem Tab „Deployment Manager“ wird möglicherweise die folgende Warnung angezeigt:

The deployment uses actions, which are an unsupported feature. We recommend
that you avoid using actions.

Bei Deployment Manager-Deployments, die zu Managed Airflow gehören, können Sie diese Warnung ignorieren.

Eine Umgebung kann nicht gelöscht werden, nachdem ihr Cluster gelöscht wurde

Dieses Problem betrifft Managed Airflow (Legacy Gen 1) und Managed Airflow (Gen 2) Version 2.0.x.

Wenn Sie den GKE-Cluster Ihrer Umgebung vor der Umgebung selbst löschen, führt der Versuch, die Umgebung zu löschen, zu folgendem Fehler:

 Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]

So löschen Sie eine Umgebung, wenn der zugehörige Cluster bereits gelöscht wurde:

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

    Deployment Manager aufrufen

  2. Alle mit Labels gekennzeichneten Bereitstellungen suchen:

    • goog-composer-environment:<environment-name>
    • goog-composer-location:<environment-location>.

    Sie sollten zwei Bereitstellungen sehen, die mit den beschriebenen Labels gekennzeichnet sind:

    • Eine Bereitstellung mit dem Namen <environment-location>-<environment-name-prefix>-<hash>-sd
    • Eine Bereitstellung mit dem Namen addons-<uuid>

  3. Löschen Sie Ressourcen, die noch in diesen beiden Bereitstellungen aufgeführt und im Projekt vorhanden sind (z. B. Pub/Sub-Themen und -Abos). Anleitung:

    1. Wählen Sie die Bereitstellungen aus.

    2. Klicken Sie auf Löschen.

    3. Wählen Sie die Option Zwei Bereitstellungen und alle von ihnen erstellten Ressourcen löschen, z. B. VMs, Load-Balancer und Laufwerke, und klicken Sie auf Alle löschen.

    Der Löschvorgang schlägt fehl, die verbleibenden Ressourcen werden jedoch gelöscht.

  4. Löschen Sie die Bereitstellungen mit einer der folgenden Optionen:

    • Wählen Sie in der Google Cloud Console beide Deployments noch einmal aus. Klicken Sie auf Löschen und wählen Sie die Option 2 Bereitstellungen löschen, aber die von ihnen erstellten Ressourcen beibehalten aus.

    • Führen Sie einen gcloud-Befehl aus, um die Bereitstellungen mit der Richtlinie ABANDON zu löschen:

      gcloud deployment-manager deployments delete addons-<uuid> \
    --delete-policy=ABANDON

gcloud deployment-manager deployments delete <location>-<env-name-prefix>-<hash>-sd \
    --delete-policy=ABANDON

  5. Löschen Sie Ihre Managed Airflow-Umgebung.

Warnungen zu doppelten Einträgen der Aufgabe „echo“, die zum DAG „echo-airflow_monitoring“ gehört.

In den Airflow-Logs wird möglicherweise der folgende Eintrag angezeigt:

in _query db.query(q) File "/opt/python3.6/lib/python3.6/site-packages/MySQLdb/
connections.py", line 280, in query _mysql.connection.query(self, query)
_mysql_exceptions.IntegrityError: (1062, "Duplicate entry
'echo-airflow_monitoring-2020-10-20 15:59:40.000000' for key 'PRIMARY'")

Sie können diese Logeinträge ignorieren, da dieser Fehler keine Auswirkungen auf den Airflow-DAG und die Aufgabenverarbeitung hat.

Wir arbeiten daran, den Managed Airflow-Dienst zu verbessern, um diese Warnungen aus Airflow-Logs zu entfernen.

Die Umgebungserstellung schlägt in Projekten fehl, bei denen Identity-Aware Proxy APIs dem VPC Service Controls-Perimeter hinzugefügt wurden.

In Projekten, in denen VPC Service Controls aktiviert ist, benötigt das Konto cloud-airflow-prod@ expliziten Zugriff in Ihrem Sicherheitsperimeter, um Umgebungen zu erstellen.

Sie können eine der folgenden Lösungen verwenden, um Umgebungen zu erstellen:

  • Fügen Sie die Cloud Identity-Aware Proxy API und die Identity-Aware Proxy TCP API nicht dem Sicherheitsperimeter hinzu.

  • Fügen Sie das Dienstkonto cloud-airflow-prod@ als Mitglied Ihres Sicherheitsperimeters hinzu. Verwenden Sie dazu die folgende Konfiguration in der YAML-Bedingungsdatei:

     - members:
    - serviceAccount:cloud-airflow-prod@

Erstellung oder Upgrade einer verwalteten Airflow-Umgebung schlägt fehl, wenn die Richtlinie „compute.vmExternalIpAccess“ deaktiviert ist

Dieses Problem betrifft Managed Airflow-Umgebungen (Legacy Gen 1) und Managed Airflow-Umgebungen (Gen 2).

Von Managed Airflow verwaltete GKE-Cluster, die im Modus „Öffentliche IP-Adresse“ konfiguriert sind, benötigen eine externe Verbindung für ihre VMs. Aus diesem Grund kann die Erstellung von VMs mit externen IP-Adressen in der Richtlinie compute.vmExternalIpAccess nicht verboten werden. Weitere Informationen zu dieser Organisationsrichtlinie finden Sie unter Einschränkungen für Organisationsrichtlinien.

Der erste DAG wird für eine hochgeladene DAG-Datei mit mehreren fehlgeschlagenen Aufgaben ausgeführt.

Wenn Sie eine DAG-Datei hochladen, schlagen manchmal die ersten Aufgaben des ersten DAG mit dem Fehler Unable to read remote log... fehl. Dieses Problem tritt auf, weil die DAG-Datei zwischen dem Bucket Ihrer Umgebung, den Airflow-Workern und den Airflow-Planern Ihrer Umgebung synchronisiert wird. Wenn der Planer die DAG-Datei abruft und sie für die Ausführung durch einen Worker plant und der Worker die DAG-Datei noch nicht hat, schlägt die Ausführung der Aufgabe fehl.

Um dieses Problem zu beheben, sind Umgebungen mit Airflow 2 standardmäßig so konfiguriert, dass zwei Wiederholungsversuche für eine fehlgeschlagene Aufgabe ausgeführt werden. Wenn eine Aufgabe fehlschlägt, wird sie zweimal im Abstand von 5 Minuten wiederholt.

Hinweise zur Einstellung der Unterstützung für verworfene Beta APIs aus GKE-Versionen

Managed Airflow verwaltet die zugrunde liegenden GKE-Cluster, die zu Managed Airflow gehören. Sofern Sie diese APIs nicht explizit in Ihren DAGs und Ihrem Code verwenden, können Sie Ankündigungen zu verworfenen GKE APIs ignorieren. Managed Airflow übernimmt bei Bedarf alle Migrationen.

Managed Airflow sollte nicht von der Apache Log4j 2-Sicherheitslücke (CVE-2021-44228) betroffen sein

Als Reaktion auf die Apache Log4j 2-Sicherheitslücke (CVE-2021-44228) hat Managed Airflow eine detaillierte Untersuchung durchgeführt und wir glauben, dass Managed Airflow nicht anfällig für diesen Exploit ist.

Bei Airflow-Workern oder -Planern können Probleme beim Zugriff auf den Cloud Storage-Bucket der Umgebung auftreten.

Managed Airflow verwendet gcsfuse, um auf den Ordner /data im Bucket der Umgebung zuzugreifen und Airflow-Aufgabenlogs im Verzeichnis /logs zu speichern (falls aktiviert). Wenn gcsfuse überlastet ist oder der Bucket der Umgebung nicht verfügbar ist, kann es zu Fehlern bei Airflow-Aufgabeninstanzen kommen und in den Airflow-Logs werden möglicherweise Transport endpoint is not connected-Fehler angezeigt.

Lösungen:

  • Deaktivieren Sie das Speichern von Logs im Bucket der Umgebung. Diese Option ist standardmäßig deaktiviert, wenn eine Umgebung mit Managed Airflow 2.8.0 oder höher erstellt wird.
  • Führen Sie ein Upgrade auf Managed Airflow 2.8.0 oder höher durch.
  • Reduzieren Sie [celery]worker_concurrency und erhöhen Sie stattdessen die Anzahl der Airflow-Worker.
  • Reduzieren Sie die Menge der im DAG-Code erzeugten Logs.
  • Folgen Sie den Empfehlungen und Best Practices für die Implementierung von DAGs und aktivieren Sie Wiederholungsversuche für Aufgaben.

Die Airflow-Benutzeroberfläche lädt ein Plug-in nach einer Änderung möglicherweise nicht neu.

Wenn ein Plug-in aus vielen Dateien besteht, die andere Module importieren, kann die Airflow-UI möglicherweise nicht erkennen, dass ein Plug-in neu geladen werden muss. Starten Sie in diesem Fall den Airflow-Webserver Ihrer Umgebung neu.

Der Cluster der Umgebung hat Arbeitslasten im Status „Nicht planbar“

Dieses bekannte Problem betrifft nur Managed Airflow (Gen 2).

In Managed Airflow (Gen 2) bleiben nach dem Erstellen einer Umgebung mehrere Arbeitslasten im Cluster der Umgebung im Status „Nicht planbar“.

Wenn eine Umgebung hochskaliert wird, werden neue Worker-Pods erstellt und Kubernetes versucht, sie auszuführen. Wenn keine ungenutzten Ressourcen für die Ausführung verfügbar sind, werden die Worker-Pods als „Nicht planbar“ markiert.

In diesem Fall fügt Cluster Autoscaler weitere Knoten hinzu, was einige Minuten dauert. Bis dahin bleiben die Pods im Status „Nicht planbar“ und führen keine Aufgaben aus.

Nicht planbare DaemonSet-Arbeitslasten mit den Namen composer-gcsfuse und composer-fluentd, die nicht auf Knoten gestartet werden können, auf denen keine Airflow-Komponenten vorhanden sind, haben keine Auswirkungen auf Ihre Umgebung.

Wenn dieses Problem über einen längeren Zeitraum (mehr als 1 Stunde) besteht, können Sie die Cluster Autoscaler-Logs prüfen. Sie finden sie in der Loganzeige mit dem folgenden Filter:

resource.type="k8s_cluster"
logName="projects/<project-name>/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
resource.labels.cluster_name="<cluster-name>"

Sie enthält Informationen zu Entscheidungen, die von Cluster Autoscaler getroffen wurden. Maximieren Sie einen beliebigen „noDecisionStatus“, um den Grund zu sehen, warum der Cluster nicht hoch- oder herunterskaliert werden kann.

Fehler 504 beim Zugriff auf die Airflow-Benutzeroberfläche

Beim Zugriff auf die Airflow-Benutzeroberfläche kann der Fehler 504 Gateway Timeout auftreten. Dieser Fehler kann mehrere Ursachen haben:

  • Vorübergehendes Kommunikationsproblem. Versuchen Sie in diesem Fall, später auf die Airflow-Benutzeroberfläche zuzugreifen. Sie können auch den Airflow-Webserver neu starten.

  • (Nur Managed Airflow (Gen 3)) Verbindungsproblem. Wenn die Airflow-UI dauerhaft nicht verfügbar ist und Zeitüberschreitungs- oder 504-Fehler generiert werden, prüfen Sie, ob Ihre Umgebung auf *.composer.googleusercontent.com zugreifen kann.

  • (Nur Managed Airflow (Gen 2)) Verbindungsproblem. Wenn die Airflow-UI dauerhaft nicht verfügbar ist und Zeitüberschreitungs- oder 504-Fehler generiert werden, prüfen Sie, ob Ihre Umgebung auf *.composer.cloud.google.com zugreifen kann. Wenn Sie den privater Google-Zugriff verwenden und Traffic über virtuelle private.googleapis.com-IP-Adressen senden oder VPC Service Controls verwenden und Traffic über virtuelle restricted.googleapis.com-IP-Adressen senden, muss Ihr Cloud DNS auch für *.composer.cloud.google.com-Domainnamen konfiguriert sein.

  • Airflow-Webserver reagiert nicht. Wenn der Fehler 504 weiterhin auftritt, Sie aber zu bestimmten Zeiten auf die Airflow-Benutzeroberfläche zugreifen können, reagiert der Airflow-Webserver möglicherweise nicht, weil er überlastet ist. Versuchen Sie, die Skalierungs- und Leistungsparameter des Webservers zu erhöhen.

Fehler 502 beim Zugriff auf die Airflow-Benutzeroberfläche

Der Fehler 502 Internal server exception gibt an, dass die Airflow-Benutzeroberfläche eingehende Anfragen nicht verarbeiten kann. Dieser Fehler kann mehrere Ursachen haben:

  • Vorübergehendes Kommunikationsproblem. Versuchen Sie später, auf die Airflow-Benutzeroberfläche zuzugreifen.

  • Der Webserver konnte nicht gestartet werden. Damit der Webserver gestartet werden kann, müssen zuerst die Konfigurationsdateien synchronisiert werden. Prüfen Sie die Webserver-Logs auf Logeinträge, die in etwa so aussehen: GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp oder GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp. Wenn diese Fehler auftreten, prüfen Sie, ob die in den Fehlermeldungen genannten Dateien noch im Bucket der Umgebung vorhanden sind.

    Wenn sie versehentlich entfernt wurden (z. B. weil eine Aufbewahrungsrichtlinie konfiguriert wurde), können Sie sie wiederherstellen:

    1. Legen Sie eine neue Umgebungsvariable in Ihrer Umgebung fest. Sie können einen beliebigen Variablennamen und -wert verwenden.

    2. Airflow-Konfigurationsoption überschreiben. Sie können eine nicht vorhandene Airflow-Konfigurationsoption verwenden.

Fehler 500 beim Zugriff auf die Airflow-Benutzeroberfläche nach dem Überschreiben von [webserver]analytics_tool

Wenn Sie in Umgebungen mit Airflow 2 die Airflow-Konfigurationsoption [webserver]analytics_tool überschreiben, um anonyme Nutzungsdaten der Airflow-Benutzeroberfläche an einen Analysedienst (z. B. Google Analytics, Segment, MetaRouter oder Matomo) weiterzuleiten, kann der Zugriff auf die Airflow-Benutzeroberfläche nach dem erfolgreichen Umgebungsupdate eine (500) Internal Server Error-Antwort mit einem der folgenden Fehler in den Airflow-Server-Logs zurückgeben:

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config

Wenn [webserver]analytics_tool in Airflow 2 festgelegt ist, müssen beim Airflow-Webserver auch die zugehörigen Analyseoptionen im Abschnitt [webserver] definiert werden, wenn die Airflow-UI gerendert wird.

In Airflow 3 werden die Konfigurationsoptionen [webserver]analytics_tool, [webserver]analytics_id und [webserver]analytics_url entfernt.

Lösungen:

  • Entfernen Sie die Überschreibung für die Airflow-Konfigurationsoption [webserver]analytics_tool oder
  • Geben Sie alle erforderlichen Airflow-Konfigurationsoptionen zusammen an:
    • [webserver]analytics_tool
    • [webserver]analytics_id
    • [webserver]analytics_url (erforderlich in Airflow 2.9 und höher, auch wenn Ihr Analysetool keine benutzerdefinierte URL verwendet)

Wenn Sie den Mauszeiger in der Strukturansicht auf eine Aufgabeninstanz bewegen, wird ein nicht abgefangener TypeError ausgegeben.

In Airflow 2 funktioniert die Strukturansicht in der Airflow-UI manchmal nicht richtig, wenn eine nicht standardmäßige Zeitzone verwendet wird. Als Behelfslösung für dieses Problem können Sie die Zeitzone explizit in der Airflow-Benutzeroberfläche konfigurieren.

Die Airflow-Benutzeroberfläche in Airflow 2.2.3 oder früheren Versionen ist anfällig für CVE-2021-45229

Wie in CVE-2021-45229 beschrieben, war der Bildschirm „Trigger DAG with config“ über das Abfrageargument origin anfällig für XSS-Angriffe.

Empfehlung: Führen Sie ein Upgrade auf die neueste Managed Airflow-Version durch, die Airflow 2.2.5 unterstützt.

Worker benötigen mehr Arbeitsspeicher als in früheren Airflow-Versionen

Symptome:

  • In Ihrer Managed Airflow-Umgebung (Gen 2) haben alle Clusterarbeitslasten der Airflow-Worker den Status CrashLoopBackOff und führen keine Aufgaben aus. Außerdem werden OOMKilling-Warnungen angezeigt, die generiert werden, wenn Sie von diesem Problem betroffen sind.

  • Dieses Problem kann Upgrades der Umgebung verhindern.

Ursache:

  • Wenn Sie einen benutzerdefinierten Wert für die Airflow-Konfigurationsoption [celery]worker_concurrency und benutzerdefinierte Speichereinstellungen für Airflow-Worker verwenden, kann dieses Problem auftreten, wenn der Ressourcenverbrauch sich dem Limit nähert.
  • Die Arbeitsspeicheranforderungen für Airflow-Worker in Airflow 2.6.3 mit Python 3.11 sind 10 % höher als für Worker in früheren Versionen.
  • Die Arbeitsspeicheranforderungen für Airflow-Worker in Airflow 2.3 und höheren Versionen sind 30 % höher als für Worker in Airflow 2.2 oder Airflow 2.1.

Lösungen:

  • Entfernen Sie die Überschreibung für worker_concurrency, damit Managed Airflow diesen Wert automatisch berechnet.
  • Wenn Sie einen benutzerdefinierten Wert für worker_concurrency verwenden, legen Sie einen niedrigeren Wert fest. Sie können den automatisch berechneten Wert als Ausgangspunkt verwenden.
  • Alternativ können Sie den für Airflow-Worker verfügbaren Arbeitsspeicher erhöhen.
  • Wenn Sie Ihre Umgebung aufgrund dieses Problems nicht auf eine neuere Version aktualisieren können, wenden Sie vor dem Upgrade eine der vorgeschlagenen Lösungen an.

DAG-Auslösung über private Netzwerke mit Cloud Run Functions

Das Auslösen von DAGs mit Cloud Run Functions über private Netzwerke mithilfe eines VPC-Connectors wird von Managed Airflow nicht unterstützt.

Empfehlung: Verwenden Sie Cloud Run Functions, um Nachrichten in Pub/Sub zu veröffentlichen. Solche Ereignisse können Pub/Sub-Sensoren aktivieren, um Airflow-DAGs auszulösen, oder einen Ansatz basierend auf zurückstellbaren Operatoren implementieren.

Leere Ordner in Scheduler und Workers

Managed Airflow entfernt leere Ordner nicht aktiv aus Airflow-Workern und -Planern. Solche Entitäten können im Rahmen der Synchronisierung des Umgebungs-Buckets erstellt werden, wenn diese Ordner im Bucket vorhanden waren und schließlich entfernt wurden.

Empfehlung: Passen Sie Ihre DAGs so an, dass solche leeren Ordner übersprungen werden.

Solche Entitäten werden schließlich aus den lokalen Speichern von Airflow-Planern und -Workern entfernt, wenn diese Komponenten neu gestartet werden (z. B. aufgrund von Herunterskalierungs- oder Wartungsvorgängen im Cluster Ihrer Umgebung).

Unterstützung für Kerberos

Managed Airflow unterstützt die Airflow-Kerberos-Konfiguration nicht.

Unterstützung für Compute-Klassen in Managed Airflow (Gen 2) und Managed Airflow (Gen 3)

Managed Airflow (Gen 3) und Managed Airflow (Gen 2) unterstützen nur die Compute-Klasse Für allgemeine Zwecke. Das bedeutet, dass Pods, die andere Compute-Klassen anfordern (z. B. Ausgeglichen oder Horizontal skalieren), nicht ausgeführt werden können.

Mit der Klasse Für allgemeine Zwecke können Pods ausgeführt werden, die bis zu 110 GB Arbeitsspeicher und bis zu 30 CPUs anfordern (wie unter Maximale Anfragen für Compute-Klassen beschrieben).

Wenn Sie eine ARM-basierte Architektur verwenden möchten oder mehr CPU und Arbeitsspeicher benötigen, müssen Sie eine andere Compute-Klasse verwenden, die in Managed Airflow-Clustern (Gen 3) und Managed Airflow-Clustern (Gen 2) nicht unterstützt wird.

Empfehlung: Verwenden Sie GKEStartPodOperator, um Kubernetes-Pods auf einem anderen Cluster auszuführen, der die ausgewählte Compute-Klasse unterstützt. Wenn Sie benutzerdefinierte Pods ausführen, die eine andere Compute-Klasse erfordern, müssen diese ebenfalls auf einem nicht verwalteten Managed Airflow-Cluster ausgeführt werden.

Unterstützung für Google Campaign Manager 360-Operatoren

Google Campaign Manager-Operatoren in Managed Airflow-Versionen vor 2.1.13 basieren auf der Campaign Manager 360 v3.5 API, die verworfen wurde und am 1. Mai 2023 eingestellt wird.

Wenn Sie Google Campaign Manager-Operatoren verwenden, aktualisieren Sie Ihre Umgebung auf Managed Airflow-Version 2.1.13 oder höher.

Support für Google Display & Video 360-Operatoren

Google Display and Video 360-Operatoren in Managed Airflow-Versionen vor 2.1.13 basieren auf der Display and Video 360 v1.1 API, die verworfen wurde und am 27. April 2023 eingestellt wird.

Wenn Sie Google Display & Video 360-Operatoren verwenden, aktualisieren Sie Ihre Umgebung auf Managed Airflow-Version 2.1.13 oder höher. Außerdem müssen Sie möglicherweise Ihre DAGs ändern, da einige der Google Display & Video 360-Operatoren verworfen und durch neue ersetzt wurden.

  • GoogleDisplayVideo360CreateReportOperator wurde eingestellt. Verwenden Sie stattdessen GoogleDisplayVideo360CreateQueryOperator. Dieser Operator gibt query_id anstelle von report_id zurück.
  • GoogleDisplayVideo360RunReportOperator wurde eingestellt. Verwenden Sie stattdessen GoogleDisplayVideo360RunQueryOperator. Dieser Operator gibt query_id und report_id anstelle von nur report_id zurück und erfordert query_id anstelle von report_id als Parameter.
  • Wenn Sie prüfen möchten, ob ein Bericht bereit ist, verwenden Sie den neuen GoogleDisplayVideo360RunQuerySensor-Sensor, der die Parameter query_id und report_id verwendet. Der verworfene GoogleDisplayVideo360ReportSensor-Sensor erforderte nur report_id.
  • Für GoogleDisplayVideo360DownloadReportV2Operator sind jetzt sowohl der Parameter query_id als auch der Parameter report_id erforderlich.
  • In GoogleDisplayVideo360DeleteReportOperator gibt es keine Änderungen, die sich auf Ihre DAGs auswirken können.

Einschränkungen für den Namen des sekundären Bereichs

CVE-2023-29247 (Die Detailseite zur Taskinstanz in der Benutzeroberfläche ist anfällig für gespeichertes XSS)

Die Airflow-UI in den Airflow-Versionen 2.0.x bis 2.5.x ist anfällig für CVE-2023-29247.

Wenn Sie eine frühere Version von Managed Airflow als 2.4.2 verwenden und vermuten, dass Ihre Umgebung für den Exploit anfällig ist, lesen Sie die folgende Beschreibung und die möglichen Lösungen.

In Managed Airflow ist der Zugriff auf die Airflow-Benutzeroberfläche mit IAM und der Zugriffssteuerung für die Airflow-Benutzeroberfläche geschützt.

Das bedeutet, dass Angreifer, um die Sicherheitslücke in der Airflow-Benutzeroberfläche auszunutzen, zuerst Zugriff auf Ihr Projekt sowie die erforderlichen IAM-Berechtigungen und -Rollen erhalten müssen.

Lösung:

Der Airflow-Monitoring-DAG der Managed Airflow-Umgebung (Gen 2) von Composer wird nach dem Löschen nicht neu erstellt

Der Airflow-Monitoring-DAG wird nicht automatisch neu erstellt, wenn er vom Nutzer gelöscht oder in Umgebungen mit composer-2.1.4-airflow-2.4.3 aus dem Bucket verschoben wird.

Lösung:

  • Dieses Problem wurde in späteren Versionen wie composer-2.4.2-airflow-2.5.3 behoben. Es wird empfohlen, ein Upgrade Ihrer Umgebung auf eine neuere Version durchzuführen.
  • Eine alternative oder temporäre Problemumgehung für ein Umgebungsupgrade besteht darin, den DAG „airflow_monitoring“ aus einer anderen Umgebung mit derselben Version zu kopieren.

Es ist nicht möglich, den Cloud SQL-Speicher zu reduzieren

Managed Airflow verwendet Cloud SQL zum Ausführen der Airflow-Datenbank. Im Laufe der Zeit kann der Speicherplatz für die Cloud SQL-Instanz zunehmen, da das Laufwerk hochskaliert wird, um die von Cloud SQL-Vorgängen gespeicherten Daten aufzunehmen, wenn die Airflow-Datenbank wächst.

Es ist nicht möglich, die Größe des Cloud SQL-Laufwerks zu verringern.

Wenn Sie die kleinste Cloud SQL-Laufwerksgröße verwenden möchten, können Sie als Behelfslösung Managed Airflow-Umgebungen mit Snapshots neu erstellen.

Der Messwert für die Speicherplatznutzung der Datenbank wird nach dem Entfernen von Datensätzen aus Cloud SQL nicht reduziert

In relationalen Datenbanken wie Postgres oder MySQL werden Zeilen nicht physisch entfernt, wenn sie gelöscht oder aktualisiert werden. Stattdessen werden sie als „tote Tupel“ markiert, um die Datenkonsistenz zu wahren und das Blockieren gleichzeitiger Transaktionen zu vermeiden.

Sowohl MySQL als auch Postgres implementieren Mechanismen, um Speicherplatz nach dem Löschen von Datensätzen freizugeben.

Es ist zwar möglich, die Datenbank zu zwingen, ungenutzten Speicherplatz freizugeben, aber dies ist ein ressourcenintensiver Vorgang, der die Datenbank zusätzlich sperrt und Managed Airflow nicht verfügbar macht. Daher wird empfohlen, sich auf die integrierten Mechanismen zur Freigabe des nicht verwendeten Speicherplatzes zu verlassen.

Zugriff blockiert: Autorisierungsfehler

Wenn dieses Problem einen Nutzer betrifft, enthält das Dialogfeld Zugriff blockiert: Autorisierungsfehler die Meldung Error 400: admin_policy_enforced.

Wenn die Option API-Steuerung > Nicht konfigurierte Drittanbieter-Apps > Nutzer dürfen nicht auf Drittanbieter-Apps zugreifen in Google Workspace aktiviert ist und die Apache Airflow-Anwendung in Managed Airflow nicht explizit zugelassen ist, können Nutzer nicht auf die Airflow-UI zugreifen, es sei denn, sie lassen die Anwendung explizit zu.

Führen Sie die Schritte unter Zugriff auf die Airflow-Benutzeroberfläche in Google Workspace zulassen aus, um den Zugriff zu erlauben.

Anmeldeschleife beim Zugriff auf die Airflow-Benutzeroberfläche

Dieses Problem kann folgende Ursachen haben:

Aufgabeninstanzen, die in der Vergangenheit erfolgreich waren, wurden als FEHLGESCHLAGEN markiert

Unter bestimmten Umständen und in seltenen Fällen können Airflow-Aufgabeninstanzen, die in der Vergangenheit erfolgreich waren, als FAILED markiert werden.

Wenn dies der Fall ist, wurde es normalerweise entweder durch ein Umgebungsupdate oder ein Upgrade oder durch eine GKE-Wartung ausgelöst.

Hinweis: Das Problem selbst weist nicht auf ein Problem in der Umgebung hin und verursacht keine tatsächlichen Fehler bei der Aufgabenausführung.

Das Problem wurde in Managed Airflow-Version 2.6.5 oder höher behoben.

Airflow-Komponenten haben Probleme bei der Kommunikation mit anderen Teilen der Managed Airflow-Konfiguration.

Dieses Problem betrifft nur Managed Airflow (Gen 2) Version 2.10.2 und früher.

In sehr seltenen Fällen kann die langsame Kommunikation mit dem Compute Engine-Metadatenserver dazu führen, dass Airflow-Komponenten nicht optimal funktionieren. Beispielsweise kann der Airflow-Planer neu gestartet werden, Airflow-Aufgaben müssen möglicherweise wiederholt werden oder die Startzeit der Aufgabe kann länger sein.

Symptome:

Die folgenden Fehler werden in den Logs der Airflow-Komponenten (z. B. Airflow-Planer, -Worker oder -Webserver) angezeigt:

Authentication failed using Compute Engine authentication due to unavailable metadata server

Compute Engine Metadata server unavailable on attempt 1 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 2 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 3 of 3. Reason: timed out

Lösung:

  • Führen Sie ein Upgrade Ihrer Umgebung auf eine neuere Managed Airflow-Version durch. Dieses Problem wurde ab Managed Airflow-Version 2.11.0 behoben.

Der Ordner „/data“ ist auf dem Airflow-Webserver nicht verfügbar.

In Managed Airflow (Gen 2) und Managed Airflow (Gen 3) ist der Airflow-Webserver hauptsächlich als schreibgeschützte Komponente gedacht. Managed Airflow synchronisiert den Ordner data/ nicht mit dieser Komponente.

Manchmal möchten Sie gängige Dateien für alle Airflow-Komponenten freigeben, einschließlich des Airflow-Webservers.

Lösung:

  • Verpacken Sie die Dateien, die für den Webserver freigegeben werden sollen, in ein PYPI-Modul und installieren Sie es als reguläres PYPI-Paket. Nachdem das PYPI-Modul in der Umgebung installiert wurde, werden die Dateien den Images von Airflow-Komponenten hinzugefügt und stehen ihnen zur Verfügung.

  • Fügen Sie dem Ordner plugins/ Dateien hinzu. Dieser Ordner wird mit dem Airflow-Webserver synchronisiert.

Nicht kontinuierliche Diagramme zur DAG-Analysezeit und DAG-Bag-Größe im Monitoring

Nicht kontinuierliche DAG-Parseverarbeitungszeiten und DAG-Bag-Größendiagramme im Monitoring-Dashboard weisen auf Probleme mit langen DAG-Parseverarbeitungszeiten (mehr als 5 Minuten) hin.

Diagramme zu Airflow-DAG-Parserzeiten und DAG-Bag-Größe mit einer Reihe von nicht kontinuierlichen Intervallen
Abbildung 1. Nicht kontinuierliche DAG-Parsetime- und DAG-Bag-Größendiagramme (zum Vergrößern klicken)

Lösung: Wir empfehlen, die Gesamtzeit für das DAG-Parsing unter 5 Minuten zu halten. Folgen Sie den Richtlinien zum Schreiben von DAGs, um die DAG-Parsing-Zeit zu reduzieren.

Logs von Managed Airflow-Komponenten fehlen in Cloud Logging

Es gibt ein Problem mit der Komponente der Umgebung, die für das Hochladen der Logs von Airflow-Komponenten in Cloud Logging verantwortlich ist. Dieser Fehler führt manchmal dazu, dass ein Log auf Managed Airflow-Ebene für eine Airflow-Komponente fehlt. Dasselbe Log ist weiterhin auf der Ebene der Kubernetes-Komponente verfügbar.

Häufigkeit des Problems: sehr selten, sporadisch

Ursache:

Falsches Verhalten der Managed Airflow-Komponente, die für das Hochladen von Logs in Cloud Logging verantwortlich ist.

Lösungen:

  • Aktualisieren Sie Ihre Umgebung auf Managed Airflow-Version 2.10.0 oder höher.

  • In früheren Versionen von Managed Airflow besteht die vorübergehende Problemumgehung darin, einen Managed Airflow-Vorgang zu initiieren, der die Komponenten neu startet, für die das Log fehlt.

Der Wechsel des Clusters der Umgebung zur GKE Enterprise Edition wird nicht unterstützt

Dieser Hinweis gilt für Managed Airflow 1 und Managed Airflow 2.

Der GKE-Cluster der Managed Airflow-Umgebung wird in der GKE Standard Edition erstellt.

Seit Dezember 2024 unterstützt der Managed Airflow-Dienst das Erstellen von Managed Airflow-Umgebungen mit Clustern in der Enterprise Edition nicht mehr.

Managed Airflow-Umgebungen wurden nicht mit der GKE Enterprise Edition getestet und haben ein anderes Abrechnungsmodell.

Weitere Informationen zur GKE Standard-Version im Vergleich zur Enterprise-Version werden im 2. Quartal 2025 veröffentlicht.

Airflow-Komponenten, bei denen Probleme bei der Kommunikation mit anderen Teilen der Managed Airflow-Konfiguration auftreten

In einigen Fällen kann es aufgrund einer fehlgeschlagenen DNS-Auflösung zu Problemen bei der Kommunikation von Airflow-Komponenten mit anderen Managed Airflow-Komponenten oder Dienstendpunkten außerhalb der Managed Airflow-Umgebung kommen.

Symptome:

Die folgenden Fehler können in den Logs von Airflow-Komponenten (z. B. Airflow-Planer, -Worker oder -Webserver) angezeigt werden:

google.api_core.exceptions.ServiceUnavailable: 503 DNS resolution failed ...
... Timeout while contacting DNS servers

oder

Could not access *.googleapis.com: HTTPSConnectionPool(host='www.googleapis.com', port=443): Max retries exceeded with url: / (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7c5ef5adba90>: Failed to resolve 'www.googleapis.com' ([Errno -3] Temporary failure in name resolution)"))

oder

redis.exceptions.ConnectionError: Error -3 connecting to
airflow-redis-service.composer-system.svc.cluster.local:6379.
Temporary failure in name resolution.

Mögliche Lösungen:

  • Führen Sie ein Upgrade auf Managed Airflow 2.9.11 oder

  • Legen Sie die folgende Umgebungsvariable fest: GCE_METADATA_HOST=169.254.169.254.

Die Umgebung befindet sich im Fehlerstatus, nachdem das Rechnungskonto des Projekts gelöscht oder deaktiviert oder die Cloud Composer API deaktiviert wurde.

Managed Airflow-Umgebungen, die von diesen Problemen betroffen sind, können nicht wiederhergestellt werden:

  • Nachdem das Rechnungskonto des Projekts gelöscht oder deaktiviert wurde, auch wenn später ein anderes Konto verknüpft wurde.
  • Nachdem die Cloud Composer API im Projekt deaktiviert wurde, auch wenn sie später wieder aktiviert wurde.

Sie können Folgendes tun, um das Problem zu beheben:

  • Sie können weiterhin auf Daten zugreifen, die in den Buckets Ihrer Umgebung gespeichert sind, aber die Umgebungen selbst sind nicht mehr nutzbar. Sie können eine neue Managed Airflow-Umgebung erstellen und dann Ihre DAGs und Daten übertragen.

  • Wenn Sie Vorgänge ausführen möchten, die dazu führen, dass Ihre Umgebungen nicht wiederhergestellt werden können, sollten Sie Ihre Daten sichern, z. B. durch Erstellen eines Snapshots der Umgebung. So können Sie eine weitere Umgebung erstellen und ihre Daten übertragen, indem Sie diesen Snapshot laden.

Warnungen zum Budget für Pod-Störungen für Umgebungscluster

In der GKE-Benutzeroberfläche für Managed Airflow-Umgebungscluster werden die folgenden Warnungen angezeigt:

GKE can't perform maintenance because the Pod Disruption Budget allows
for 0 Pod evictions. Update the Pod Disruption Budget.

A StatefulSet is configured with a Pod Disruption Budget but without readiness
probes, so the Pod Disruption Budget isn't as effective in gauging application
readiness. Add one or more readiness probes.

Diese Warnungen können nicht entfernt werden. Wir arbeiten daran, dass diese Warnungen nicht mehr generiert werden.

Mögliche Lösungen:

  • Ignorieren Sie diese Warnungen, bis das Problem behoben ist.

Ein Feldwert in einer Airflow-Verbindung kann nicht entfernt werden

Ursache:

Die Apache Airflow-Benutzeroberfläche hat eine Einschränkung, bei der es nicht möglich ist, Verbindungsfelder auf leere Werte zu aktualisieren. Wenn Sie dies versuchen, werden die zuvor gespeicherten Einstellungen wiederhergestellt.

Mögliche Lösungen:

Apache Airflow Version 2.10.4 enthält eine dauerhafte Lösung. Für Nutzer früherer Versionen gibt es einen temporären Workaround. Dazu müssen Sie die Verbindung löschen und dann neu erstellen. Lassen Sie dabei die Pflichtfelder leer. Die Befehlszeile ist die empfohlene Methode zum Löschen der Verbindung:

gcloud composer environments run ENVIRONMENT_NAME \
--location LOCATION \
connections delete -- \
CONNECTION_ID

Erstellen Sie die Verbindung nach dem Löschen über die Airflow-Benutzeroberfläche neu und achten Sie darauf, dass die Felder, die Sie leer lassen möchten, tatsächlich leer sind. Sie können die Verbindung auch erstellen, indem Sie den Airflow-CLI-Befehl connections add mit der Google Cloud CLI ausführen.

Logs für Airflow-Aufgaben werden nicht erfasst, wenn [core]execute_tasks_new_python_interpreter auf „True“ gesetzt ist

Managed Airflow erfasst keine Logs für Airflow-Aufgaben, wenn die Airflow-Konfigurationsoption [core]execute_tasks_new_python_interpreter auf True gesetzt ist.

Mögliche Lösung:

  • Entfernen Sie die Überschreibung für diese Konfigurationsoption oder legen Sie den Wert auf False fest.

Fehlende Datenpunkte in Messwerten, ValueError: Pfad kann ohne Bucket-Namen nicht bestimmt werden

In Umgebungen mit den Managed Airflow (Gen 2)-Versionen 2.16.0 und 2.16.1 kann ein bekanntes Problem bei der Berichterstellung von Messwerten auftreten. In den gemeldeten Messwerten werden möglicherweise einige übersprungene Datenpunkte angezeigt. Außerdem werden in den Umgebungsprotokollen Fehlermeldungen zu den Neustarts des airflow-monitoring-Pods angezeigt.

Beispiel für eine Fehlermeldung: ValueError: Cannot determine path without bucket name error.

Dieses Problem hat keine Auswirkungen auf die Funktionalität der Umgebung. Die Umgebung ist weiterhin betriebsbereit und die Informationen zum Zustand und Monitoring der Umgebung werden korrekt gemeldet. Sie können die Fehlermeldungen ignorieren.

Beeinträchtigte Umgebungsleistung in mehreren google-api-core-Paketversionen

Versionen von 2.28.0 bis 2.30.2

Die vorinstallierten google-api-core-Paketversionen von 2.28.0 bis 2.30.2 können zu einer verminderten Leistung der Umgebung führen. Dies kann dazu führen, dass die Ausführung einer Aufgabe länger dauert und es länger dauert, eine Aufgabe vom Status „In der Warteschlange“ in den Status „Wird ausgeführt“ zu verschieben.

Die Basis-Container-Images für die betroffenen Builds wurden gepatcht, sodass neu erstellte Umgebungen nicht betroffen sind. Nur vorhandene Umgebungen, deren Container-Images seit dem 4. November 2026 nicht aktualisiert wurden, sind weiterhin betroffen.

Betroffene Managed Airflow (Gen 3)-Builds:

  • composer-3-airflow-3.1.7-build.0 bis composer-3-airflow-3.1.7-build.5
  • composer-3-airflow-3.1.0-build.5 bis composer-3-airflow-3.1.0-build.10
  • composer-3-airflow-2.11.1-build.0
  • composer-3-airflow-2.10.5-build.22 bis composer-3-airflow-2.10.5-build.33
  • composer-3-airflow-2.9.3-build.42 bis composer-3-airflow-2.9.3-build.53

Betroffene Managed Airflow (Gen 2)-Builds:

  • composer-2.16.10-airflow-2.11.1
  • composer-2.16.0-airflow-2.10.5 bis composer-2.16.10-airflow-2.10.5
  • composer-2.16.0-airflow-2.9.3 bis composer-2.16.10-airflow-2.9.3

Lösungen:

Um dieses Problem in einer vorhandenen Umgebung zu beheben, führen Sie ein Upgrade auf ein Image durch, das am oder nach dem 6. November 2026 veröffentlicht wurde (enthält google-api-core 2.43.1), führen Sie ein Upgrade auf einen der folgenden Builds durch (enthält google-api-core 2.27.0) oder folgen Sie den Schritten zur Selbsthilfe unter Versionen von 2.30.3 bis 2.43.0 mit Python 3.11:

  • composer-3-airflow-2.11.1-build.1
  • composer-3-airflow-2.10.5-build.34
  • composer-3-airflow-2.9.3-build.54
  • composer-2.16.11-airflow-2.11.1
  • composer-2.16.11-airflow-2.10.5
  • composer-2.16.11-airflow-2.9.3

Versionen von 2.30.3 bis 2.43.0 auf Python 3.11

Ab dem 24. Oktober 2026 wird in den google-api-core-Paketversionen 2.30.3 bis 2.43.0 (sowie 2.28.0 bis 2.30.2) eine Prüfung auf die Einstellung von Python 3.11 durchgeführt. Dabei werden die Metadaten installierter Pakete gescannt, wenn eine Clientbibliothek von Google Cloud in einen neuen Python-Unterprozess importiert wird.

In Managed Airflow-Umgebungen, in denen Python 3.11 ausgeführt wird, kann dieses Verhalten die Leistung beeinträchtigen, insbesondere in Umgebungen mit vielen DAGs, häufigen kurz laufenden Aufgaben oder aktivierter Datenherkunftsintegration.

Status:

  • In den Releases vom 6. November 2026 und höher behoben: In den Images composer-3-airflow-3.3.1-build.6, composer-3-airflow-3.2.2-build.10, composer-3-airflow-2.11.1-build.23, composer-2.17.17-airflow-2.11.1 und höher ist google-api-core 2.43.1 vorinstalliert, wodurch dieses Problem behoben wird.
  • Gepatchte Basis-Images für frühere Builds: Basis-Container-Images für alle betroffenen Builds, die in diesem Abschnitt aufgeführt sind, wurden in allen Regionen gepatcht. Neu erstellte Umgebungen sind nicht betroffen, auch wenn Sie sie mit einem früheren Build erstellen.
  • Vorhandene Umgebungen: Umgebungen, die vor dem 5. November 2026 erstellt wurden, verwenden weiterhin zuvor im Cache gespeicherte Container-Images, bis sie durch geplante Wartungsarbeiten oder einen der Schritte zur Problembehebung in diesem Abschnitt aktualisiert werden.

Zu den Symptomen gehören:

  • Längere DAG-Parsing-Zeiten und höhere CPU-Auslastung auf Airflow-DAG-Prozessoren.
  • Längere Taskausführungszeiten und höhere CPU-Auslastung bei Airflow-Workern.
  • Häufige FutureWarning-Logeinträge von google/api_core/_python_version_support.py, die darauf hinweisen, dass der Support für Python 3.11 am 24.10.2027 endet.

Vor der Image-Aktualisierung waren Python 3.11-Umgebungen betroffen, in denen die google-api-core-Version 2.30.3 bis 2.43.0 vorinstalliert oder manuell installiert war, einschließlich der folgenden Builds.

Betroffene Managed Airflow (Gen 3)-Builds:

  • composer-3-airflow-3.3.1-build.0 bis composer-3-airflow-3.3.1-build.5
  • composer-3-airflow-3.2.2-build.0 bis composer-3-airflow-3.2.2-build.9
  • composer-3-airflow-3.1.8-build.0 bis composer-3-airflow-3.1.8-build.4
  • composer-3-airflow-3.1.7-build.7 bis composer-3-airflow-3.1.7-build.13
  • composer-3-airflow-2.11.1-build.3 bis composer-3-airflow-2.11.1-build.22
  • composer-3-airflow-2.10.5-build.36 bis composer-3-airflow-2.10.5-build.52

Betroffene Managed Airflow (Gen 2)-Builds:

  • composer-2.17.0-airflow-2.11.1 bis composer-2.17.16-airflow-2.11.1
  • composer-2.17.0-airflow-2.10.5 bis composer-2.17.13-airflow-2.10.5

Maßnahmen für vorhandene Umgebungen:

Wählen Sie eine der folgenden Optionen in einer beliebigen Region aus:

  • Option 1: Umgebung aktualisieren Führen Sie ein Upgrade auf composer-2.17.17-airflow-2.11.1 oder eine andere neuere Managed Airflow-Image-Version (Gen 2) durch.

  • Option 2: PyPI-Paketaktualisierung auslösen (erfordert Zugriff auf das PyPI-Repository). Aktualisieren Sie ein vorhandenes benutzerdefiniertes PyPI-Paket oder installieren Sie ein zusätzliches Paket, um das Umgebungs-Image auf dem gepatchten Basis-Image neu zu erstellen und alle Airflow-Pods neu zu starten. Installieren Sie google-api-core>=2.43.1 nicht direkt auf composer-2.17.16- oder früheren Images, da opentelemetry-api>=1.44.0 erforderlich ist und Abhängigkeitskonflikte verursacht werden.

  • Option 3 (alternative Problemumgehung ohne Upgrade oder Änderung von PyPI-Paketen): Wenden Sie einen sitecustomize.py-Laufzeitpatch an. Verwenden Sie diese Option, wenn Ihre Umgebung beispielsweise VPC Service Controls ohne Zugriff auf das PyPI-Repository verwendet und Sie nicht sofort ein Upgrade durchführen können:

    1. Laden Sie sitecustomize.py von GitHub herunter.

    2. Laden Sie sitecustomize.py in den Ordner dags/patches im Bucket Ihrer Umgebung hoch.

    3. Setzen Sie die Umgebungsvariable PYTHONPATH auf /home/airflow/gcs/dags/patches.

      Wenn PYTHONPATH bereits festgelegt ist, stellen Sie /home/airflow/gcs/dags/patches: dem vorhandenen Wert voran. Beispiel: /home/airflow/gcs/dags/patches:PREVIOUS_PYTHONPATH_VALUE

    Bereinigung: Nachdem Sie ein Upgrade Ihrer Umgebung durchgeführt oder das Image mit den vorherigen Schritten neu erstellt haben, können Sie die Überschreibung PYTHONPATH entfernen und dags/patches/sitecustomize.py löschen.

Nächste Schritte