Bekannte Probleme

Cloud Composer 1 Cloud Composer 2

Auf dieser Seite werden bekannte Cloud Composer-Probleme aufgeführt. Einige Fehlerkorrekturen für diese Probleme sind derzeit in Arbeit und werden in zukünftigen Versionen verfügbar sein.

Einige Probleme betreffen ältere Versionen. Sie können durch Upgrade der Umgebung behoben werden.

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

Cloud Composer ist darauf angewiesen, dass GKE Unterstützung für Adressen außerhalb RFC 1918 für Pods und Dienste bereitstellt. Derzeit wird in Cloud Composer nur die folgende Liste von Bereichen außerhalb 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

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.

Zeitweise fehlgeschlagenen Aufgaben während der Planung in Cloud Composer

Das Problem wird in einem Airflow-Planer für die Taskinstanz während der Ausführung der Task angezeigt. Die Logs erklären jedoch nicht die Ursache des Taskfehlers und der Airflow-Worker und der Airflow-Planer sahen relativ fehlerfrei aus.

Die Fehlermeldung im Airflow-Planer kann wie folgt 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?

Es kann auch ein Fehler im Airflow-Worker auftreten, der diesem Fehler ä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 die Robustheit solcher Fehler zu gewährleisten, die auf einem langjährigen Problem in Airflow zurückzuführen sind, wird dringend empfohlen, proaktiv geeignete Wiederholungsstrategien sowohl auf Aufgaben- als auch auf DAG-Ebene zu implementieren. Durch die Einbeziehung dieser Maßnahmen kann das System die Auswirkungen dieser Fehler effektiv abschwächen und so die Zuverlässigkeit und Robustheit des Workflows insgesamt verbessern.

GKE Workload Identity wird nicht unterstützt

Dieses Problem betrifft nur Cloud Composer 1-Umgebungen. Cloud Composer 2-Umgebungen verwenden Workload Identity.

Sie können Workload Identity nicht für Cloud Composer-Umgebungscluster aktivieren. Daher wird in Security Command Center möglicherweise das Ergebnis WORKLOAD_IDENTITY_DISABLED angezeigt.

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

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

GKE-Upgrades im Zusammenhang mit Problem CVE-2020-14386

Wir arbeiten derzeit an der Behebung der Sicherheitslücke CVE-2020-14386 in allen Cloud Composer-Umgebungen. Im Rahmen der Fehlerbehebung werden alle vorhandenen GKE-Cluster von Cloud Composer auf eine neuere Version aktualisiert.

Kunden, die sich dazu entschließen, die Sicherheitslücke sofort zu beheben, können ein Upgrade für Composer-GKE-Cluster ausführen. Dazu folgen sie dieser Anleitung und berücksichtigen dabei Folgendes:

Schritt 1: Wenn Sie eine Cloud Composer-Version vor Version 1.7.2 ausführen, führen Sie ein Upgrade auf eine neuere Version von Cloud Composer durch. Wenn Sie bereits Version 1.7.2 oder höher haben, fahren Sie mit dem nächsten Punkt fort.

Schritt 2: Aktualisieren Sie die GKE-Cluster (Master und Knoten) auf die neueste 1.15-Patch-Version, die den Fehlerbehebung für diese Sicherheitslücke enthält.

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

Mit Airflow 1.10.x wurden nicht abwärtskompatible Änderungen an der Namenskonvention für Logdateien eingeführt. Den Lognamen für Airflow-Aufgaben werden jetzt Zoneninformationen hinzugefü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 constraints/compute.disableSerialPortLogging für das Zielprojekt erzwungen, so schlägt die Erstellung der Cloud Composer-Umgebung fehl.

Hinweis: Dieses Problem tritt nur bei Clustern auf, die vor der Cloud Composer-Version vom 9. November 2020 erstellt wurden. In Cloud Composer-Umgebungen, die nach dem 9. November 2020 erstellt wurden, wurden alle GKE-Clusterknoten erstellt, die mit serial-logging-enable=false erstellt wurden. Dieses Problem wird dadurch verhindert.

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:

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 Google Cloud-Ressourcen, die durch VPC Service Controls geschützt sind

Composer verwendet Deployment Manager, 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 verdeutlichen, dass Ihrerseits keine Maßnahmen erforderlich sind, wenn Sie Composer verwenden und Deployment Manager nicht direkt zum Verwalten von Google Cloud-Ressourcen verwenden, die in der Ankündigung von Deployment Manager erwähnt werden.

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

Wenn Sie den 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 GKE-Cluster bereits gelöscht ist:

