Problemi noti

Cloud Composer 1 | Cloud Composer 2

Questa pagina elenca i problemi noti di Cloud Composer. Alcune correzioni di questi problemi sono in fase di sviluppo e saranno disponibili nelle versioni future.

Alcuni problemi interessano le versioni precedenti e possono essere risolti eseguendo l'upgrade dell'ambiente.

Gli intervalli di indirizzi non RFC 1918 sono parzialmente supportati per pod e servizi

Cloud Composer fornisce il supporto di indirizzi non RFC 1918 da GKE per pod e servizi, in base a GKE. Attualmente, in Cloud Composer è supportato solo il seguente elenco di intervalli non RFC 1918:

  • 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

La UI di Airflow non mostra i log delle attività quando la serializzazione DAG è attiva in Composer 1.10.2 e Composer 1.10.3

L'abilitazione della Serializzazione DAG in ambienti che utilizzano Composer versioni 1.10.2 e 1.10.3 impedisce la visualizzazione dei log nel server web Airflow. Esegui l'upgrade alla versione 1.10.4 (o successiva) per risolvere il problema.

Errore di attività intermittente durante la pianificazione in Cloud Composer

Il problema viene rilevato in uno scheduler Airflow per l'istanza dell'attività durante l'esecuzione dell'attività. Tuttavia, i log non spiegano la causa dell'errore dell'attività e il worker di Airflow e lo scheduler di Airflow sembravano relativamente integri.

Il messaggio di errore sullo scheduler Airflow potrebbe essere simile al seguente:

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?

Oppure potrebbe esserci un errore sul worker di Airflow simile al seguente errore:

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

Per garantire la robustezza di questi errori derivanti da un problema di lunga data in Airflow, consigliamo vivamente di implementare proattivamente strategie appropriate per i nuovi tentativi sia a livello di attività che a livello di DAG. Incorporando queste misure, il sistema può mitigare in modo efficace l'impatto di questi errori, migliorando così l'affidabilità e la resilienza complessive del flusso di lavoro.

GKE Workload Identity non è supportato

Questo problema riguarda solo gli ambienti Cloud Composer 1. Gli ambienti Cloud Composer 2 utilizzano Workload Identity.

Non puoi attivare Workload Identity per i cluster di ambiente Cloud Composer. Di conseguenza, potresti visualizzare il risultato WORKLOAD_IDENTITY_DISABLED in Security Command Center.

Le etichette di ambiente aggiunte durante un aggiornamento non vengono propagate completamente

Le etichette di ambiente aggiornate non vengono applicate alle VM di Compute Engine. Per risolvere il problema, è possibile applicare queste etichette manualmente.

Upgrade di GKE nel contesto del problema CVE-2020-14386

Stiamo lavorando per risolvere la vulnerabilità CVE-2020-14386 per tutti gli ambienti Cloud Composer. Nell'ambito della correzione, tutti i cluster GKE di Cloud Composer esistenti verranno aggiornati a una versione più recente.

I clienti che decidono di risolvere immediatamente la vulnerabilità possono eseguire l'upgrade del cluster GKE di Composer seguendo queste istruzioni con le seguenti considerazioni:

Passaggio 1: Se esegui una versione di Cloud Composer precedente alla 1.7.2, esegui l'upgrade a una versione più recente di Cloud Composer. Se hai già la versione 1.7.2 o successiva, vai al punto successivo.

Passaggio 2: Esegui l'upgrade del cluster GKE (master e nodi) alla versione più recente della patch 1.15 contenente la correzione per questa vulnerabilità.

I log delle attività di Airflow non sono disponibili nel server web di Airflow dopo l'upgrade da Airflow 1.9.0 a Airflow 1.10.x

Airflow 1.10.x ha introdotto modifiche incompatibili con le versioni precedenti alla convenzione di denominazione per i file di log. Ora le informazioni sulla zona vengono aggiunte ai nomi dei log per le attività Airflow.

Airflow 1.9.0 archivia e prevede che i nomi dei log siano nel seguente formato: BUCKET/logs/DAG/2020-03-30T10:29:06/1.log Airflow 1.10.x archivia e prevede che i nomi dei log siano nel seguente formato: BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Di conseguenza, se esegui l'upgrade da Airflow 1.9.0 a Airflow 1.10.x e vuoi leggere il log per un'attività eseguita con Airflow 1.9.0, il server web Airflow mostrerà il seguente messaggio di errore: Unable to read remote log from BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Soluzione:rinomina i log generati da Airflow 1.9.0 nel bucket Cloud Storage utilizzando il formato: BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Impossibile creare ambienti Cloud Composer con il criterio dell'organizzazione constraints/compute.disableSerialPortLogging applicato

