Bekannte Probleme

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Auf dieser Seite werden bekannte Probleme mit Cloud Composer aufgeführt. Informationen zu Fehlerkorrekturen 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

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

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

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.

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

Die Erstellung der Cloud Composer-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:

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

Problemumgehungen:

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

  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 durch VPC Service Controls geschützten Google Cloud Ressourcen

In Cloud Composer 1 und Cloud Composer 2-Versionen 2.0.x wird Deployment Manager verwendet, um Komponenten von Cloud Composer-Umgebungen zu erstellen.

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

Im Tab „Deployment Manager“ kann die folgende Warnung angezeigt werden:

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-Versionen 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 Cluster bereits gelöscht ist:

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

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

Fehler beim Erstellen von Umgebungen in Projekten, in 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 cloud-airflow-prod@system.gserviceaccount.com-Konto 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 Sicherheitsbereichs hinzu, indem Sie die folgende Konfiguration in der YAML-Datei mit den Bedingungen verwenden:

     - members:
    - serviceAccount:cloud-airflow-prod@system.gserviceaccount.com

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.

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 ausführen zu lassen, und wenn der Worker noch nicht die DAG-Datei hat, schlägt die Aufgabenausführung fehl.

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

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 nicht von der Sicherheitslücke in Apache Log4j 2 (CVE-2021-44228) betroffen sein.

Als Reaktion auf die Apache Log4j 2-Sicherheitslücke (CVE-2021-44228) haben wir eine detaillierte Untersuchung durchgeführt und sind der Ansicht, dass Cloud Composer nicht anfällig für diesen Exploit ist.

Airflow-Worker oder -Planer haben möglicherweise Probleme beim Zugriff auf den Cloud Storage-Bucket der Umgebung

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

Lösungen:

  • Deaktivieren Sie das Speichern von Logs 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 eine höhere Version durch.
  • Reduzieren Sie [celery]worker_concurrency und erhöhen Sie stattdessen die Anzahl der Airflow-Worker.
  • Reduzieren Sie die Menge der Logs, die im Code des DAG erzeugt werden.
  • Befolgen Sie die Empfehlungen und Best Practices für die Implementierung von DAGs und aktivieren Sie Wiederholungsversuche für Aufgaben.

Manchmal wird ein Plug-in in der Airflow-Benutzeroberfläche nach einer Änderung nicht neu geladen.

Wenn ein Plug-in aus vielen Dateien besteht, in denen andere Module importiert werden, kann es sein, dass die Airflow-Benutzeroberfläche nicht erkennt, dass ein Plug-in neu geladen werden sollte. 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 Cloud Composer 2.

In Cloud Composer 2 bleiben nach dem Erstellen einer Umgebung mehrere Arbeitslasten im Cluster der Umgebung im Status „Nicht planbar“.

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

In diesem Fall fügt der 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, wirken sich nicht auf Ihre Umgebung aus.

Wenn dieses Problem längere Zeit (über 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 vom Cluster Autoscaler getroffen wurden. Erweitern Sie „noDecisionStatus“, um den Grund dafür 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-UI kann der Fehler 504 Gateway Timeout auftreten. Dieser Fehler kann verschiedene 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-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 Cloud Composer 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 privater 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 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 auf die Airflow-UI zugreifen können, ist der Airflow-Webserver möglicherweise überlastet und reagiert nicht mehr. 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 verschiedene 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 Konfigurationsdateien synchronisiert werden. Prüfen Sie die Webserverprotokolle auf Logeinträge, die 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 angezeigt werden, prüfen Sie, ob die in den Fehlermeldungen genannten Dateien noch im Bucket der Umgebung vorhanden sind.

    Falls 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. Überschreiben Sie eine Airflow-Konfigurationsoption. Sie können eine nicht vorhandene Airflow-Konfigurationsoption verwenden.

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

In Airflow 2 funktioniert die Baumansicht 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-UI 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 „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.

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

Symptome:

  • In Ihrer Cloud Composer 2-Umgebung haben alle Clusterarbeitslasten der Airflow-Worker den Status CrashLoopBackOff und führen keine Aufgaben aus. Außerdem können Sie OOMKilling-Warnungen sehen, die generiert werden, wenn Sie von diesem Problem betroffen sind.

  • Dieses Problem kann Umgebungsupgrades 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.
  • Der Arbeitsspeicherbedarf von Airflow-Workern in Airflow 2.6.3 mit Python 3.11 ist 10 % höher als bei Workern in früheren Versionen.
  • Der Arbeitsspeicherbedarf von Airflow-Workern in Airflow 2.3 und höher ist 30 % höher als bei Workern in Airflow 2.2 oder Airflow 2.1.

Lösungen:

  • Entfernen Sie die Überschreibung für worker_concurrency, damit Cloud Composer diesen Wert automatisch berechnet.
  • Wenn Sie einen benutzerdefinierten Wert für worker_concurrency verwenden, legen Sie ihn auf 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-Funktionen über private Netzwerke mit einem VPC-Connector 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 auslösen, um Airflow-DAGs zu starten, oder einen Ansatz basierend auf zurückstellbaren Operatoren implementieren.

Leere Ordner in Scheduler und Workern

In Cloud Composer werden leere Ordner nicht aktiv von Airflow-Workern und -Planern entfernt. Solche Einheiten werden möglicherweise im Rahmen der Synchronisierung des Umgebungs-Buckets erstellt, wenn diese Ordner im Bucket vorhanden waren und schließlich entfernt wurden.

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

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 Herunterskalierungen oder Wartungsvorgängen im Cluster Ihrer Umgebung).

