Problemi noti

Managed Airflow (Gen 3) | Managed Airflow (Gen 2) | Managed Airflow (Legacy Gen 1)

Questa pagina elenca i problemi noti di Managed Airflow. Per informazioni sulle correzioni dei problemi, consulta le note di rilascio.

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

Managed Airflow dipende da GKE per fornire il supporto per indirizzi non RFC 1918 per pod e servizi. In Managed Airflow è 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

L'interfaccia utente di Airflow non mostra i log delle attività quando la serializzazione DAG è attiva in Composer 1.10.2 e Composer 1.10.3

L'attivazione della serializzazione DAG negli ambienti che utilizzano le versioni 1.10.2 e 1.10.3 di Composer impedisce la visualizzazione dei log nel server web Airflow. Esegui l'upgrade alla versione 1.10.4 (o successive) per risolvere il problema.

Errore intermittente dell'attività durante la pianificazione in Managed Airflow

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

Il messaggio di errore nello 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?

In alternativa, potrebbe verificarsi un errore sul worker Airflow simile al seguente messaggio di 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 contro questi errori derivanti da un problema di lunga data in Airflow, è fortemente consigliabile implementare in modo proattivo strategie di ripetizione appropriate a livello di attività e DAG. Incorporando queste misure, il sistema può mitigare efficacemente l'impatto di questi errori, migliorando così l'affidabilità e la resilienza complessive del flusso di lavoro.

Workload Identity Federation per GKE non è supportata

In Managed Airflow (Legacy Gen 1), non puoi abilitare Workload Identity Federation for GKE per i cluster dell'ambiente Managed Airflow. Di conseguenza, potresti visualizzare il risultato WORKLOAD_IDENTITY_DISABLED in Security Command Center.

Le etichette dell'ambiente aggiunte durante un aggiornamento non vengono propagate completamente

Quando aggiorni le etichette dell'ambiente, queste non vengono applicate alle VM di Compute Engine nel cluster dell'ambiente. Per risolvere il problema, puoi applicare le etichette manualmente.

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

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

Airflow 1.9.0 memorizza 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 memorizza 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 ad Airflow 1.10.x e vuoi leggere il log di un'attività eseguita con Airflow 1.9.0, il server web di 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 alternativa: 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 Managed Airflow con i vincoli dei criteri dell'organizzazione/compute.disableSerialPortLogging applicati

La creazione dell'ambiente Managed Airflow non riesce se il criterio dell'organizzazione constraints/compute.disableSerialPortLogging è applicato al progetto di destinazione.

Nota: questo problema si verifica solo per i cluster creati prima del rilascio di Managed Airflow del 9 novembre 2020. Gli ambienti Managed Airflow creati dopo il 9 novembre 2020 hanno tutti i nodi del cluster GKE creati con serial-logging-enable=false, il che impedisce il verificarsi di questo problema.

Diagnosi

Per determinare se il tuo account è interessato dal problema, segui questa procedura:

Vai al menu GKE nella consoleGoogle Cloud . Visita il menu GKE

Poi seleziona il cluster appena creato. Verifica 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. Disattiva la policy dell'organizzazione nel progetto in cui verrà creato l'ambiente Managed Airflow.

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

2. Utilizzare i filtri di esclusione

   L'utilizzo di un filtro di esclusione per i log della porta seriale. raggiunge lo stesso obiettivo della disattivazione del criterio dell'organizzazione, in quanto in Logging saranno presenti i log della console seriale. Per ulteriori dettagli, consulta la pagina Filtri di esclusione.

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

Le versioni 2.0.x di Managed Airflow (legacy di prima generazione) e Managed Airflow (di seconda generazione) utilizzano Deployment Manager per creare i componenti degli ambienti Managed Airflow.

A dicembre 2020, potresti aver ricevuto informazioni che ti invitavano a eseguire una configurazione aggiuntiva di Controlli di servizio VPC per poter utilizzare Deployment Manager per gestire le risorse protette da Controlli di servizio VPC.

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

Deployment Manager mostra informazioni su una funzionalità non supportata

Potresti visualizzare 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 Managed Airflow, puoi ignorare questo avviso.