La creazione dell'ambiente Cloud Composer non riuscirà se constraints/compute.disableSerialPortLogging viene applicato al progetto di destinazione.

Diagnosi

Per capire se questo problema ti riguarda, segui questa procedura:

Vai al menu GKE nella console Google Cloud. Vai al menu GKE

Quindi, seleziona il cluster appena creato. Controlla se è presente il seguente errore:

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

Soluzioni:

  1. Disabilita il criterio dell'organizzazione sul progetto in cui verrà creato l'ambiente Cloud Composer.

    Un criterio dell'organizzazione può sempre essere disabilitato a livello di progetto anche se è abilitato nelle risorse padre (organizzazione o cartella). Per ulteriori dettagli, consulta la pagina Personalizzazione delle norme per i vincoli booleani.

  2. Utilizzare i filtri di esclusione

    L'utilizzo di un filtro di esclusione per i log delle porte seriali raggiunge lo stesso obiettivo della disabilitazione del criterio dell'organizzazione, dato che in Logging saranno disponibili i log della console seriale. Per ulteriori dettagli, consulta la pagina Filtri di esclusione.

Utilizzo di Deployment Manager per gestire le risorse Google Cloud protette dai Controlli di servizio VPC

Composer utilizza Deployment Manager per creare componenti degli ambienti Cloud Composer.

A dicembre 2020, potresti aver ricevuto informazioni relative alla necessità di eseguire una configurazione aggiuntiva dei Controlli di servizio VPC per poter utilizzare Deployment Manager per gestire le risorse protette dai Controlli di servizio VPC.

Vorremmo chiarire che non è richiesta alcuna azione da parte tua se utilizzi Composer e non utilizzi direttamente Deployment Manager per gestire le risorse Google Cloud menzionate nell'annuncio di Deployment Manager.

Impossibile eliminare un ambiente dopo l'eliminazione del relativo cluster GKE

Se elimini il cluster del tuo ambiente prima dell'ambiente stesso, i tentativi di eliminazione dell'ambiente generano il seguente errore:

 Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]

Per eliminare un ambiente quando il relativo cluster GKE è già stato eliminato:

  1. Apri la pagina Deployment Manager nella console Google Cloud.

    Apri la pagina di Deployment Manager

  2. Trova tutti i deployment contrassegnati con le etichette:

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

    Dovresti vedere due deployment contrassegnati con le etichette descritte:

    • Un deployment denominato <environment-location>-<environment-name-prefix>-<hash>-sd
    • Un deployment denominato addons-<uuid>

  3. Elimina manualmente le risorse ancora elencate in questi due deployment e che esistono nel progetto, ad esempio argomenti e abbonamenti Pub/Sub. Ecco come fare:

    1. Seleziona i deployment.

    2. Fai clic su Elimina.

    3. Seleziona l'opzione Elimina 2 deployment e tutte le risorse da loro create, come VM, bilanciatori del carico e dischi, e fai clic su Elimina tutto.

    L'operazione di eliminazione non riesce, ma le risorse rimaste vengono eliminate.

  4. Elimina i deployment utilizzando una delle seguenti opzioni:

    • Nella console Google Cloud, seleziona di nuovo entrambi i deployment. Fai clic su Elimina, poi seleziona l'opzione Elimina 2 deployment, ma mantieni le risorse create.

    • Esegui un comando gcloud per eliminare i deployment con il criterio ABANDON:

      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. Elimina il tuo ambiente Cloud Composer.

Deployment Manager mostra informazioni su una funzionalità non supportata

Potresti vedere il seguente avviso nella scheda Deployment Manager:

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

Per i deployment di Deployment Manager di proprietà di Cloud Composer, puoi ignorare questo avviso.

Avvisi sulle voci duplicate dell'attività "echo" appartenenti al DAG "echo-airflow_monitoring"

Nei log di Airflow potrebbe essere visualizzata la voce seguente:

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'")

Puoi ignorare queste voci di log, perché questo errore non influisce sull'elaborazione delle attività e del DAG di Airflow.

Stiamo lavorando per migliorare il servizio Cloud Composer in modo da rimuovere questi avvisi dai log di Airflow.

La creazione dell'ambiente non va a buon fine nei progetti con API Identity-Aware Proxy aggiunte al perimetro dei Controlli di servizio VPC

