Cloud Composer 1 befindet sich im Modus nach der Wartung. Google veröffentlicht keine weiteren Updates für Cloud Composer 1, einschließlich neuer Versionen von Airflow, Fehlerkorrekturen und Sicherheitsupdates. Wir empfehlen die Migration zu Cloud Composer 2.

Diese Seite wurde von der Cloud Translation API übersetzt.

Bekannte Probleme

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Auf dieser Seite werden bekannte Cloud Composer-Probleme aufgeführt. Informationen zu Fehlerkorrekturen finden Sie in den Versionshinweisen.

Einige Probleme betreffen ältere 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

Cloud Composer ist von GKE abhängig, um Nicht-RFC 1918-Adressen für Pods und Dienste bereitzustellen. In Cloud Composer wird nur die folgende Liste mit Nicht-RFC 1918-Bereichen 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

In der Airflow-Benutzeroberfläche werden keine Aufgabenlogs angezeigt, wenn sich die DAG-Serialisierung in Composer 1.10.2 und Composer 1.10.3 befindet

Durch Aktivieren der DAG-Serialisierung in Umgebungen mit Composer-Versionen 1.10.2 und 1.10.3 werden die Logs nicht im Airflow-Webserver angezeigt. Führen Sie zur Problembehebung ein Upgrade auf Version 1.10.4 oder höher durch.

Inkonsistenter Taskfehler bei der Planung in Cloud Composer

Das Problem wird im Airflow-Planer für die Aufgabeninstanz während der Ausführung einer Aufgabe angezeigt. Die Protokolle erklären jedoch nicht die Ursache des Aufgabenfehlers und der Airflow-Worker und der Airflow-Planer sahen relativ gesund aus.

Die Fehlermeldung im Airflow-Planer kann so aussehen:

Executor reports task instance <TaskInstance: xx.xxxx
scheduled__2022-04-21T06:00:00+00:00 [queued]> finished (failed) although the
task says its queued. (Info: None) Was the task killed externally?

Möglicherweise gibt es auch einen Fehler beim Airflow-Worker, der der folgenden Fehlermeldung ähnelt:

Log file is not found: gs://$BUCKET_NAME/logs/$DAG_NAME/$TASK_NAME/
2023-01-25T05:01:17.044759+00:00/1.log.
The task might not have been executed or worker executing it might have
finished abnormally (e.g. was evicted).

Um für Robustheit gegenüber solchen Fehlern zu sorgen, die auf ein langjähriges Problem in Airflow zurückzuführen sind, empfehlen wir dringend, proaktiv geeignete Wiederholungsstrategien sowohl auf Aufgaben- als auch auf DAG-Ebene zu implementieren. Durch die Implementierung dieser Maßnahmen kann das System die Auswirkungen dieser Fehler effektiv abmildern und so die Zuverlässigkeit und Resilienz des Workflows insgesamt verbessern.

GKE Workload Identity Federation for GKE wird nicht unterstützt

In Cloud Composer 1 können Sie die Workload Identity-Föderation für GKE nicht für Cluster von Cloud Composer-Umgebungen aktivieren. Daher wird möglicherweise das Ergebnis WORKLOAD_IDENTITY_DISABLED im Security Command Center angezeigt.

Während einer Aktualisierung hinzugefügte Umgebungslabels werden nicht vollständig übernommen

Aktualisierte Umgebungslabels werden nicht auf Compute Engine-VMs angewendet. Als Behelfslösung können Sie diese Labels manuell anwenden.

Airflow-Aufgabenlogs sind im Airflow-Webserver nach einem Upgrade von Airflow 1.9.0 auf Airflow 1.10.x nicht verfügbar.

In Airflow 1.10.x wurden nicht abwärtskompatible Änderungen an der Namenskonvention für Logdateien vorgenommen. In den Lognamen für Airflow-Aufgaben werden jetzt Zoneninformationen eingefügt.

Airflow 1.9.0 speichert und erwartet, dass die Log-Namen das folgende Format haben:BUCKET/logs/DAG/2020-03-30T10:29:06/1.log Airflow 1.10.x speichert und erwartet, dass die Log-Namen das folgende Format haben:BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Wenn Sie ein Upgrade von Airflow 1.9.0 auf Airflow 1.10.x durchführen und das Log für eine mit Airflow 1.9.0 ausgeführte Aufgabe lesen möchten, zeigt der Airflow-Webserver die folgende Fehlermeldung an: Unable to read remote log from BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Problemumgehung: Benennen Sie die von Airflow 1.9.0 im Cloud Storage-Bucket generierten Logs in folgendem Format um: BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Es können keine Cloud Composer-Umgebungen mit der erzwungenen Organisationsrichtlinieneinschränkung /compute.disableSerialPortLogging erstellt werden

