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 werden, 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.

Die Erstellung einer verwalteten 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 nicht Deployment Manager direkt verwenden, um die in der Deployment Manager-Ankündigung erwähnten Google Cloud -Ressourcen zu verwalten.

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-Bereitstellungen, 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 noch einmal beide Bereitstellungen aus. Klicken Sie auf Löschen und wählen Sie die Option 2 Bereitstellungen löschen, aber von ihnen erstellte 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@

Das Erstellen oder Upgraden einer Managed 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 Aufgabenwiederholungen.

Die Airflow-Benutzeroberfläche lädt ein geändertes Plug-in manchmal 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 zum Ausführen der Worker-Pods verfügbar sind, werden sie 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 Sie diese Fehler sehen, 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 für den 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-UI 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, 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 mit dem VPC-Connector 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 Skalierungs- 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 (z. B. Balanced oder Scale-Out) anfordern, 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 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.

Unterstützung 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 eingestellt 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 der Taskinstanz in der Benutzeroberfläche ist anfällig für gespeichertes XSS)

Die Airflow-UI in Airflow-Versionen von 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-UI mit IAM und der Zugriffssteuerung für die Airflow-UI 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:

  • Prüfen Sie die IAM-Berechtigungen und -Rollen in Ihrem Projekt, einschließlich der Managed Service for Apache Airflow-Rollen, die einzelnen Nutzern zugewiesen sind. Sorgen Sie dafür, dass nur genehmigte Nutzer auf die Airflow-UI zugreifen können.

  • Prüfen Sie die Rollen, die Nutzern über den Mechanismus Zugriffssteuerung für die Airflow-UI zugewiesen wurden. Dies ist ein separater Mechanismus, der einen detaillierteren Zugriff auf die Airflow-UI ermöglicht. Sorgen Sie dafür, dass nur genehmigte Nutzer auf die Airflow-Benutzeroberfläche zugreifen können und dass alle neuen Nutzer mit einer geeigneten Rolle registriert sind.

  • Erwägen Sie eine zusätzliche Härtung mit VPC Service Controls.

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 so skaliert wird, dass es die von Cloud SQL-Vorgängen gespeicherten Daten aufnehmen kann, 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-Laufwerkgröße verwenden möchten, können Sie als Behelfslösung Managed Airflow-Umgebungen mit Snapshots neu erstellen.

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

Relationale Datenbanken wie Postgres oder MySQL entfernen Zeilen nicht physisch, 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 gelöschten 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 ein Nutzer von diesem Problem betroffen ist, 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 Apache Airflow in der Managed Airflow-Anwendung nicht explizit zugelassen ist, können Nutzer nicht auf die Airflow-Benutzeroberfläche 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 Taskausfü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 mit dem Webserver geteilt 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 DAG-Parseverarbeitungszeiten und DAG-Bag-Größendiagramme im Monitoring

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

Diagramme zu Airflow-DAG-Parsezeiten und DAG-Bag-Größe mit einer Reihe von nicht kontinuierlichen Intervallen
Abbildung 1. Diagramme zu nicht kontinuierlichen DAG-Analysezeiten und zur DAG-Bag-Größe (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 Zeit für das Parsen von DAGs zu verkürzen.

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 Ihre Umgebungen unwiederbringlich machen, sollten Sie Ihre Daten sichern, z. B. durch Erstellen eines Snapshots einer 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 älterer Versionen gibt es jedoch einen temporären Workaround. Dazu müssen Sie die Verbindung löschen und dann neu erstellen. Lassen Sie dabei die erforderlichen Felder 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 und in den Umgebungsprotokollen Fehlermeldungen zu den Neustarts des airflow-monitoring-Pods.

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.

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 zu composer-2.16.10-airflow-2.9.3

Führen Sie ein Upgrade Ihrer Umgebung auf einen der folgenden Builds durch, die die vorinstallierte google-api-core-Version 2.27.0 enthalten und nicht von diesem Problem betroffen sind:

  • 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

Alternativ können Sie ein Upgrade auf ein Image mit google-api-core 2.43.1 oder höher ausführen oder manuell eine kompatible Version installieren.

In Python 3.11 verursachen die google-api-core-Versionen 2.30.3 bis 2.43.0 ab dem 24. Oktober 2026 ein separates Leistungsproblem. Wenn in Ihrer Umgebung Python 3.11 ausgeführt wird, wenden Sie eine der Problemumgehungen an, die unter Versionen von 2.30.3 bis 2.43.0 in Python 3.11 aufgeführt sind.

Versionen von 2.30.3 bis 2.43.0 in Python 3.11

Ab dem 24. Oktober 2026 führen die google-api-core-Paketversionen 2.30.3 bis 2.43.0 eine Prüfung auf die Einstellung von Python 3.11 durch. Dabei werden die Metadaten installierter Pakete gescannt, wenn eine Google Cloud Clientbibliothek 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. Dieses Problem ist in Umgebungen mit vielen DAGs, häufigen kurz laufenden Aufgaben oder aktivierter Datenherkunftsintegration schwerwiegender.

Die Symptome sind folgende:

  • 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.

Dieses Problem betrifft alle Python 3.11-Umgebungen, in denen die google-api-core-Version 2.30.3 bis 2.43.0 entweder vorinstalliert oder manuell installiert ist, einschließlich der folgenden Builds.

Dieses Problem betrifft die folgenden 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

Problemumgehungen:

Wählen Sie je nach Image-Version Ihrer Umgebung eine der folgenden Optionen aus:

  • Option 1 Nur kompatible Managed Airflow-Builds (Gen 3) mit Airflow 3: Installieren Sie das PyPI-Paket google-api-core mit der Versionsbeschränkung >=2.43.1.

    Kompatible Managed Airflow-Builds (Gen 3):

    • composer-3-airflow-3.3.1-build.0 bis composer-3-airflow-3.3.1-build.5
    • composer-3-airflow-3.2.2-build.1 bis composer-3-airflow-3.2.2-build.9
    • composer-3-airflow-3.1.8-build.3 bis composer-3-airflow-3.1.8-build.4

    Verwenden Sie diese Option nicht für Airflow 2-Builds oder frühere Airflow 3-Builds, einschließlich composer-3-airflow-3.2.2-build.0 und composer-3-airflow-3.1.8-build.0 bis build.2. In diesen Builds verursacht google-api-core 2.43.1 Abhängigkeitskonflikte, da opentelemetry-api>=1.44.0 erforderlich ist. Verwenden Sie für diese Builds Option 2.

  • Option 2. Alle betroffenen Managed Airflow (Gen 3)- und Managed Airflow (Gen 2)-Builds: Wenden Sie einen sitecustomize.py-Laufzeitpatch an.

    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 nach einem Upgrade: In zukünftigen Managed Airflow-Releases wird die google-api-core-Paketversion 2.43.1 oder höher vorinstalliert sein. Nach dem Upgrade auf ein Image mit google-api-core 2.43.1 oder höher können Sie die Überschreibung von PYTHONPATH entfernen und dags/patches/sitecustomize.py löschen.

Nächste Schritte