Nei progetti in cui sono abilitati i Controlli di servizio VPC, l'account cloud-airflow-prod@system.gserviceaccount.com richiede l'accesso esplicito al perimetro di sicurezza per creare ambienti.

Per creare ambienti, puoi utilizzare una delle seguenti soluzioni:

  • Non aggiungere l'API Cloud Identity-Aware Proxy e l'API TCP Identity-Aware Proxy al perimetro di sicurezza.

  • Aggiungi l'account di servizio cloud-airflow-prod@system.gserviceaccount.com come membro del perimetro di sicurezza utilizzando la seguente configurazione nel file delle condizioni YAML:

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

La creazione dell'ambiente Cloud Composer 1 non riesce quando il criterio compute.requireOsLogin è abilitato

Se il criterio compute.requireOsLogin viene impostato su true nel progetto, le operazioni di creazione dell'ambiente di Cloud Composer 1 v1 non andranno a buon fine.

Per creare ambienti Cloud Composer 1, disabilita questo criterio nel tuo progetto.

Per ulteriori informazioni su questi criteri dell'organizzazione, vedi Vincoli dei criteri dell'organizzazione.

La creazione o l'upgrade dell'ambiente Cloud Composer non riesce quando compute.vmExternalIpAccess è disabilitato

I cluster GKE di proprietà di Cloud Composer, configurati in modalità IP pubblico, richiedono connettività esterna per le relative VM. Per questo motivo, il criterio compute.vmExternalIpAccess non può vietare la creazione di VM con indirizzi IP esterni. Per ulteriori informazioni su questi criteri dell'organizzazione, vedi Vincoli dei criteri dell'organizzazione.

La creazione dell'ambiente Cloud Composer non riesce se il criterio compute.vmCanIpForward è disabilitato

Gli ambienti Cloud Composer 1 creati in modalità non VPC-native (mediante IP alias) richiedono questo criterio per consentire la creazione di VM con la funzionalità "IP Forwarding" abilitata. Per ulteriori informazioni su questi criteri dell'organizzazione, vedi Vincoli dei criteri dell'organizzazione.

La prima esecuzione di DAG per un file DAG caricato presenta diverse attività non riuscite

Quando carichi un file DAG, a volte le prime attività della prima esecuzione di DAG non vanno a buon fine e viene generato l'errore Unable to read remote log.... Questo problema si verifica perché il file DAG viene sincronizzato tra il bucket del tuo ambiente, i worker Airflow e gli scheduler Airflow del tuo ambiente. Queste sincronizzazioni vengono eseguite in modo indipendente. Se lo scheduler recupera il file DAG e ne pianifica l'esecuzione da parte di un worker, mentre se il worker non ha ancora il file DAG, l'esecuzione dell'attività non va a buon fine.

Come soluzione alternativa, gli ambienti Airflow 2 in Cloud Composer 1.17.0-preview.9 e nelle versions successive sono configurati per eseguire due nuovi tentativi per un'attività non riuscita per impostazione predefinita. Se un'attività non va a buon fine, viene ripetuta due volte a intervalli di 5 minuti.

Per utilizzare la soluzione alternativa per questo problema in Airflow 1, esegui l'override dell'opzione di configurazione di Airflow core-default_task_retries e impostala su un numero maggiore o uguale a 2.

L'attività non riesce con "Errore OS: [Errno 5] Errore di input/output" in Airflow 1.10.15 o versioni precedenti

Un bug nelle versioni di Airflow 1 causa il doppio inserimento delle attività nella coda Redis in alcuni rari casi.

A volte può verificarsi una race condition nel file di log e un conseguente fallimento dell'attività. Le attività non riescono con OSError: [Errno 5] Input/output error in Cloud Logging e Task is in the 'running' state which is not a valid state for execution. nel log dei tentativi di attività.

Questo bug è stato risolto in Airflow 2. Se riscontri questo problema in Airflow 1 in un'attività a lunga esecuzione, aumenta il valore dell'opzione di configurazione di Airflow [celery_broker_transport_options]visibility_timeout (il valore predefinito è 604800 per Composer 1.17.0, 21600 per gli ambienti meno recenti). Per le attività a breve esecuzione, valuta la possibilità di aggiungere ulteriori nuovi tentativi alle attività interessate o di eseguire la migrazione dell'ambiente ad Airflow 2.

Gli operatori di Dataproc/Dataflow non riescono con Negsignal.SIGSEGV

Questo è un problema intermittente della libreria grcpio, quando utilizzato da un worker Celery. Questo problema riguarda Airflow 1.10.14 e versioni successive.