1. Öffnen Sie in der Google Cloud Console die Seite Deployment Manager.

   Seite „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 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.

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.

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 der Umgebung schlägt in Projekten mit Identity-Aware Proxy-APIs fehl, die dem VPC Service Controls-Perimeter hinzugefügt wurden.

Hinweis: Dieses Problem betrifft alle Versionen von Cloud Composer 1 und 2.0.* von Cloud Composer 2.

In Projekten mit aktiviertem VPC Service Controls benötigt das Konto [e-mail] expliziten Zugriff in Ihrem Sicherheitsperimeter, um Umgebungen zu erstellen.

Zum Erstellen von Umgebungen können Sie eine der folgenden Lösungen verwenden:

• 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 [e-mail] als Mitglied des Sicherheitsperimeters hinzu. Verwenden Sie dazu die folgende Konfiguration in der YAML-Bedingungsdatei:

   - members:
      - serviceAccount:[e-mail]
  

Die Cloud Composer 1-Umgebung kann nicht erstellt werden, wenn die Richtlinie compute.requireOsLogin aktiviert ist

Wenn die Richtlinie compute.requireOsLogin in Ihrem Projekt auf true gesetzt ist, schlägt das Erstellen der Cloud Composer 1 v1-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.

Das Erstellen oder Upgraden der Cloud Composer-Umgebung schlägt fehl, wenn compute.vmExternalIpAccess deaktiviert ist

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.

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

Wenn die Richtlinie compute.vmCanIpForward deaktiviert ist, schlägt das Erstellen der Cloud Composer-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.

Hinweis: Diese Anforderung gilt nur für Cloud Composer 1.

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. Diese Synchronisierungen werden unabhängig voneinander durchgeführt. 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.

Als Behelfslösung können Airflow-2-Umgebungen in Cloud Composer 1.17.0-preview.9 und höhere versions standardmäßig so konfiguriert werden, 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.

So verwenden Sie die Problemumgehung in Problem 1: Überschreiben Sie die core-default_task_retries Airflow-Konfigurationsoption 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/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.

GKE-Upgrades im Zusammenhang mit Sicherheitsproblemen mit CVE-2021-25741

Alle GKE-Cluster von Cloud Composer werden automatisch auf neuere GKE-Versionen aktualisiert, wobei die in CVE-2021-25741 beschriebenen Probleme behoben werden.

Wenn Sie diese Sicherheitslücke sofort beheben möchten, führen Sie ein Upgrade des GKE-Clusters Ihrer Umgebung durch. Folgen Sie dazu der Anleitung zum Upgrade eines Clusters.

• Wenn Sie eine Cloud Composer 1-Umgebung und GKE-Version 1.18.x oder früher haben, aktualisieren Sie auf 1.18.20-gke.4501.

• Wenn Sie eine Cloud Composer 1-Umgebung und GKE-Version 1.19.x haben, führen Sie ein Upgrade auf 1.19.14-gke.301 durch.

• Wenn Sie eine Cloud Composer 2-Umgebung und GKE-Version 1.21.x haben, führen Sie ein Upgrade auf 1.21.4-gke.301 durch.

Cloud Composer 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 Cloud Composer eine detaillierte Untersuchung durchgeführt und wir sind der Meinung, dass Cloud Composer nicht anfällig für diesen Exploit ist.

Cloud Composer 2: Bei Airflow-Workern oder Planern können Probleme beim Zugriff auf Cloud Storage-Buckets auftreten

In einigen sporadischen Situationen kann es bei Cloud Composer 2-Umgebungen zu Fehlfunktionen kommen, wenn der Airflow-Worker oder der Airflow-Planer neu gestartet wird, und es können Probleme beim Zugriff auf den Inhalt des Cloud Storage-Bucket auftreten.

In diesem Fall werden in Airflow-Logs möglicherweise Fehler angezeigt, die mit Transport endpoint is not connected beginnen.

Das Fehlerlog für den Airflow-Worker könnte beispielsweise so aussehen:

[Errno 107] Transport endpoint is not connected: '/home/airflow/gcs/logs/airflow_monitoring/echo/2022-01-11T22:50:48+00:00'

Lösung:

• Upgrade auf Cloud Composer 2.0.26 oder höher ausführen

Ein Plug-in wird in der Airflow-UI möglicherweise nicht neu geladen, nachdem es geändert wurde