Wird die Organisationsrichtlinie constraints/compute.disableSerialPortLogging für das Zielprojekt erzwungen, so schlägt die Erstellung der Cloud Composer-Umgebung fehl.

Diagnose

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

Rufen Sie in der Google 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:

Constraint constraints/compute.disableSerialPortLogging violated for
project <target project number>.

Problemumgehungen:

Deaktivieren Sie die Organisationsrichtlinie für das Projekt, in dem die Cloud Composer-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.
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 Cloud Composer 1 und Cloud Composer 2 Version 2.0.x werden Komponenten von Cloud Composer-Umgebungen mit Deployment Manager erstellt.

Im Dezember 2020 haben Sie möglicherweise Informationen erhalten, die Sie unter Umständen zur Konfiguration weiterer VPC Service Controls-Ressourcen benötigen, um Deployment Manager zum Verwalten von Ressourcen zu verwenden, die durch VPC Service Controls geschützt sind.

Wir möchten Sie darüber informieren, dass von Ihrer Seite aus keine Aktion erforderlich ist, falls Sie Cloud Composer nutzen und nicht direkt Deployment Manager verwenden, um in der Ankündigung von Deployment Manager erwähnte 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 Bereitstellungen von Deployment Manager, die Cloud Composer gehören, können Sie diese Warnung ignorieren.

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

Dieses Problem betrifft Cloud Composer 1 und Cloud Composer 2 Version 2.0.x.

Wenn Sie den GKE-Cluster der 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 ist:

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

Deployment Manager aufrufen
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>
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.
Löschen Sie die Bereitstellungen mit einer der folgenden Optionen:
- Wählen Sie in der Google Cloud Console beide Bereitstellungen noch einmal aus. Klicken Sie auf Löschen und wählen Sie die Option Zwei 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
```
Ihre Cloud Composer-Umgebung löschen.

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 an der Verbesserung des Cloud Composer-Dienstes, um diese Warnungen aus Airflow-Logs zu entfernen.

Das Erstellen von Umgebungen in Projekten mit Identity-Aware Proxy APIs, die dem VPC Service Controls-Perimeter hinzugefügt wurden, schlägt fehl

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

Sie haben folgende Möglichkeiten, Umgebungen zu erstellen:

Fügen Sie dem Sicherheitsperimeter nicht die Cloud Identity-Aware Proxy API und die Identity-Aware Proxy TCP API hinzu.
Fügen Sie das Dienstkonto cloud-airflow-prod@system.gserviceaccount.com als Mitglied Ihres Sicherheitsperimeters hinzu. Verwenden Sie dazu die folgende Konfiguration in der YAML-Bedingungsdatei:
```
 - members:
    - serviceAccount:cloud-airflow-prod@system.gserviceaccount.com