La soluzione alternativa consiste nel cambiare la strategia di polling grpcio aggiungendo la seguente variabile di ambiente al tuo ambiente: GRPC_POLL_STRATEGY=epoll1. Questa soluzione alternativa è già applicata in Cloud Composer 1.17.1 e versioni successive.

Annunci relativi alla rimozione del supporto per le API beta deprecate dalle versioni di GKE

Cloud Composer gestisce i cluster GKE sottostanti di proprietà di Cloud Composer. A meno che non usi esplicitamente queste API nei DAG e nel codice, puoi ignorare gli annunci relativi al ritiro delle API GKE. Cloud Composer si occupa di qualsiasi migrazione, se necessario.

Upgrade di GKE nel contesto del problema di sicurezza CVE-2021-25741

Verrà eseguito l'upgrade automatico di tutti i cluster GKE di Cloud Composer esistenti alle versioni GKE più recenti con una correzione per i problemi descritti in CVE-2021-25741.

Se vuoi risolvere immediatamente questa vulnerabilità, esegui l'upgrade del cluster GKE del tuo ambiente seguendo le istruzioni per l'upgrade di un cluster.

  • Se hai un ambiente Cloud Composer 1 e GKE versione 1.18.x o precedente, esegui l'upgrade alla versione 1.18.20-gke.4501.

  • Se hai un ambiente Cloud Composer 1 e la versione 1.19.x di GKE, esegui l'upgrade alla versione 1.19.14-gke.301.

  • Se hai un ambiente Cloud Composer 2 e la versione 1.21.x di GKE, esegui l'upgrade alla versione 1.21.4-gke.301.

Cloud Composer non dovrebbe essere interessato dalla vulnerabilità di Apache Log4j 2 (CVE-2021-44228)

In risposta alla vulnerabilità di Apache Log4j 2 (CVE-2021-44228), Cloud Composer ha condotto un'indagine dettagliata e riteniamo che Cloud Composer non sia vulnerabile a questo exploit.

Cloud Composer 2: i worker o gli scheduler di Airflow potrebbero riscontrare problemi durante l'accesso ai bucket Cloud Storage

In alcune situazioni sporadiche, nel caso di ambienti Cloud Composer 2 quando il worker o lo scheduler Airflow riavvii, questo potrebbe non funzionare correttamente e riscontrare problemi durante l'accesso al contenuto del bucket Cloud Storage.

In questa situazione, potresti visualizzare errori che iniziano con Transport endpoint is not connected nei log di Airflow.

Ad esempio, il log degli errori per il worker di Airflow potrebbe avere il seguente aspetto:

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

Soluzione:

  • Esegui l'upgrade a Cloud Composer 2.0.26 o versione più recente

A volte, la UI di Airflow potrebbe non ricaricare un plug-in dopo la modifica

Se un plug-in è composto da molti file che importano altri moduli, l'interfaccia utente di Airflow potrebbe non essere in grado di riconoscere il fatto che un plug-in deve essere ricaricato. In tal caso, è necessario attivare un riavvio del server web Airflow. Puoi farlo aggiungendo una variabile di ambiente o tramite l'installazione o la disinstallazione delle dipendenze PYPI. Puoi anche riavviare il server web Airflow.

Problemi intermittenti durante la comunicazione con il database di metadati Airflow

Questo problema noto riguarda solo Cloud Composer 1.

Alcuni ambienti Cloud Composer 1 meno recenti (1.16.3 o versioni precedenti) creati prima del 12 agosto 2021 potrebbero riscontrare problemi temporanei relativi alla comunicazione con i database di metadati Airflow.

Se si verifica questo problema, nei log delle attività di Airflow visualizzerai il seguente messaggio di errore:

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

Il team di Cloud Composer sta lavorando alla risoluzione del problema. Nel frattempo, se ritieni di essere molto interessato da questo problema, puoi fare quanto segue per eliminarlo:

  1. Nella console Google Cloud, vai alla pagina Configurazione dell'ambiente degli ambienti Cloud Composer interessati.
  2. Segui il link per visualizzare i dettagli del cluster per accedere al cluster GKE sottostante dell'ambiente.
  3. Vai alla scheda Nodi e fai clic su default-pool visibile nella sezione Pool di nodi. seleziona pool-predefinito
  4. Fai clic su Modifica nella parte superiore della pagina.
  5. Modifica il tipo di immagine in Container-Optimized OS con containerd e salva la configurazione come mostrato di seguito. Modifica il tipo di immagine del pool di nodi da Docker a containerd
  6. Una volta inviata la modifica, il tuo pool di nodi default-pool verrà riconfigurato in modo da utilizzare containerd come runtime del container. Alcune attività Airflow potrebbero non riuscire durante la riconfigurazione del pool di nodi. Se per queste attività sono stati configurati nuovi tentativi, verranno eseguiti nuovamente da Airflow al termine dell'operazione sul pool di nodi.