Wenn ein Plug-in aus vielen Dateien besteht, die andere Module importieren, erkennt die Airflow-UI möglicherweise nicht, dass ein Plug-in neu geladen werden sollte. In einem solchen Fall muss ein Neustart des Airflow-Webservers ausgelöst werden. Dazu können Sie eine Umgebungsvariable hinzufügen oder PYPI-Abhängigkeiten installieren oder deinstallieren. Sie können auch den Airflow-Webserver neu starten.

Zeitweilige Probleme bei der Kommunikation mit der Airflow-Metadatendatenbank

Dieses bekannte Problem betrifft nur Cloud Composer 1.

In einigen älteren Cloud Composer 1-Umgebungen (1.16.3 oder früher), die vor dem 12. August 2021 erstellt wurden, können vorübergehende Probleme im Zusammenhang mit der Kommunikation mit Airflow-Metadatendatenbanken auftreten.

Wenn dieses Problem auftritt, 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 stark von dem Problem betroffen sind, können Sie es so beheben:

1. Rufen Sie in der Google Cloud Console die Seite Umgebungskonfiguration der betroffenen Cloud Composer-Umgebungen auf.
2. Folgen Sie dem Link Clusterdetails ansehen, um den der Umgebung zugrunde liegenden GKE-Cluster aufzurufen.
3. Gehen Sie zum Tab Knoten und klicken Sie im Abschnitt Knotenpools auf default-pool.
4. Klicken Sie oben auf der Seite auf Bearbeiten.
5. Ändern Sie den Image-Typ in Container-Optimized OS mit containerd und speichern Sie die Konfiguration wie unten dargestellt.
6. Nachdem die Änderung gesendet wurde, wird der Knotenpool default-pool neu konfiguriert, um containerd als Containerlaufzeit zu verwenden. 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 für den Knotenpool abgeschlossen ist.

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

Dieses bekannte Problem betrifft nur Cloud Composer 2.

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

Wenn eine Umgebung hochskaliert wird, werden neue Worker-Pods erstellt und Kubernetes versucht, sie auszuführen. Wenn keine kostenlosen Ressourcen zum Ausführen verfügbar sind, werden die Worker-Pods als nicht planbar gekennzeichnet.

In diesem Fall fügt der Cluster-Autoscaling 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 lange (mehr als 1 Stunde) besteht, können Sie die Logs von Cluster Autoscaler überprü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>"

Es enthält Informationen zu den vom Cluster-Autoscaling getroffenen Entscheidungen. Maximieren Sie jeden noDecisionStatus, um den Grund zu sehen, warum der Cluster nicht hoch- oder herunterskaliert werden kann.

Fehler 504 beim Zugriff auf die Airflow-UI

Beim Zugriff auf die Airflow-UI wird der Fehler 504 Gateway Timeout angezeigt. Dieser Fehler kann mehrere Ursachen haben:

• Vorübergehendes Kommunikationsproblem. Versuchen Sie in diesem Fall später, auf die Airflow-UI zuzugreifen. Sie können auch den Airflow-Webserver neu starten.
• Konnektivitätsproblem (nur Cloud Composer 2). Wenn die Airflow-UI dauerhaft nicht verfügbar ist und Zeitüberschreitungs- oder 504-Fehler auftreten, prüfen Sie, ob Ihre Umgebung auf *.composer.cloud.google.com zugreifen kann. Wenn Sie den privater Google-Zugriff verwenden, Traffic über virtuelle private.googleapis.com-IP-Adressen oder VPC Service Controls senden und Traffic über restricted.googleapis.com virtuelle 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 besteht, Sie aber zu bestimmten Zeiten trotzdem auf die Airflow-UI zugreifen können, reagiert der Airflow-Webserver möglicherweise nicht mehr, da er überlastet ist. Versuchen Sie, die Parameter für Skalierung und Leistung des Webservers zu erhöhen.

Fehler 502 beim Zugriff auf die Airflow-UI

Der Fehler 502 Internal server exception gibt an, dass eingehende Anfragen über die Airflow-UI nicht verarbeitet werden können. Dieser Fehler kann mehrere Ursachen haben:

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

• Webserver konnte nicht gestartet werden. Zuerst müssen die Konfigurationsdateien des Webservers synchronisiert werden. Prüfen Sie Webserverlogs auf Logeinträge, die in etwa so aussehen: GCS sync exited with 1: gsutil -m cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp oder GCS sync exited with 1: gsutil -m 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 Fehlermeldungen erwähnten 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.

Die Airflow-UI in Airflow 2.2.3 und früheren Versionen ist anfällig für CVE-2021-45229.

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

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 Umgebung von Airflow-Workern den Status CrashLoopBackOff und führen keine Aufgaben aus. Wenn Sie von diesem Problem betroffen sind, werden auch OOMKilling-Warnungen angezeigt.