Impossibile eliminare un ambiente dopo l'eliminazione del relativo cluster

Questo problema riguarda le versioni 2.0.x di Managed Airflow (Legacy Gen 1) e Managed Airflow (Gen 2).

Se elimini il cluster GKE 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 è già stato eliminato:

1. Nella console Google Cloud , vai alla pagina Deployment Manager.

   Vai a Deployment Manager

2. Trova tutti i deployment contrassegnati con le etichette:

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

   Dovresti visualizzare due deployment contrassegnati dalle 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 ed esistenti nel progetto (ad esempio, argomenti e sottoscrizioni 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 create, come VM, bilanciatori del carico e dischi e fai clic su Elimina tutto.

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

4. Elimina i deployment utilizzando una di queste 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 l'ambiente Managed Airflow.

Avvisi relativi alle voci duplicate dell'attività "echo" appartenente al DAG "echo-airflow_monitoring"

Nei log di Airflow potresti visualizzare la seguente voce:

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 di DAG e attività di Airflow.

Stiamo lavorando per migliorare il servizio Managed Airflow per rimuovere questi avvisi dai log di Airflow.

La creazione dell'ambiente non riesce nei progetti con le API Identity-Aware Proxy aggiunte al perimetro dei Controlli di servizio VPC

Nota: questo problema interessa tutte le versioni di Managed Airflow (Legacy Gen 1).

Nei progetti con Controlli di servizio VPC abilitati, l'account [e-mail] richiede l'accesso esplicito nel perimetro di sicurezza per creare ambienti.

Per creare ambienti, puoi utilizzare una delle seguenti soluzioni:

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

• Aggiungi l'account di servizio [e-mail] come membro del perimetro di sicurezza utilizzando la seguente configurazione nel file delle condizioni YAML:

   - members:
      - serviceAccount:[e-mail]
  

La creazione dell'ambiente Managed Airflow (legacy di prima generazione) non riesce quando è abilitata la policy compute.requireOsLogin

Se il criterio compute.requireOsLogin è impostato su true nel tuo progetto, le operazioni di creazione dell'ambiente Managed Airflow (legacy Gen 1) v1 non vanno a buon fine.

Per creare ambienti Managed Airflow (legacy di prima gen.) disattiva questo criterio nel tuo progetto.

Per saperne di più su questa policy dell'organizzazione, consulta Vincoli delle policy dell'organizzazione.

La creazione o l'upgrade dell'ambiente Managed Airflow non va a buon fine quando la policy compute.vmExternalIpAccess è disattivata

Questo problema riguarda gli ambienti Managed Airflow (legacy di prima generazione) e Managed Airflow (di seconda generazione).

I cluster GKE di proprietà di Managed Airflow configurati in modalità IP pubblico richiedono la 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 saperne di più su questa policy dell'organizzazione, consulta Vincoli delle policy dell'organizzazione.

La creazione dell'ambiente Managed Airflow (legacy Gen 1) non va a buon fine quando la policy compute.vmCanIpForward è disattivata

Gli ambienti Managed Airflow (legacy Gen 1) creati in modalità non VPC nativa (utilizzando l'IP alias) richiedono questo criterio per consentire la creazione di VM con la funzionalità di inoltro IP abilitata. Per saperne di più su questa policy dell'organizzazione, consulta Vincoli delle policy 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 DAG non vanno a buon fine e viene visualizzato l'errore Unable to read remote log.... Questo problema si verifica perché il file DAG viene sincronizzato tra il bucket dell'ambiente, i worker Airflow e gli scheduler Airflow dell'ambiente. Se lo scheduler riceve il file DAG e ne pianifica l'esecuzione da parte di un worker e se il worker non ha ancora il file DAG, l'esecuzione dell'attività non va a buon fine.

Per risolvere questo problema, gli ambienti con Airflow 2 sono configurati per eseguire due tentativi per un'attività non riuscita per impostazione predefinita. Se un'attività non riesce, viene riprovata due volte a intervalli di 5 minuti.

Per risolvere 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 "OSError: [Errno 5] Input/output error" in Airflow 1.10.15 o versioni precedenti

Un bug nelle versioni di Airflow 1 fa sì che le attività vengano inserite due volte nella coda delle attività dell'ambiente in rari casi.

A volte può causare una race condition nel file di log e un successivo errore 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 corretto in Airflow 2. Se riscontri questo problema in Airflow 1 in un'attività a esecuzione prolungata, aumenta il valore dell'opzione di configurazione [celery_broker_transport_options]visibility_timeout di Airflow (il valore predefinito è 604800 per Composer 1.17.0, 21600 per gli ambienti precedenti). Per le attività a esecuzione breve, valuta la possibilità di aggiungere ulteriori tentativi alle attività interessate o di eseguire la migrazione dell'ambiente ad Airflow 2.

Gli operatori Managed Service per Apache Spark e Dataflow non riescono a eseguire l'operazione con Negsignal.SIGSEGV

Si tratta di un problema intermittente della libreria grcpio, quando viene utilizzata da un worker Celery. Questo problema riguarda Airflow 1.10.14 e versioni successive.

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

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

Managed Airflow gestisce i cluster GKE di proprietà di Managed Airflow sottostanti. A meno che tu non utilizzi esplicitamente queste API nei tuoi DAG e nel tuo codice, puoi ignorare gli annunci relativi al ritiro delle API GKE. Managed Airflow si occupa di eventuali migrazioni, se necessario.

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

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

I worker o gli scheduler di Airflow potrebbero riscontrare problemi durante l'accesso al bucket Cloud Storage dell'ambiente

Managed Airflow utilizza gcsfuse per accedere alla cartella /data nel bucket dell'ambiente e per salvare i log delle attività di Airflow nella directory /logs (se abilitata). Se gcsfuse è sovraccarico o il bucket dell'ambiente non è disponibile, potresti riscontrare errori delle istanze di attività Airflow e visualizzare errori Transport endpoint is not connected nei log di Airflow.

Soluzioni:

• Disattiva il salvataggio dei log nel bucket dell'ambiente. Questa opzione è già disattivata per impostazione predefinita se un ambiente viene creato utilizzando Managed Airflow 2.8.0 o versioni successive.
• Esegui l'upgrade a Managed Airflow 2.8.0 o versioni successive.
• Riduci [celery]worker_concurrency e aumenta invece il numero di worker Airflow.
• Riduci la quantità di log prodotti nel codice del DAG.
• Segui i consigli e le best practice per implementare i DAG e attivare i tentativi di ripetizione delle attività.

A volte la UI di Airflow non ricarica un plug-in dopo la modifica

Se un plug-in è composto da molti file che importano altri moduli, l'interfaccia utente Airflow potrebbe non essere in grado di riconoscere il fatto che un plug-in deve essere ricaricato. In questo caso, riavvia il server web di Airflow del tuo ambiente.

Problemi intermittenti durante la comunicazione con il database dell'ambiente

Questo problema noto si applica solo a Managed Airflow (legacy di prima generazione).

Alcuni ambienti Managed Airflow precedenti (Legacy Gen 1) (1.16.3 o versioni precedenti) creati prima del 12 agosto 2021 potrebbero riscontrare problemi temporanei relativi alla comunicazione con il database Airflow.

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

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

Il team di Managed Airflow sta lavorando per risolvere il problema. Nel frattempo, se ritieni che questo problema ti stia causando gravi disagi, puoi attenuarlo nel seguente modo:

1. Nella console Google Cloud , vai alla pagina Configurazione ambiente degli ambienti Managed Airflow interessati.

2. Segui il link Visualizza dettagli cluster per passare al cluster GKE sottostante dell'ambiente.

3. Vai alla scheda Nodi e fai clic su default-pool visibile nella sezione Pool di nodi.

   

   Figura 1. default-pool nell'elenco dei pool di nodi (fai clic per ingrandire)

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:

   

   Figura 2. Modifica il tipo di immagine del node pool da Docker a containerd (fai clic per ingrandire)

6. Una volta inviata la modifica, il pool di nodi default-pool verrà riconfigurato per utilizzare containerd come runtime del container. Alcuni dei tuoi task Airflow potrebbero non riuscire durante la riconfigurazione del pool di nodi. Se per queste attività sono configurati tentativi, verranno eseguite di nuovo da Airflow al termine dell'operazione supool di nodiol.

Errore 504 durante l'accesso alla UI di Airflow

Puoi ricevere 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, tenta di accedere all'interfaccia utente di Airflow in un secondo momento. Puoi anche riavviare il server web Airflow.

• (Solo Managed Airflow (Gen 3)) Problema di connettività. Se la UI di Airflow non è disponibile in modo permanente e vengono generati errori di timeout o 504, assicurati che il tuo ambiente possa accedere a *.composer.googleusercontent.com.

• (Solo Managed Airflow (Gen 2)) Problema di connettività. Se la UI di Airflow non è disponibile in modo permanente 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 il traffico tramite gli IP virtuali private.googleapis.com o i Controlli di servizio VPC e invii il traffico tramite gli IP virtuali restricted.googleapis.com, assicurati che Cloud DNS sia configurato anche per i nomi di dominio *.composer.cloud.google.com.

• Il server web Airflow non risponde. Se l'errore 504 persiste, ma puoi comunque accedere alla UI di Airflow in determinati momenti, allora il server web Airflow potrebbe non rispondere perché è sovraccarico. Prova ad aumentare i parametri di scalabilità e rendimento del server web.

Errore 502 durante l'accesso alla UI di Airflow

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

• Problema di comunicazione temporaneo. Prova ad accedere all'interfaccia utente di Airflow più tardi.

• Impossibile avviare il server web. Per iniziare, il server web richiede la sincronizzazione dei file di configurazione. Controlla i log del server web per le voci di log simili a: GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp o GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp. Se visualizzi 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é è stata configurata una policy di conservazione), puoi ripristinarli:

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

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

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

Come indicato in CVE-2021-45229, la schermata "Attiva DAG con configurazione" era vulnerabile agli attacchi XSS tramite l'argomento della query origin.

Consiglio: esegui l'upgrade all'ultima versione di Managed Airflow che supporta Airflow 2.2.5.

Attivazione dei DAG tramite reti private utilizzando Cloud Run Functions

L'attivazione di DAG con Cloud Run Functions tramite reti private con l'utilizzo del connettore VPC non è supportata da Managed Airflow.

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

Cartelle vuote in Scheduler e worker

Managed Airflow non rimuove attivamente le cartelle vuote dai worker e dagli scheduler di Airflow. Queste entità potrebbero essere create in seguito al processo di sincronizzazione del bucket dell'ambiente quando queste cartelle esistevano nel bucket e sono state rimosse.

Consiglio: modifica i DAG in modo che siano pronti a ignorare le cartelle vuote.

Queste entità vengono rimosse definitivamente dagli spazi di archiviazione locali degli scheduler e dei worker Airflow quando questi componenti vengono riavviati (ad esempio, a seguito di operazioni di riduzione o manutenzione nel cluster del tuo ambiente).

Supporto di Kerberos

Managed Airflow non supporta la configurazione Kerberos di Airflow.

Supporto per gli operatori di Google Campaign Manager 360

Gli operatori Google Campaign Manager nelle versioni di Managed Airflow precedenti alla 2.1.13 si basano sull'API Campaign Manager 360 v3.5, che è ritirata e la cui data di ritiro è il 1° maggio 2023.

Se utilizzi gli operatori di Google Campaign Manager, esegui l'upgrade dell'ambiente alla versione 2.1.13 o successive di Managed Airflow.

Supporto per gli operatori di Google Display & Video 360

Gli operatori Google Display & Video 360 nelle versioni di Managed Airflow precedenti alla 2.1.13 si basano sull'API Display & Video 360 v1.1, che è deprecata e la cui data di ritiro è il 27 aprile 2023.

Se utilizzi gli operatori Google Display & Video 360, esegui l'upgrade dell'ambiente alla versione 2.1.13 o successive di Managed Airflow. Inoltre, potresti dover modificare i tuoi DAG perché alcuni operatori di Google Display & Video 360 sono ritirati e sostituiti con nuovi.

• GoogleDisplayVideo360CreateReportOperator è ora deprecato. Utilizza invece GoogleDisplayVideo360CreateQueryOperator. Questo operatore restituisce query_id anziché report_id.
• GoogleDisplayVideo360RunReportOperator è ora deprecato. 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 ritirato richiedeva solo report_id.
• GoogleDisplayVideo360DownloadReportV2Operator ora richiede sia i parametri query_id che report_id.
• In GoogleDisplayVideo360DeleteReportOperator non sono presenti modifiche che possono influire sui tuoi DAG.

Limitazioni relative al nome dell'intervallo secondario

Nota :la convenzione di denominazione gke-.*-(pods|services)-.* è riservata agli intervalli secondari dei cluster GKE creati automaticamente. Non puoi utilizzare nomi di intervalli secondari in questo formato durante la creazione di istanze Managed Airflow.

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

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

Nota :Managed Airflow versione 2.4.2 risolve questo problema nelle versioni 2.4.3 e 2.5.3 di Airflow. Ti consigliamo di aggiornare l'ambiente a Managed Airflow 2.4.2 o versioni successive. Questo problema non riguarda Airflow 2.6.x e versioni successive.

Se utilizzi una versione di Managed Airflow 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 Managed Airflow, l'accesso alla UI di Airflow è protetto con IAM e controllo dell'accesso alla UI di Airflow.

Ciò significa che, per sfruttare la vulnerabilità dell'interfaccia utente di Airflow, gli autori degli attacchi devono prima ottenere l'accesso al tuo progetto insieme ai ruoli e alle autorizzazioni IAM necessari.

Soluzione:

• Verifica le autorizzazioni e i ruoli IAM nel tuo progetto, inclusi i ruoli Managed Service for Apache Airflow assegnati ai singoli utenti. Assicurati che solo gli utenti approvati possano accedere all'interfaccia utente di Airflow.

• Verifica i ruoli assegnati agli utenti tramite il meccanismo di controllo dell'accesso all'interfaccia utente di Airflow (si tratta di un meccanismo separato che fornisce un accesso più granulare all'interfaccia utente 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 un'ulteriore protezione con i Controlli di servizio VPC.

Non è possibile ridurre lo spazio di archiviazione Cloud SQL

Managed Airflow utilizza Cloud SQL per eseguire il database Airflow. Nel tempo, lo spazio di archiviazione su disco per l'istanza Cloud SQL potrebbe aumentare perché il disco viene scalato per adattarsi ai dati archiviati dalle operazioni Cloud SQL man mano che 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ù piccole, puoi ricreare gli ambienti Managed Airflow con gli snapshot.

La metrica Utilizzo disco del database non diminuisce 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. Li contrassegna invece come "tuple morte" per mantenere la coerenza dei dati ed evitare di bloccare le transazioni simultanee.

Sia MySQL che PostgreSQL implementano meccanismi di recupero dello spazio dopo l'eliminazione dei record.

Sebbene sia possibile forzare il database a recuperare lo spazio su disco inutilizzato, questa è un'operazione che richiede molte risorse e che blocca anche il database rendendo Managed Airflow non disponibile. Pertanto, è consigliabile fare affidamento sui meccanismi di creazione per recuperare lo spazio inutilizzato.

I tentativi di attività riusciti in passato contrassegnati come NON RIUSCITI

In alcune circostanze e in rari scenari, le istanze di attività Airflow che hanno avuto esito positivo in passato possono essere contrassegnate come FAILED.

In genere, si verifica a seguito di un aggiornamento o di un'operazione di upgrade dell'ambiente oppure a causa della manutenzione di GKE.

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

Il problema è stato risolto nella versione 2.6.5 o successive di Managed Airflow.

Diagrammi dei tempi di analisi DAG non continui e delle dimensioni del bag DAG nel monitoraggio

I grafici dei tempi di analisi DAG non continui e delle dimensioni del pacchetto DAG nella dashboard di monitoraggio indicano problemi con tempi di analisi DAG lunghi (più di 5 minuti).

Figura 3. Grafici dei tempi di analisi DAG non continui e delle dimensioni del bag DAG (fai clic per ingrandire)

Soluzione: Ti consigliamo di mantenere il tempo totale di analisi del DAG al di sotto dei 5 minuti. Per ridurre il tempo di analisi del DAG, segui le linee guida per la scrittura dei DAG.

Il passaggio del cluster dell'ambiente a GKE Enterprise Edition non è supportato

Questa nota si applica a Managed Airflow 1 e Managed Airflow 2.

Il cluster GKE dell'ambiente Airflow gestito viene creato all'interno di GKE Standard.

A partire da dicembre 2024, il servizio Managed Airflow non supporta la creazione di ambienti Managed Airflow con cluster in Enterprise Edition.

Gli ambienti Managed Airflow non sono stati testati con GKE Enterprise Edition e hanno un modello di fatturazione diverso.

Attenzione: non eseguire l'upgrade dei cluster Managed Airflow a Enterprise Edition. Gli ambienti Managed Airflow non sono stati testati con Enterprise Edition e potresti incorrere in costi aggiuntivi dopo l'upgrade. Se esegui l'upgrade del cluster del tuo ambiente a Enterprise Edition, non sarà supportato da Google.

Ulteriori comunicazioni relative alla versione GKE Standard rispetto alla versione Enterprise verranno effettuate nel secondo trimestre del 2025.

L'ambiente è in stato ERROR dopo l'eliminazione o la disattivazione dell'account di fatturazione del progetto oppure la disattivazione dell'API Managed Airflow

Gli ambienti Managed Airflow interessati da questi problemi non sono recuperabili:

• Dopo l'eliminazione o la disattivazione dell'account di fatturazione del progetto, anche se un altro account è stato collegato in un secondo momento.
• Dopo la disattivazione dell'API Managed Airflow nel progetto, anche se è stata abilitata in un secondo momento.

Per risolvere il problema, puoi:

• Puoi comunque accedere ai dati archiviati nei bucket del tuo ambiente, ma gli ambienti stessi non sono più utilizzabili. Puoi creare un nuovo ambiente Managed Airflow e poi trasferire i tuoi DAG e i tuoi dati.

• Se vuoi eseguire una delle operazioni che rendono i tuoi ambienti non recuperabili, assicurati di eseguire il backup dei dati, ad esempio creando uno snapshot dell'ambiente. In questo modo, puoi creare un altro ambiente e trasferire i relativi dati caricando questo snapshot.

Avvisi relativi al budget di interruzione dei pod per i cluster di ambiente

Nell'interfaccia utente di GKE puoi visualizzare i seguenti avvisi per i cluster dell'ambiente Managed Airflow:

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.

Non è possibile eliminare questi avvisi. Ci adoperiamo per impedire la generazione di questi avvisi.

Possibili soluzioni:

• Ignora questi avvisi finché il problema non viene risolto.

Non è possibile rimuovere un valore di campo in una connessione Airflow

Causa:

L'interfaccia utente di Apache Airflow presenta una limitazione che non consente di aggiornare i campi di connessione con valori vuoti. Quando tenti di farlo, il sistema ripristina le impostazioni salvate in precedenza.

Possibili soluzioni:

La versione 2.10.4 di Apache Airflow include una correzione permanente, ma esiste una soluzione alternativa temporanea per gli utenti che utilizzano versioni precedenti. Ciò comporta l'eliminazione della connessione e la sua ricreazione, lasciando vuoti i campi obbligatori. L'interfaccia a riga di comando è l'approccio consigliato per eliminare la connessione:

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

Dopo aver eliminato la connessione, ricreala utilizzando l'interfaccia utente di Airflow, assicurandoti che i campi che intendi lasciare vuoti siano effettivamente vuoti. Puoi anche creare la connessione eseguendo il comando CLI di Airflow connections add con Google Cloud CLI.

I log per le attività Airflow non vengono raccolti se [core]execute_tasks_new_python_interpreter è impostato su True

Managed Airflow non raccoglie i log per le attività Airflow se l'opzione di configurazione di Airflow [core]execute_tasks_new_python_interpreter è impostata su True.

Possibile soluzione:

• Rimuovi l'override per questa opzione di configurazione o imposta il relativo valore su False.

Passaggi successivi

• Risoluzione dei problemi di creazione dell'ambiente
• Risoluzione dei problemi dei DAG
• Risoluzione dei problemi dello scheduler Airflow