Unterstützung für Kerberos

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

Unterstützung für Compute-Klassen in Cloud Composer 2 und Cloud Composer 3

Cloud Composer 3 und Cloud Composer 2 unterstützen nur die Allzweck- Compute-Klasse. Das bedeutet, dass die Ausführung von Pods, die andere Compute-Klassen anfordern (z. B. Balanced oder Scale-Out), nicht möglich ist.

In der Klasse general-purpose können Pods ausgeführt werden, die bis zu 110 GB Arbeitsspeicher und bis zu 30 CPUs anfordern (siehe Maximale Anforderungen für Compute-Klassen).

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 Cloud Composer 3- und Cloud Composer 2-Clustern nicht unterstützt wird.

Empfehlung: Verwenden Sie GKEStartPodOperator, um Kubernetes-Pods in 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 sie auch in einem Nicht-Cloud Composer-Cluster ausgeführt werden.

Support für Google Campaign Manager 360-Operatoren

Google Campaign Manager-Operatoren in Cloud Composer-Versionen vor 2.1.13 basieren auf der Campaign Manager 360 v3.5 API, die eingestellt wurde. Das Enddatum ist der 1. Mai 2023.

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.

Support 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 wurde. Das Enddatum ist der 27. April 2023.

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 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.
  • Verwenden Sie den neuen Sensor GoogleDisplayVideo360RunQuerySensor mit den Parametern query_id und report_id, um zu prüfen, ob ein Bericht fertig ist. Für den eingestellten Sensor GoogleDisplayVideo360ReportSensor war nur report_id erforderlich.
  • Für GoogleDisplayVideo360DownloadReportV2Operator sind jetzt sowohl die Parameter 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 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 Cloud Composer als 2.4.2 verwenden und vermuten, dass Ihre Umgebung anfällig für den Exploit sein könnte, lesen Sie die folgende Beschreibung und die möglichen Lösungen.

In Cloud Composer wird der Zugriff auf die Airflow-UI durch IAM und die Airflow-UI-Zugriffssteuerung geschützt.

Das bedeutet, dass Angreifer zuerst Zugriff auf Ihr Projekt sowie die erforderlichen IAM-Berechtigungen und -Rollen benötigen, um die Airflow-UI-Sicherheitslücke auszunutzen.

Lösung:

  • Prüfen Sie die IAM-Berechtigungen und -Rollen in Ihrem Projekt, einschließlich der Cloud Composer-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 Airflow-UI-Zugriffssteuerung zugewiesen sind. Dieser Mechanismus ist separat und bietet einen detaillierteren Zugriff auf die Airflow-UI. Achten Sie darauf, dass nur genehmigte Nutzer auf die Airflow-UI zugreifen können und alle neuen Nutzer mit der richtigen Rolle registriert werden.

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

Die Airflow-Monitoring-DAG der Cloud Composer 2-Umgebung wird nach dem Löschen nicht neu erstellt

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

Lösung:

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

Cloud SQL-Speicher kann nicht reduziert werden

Cloud Composer verwendet Cloud SQL zum Ausführen der Airflow-Datenbank. Im Laufe der Zeit kann der Festplattenspeicher für die Cloud SQL-Instanz anwachsen, da die Festplatte skaliert wird, um die von Cloud SQL-Vorgängen gespeicherten Daten aufzunehmen, wenn die Airflow-Datenbank wächst.

Die Cloud SQL-Festplattengröße kann nicht verkleinert werden.

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

Der Messwert „Datenbank-Festplattennutzung“ wird nach dem Entfernen von Datensätzen aus Cloud SQL nicht reduziert.

In relationalen Datenbanken wie Postgres oder MySQL werden Zeilen beim Löschen oder Aktualisieren nicht physisch entfernt. Stattdessen werden sie als „gelöschte Tupel“ markiert, um die Datenkonsistenz aufrechtzuerhalten und gleichzeitige Transaktionen nicht zu blockieren.

Sowohl MySQL als auch Postgres implementieren Mechanismen zum Freigeben von Speicherplatz nach dem Löschen von Datensätzen.

Es ist zwar möglich, die Datenbank zu zwingen, nicht verwendeten Speicherplatz freizugeben, dies ist jedoch ein ressourcenintensiver Vorgang, der die Datenbank zusätzlich sperrt und Cloud Composer nicht verfügbar macht. Daher wird empfohlen, sich auf die Build-Mechanismen zu verlassen, um den nicht verwendeten Speicherplatz zurückzugewinnen.