• Dieses Problem kann Umgebungsupgrades verhindern.

Ursache:

• Wenn Sie einen benutzerdefinierten Wert für die Airflow-Konfigurationsoption [celery]worker_concurrency und benutzerdefinierte Arbeitsspeichereinstellungen für Airflow-Worker verwenden, tritt dieses Problem möglicherweise auf, wenn sich der Ressourcenverbrauch dem Limit nähert.
• Die Arbeitsspeicheranforderungen an Airflow-Worker in Airflow 2.6.3 mit Python 3.11 sind 10 % höher im Vergleich zu Workern in früheren Versionen.
• Die Arbeitsspeicheranforderungen an Airflow-Worker in Airflow 2.3 und höheren Versionen sind 30 % höher als 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 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 aus diesem Grund kein Upgrade Ihrer Umgebung auf eine neuere Version ausführen, wenden Sie eine der vorgeschlagenen Lösungen vor dem Upgrade an.

DAG-Trigger über private Netzwerke mit Cloud Functions

Das Auslösen von DAGs mit Cloud Functions über private Netzwerke bei Verwendung eines VPC-Connectors wird von Cloud Composer nicht unterstützt.

Empfehlung: Verwenden Sie Cloud Functions, um Nachrichten in Pub/Sub zu veröffentlichen. Mit solchen Ereignissen können Pub/Sub-Sensoren Airflow-DAGs auslösen oder einen auf verzögernden Operatoren beruhenden Ansatz implementieren.

Problem mit gcloud composer-Befehlen in Version 410.0.0

In der gcloud-Version 410.0.0 werden die folgenden Cloud Composer-Befehle verwendet:

• gcloud composer environments run
• gcloud composer environments list-packages

einen Fehlercode ungleich null zurückgeben und diese Fehlermeldung anzeigen:

  (ERROR: gcloud crashed (TypeError): 'NoneType' object is not callable)

Dieses Verhalten tritt zusätzlich zur regulären Ausgabe auf, die von den gcloud-Befehlen erstellt wird. Es wirkt sich nicht auf deren Funktionalität aus.

Wenn sich dieses Problem nicht auf Ihre Vorgänge auswirkt, können Sie die Version 410.0.0 weiterhin verwenden und die falsche Fehlermeldung ignorieren. Wenn Sie die Version 410.0.0 verwenden müssen und den gcloud-Befehl programmatisch verwenden, implementieren Sie bitte eine zusätzliche Logik, um Fehlercode ungleich null und Informationen zum Fehler-Stacktrace in der Ausgabe zu ignorieren. Sie können auch einen Blick auf den Abschnitt "Lösung" werfen, um weitere Behelfslösungen zu finden.

Lösung

• Führen Sie kein Upgrade auf die Version 410.0.0 durch. Verwenden Sie Version 409.0.0 oder niedriger.
• Wenn Sie bereits ein Upgrade durchgeführt haben, führen Sie ein Downgrade auf eine frühere Version aus, z. B. auf 409.0.0. Weitere Informationen finden Sie unter Versionierte Archive verwenden.

Leere Ordner in „Planer und Worker“

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

Empfehlung: Passen Sie Ihre DAGs an, damit sie darauf vorbereitet sind, solche leeren Ordner zu überspringen.

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

Unterstützung für Kerberos

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

Unterstützung von Compute-Klassen in Cloud Composer 2

Cloud Composer 2 unterstützt nur die Computing-Klasse für allgemeine Zwecke. Dies bedeutet, dass das Ausführen von Pods, die andere Computing-Klassen anfordern (z. B. Balanced oder Scale-Out), nicht möglich ist.

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

Wenn Sie die ARM-basierte Architektur verwenden oder mehr CPU und Arbeitsspeicher benötigen, müssen Sie eine andere Compute-Klasse verwenden, die in Cloud Composer 2-Clustern 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 sie auch in einem Cluster ausgeführt werden, der nicht zu Cloud Composer 2 gehört.

Unterstützung 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 API 3.5. Diese API wird am 1. Mai 2023 eingestellt.

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

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 API 1.1, die eingestellt wurde 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 aus. Außerdem müssen Sie Ihre DAGs möglicherweise ändern, da einige der Google Display & Video 360-Operatoren verworfen und durch neue ersetzt wurden.

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

Namenseinschränkungen für sekundäre Bereiche

Hinweis: Die Namenskonvention gke-.*-(pods|services)-.* ist für automatisch erstellte sekundäre Bereiche von GKE-Cluster reserviert. Sie können beim Erstellen von Composer-Instanzen keine sekundären Bereichsnamen in diesem Format verwenden.