Il cluster dell'ambiente ha carichi di lavoro in stato Non pianificabile

Questo problema noto riguarda solo Cloud Composer 2.

In Cloud Composer 2, dopo la creazione di un ambiente, diversi carichi di lavoro nel cluster dell'ambiente rimangono in stato Non pianificabile.

Quando un ambiente fa lo scale up, vengono creati nuovi pod worker e Kubernetes prova a eseguirli. Se non sono disponibili risorse gratuite per eseguirle, i pod worker vengono contrassegnati come non pianificabili.

In questa situazione, il gestore della scalabilità automatica del cluster aggiunge altri nodi, l'operazione richiede un paio di minuti. Finché questa operazione non è completata, i pod rimangono nello stato Non pianificabile e non eseguono alcuna attività.

I carichi di lavoro DaemonSet non pianificabili denominati composer-gcsfuse e composer-fluentd che non possono essere avviati su nodi in cui non sono presenti componenti Airflow non influiscono sull'ambiente.

Se il problema persiste per molto tempo (oltre un'ora), puoi controllare i log del gestore della scalabilità automatica del cluster. Puoi trovarli nel visualizzatore log con il filtro seguente:

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

Contiene informazioni sulle decisioni prese dal gestore della scalabilità automatica del cluster: espandi qualsiasi noDecisionStatus per capire il motivo per cui non è possibile fare lo scale up o lo scale down del cluster.

Errore 504 durante l'accesso all'interfaccia utente di Airflow

Puoi visualizzare l'errore 504 Gateway Timeout quando accedi all'interfaccia utente di Airflow. Questo errore può avere diverse cause:

  • Problema di comunicazione temporaneo. In questo caso, prova ad accedere all'UI di Airflow in un secondo momento. Puoi anche riavviare il server web Airflow.
  • (Solo Cloud Composer 2) Problema di connettività. Se la UI di Airflow non è disponibile definitivamente e vengono generati errori di timeout o 504, assicurati che il tuo ambiente possa accedere a *.composer.cloud.google.com. Se utilizzi l'accesso privato Google e invii traffico su IP virtuali private.googleapis.com o Controlli di servizio VPC e invii traffico su IP virtuali restricted.googleapis.com, assicurati che Cloud DNS sia configurato anche per i nomi di dominio *.composer.cloud.google.com.
  • Server web Airflow non risponde. Se l'errore 504 persiste, ma puoi comunque accedere all'interfaccia utente di Airflow in determinati momenti, il server web Airflow potrebbe non rispondere a causa di un sovraccarico. Prova ad aumentare i parametri di scalabilità e prestazioni del server web.

Errore 502 durante l'accesso alla UI di Airflow

L'errore 502 Internal server exception indica che la UI di Airflow non può gestire le richieste in entrata. Questo errore può avere diverse cause:

  • Problema di comunicazione temporaneo. Prova ad accedere alla UI di Airflow in un secondo momento.

  • Impossibile avviare il server web. Per iniziare, il server web richiede che i file di configurazione siano sincronizzati. Verifica la presenza di voci di log simili a GCS sync exited with 1: gsutil -m cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp o GCS sync exited with 1: gsutil -m cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp nei log del server web. Se riscontri questi errori, controlla se i file menzionati nei messaggi di errore sono ancora presenti nel bucket dell'ambiente.

    In caso di rimozione accidentale (ad esempio, perché è stato configurato un criterio di conservazione), puoi ripristinarli:

    1. Imposta una nuova variabile di ambiente nel tuo ambiente. Puoi utilizzare qualsiasi nome e valore della variabile.

    2. Esegui l'override di un'opzione di configurazione Airflow. Puoi usare un'opzione di configurazione Airflow inesistente.

La UI di Airflow in Airflow 2.2.3 o versioni precedenti è vulnerabile a CVE-2021-45229

Come sottolineato in CVE-2021-45229, la schermata "Attiva il DAG con configurazione" era suscettibile agli attacchi XSS tramite l'argomento di query origin.

Suggerimento: esegui l'upgrade alla versione più recente di Cloud Composer che supporta Airflow 2.2.5.

I worker richiedono più memoria rispetto alle versioni precedenti di Airflow

Sintomi:

  • Nel tuo ambiente Cloud Composer 2, tutti i carichi di lavoro dei cluster dei worker di Airflow sono nello stato CrashLoopBackOff e non eseguono attività. Puoi anche vedere gli avvisi (OOMKilling) generati se il problema ti riguarda.

  • Questo problema può impedire gli upgrade dell'ambiente.

Causa:

  • Se utilizzi un valore personalizzato per l'opzione di configurazione di Airflow [celery]worker_concurrency e le impostazioni di memoria personalizzate per i worker di Airflow, potresti riscontrare questo problema quando il consumo delle risorse si avvicina al limite.
  • I requisiti di memoria dei worker di Airflow in Airflow 2.6.3 con Python 3.11 sono superiori del 10% rispetto ai worker delle versioni precedenti.
  • I requisiti di memoria dei worker di Airflow 2.3 e versioni successive sono superiori del 30% rispetto ai worker di Airflow 2.2 o Airflow 2.1.

Soluzioni:

  • Rimuovi l'override di worker_concurrency, in modo che Cloud Composer calcoli automaticamente questo valore.
  • Se utilizzi un valore personalizzato per worker_concurrency, impostalo su un valore più basso. Puoi utilizzare il valore calcolato automaticamente come punto di partenza.
  • In alternativa, puoi aumentare la quantità di memoria disponibile per i worker di Airflow.
  • Se a causa di questo problema non puoi eseguire l'upgrade dell'ambiente a una versione successiva, applica una delle soluzioni proposte prima di eseguire l'upgrade.

Trigger di DAG tramite reti private con Cloud Functions

L'attivazione di DAG con Cloud Functions tramite reti private con l'utilizzo del connettore VPC non è supportato da Cloud Composer.

Suggerimento: usa Cloud Functions per pubblicare messaggi su Pub/Sub. Questi eventi possono attivare i sensori Pub/Sub per attivare i DAG di Airflow o implementare un approccio basato su operatori differibili.

Problema con i comandi di gcloud Composer nella versione 410.0.0

Nella versione 410.0.0 di gcloud, sono disponibili i seguenti comandi di Cloud Composer:

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

restituire un codice di errore diverso da zero e visualizzare questo messaggio di errore:

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

Questo comportamento si verifica in aggiunta al regolare output prodotto dai comandi gcloud e non influisce sulla loro funzionalità.

Se questo problema non incide sulle tue operazioni, puoi continuare a utilizzare la versione 410.0.0 e ignorare il messaggio di errore errato. Se hai bisogno di utilizzare la versione 410.0.0 e usi il comando gcloud in modo programmatico, implementa una logica aggiuntiva per ignorare il codice di errore diverso da zero e le informazioni sullo stacktrace degli errori nell'output. Puoi anche consultare la sezione Soluzione per conoscere altre soluzioni alternative.

Soluzione:

Cartelle vuote nello scheduler e nei worker

Cloud Composer non rimuove attivamente cartelle vuote dai worker e dagli scheduler Airflow. Queste entità possono essere create come risultato del processo di sincronizzazione dei bucket di ambiente quando queste cartelle erano presenti nel bucket e alla fine sono state rimosse.

Consiglio: modifica i DAG in modo che siano pronti a saltare queste cartelle vuote.

Queste entità vengono alla fine rimosse dagli archivi locali di scheduler e worker Airflow quando questi componenti vengono riavviati (ad esempio, a seguito dello scale down o di operazioni di manutenzione nel cluster Cloud Composer).

Supporto per Kerberos

Cloud Composer non supporta ancora la configurazione Kerberos di Airflow.

Supporto per le classi di computing in Cloud Composer 2

Cloud Composer 2 supporta solo classi di calcolo per uso generico. Significa che non è possibile eseguire pod che richiedono altre classi di computing (ad esempio Bilanciata o Scale out).

La classe uso generico consente di eseguire pod che richiedono fino a 110 GB di memoria e fino a 30 CPU (come descritto in Richieste di classe Max Compute.

Se vuoi utilizzare un'architettura basata su ARM o hai bisogno di più CPU e memoria, devi utilizzare una classe di computing diversa, che non è supportata nei cluster Cloud Composer 2.

Suggerimento: utilizza GKEStartPodOperator per eseguire pod Kubernetes su un cluster diverso che supporta la classe di computing selezionata. Se esegui pod personalizzati che richiedono una classe di computing diversa, devono essere eseguiti anche su un cluster non Cloud Composer 2.

Supporto per gli operatori di Google Campaign Manager 360

Gli operatori di Google Campaign Manager nelle versioni di Cloud Composer precedenti alla 2.1.13 sono basati sull'API Campaign Manager 360 3.5 deprecata e la data di ritiro è il 1° maggio 2023.

Se utilizzi gli operatori di Google Campaign Manager, esegui l'upgrade del tuo ambiente a Cloud Composer versione 2.1.13 o successive.

Supporto per gli operatori di Google Display & Video 360

Gli operatori di Google Display & Video 360 nelle versioni di Cloud Composer precedenti alla 2.1.13 si basano sull'API Display & Video 360 v1.1 che è stata ritirata e la data di ritiro è il 27 aprile 2023.

Se utilizzi gli operatori di Google Display & Video 360, esegui l'upgrade del tuo ambiente a Cloud Composer versione 2.1.13 o successive. Inoltre, potresti dover modificare i DAG perché alcuni degli operatori di Google Display & Video 360 sono deprecati e sostituiti con altri nuovi.

  • L'API GoogleDisplayVideo360CreateReportOperator è deprecata. Utilizza invece GoogleDisplayVideo360CreateQueryOperator. Questo operatore restituisce query_id anziché report_id.
  • L'API GoogleDisplayVideo360RunReportOperator è deprecata. Utilizza invece GoogleDisplayVideo360RunQueryOperator. Questo operatore restituisce query_id e report_id anziché solo report_id e richiede query_id anziché report_id come parametro.
  • Per verificare se un report è pronto, utilizza il nuovo sensore GoogleDisplayVideo360RunQuerySensor che utilizza i parametri query_id e report_id. Il sensore GoogleDisplayVideo360ReportSensor deprecato richiedeva solo report_id.
  • GoogleDisplayVideo360DownloadReportV2Operator ora richiede i parametri query_id e report_id.
  • In GoogleDisplayVideo360DeleteReportOperator non sono presenti modifiche che possono influire sui tuoi DAG.

Limitazioni per i nomi degli intervalli secondari

CVE-2023-29247 (la pagina dei dettagli dell'istanza dell'attività nell'interfaccia utente è vulnerabile a un XSS archiviato)

La UI di Airflow nelle versioni di Airflow dalla versione 2.0.x alla versione 2.5.x è vulnerabile a CVE-2023-29247.

Se utilizzi una versione di Cloud Composer precedente alla 2.4.2 e sospetti che il tuo ambiente possa essere vulnerabile all'exploit, leggi la seguente descrizione e le possibili soluzioni.

In Cloud Composer, l'accesso all'interfaccia utente di Airflow è protetto con IAM e il controllo dell'accesso dell'interfaccia utente di Airflow.

Ciò significa che, per sfruttare la vulnerabilità dell'interfaccia utente di Airflow, gli utenti malintenzionati devono prima accedere al progetto e disporre dei ruoli e delle autorizzazioni IAM necessari.

Soluzione:

  • Verifica le autorizzazioni e i ruoli IAM nel tuo progetto, inclusi i ruoli di Cloud Composer assegnati a singoli utenti. Assicurati che solo gli utenti approvati possano accedere alla UI di Airflow.

  • Verifica i ruoli assegnati agli utenti tramite il meccanismo di controllo dell'accesso UI di Airflow (questo è un meccanismo separato che fornisce un accesso più granulare alla UI di Airflow). Assicurati che solo gli utenti approvati possano accedere all'interfaccia utente di Airflow e che tutti i nuovi utenti siano registrati con un ruolo appropriato.

  • Valuta la possibilità di rafforzare ulteriormente la protezione con i Controlli di servizio VPC.

Il DAG di monitoraggio del flusso d'aria dell'ambiente Cloud Composer 2 Composer non viene ricreato dopo l'eliminazione

Il DAG di monitoraggio del flusso d'aria non viene ricreato automaticamente se eliminato dall'utente o spostato dal bucket negli ambienti Composer con Composer-2.1.4-airflow-2.4.3.

Soluzione:

  • Questo problema è stato risolto nelle versioni successive, come Composer-2.4.2-airflow-2.5.3. L'approccio suggerito consiste nell'eseguire l'upgrade dell'ambiente a una versione più recente.
  • Una soluzione alternativa o temporanea all'upgrade di un ambiente è copiare il DAG airflow_monitoring da un altro ambiente con la stessa versione.

Le operazioni di upgrade potrebbero non riuscire se Sentry è abilitato

L'operazione di upgrade per un ambiente Cloud Composer potrebbe non riuscire se hai configurato Sentry nel tuo ambiente e hai impostato l'impostazione [sentry]sentry_on su true.

Soluzione:

  • Disattiva Sentry nel tuo ambiente, esegui l'upgrade e configura di nuovo Sentry.

Non è possibile ridurre lo spazio di archiviazione di Cloud SQL

Cloud Composer utilizza Cloud SQL per eseguire il database Airflow. Nel corso del tempo, lo spazio di archiviazione su disco per l'istanza Cloud SQL potrebbe aumentare perché il disco viene fatto lo scale up per adattarsi ai dati archiviati dalle operazioni di Cloud SQL quando il database Airflow cresce.

Non è possibile fare lo scale down delle dimensioni del disco Cloud SQL.

Come soluzione alternativa, se vuoi utilizzare le dimensioni del disco Cloud SQL più ridotte, puoi ricreare ambienti Cloud Composer con gli snapshot.

La metrica di utilizzo del disco di database non si riduce dopo la rimozione dei record da Cloud SQL

I database relazionali, come Postgres o MySQL, non rimuovono fisicamente le righe quando vengono eliminate o aggiornate. Le contrassegna invece come "tuple non attive" per mantenere la coerenza dei dati ed evitare di bloccare le transazioni simultanee.

Sia MySQL che Postgres implementano meccanismi per recuperare spazio dopo record eliminati.

Sebbene sia possibile forzare il database a recuperare spazio su disco inutilizzato, questa è un'operazione che utilizza molte risorse, che blocca inoltre il database rendendo Cloud Composer non disponibile. Pertanto, consigliamo di fare affidamento sui meccanismi di creazione per recuperare lo spazio inutilizzato.

Accesso bloccato: errore di autorizzazione

Se questo problema riguarda un utente, la finestra di dialogo Accesso bloccato: errore di autorizzazione contiene il messaggio Error 400: admin_policy_enforced.

Se l'opzione Controlli API > App di terze parti non configurate > Non consentire agli utenti di accedere alle app di terze parti è attivata in Google Workspace e l'app Apache Airflow nell'app Cloud Composer non è esplicitamente consentita, gli utenti non possono accedere all'interfaccia utente di Airflow a meno che non autorizzino esplicitamente l'applicazione.

Per consentire l'accesso, segui i passaggi indicati in Consentire l'accesso alla UI di Airflow in Google Workspace.

Istanze di attività andate a buon fine in passato contrassegnate come NON RIUSCITA

In alcuni casi e in scenari rari, le istanze delle attività Airflow andate a buon fine in passato possono essere contrassegnate come FAILED.

Se succede, di solito è stato attivato da un'operazione di aggiornamento o upgrade dell'ambiente oppure dalla manutenzione di GKE.

Nota: il problema in sé non indica alcun problema nell'ambiente e non causa errori effettivi nell'esecuzione dell'attività.

Il problema è stato risolto in Cloud Composer 2.6.5 o versioni successive.

I componenti di Airflow presentano problemi durante la comunicazione con altre parti della configurazione di Cloud Composer

In rarissimi casi, la lentezza della comunicazione con il server metadati di Compute Engine potrebbe comportare il malfunzionamento dei componenti di Airflow. Ad esempio, lo scheduler Airflow potrebbe essere riavviato, potrebbe essere necessario riprovare le attività Airflow o il tempo di avvio dell'attività potrebbe essere più lungo.

Sintomi:

I seguenti errori vengono visualizzati nei log dei componenti Airflow (ad esempio scheduler, worker o server web di Airflow):

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

Soluzione:

Imposta la seguente variabile di ambiente: GCE_METADATA_TIMEOUT=30.

La cartella /data non è disponibile nel server web Airflow

In Cloud Composer 2, il server web Airflow è destinato principalmente a essere un componente di sola lettura e Cloud Composer non sincronizza la cartella data/ con questo componente.

A volte, potresti voler condividere file comuni tra tutti i componenti Airflow, incluso il server web Airflow.

Soluzione:

  • Inserire un a capo in un modulo PYPI per i file da condividere con il server web e installarlo come un normale pacchetto PYPI. Una volta installato il modulo PYPI nell'ambiente, i file vengono aggiunti alle immagini dei componenti Airflow e diventano disponibili.

  • Aggiungi file alla cartella plugins/. Questa cartella è sincronizzata con il server web Airflow.

Passaggi successivi