```

Wird die Richtlinie „compute.requireOsLogin“ aktiviert, schlägt das Erstellen der Cloud Composer 1-Umgebung fehl.

Wenn die Richtlinie compute.requireOsLogin in Ihrem Projekt auf true gesetzt ist, schlägt das Erstellen der Cloud Composer 1-Umgebung fehl.

Deaktivieren Sie diese Richtlinie in Ihrem Projekt, um Cloud Composer 1-Umgebungen zu erstellen.

Weitere Informationen zu dieser Organisationsrichtlinie finden Sie unter Einschränkungen für Organisationsrichtlinien.

Wenn die Richtlinie compute.vmExternalIpAccess deaktiviert ist, schlägt das Erstellen oder Aktualisieren der Cloud Composer-Umgebung fehl.

Dieses Problem betrifft Cloud Composer 1- und Cloud Composer 2-Umgebungen.

Cloud Composer-eigene GKE-Cluster, die im Modus für öffentliche IP-Adressen konfiguriert sind, erfordern 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.

Wenn die Richtlinie compute.vmCanIpForward deaktiviert ist, schlägt das Erstellen der Cloud Composer 1-Umgebung fehl.

In Cloud Composer 1-Umgebungen, die im Modus nicht VPC-nativ (mit Alias-IP) erstellt werden, ist diese Richtlinie erforderlich, um das Erstellen von VMs mit der aktivierten Funktion „IP-Weiterleitung“ zu ermöglichen. 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 plant, sie von einem Worker ausgeführt zu werden, und wenn der Worker noch nicht die DAG-Datei hat, schlägt die Aufgabenausführung fehl.

Um dieses Problem zu minimieren, sind Umgebungen mit Airflow 2 standardmäßig so konfiguriert, dass bei einer fehlgeschlagenen Aufgabe zwei Wiederholungen ausgeführt werden. Wenn eine Aufgabe fehlschlägt, wird sie zweimal mit Intervallen von 5 Minuten wiederholt.

So beheben Sie das Problem in Airflow 1: Überschreiben Sie die Airflow-Konfigurationsoption [core]default_task_retries und legen Sie sie auf eine Zahl größer oder gleich 2 fest.

Aufgabe schlägt mit „OSError: [Errno 5] Input/output error“ in Airflow 1.10.15 oder früheren Versionen fehl

Ein Programmfehler in Airflow-1-Versionen führt dazu, dass in einigen seltenen Fällen Aufgaben zweimal in die Redis-Warteschlange gestellt werden.

Manchmal kann dies zu einer Race-Bedingung in der Logdatei und einem nachfolgenden Aufgabenfehler führen. Aufgaben schlagen mit OSError: [Errno 5] Input/output error in Cloud Logging und Task is in the 'running' state which is not a valid state for execution. im Aufgabenversuchslog fehl.

Dieser Fehler wurde in Airflow 2 behoben. Wenn dieses Problem in Airflow 1 bei einer lang andauernden Aufgabe auftritt, erhöhen Sie den Wert der Airflow-Konfigurationsoption [celery_broker_transport_options]visibility_timeout (Standardwert ist 604800 für Composer 1.17.0, 21600 für ältere Umgebungen). Erwägen Sie bei kurz laufenden Aufgaben, zusätzliche Wiederholungen zu den betroffenen Aufgaben hinzuzufügen oder Ihre Umgebung zu Airflow 2 zu migrieren.

Dataproc- und Dataflow-Operatoren schlagen mit Negsignal.SIGSEGV fehl

Dies ist ein vorübergehendes Problem der grcpio-Bibliothek, wenn sie von einem Celery-Worker verwendet wird. Dieses Problem betrifft Airflow-Versionen ab 1.10.14.

Das Problem lässt sich dadurch umgehen, dass Sie die Abfragestrategie grpcio ändern. Dazu fügen Sie der Umgebung die folgende Umgebungsvariable hinzu: GRPC_POLL_STRATEGY=epoll1. Diese Problemumgehung wurde bereits in Cloud Composer 1.17.1 und höheren Versionen angewendet.

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

Cloud Composer verwaltet zugrunde liegende Cloud Composer-Cluster. Sofern Sie diese APIs nicht explizit in Ihren DAGs und Ihrem Code verwenden, können Sie Ankündigungen zu verworfenen GKE APIs ignorieren. Cloud Composer übernimmt bei Bedarf alle Migrationen.

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

Wir haben Cloud Composer auf die Apache Log4j 2-Sicherheitslücke (CVE-2021-44228) hin untersucht und sind zu dem Schluss gekommen, dass Cloud Composer nicht anfällig für diese Ausnutzung ist.

Airflow-Worker oder -Planer können beim Zugriff auf den Cloud Storage-Bucket der Umgebung Probleme auftreten.

Cloud Composer verwendet gcsfuse, um auf den Ordner /data im Bucket der Umgebung zuzugreifen und Airflow-Aufgabenprotokolle 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 Transport endpoint is not connected-Fehler angezeigt.

Lösungen:

Deaktivieren Sie das Speichern von Protokollen im Bucket der Umgebung. Diese Option ist bereits standardmäßig deaktiviert, wenn eine Umgebung mit Cloud Composer 2.8.0 oder höher erstellt wird.
Führen Sie ein Upgrade auf Cloud Composer 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 Anzahl der Protokolle, die im DAG-Code generiert werden.
Befolgen Sie die Empfehlungen und Best Practices für die Implementierung von DAGs und aktivieren Sie die Wiederholung von Aufgaben.

Die Airflow-Benutzeroberfläche lädt ein Plug-in manchmal nicht neu, nachdem es geändert wurde.

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

Intermittierende Probleme bei der Kommunikation mit der Datenbank der Umgebung

Dieses bekannte Problem betrifft nur Cloud Composer 1.

Bei einigen älteren Cloud Composer 1-Umgebungen (1.16.3 oder älter), die vor dem 12. August 2021 erstellt wurden, kann es zu vorübergehenden Problemen mit der Kommunikation mit der Airflow-Datenbank kommen.

In diesem Fall wird in den Airflow-Task-Logs die folgende Fehlermeldung angezeigt:

"Can't connect to MySQL server on 'airflow-sqlproxy-service.default.svc.cluster.local' (104)"

Das Cloud Composer-Team arbeitet an der Lösung dieses Problems. Wenn Sie der Meinung sind, dass Sie von diesem Problem stark betroffen sind, können Sie in der Zwischenzeit Folgendes tun, um die Auswirkungen zu minimieren:

Rufen Sie in der Google Cloud Console die Seite Umgebungskonfiguration der betroffenen Cloud Composer-Umgebungen auf.
Klicken Sie auf den Link Clusterdetails aufrufen, um den zugrunde liegenden GKE-Cluster der Umgebung aufzurufen.
Rufen Sie den Tab Knoten auf und klicken Sie im Bereich Knotenpools auf default-pool.

Abbildung 1: „default-pool“ in der Liste der Knotenpools (zum Vergrößern anklicken)
Klicken Sie oben auf der Seite auf Bearbeiten.
Ändern Sie den Image-Typ in Container-Optimized OS mit containerd und speichern Sie die Konfiguration:

Abbildung 2. Image-Typ des Knotenpools von Docker zu containerd ändern (zum Vergrößern anklicken)
Sobald die Änderung eingereicht wurde, wird der Knotenpool default-pool so neu konfiguriert, dass containerd als Containerlaufzeit verwendet wird. Einige Ihrer Airflow-Aufgaben schlagen möglicherweise fehl, während der Knotenpool neu konfiguriert wird. Wenn für diese Aufgaben Wiederholungen konfiguriert sind, werden sie von Airflow noch einmal ausgeführt, sobald der Vorgang am Knotenpool abgeschlossen ist.

Fehler 504 beim Zugriff auf die Airflow-Benutzeroberfläche

Der Fehler 504 Gateway Timeout kann beim Zugriff auf die Airflow-Benutzeroberfläche 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 Cloud Composer 3) Verbindungsproblem. Wenn die Airflow-Benutzeroberfläche dauerhaft nicht verfügbar ist und Zeitüberschreitungen oder 504-Fehler auftreten, prüfen Sie, ob Ihre Umgebung auf *.composer.googleusercontent.com zugreifen kann.
(Nur Cloud Composer 2) Verbindungsproblem. Wenn die Airflow-Benutzeroberfläche dauerhaft nicht verfügbar ist und Zeitüberschreitungen oder 504-Fehler auftreten, prüfen Sie, ob Ihre Umgebung auf *.composer.cloud.google.com zugreifen kann. Wenn Sie den privaten Google-Zugriff verwenden und Traffic über private.googleapis.com-virtuelle IP-Adressen senden oder VPC Service Controls verwenden und Traffic über restricted.googleapis.com-virtuelle IP-Adressen senden, muss Ihr Cloud DNS auch für *.composer.cloud.google.com-Domainnamen konfiguriert sein.
Der Airflow-Webserver reagiert nicht. Wenn der Fehler 504 weiterhin auftritt, Sie aber zu bestimmten Zeiten weiterhin 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 keine eingehenden Anfragen bedienen kann. Dieser Fehler kann mehrere Ursachen haben:

Vorübergehendes Kommunikationsproblem. Versuchen Sie später noch einmal, 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 Webserverprotokolle auf Einträge, die 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.

Bei versehentlichem Entfernen (z. B. weil eine Aufbewahrungsrichtlinie konfiguriert wurde) können Sie sie so wiederherstellen:
1. Legen Sie in Ihrer Umgebung eine neue Umgebungsvariable fest. Sie können einen beliebigen Variablennamen und -wert verwenden.
2. Überschreiben Sie eine Airflow-Konfigurationsoption. Sie können eine nicht vorhandene Airflow-Konfigurationsoption verwenden.

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

Wie unter CVE-2021-45229 beschrieben, war der Bildschirm „DAG mit Konfiguration auslösen“ anfällig für XSS-Angriffe über das Abfrageargument origin.

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

DAG-Triggerung über private Netzwerke mit Cloud Run-Funktionen

Das Auslösen von DAGs mit Cloud Run-Funktionen über private Netzwerke mithilfe des VPC-Connectors wird von Cloud Composer nicht unterstützt.

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

Leere Ordner im Scheduler und in den Workern

Cloud Composer entfernt leere Ordner nicht aktiv aus Airflow-Workern und -Planern. Solche Entitäten können durch die Bucket-Synchronisierung der Umgebung erstellt werden, wenn diese Ordner im Bucket vorhanden waren und später entfernt wurden.

Empfehlung: Passen Sie Ihre DAGs so an, dass sie solche leeren Ordner überspringen.

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

Unterstützung für Kerberos

Cloud Composer unterstützt die Kerberos-Konfiguration von Airflow nicht.

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

Google Campaign Manager-Operator in Cloud Composer-Versionen vor 2.1.13 basieren auf der Campaign Manager 360 v3.5 API, die eingestellt wird und am 1. Mai 2023 eingestellt wird.

Wenn Sie Google Campaign Manager-Operatoren verwenden, führen Sie ein Upgrade Ihrer Umgebung auf Cloud Composer Version 2.1.13 oder höher durch.

Unterstützung für Google Display & Video 360-Operatoren

Google Display & Video 360-Operatoren in Cloud Composer-Versionen vor 2.1.13 basieren auf der Display & Video 360 v1.1 API, die eingestellt wird und am 27. April 2023 eingestellt wird.

Wenn Sie Google Display & Video 360-Operatoren verwenden, führen Sie ein Upgrade Ihrer Umgebung auf Cloud Composer Version 2.1.13 oder höher durch. Außerdem müssen Sie möglicherweise Ihre DAGs ändern, da einige der Google Display & Video 360-Operatoren eingestellt und durch neue ersetzt werden.

GoogleDisplayVideo360CreateReportOperator ist jetzt eingestellt. Verwenden Sie stattdessen GoogleDisplayVideo360CreateQueryOperator. Dieser Operator gibt query_id anstelle von report_id zurück.
GoogleDisplayVideo360RunReportOperator ist jetzt 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.
Mit dem neuen Sensor GoogleDisplayVideo360RunQuerySensor, der die Parameter query_id und report_id verwendet, können Sie prüfen, ob ein Bericht verfügbar ist. Für den eingestellten GoogleDisplayVideo360ReportSensor-Sensor war nur report_id erforderlich.
Für GoogleDisplayVideo360DownloadReportV2Operator sind jetzt sowohl query_id als auch 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 Seite mit den Details zur Taskinstanz in der Benutzeroberfläche ist anfällig für gespeicherte XSS-Angriffe)

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

Wenn Sie eine ältere Cloud Composer-Version als 2.4.2 verwenden und vermuten, dass Ihre Umgebung anfällig für den Exploit ist, lesen Sie die folgende Beschreibung und die möglichen Lösungen.

In Cloud Composer wird der Zugriff auf die Airflow-Benutzeroberfläche mit IAM und der Zugriffssteuerung der Airflow-Benutzeroberfläche geschützt.

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

Lösung:

Prüfen Sie die IAM-Berechtigungen und -Rollen in Ihrem Projekt, einschließlich der Cloud Composer-Rollen, die einzelnen Nutzern zugewiesen sind. Achten Sie darauf, dass nur genehmigte Nutzer auf die Airflow-Benutzeroberfläche zugreifen können.
Überprüfen Sie die Rollen, die Nutzern über den Mechanismus Airflow UI Access Control (Zugriffssteuerung der Airflow-Benutzeroberfläche) zugewiesen wurden. Dies ist ein separater Mechanismus, der einen detaillierteren Zugriff auf die Airflow-Benutzeroberfläche ermöglicht. Achten Sie darauf, dass nur genehmigte Nutzer auf die Airflow-Benutzeroberfläche zugreifen können und dass alle neuen Nutzer mit einer geeigneten Rolle registriert sind.
Sie können die Sicherheit mit VPC Service Controls weiter erhöhen.

Cloud SQL-Speicherplatz kann nicht reduziert werden

Cloud Composer verwendet Cloud SQL, um die Airflow-Datenbank auszuführen. Im Laufe der Zeit kann der Laufwerkspeicher für die Cloud SQL-Instanz zunehmen, da das Laufwerk skaliert wird, um die von Cloud SQL-Vorgängen gespeicherten Daten aufzunehmen, wenn die Airflow-Datenbank wächst.

Die Größe des Cloud SQL-Laufwerks kann nicht verringert werden.

Wenn Sie die kleinste Cloud SQL-Speicherplatzgröße verwenden möchten, können Sie Cloud Composer-Umgebungen mit Snapshots neu erstellen.

Der Messwert „Datenplattennutzung der Datenbank“ wird nach dem Entfernen von Einträgen 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“ gekennzeichnet, um die Datenkonsistenz aufrechtzuerhalten und das Blockieren paralleler Transaktionen zu vermeiden.

Sowohl MySQL als auch Postgres implementieren Mechanismen zur Wiederverwendung von Speicherplatz nach dem Löschen von Einträgen.

Es ist zwar möglich, die Datenbank zu zwingen, nicht verwendeten Speicherplatz zurückzufordern, aber dies ist ein ressourcenintensiver Vorgang, der die Datenbank zusätzlich sperrt und Cloud Composer nicht verfügbar macht. Daher wird empfohlen, die Gebäudemechanismen zu verwenden, um den nicht verwendeten Speicherplatz wiederherzustellen.

Aufgabeninstanzen, die in der Vergangenheit erfolgreich waren, als FAILED markiert

In einigen Fällen und seltenen Szenarien können Airflow-Aufgabeninstanzen, die in der Vergangenheit erfolgreich waren, als FAILED markiert werden.

In der Regel wird er entweder durch eine Umgebungsaktualisierung oder ein Upgrade oder durch eine GKE-Wartung ausgelöst.

Hinweis:Das Problem selbst weist nicht auf ein Problem in der Umgebung hin und führt nicht zu tatsächlichen Fehlern bei der Aufgabenausführung.

Das Problem wurde in Cloud Composer Version 2.6.5 oder höher behoben.

Airflow-Komponenten haben Probleme bei der Kommunikation mit anderen Teilen der Cloud Composer-Konfiguration

In sehr seltenen Fällen kann die langsame Kommunikation mit dem Compute Engine-Metadatenserver dazu führen, dass Airflow-Komponenten nicht optimal funktionieren. So kann es beispielsweise vorkommen, dass der Airflow-Planer neu gestartet wird, Airflow-Aufgaben noch einmal versucht werden müssen oder die Startzeit der Aufgabe länger ist.

Symptome:

Die folgenden Fehler werden in den Logs von Airflow-Komponenten wie Airflow-Planern, Workern oder dem 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

Legen Sie die folgende Umgebungsvariable fest: GCE_METADATA_TIMEOUT=30.

Diagramme für nicht kontinuierliche DAG-Parsing-Zeiten und DAG-Bag-Größe im Monitoring

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

Diagramme mit Airflow-DAG-Parsing-Zeiten und DAG-Bag-Größen, die eine Reihe von nicht zusammenhängenden Intervallen zeigen — **Abbildung 3.** Diagramme für nicht kontinuierliche DAG-Parsingzeiten und DAG-Bag-Größen (zum Vergrößern anklicken)

Lösung:Wir empfehlen, die Gesamtzeit für die DAG-Analyse unter 5 Minuten zu halten. Um die DAG-Parsingzeit zu verkürzen, folgen Sie den Richtlinien zum Schreiben von DAGs.

Der Wechsel des Clusters der Umgebung zur GKE Enterprise-Version wird nicht unterstützt.

Dieser Hinweis gilt für Cloud Composer 1 und Cloud Composer 2.

Der GKE-Cluster der Cloud Composer-Umgebung wird in der GKE Standard Edition erstellt.

Ab Dezember 2024 wird das Erstellen von Cloud Composer-Umgebungen mit Clustern in der Enterprise-Version nicht mehr vom Cloud Composer-Dienst unterstützt.

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

Weitere Informationen zur GKE Standard- und Enterprise-Version erhalten Sie im 2. Quartal 2025.

Die Umgebung hat den Status „FEHLER“, nachdem das Rechnungskonto des Projekts gelöscht oder deaktiviert wurde oder die Cloud Composer API deaktiviert wurde

Von diesen Problemen betroffene Cloud Composer-Umgebungen 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.

So können Sie das Problem beheben:

Sie können weiterhin auf Daten in den Buckets Ihrer Umgebung zugreifen. Die Umgebungen selbst können jedoch nicht mehr verwendet werden. Sie können eine neue Cloud Composer-Umgebung erstellen und dann Ihre DAGs und Daten übertragen.
Wenn Sie einen der Vorgänge ausführen möchten, durch den Ihre Umgebungen nicht wiederhergestellt werden können, sollten Sie Ihre Daten sichern, z. B. indem Sie einen Snapshot einer Umgebung erstellen. So können Sie eine weitere Umgebung erstellen und die Daten übertragen, indem Sie diesen Snapshot laden.