Zugriff blockiert: Autorisierungsfehler

Wenn ein Nutzer von diesem Problem betroffen ist, enthält das Dialogfeld Zugriff gesperrt: Autorisierungsfehler die Meldung Error 400: admin_policy_enforced.

Wenn in Google Workspace die Option API-Steuerelemente > Nicht konfigurierte Drittanbieter-Apps > Nutzer dürfen nicht auf Drittanbieter-Apps zugreifen aktiviert ist und die Apache Airflow in Cloud Composer-App 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 ermöglichen.

Anmeldeschleife beim Zugriff auf die Airflow-UI

Dieses Problem kann folgende Ursachen haben:

Aufgabeninstanzen, die in der Vergangenheit erfolgreich waren, 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 das passiert, wurde es in der Regel entweder durch eine Aktualisierung oder ein Upgrade der Umgebung oder durch die 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 Ausführung von Aufgaben.

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.

Dieses Problem betrifft nur Cloud Composer 2-Versionen 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 noch einmal versucht werden oder die Startzeit von Aufgaben kann länger sein.

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

  • (Empfohlen) Führen Sie ein Upgrade Ihrer Umgebung auf eine neuere Cloud Composer-Version durch. Dieses Problem wurde ab Cloud Composer-Version 2.11.0 behoben.

  • Als vorübergehende Problemumgehung können Sie die folgende Umgebungsvariable festlegen: GCE_METADATA_TIMEOUT=30. Entfernen Sie diese Einstellung, wenn Sie bereit sind, Ihre Umgebung zu aktualisieren.

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

In Cloud Composer 2 und Cloud Composer 3 ist der Airflow-Webserver hauptsächlich eine schreibgeschützte Komponente und Cloud Composer synchronisiert den Ordner data/ nicht mit dieser Komponente.

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

Lösung

  • Packen 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 der Airflow-Komponenten hinzugefügt und sind für sie verfügbar.

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

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

Diagramme für nicht kontinuierliche DAG-Parsing-Zeiten und die DAG-Bag-Größe im Monitoring-Dashboard weisen auf Probleme mit langen DAG-Parsing-Zeiten (mehr als 5 Minuten) hin.

Diagramme für Airflow-DAG-Parsing-Zeiten und DAG-Bag-Größe mit einer Reihe von nicht kontinuierlichen Intervallen
Abbildung 1. Diagramme für nicht kontinuierliche DAG-Parsingzeiten und DAG-Bag-Größe (zum Vergrößern klicken)

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

Cloud Composer-Komponenten-Logs fehlen in Cloud Logging

Es gibt ein Problem in 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 Cloud Composer-Ebene für eine Airflow-Komponente fehlt. Dasselbe Log ist weiterhin auf der Ebene der Kubernetes-Komponenten verfügbar.

Auftreten des Problems: sehr selten, sporadisch

Ursache:

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

Lösungen:

  • Führen Sie ein Upgrade Ihrer Umgebung auf Cloud Composer-Version 2.10.0 oder höher durch.

  • In früheren Versionen von Cloud Composer bestand die temporäre Problemumgehung in dieser Situation darin, einen Cloud Composer-Vorgang zu starten, der die Komponenten neu startet, für die das Log fehlt.

Das Wechseln des Clusters der Umgebung zu GKE Enterprise Edition 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 GKE Standard Edition erstellt.

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

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

Weitere Informationen zu GKE Standard Edition im Vergleich zur Enterprise-Version folgen im zweiten Quartal 2025.

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

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

Symptome:

In den Logs von Airflow-Komponenten wie Airflow-Planern, ‑Workern oder dem Webserver können die folgenden Fehler auftreten:

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 Cloud Composer 2.9.11 durch.

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

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

Cloud Composer-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.

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 die Ihre Umgebungen nicht mehr wiederhergestellt werden können, sollten Sie Ihre Daten sichern, z. B. indem Sie einen Snapshot der Umgebung erstellen. 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-UI für Cloud Composer-Umgebungscluster werden möglicherweise 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 deaktiviert 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, die es unmöglich macht, Verbindungsfelder auf leere Werte zu aktualisieren. Wenn Sie das 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 eine temporäre Problemumgehung. Dazu müssen Sie die Verbindung löschen und dann neu erstellen. Lassen Sie dabei die erforderlichen Felder leer. Die Befehlszeilenschnittstelle ist die empfohlene Methode zum Löschen der Verbindung:

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

Nachdem Sie die Verbindung gelöscht haben, erstellen Sie sie über die Airflow-Benutzeroberfläche neu und achten Sie darauf, dass die Felder, die Sie leer lassen möchten, tatsächlich leer bleiben. Sie können die Verbindung auch erstellen, indem Sie den connections add-Befehl der Airflow-Befehlszeile 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

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

Mögliche Lösung:

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

Nächste Schritte