CVE-2023-29247 (Detailseite der Aufgabeninstanz in der UI ist anfällig für gespeicherte XSS)

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

Hinweis: Die Cloud Composer-Version 2.4.2 behebt dieses Problem in den Airflow-Versionen 2.4.3 und 2.5.3. Wir empfehlen, Ihre Umgebung auf Cloud Composer 2.4.2 oder höher zu aktualisieren. Dieses Problem hat keine Auswirkungen auf Airflow 2.6.x und höher.

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

In Cloud Composer ist der Zugriff auf die Airflow-UI mit IAM und der Zugriffssteuerung für die Airflow-UI geschützt.

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

Lösung:

• Prüfen Sie IAM-Berechtigungen und -Rollen in Ihrem Projekt, einschließlich Cloud Composer-Rollen, die einzelnen Nutzern zugewiesen werden. Achten Sie darauf, dass nur genehmigte Nutzer auf die Airflow-UI zugreifen können.

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

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

Der DAG für das Airflow-Monitoring der Cloud Composer 2 Composer-Umgebung 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 Composer-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, die Umgebung auf eine neuere Version zu aktualisieren.
• Eine alternative oder vorübergehende Problemumgehung für ein Umgebungsupgrade wäre das Kopieren des DAG „airflow_monitoring“ aus einer anderen Umgebung mit derselben Version.

Hinweis: Löschen Sie den Monitoring-DAG nicht. Er wird von Cloud Composer zum Überwachen des Zustands Ihrer Umgebung verwendet.

Upgradevorgänge können fehlschlagen, wenn Sentry aktiviert ist

Der Upgradevorgang für eine Cloud Composer-Umgebung kann fehlschlagen, wenn Sie Sentry in Ihrer Umgebung konfiguriert und die Einstellung [sentry]sentry_on auf true festgelegt haben.

Lösung:

• Deaktivieren Sie Sentry in Ihrer Umgebung, führen Sie das Upgrade durch und konfigurieren Sie Sentry noch einmal.

Der Cloud SQL-Speicher kann nicht reduziert werden

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

Es ist nicht möglich, die Cloud SQL-Laufwerksgröße herunterzuskalieren.

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

Messwert für die Nutzung des Datenbanklaufwerks schrumpft nach dem Entfernen von Einträgen aus Cloud SQL nicht

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 zu vermeiden, dass gleichzeitige Transaktionen blockiert werden.

Sowohl MySQL als auch Postgres implementieren Mechanismen zur Freigabe von Speicherplatz nach gelöschten Einträgen.

Es ist zwar möglich, die Datenbank zu zwingen, ungenutzten Speicherplatz freizugeben, dies ist jedoch ein ressourcenintensiver Vorgang, der die Datenbank zusätzlich sperrt, sodass Cloud Composer nicht mehr verfügbar ist. Daher empfiehlt es sich, die Gebäudemechanismen zu verwenden, um ungenutzten Speicherplatz freizugeben.

Zugriff blockiert: Autorisierungsfehler

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

Wenn in Google Workspace die Option API-Steuerung > Nicht konfigurierte Drittanbieter-Apps > Nutzer dürfen nicht auf Drittanbieter-Apps zugreifen aktiviert ist und Apache Airflow in der Cloud Composer-Anwendung nicht explizit zugelassen ist, können Nutzer nur dann auf die Airflow-UI zugreifen, wenn sie die Anwendung explizit zulassen.

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

Erfolgreiche Aufgabeninstanzen, die in der Vergangenheit als FEHLGESCHLAGEN markiert sind

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

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

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

Das Problem wurde in 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. Beispielsweise kann der Airflow-Planer neu gestartet werden, Airflow-Aufgaben müssen wiederholt werden oder die Startzeit der Aufgaben kann länger sein.

Symptome:

Die folgenden Fehler werden in Logs von 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

Legen Sie die folgende Umgebungsvariable fest: GCE_METADATA_TIMEOUT=30.

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

In Cloud Composer 2 ist der Airflow-Webserver überwiegend schreibgeschützt und Cloud Composer synchronisiert den Ordner data/ nicht mit dieser Komponente.

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

Lösung

• Verpacken Sie die Dateien, die für den Webserver freigegeben werden sollen, in einem 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 stehen ihnen zur Verfügung.

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

Nächste Schritte

• Fehlerbehebung beim Erstellen der Umgebung
• Fehlerbehebung bei DAGs
• Fehlerbehebung bei Airflow Scheduler-Problemen