Problèmes connus

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Cette page répertorie les problèmes connus liés à Cloud Composer. Pour en savoir plus sur les corrections de bugs, consultez les notes de version.

Certains problèmes affectent des versions antérieures et peuvent être résolus en mettant à niveau votre environnement.

Les plages d'adresses non-RFC 1918 sont partiellement compatibles avec les pods et les services.

Cloud Composer dépend de GKE pour assurer la compatibilité des adresses non-RFC 1918 avec les pods et les services. Seule la liste suivante de plages non-RFC 1918 est acceptée dans Cloud Composer:

• 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'interface utilisateur d'Airflow n'affiche pas les journaux des tâches lorsque la sérialisation des DAG est activée dans Composer 1.10.2 et Composer 1.10.3.

L'activation de la sérialisation des DAG dans les environnements utilisant les versions 1.10.2 et 1.10.3 de Composer empêche l'affichage des journaux sur le serveur Web Airflow. Pour résoudre ce problème, passez à la version 1.10.4 (ou ultérieure).

Échec intermittent de la tâche lors de la planification dans Cloud Composer

Le problème apparaît dans le planificateur Airflow pour l'instance de tâche lors de l'exécution d'une tâche. Cependant, les journaux n'expliquent pas la cause de l'échec de la tâche, et le nœud de calcul et le programmeur Airflow semblaient relativement opérationnels.

Le message d'erreur du planificateur Airflow peut ressembler à ceci:

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?

Une erreur semblable au message d'erreur suivant peut également s'afficher sur le nœud de calcul Airflow:

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

Pour assurer la robustesse contre ces erreurs provenant d'un problème de longue date dans Airflow, nous vous recommandons vivement d'implémenter de manière proactive des stratégies de nouvelle tentative appropriées au niveau des tâches et des DAG. En intégrant ces mesures, le système peut atténuer efficacement l'impact de ces erreurs, ce qui améliore la fiabilité et la résilience globales du workflow.

La fédération d'identité de charge de travail pour GKE n'est pas compatible.

Dans Cloud Composer 1, vous ne pouvez pas activer la fédération d'identité de charge de travail pour GKE pour les clusters d'environnement Cloud Composer. Par conséquent, il se peut que la recherche WORKLOAD_IDENTITY_DISABLED s'affiche dans Security Command Center.

Les libellés d'environnement ajoutés lors d'une mise à jour ne sont pas entièrement propagés

Lorsque vous mettez à jour les libellés d'environnement, ils ne sont pas appliqués aux VM Compute Engine du cluster de l'environnement. Pour contourner ce problème, vous pouvez appliquer les libellés manuellement.

Les journaux des tâches Airflow ne sont plus disponibles sur le serveur Web Airflow après la mise à niveau d'Airflow 1.9.0 vers Airflow 1.10.x

Airflow 1.10.x a introduit des modifications non rétrocompatibles dans la convention de nommage des fichiers journaux. Les informations sur les zones sont désormais ajoutées aux noms des journaux des tâches Airflow.

Airflow 1.9.0 génère et s'attend à trouver des journaux nommés comme ceci : BUCKET/logs/DAG/2020-03-30T10:29:06/1.log Airflow 1.10.x génère et s'attend à trouver des journaux nommés comme ceci : BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Par conséquent, si vous passez d'Airflow 1.9.0 à Airflow 1.10.x et que vous souhaitez lire le journal d'une tâche exécutée avec Airflow 1.9.0, le serveur Web Airflow affiche le message d'erreur suivant : Unable to read remote log from BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Solution de contournement : Dans le bucket Cloud Storage, renommez les journaux générés par Airflow 1.9.0 selon le format suivant : BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Impossible de créer des environnements Cloud Composer lorsque la règle d'administration constraints/compute.disableSerialPortLogging est activée

La création de l'environnement Cloud Composer échoue si la règle d'administration constraints/compute.disableSerialPortLogging est appliquée au projet cible.

Remarque : Ce problème ne se produit que pour les clusters créés avant la release de Cloud Composer datant du 9 novembre 2020. Tous les nœuds de cluster GKE sont créés avec serial-logging-enable=false dans les environnements Cloud Composer créés après le 9 novembre 2020, ce qui permet d'éviter que ce problème ne se produise.

Diagnostic

Pour savoir si vous êtes concerné par ce problème, procédez comme suit :

Accédez au menu GKE dans la console Google Cloud. Accéder au menu de GKE

Sélectionnez ensuite le cluster que vous venez de créer. Recherchez l'erreur suivante :

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

Solutions :

1. Désactivez la règle d'administration sur le projet dans lequel l'environnement Cloud Composer sera créé.

   Une règle d'administration peut toujours être désactivée au niveau du projet même si elle est activée au niveau des ressources parentes (organisation ou dossier). Pour en savoir plus, consultez la page Personnaliser les règles pour les contraintes booléennes.

2. Utiliser des filtres d'exclusion

   L'utilisation d'un filtre d'exclusion pour les journaux des ports série permet d'atteindre le même objectif que la désactivation de la règle d'organisation, car Logging comprend des journaux de la console série. Pour en savoir plus, consultez la page Filtres d'exclusion.

Utiliser Deployment Manager pour gérer les Google Cloud ressources protégées par VPC Service Controls

Les versions 2.0.x de Cloud Composer 1 et Cloud Composer 2 utilisent Deployment Manager pour créer des composants d'environnements Cloud Composer.

En décembre 2020, il se peut que vous ayez été informé que vous devrez peut-être effectuer une configuration supplémentaire de VPC Service Controls pour pouvoir gérer les ressources protégées par VPC Service Controls à l'aide de Deployment Manager.

Nous souhaitons préciser qu'aucune action n'est requise de votre part si vous utilisez Cloud Composer et que vous n'utilisez pas Deployment Manager directement pour gérer les Google Cloud ressources mentionnées dans l'annonce de Deployment Manager.

Deployment Manager affiche des informations sur une fonctionnalité non compatible

L'avertissement suivant peut s'afficher dans l'onglet "Deployment Manager" :

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

Pour les déploiements de Deployment Manager appartenant à Cloud Composer, vous pouvez ignorer cet avertissement.

Impossible de supprimer un environnement après la suppression de son cluster

Ce problème s'applique aux versions 2.0.x de Cloud Composer 1 et Cloud Composer 2.

Si vous supprimez le cluster GKE de votre environnement avant l'environnement lui-même, les tentatives de suppression de votre environnement entraînent l'erreur suivante:

 Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]

Pour supprimer un environnement lorsque son cluster est déjà supprimé:

1. Dans la console Google Cloud, accédez à la page Deployment Manager.

   Accéder à Deployment Manager

2. Recherchez tous les déploiements marqués avec des libellés :

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

   Vous devriez voir deux déploiements marqués avec les libellés décrits :

   • Un déploiement nommé <environment-location>-<environment-name-prefix>-<hash>-sd
   • Un déploiement nommé addons-<uuid>

3. Supprimez manuellement les ressources toujours répertoriées dans ces deux déploiements et existant dans le projet (par exemple, les sujets et les abonnements Pub/Sub). Pour ce faire :

   1. Sélectionnez les déploiements.

   2. Cliquez sur Supprimer.

   3. Sélectionnez l'option Supprimer deux déploiements et toutes les ressources créées par ceux-ci, telles que les VM, les équilibreurs de charge et les disques, puis cliquez sur Tout supprimer.

   L'opération de suppression échoue, mais les ressources restantes sont supprimées.

4. Supprimez les déploiements en utilisant l'une des options suivantes :

   • Dans la console Google Cloud, sélectionnez à nouveau les deux déploiements. Cliquez sur Supprimer, puis sélectionnez l'option Supprimer deux déploiements, mais conserver les ressources créées par ceux-ci.

   • Exécutez une commande gcloud pour supprimer les déploiements avec la règle 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. Supprimez votre environnement Cloud Composer.

Avertissements concernant les entrées en double de la tâche "echo" appartenant au DAG "echo-airflow_monitoring"

L'entrée suivante peut s'afficher dans les journaux Airflow :

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

Vous pouvez ignorer ces entrées de journal, car cette erreur n'a aucune incidence sur le traitement du DAG et des tâches par Airflow.

Nous nous efforçons d'améliorer le service Cloud Composer pour supprimer ces avertissements des journaux Airflow.

La création d'environnement échoue dans les projets où des API Identity-Aware Proxy ont été ajoutées au périmètre VPC Service Controls

Remarque :Ce problème affecte toutes les versions de Cloud Composer 1.

Dans les projets où VPC Service Controls est activé, le compte [e-mail] nécessite un accès explicite dans votre périmètre de sécurité pour créer des environnements.

Pour créer des environnements, vous pouvez utiliser l'une des solutions suivantes:

• N'ajoutez pas l'API Cloud Identity-Aware Proxy et l'API TCP d'Identity-Aware Proxy au périmètre de sécurité.

• Ajoutez le compte de service [e-mail] en tant que membre de votre périmètre de sécurité à l'aide de la configuration suivante dans le fichier de conditions YAML:

   - members:
      - serviceAccount:[e-mail]
  

La création de l'environnement Cloud Composer 1 échoue lorsque la règle compute.requireOsLogin est activée

Si la règle compute.requireOsLogin est définie sur true dans votre projet, les opérations de création d'environnement Cloud Composer 1 v1 échouent.

Pour créer des environnements Cloud Composer 1, désactivez cette règle dans votre projet.

Pour en savoir plus sur cette règle d'administration, consultez la page Contraintes liées aux règles d'administration.

La création ou la mise à niveau d'un environnement Cloud Composer échoue lorsque la règle compute.vmExternalIpAccess est désactivée

Ce problème s'applique aux environnements Cloud Composer 1 et Cloud Composer 2.

Les clusters GKE appartenant à Cloud Composer configurés en mode adresse IP publique nécessitent une connectivité externe pour leurs VM. De ce fait, la règle compute.vmExternalIpAccess ne peut pas interdire la création de VM ayant des adresses IP externes. Pour en savoir plus sur cette règle d'administration, consultez la page Contraintes liées aux règles d'administration.

La création de l'environnement Cloud Composer 1 échoue lorsque la règle compute.vmCanIpForward est désactivée

Les environnements Cloud Composer 1 créés en mode non VPC natif (utilisation d'une adresse IP d'alias) nécessitent cette règle pour autoriser la création de VM ayant la fonctionnalité "Transfert IP" activée. Pour en savoir plus sur cette règle d'administration, consultez la page Contraintes liées aux règles d'administration.

La première exécution du DAG pour un fichier de DAG importé comporte plusieurs tâches ayant échoué

Lorsque vous importez un fichier de DAG, il se peut que les premières tâches de la première exécution de DAG associée à ce fichier échouent avec l'erreur Unable to read remote log.... Ce problème est dû au fait que le fichier de DAG est synchronisé entre le bucket de votre environnement, les nœuds de calcul Airflow et les programmeurs Airflow de votre environnement. Si le planificateur obtient le fichier de DAG et planifie son exécution par un nœud de calcul alors que ce nœud de calcul ne dispose pas encore du fichier de DAG, l'exécution de la tâche échoue.

Pour atténuer ce problème, les environnements avec Airflow 2 sont configurés pour effectuer par défaut deux tentatives pour chaque tâche ayant échoué. Si une tâche échoue, elle est relancée deux fois avec un intervalle de cinq minutes.

Pour atténuer ce problème dans Airflow 1, remplacez l'option de configuration Airflow [core]default_task_retries et définissez-la sur une valeur supérieure ou égale à 2.

La tâche échoue avec "OSError: [Errno 5] Input/output error" dans Airflow 1.10.15 ou des versions antérieures.

Dans certains cas rares, un bug dans les versions Airflow 1 place les tâches dans la file d'attente Redis deux fois.

Parfois, cela peut entraîner une condition de concurrence sur le fichier journal, qui entraîne alors l'échec de la tâche. Les tâches échouent avec une erreur OSError: [Errno 5] Input/output error dans Cloud Logging et Task is in the 'running' state which is not a valid state for execution. dans le journal des tentatives de tâche.

Ce bug est corrigé dans Airflow 2. Si vous rencontrez ce problème dans Airflow 1 dans une tâche de longue durée, augmentez la valeur de l'option de configuration Airflow [celery_broker_transport_options]visibility_timeout (la valeur par défaut correspond à 604800 pour Composer 1.17.0 et à 21600 pour les environnements plus anciens). Pour les tâches de courte durée, envisagez d'ajouter des tentatives supplémentaires aux tâches concernées ou de migrer votre environnement vers Airflow 2.

Les opérateurs Dataproc et Dataflow échouent avec une erreur Negsignal.SIGSEGV

Il s'agit d'un problème intermittent de la bibliothèque grcpio, lorsqu'elle est utilisée à partir d'un nœud de calcul Celery. Ce problème affecte Airflow 1.10.14 et versions ultérieures.

La solution consiste à modifier la stratégie d'interrogation grpcio en ajoutant la variable d'environnement suivante à votre environnement : GRPC_POLL_STRATEGY=epoll1. Cette solution est déjà appliquée dans Cloud Composer 1.17.1 et versions ultérieures.

Annonces concernant la suppression de la compatibilité avec les API bêta obsolètes dans les versions de GKE

Cloud Composer gère les clusters GKE sous-jacents appartenant à Cloud Composer. À moins que vous n'utilisiez explicitement ces API dans vos DAG et votre code, vous pouvez ignorer les annonces concernant les abandons d'API GKE. Cloud Composer se charge de toutes les migrations, si nécessaire.

Cloud Composer ne devrait pas être affecté par la faille Apache Log4j 2 (CVE-2021-44228)

En réponse à la faille Apache Log4j 2 (CVE-2021-44228), Cloud Composer a mené une enquête détaillée et nous pensons que Cloud Composer n'est pas vulnérable à cet exploit.

Les nœuds de calcul ou les programmeurs Airflow peuvent rencontrer des problèmes lors de l'accès au bucket Cloud Storage de l'environnement.

Cloud Composer utilise gcsfuse pour accéder au dossier /data du bucket de l'environnement et pour enregistrer les journaux de tâches Airflow dans le répertoire /logs (si activé). Si gcsfuse est surchargé ou si le bucket de l'environnement n'est pas disponible, des erreurs d'instance de tâche Airflow peuvent se produire et des erreurs Transport endpoint is not connected peuvent s'afficher dans les journaux Airflow.

Solutions :

• Désactivez l'enregistrement des journaux dans le bucket de l'environnement. Cette option est déjà désactivée par défaut si un environnement est créé à l'aide de Cloud Composer 2.8.0 ou version ultérieure.
• Effectuez une mise à niveau vers Cloud Composer 2.8.0 ou une version ultérieure.
• Réduisez [celery]worker_concurrency et augmentez plutôt le nombre de nœuds de calcul Airflow.
• Réduisez la quantité de journaux générés dans le code du DAG.
• Suivez les recommandations et bonnes pratiques pour implémenter des DAG et activez les nouvelles tentatives de tâches.

L'interface utilisateur d'Airflow peut parfois ne pas recharger un plug-in une fois qu'il a été modifié.

Si un plug-in se compose de nombreux fichiers qui importent d'autres modules, l'interface utilisateur d'Airflow risque de ne pas pouvoir reconnaître qu'un plug-in doit être réactivé. Dans ce cas, redémarrez le serveur Web Airflow de votre environnement.

Problèmes intermittents lors de la communication avec la base de données de l'environnement

Ce problème connu ne concerne que Cloud Composer 1.

Certains environnements Cloud Composer 1 antérieurs (1.16.3 ou version antérieure) créés avant le 12 août 2021 peuvent rencontrer des problèmes temporaires liés à la communication avec la base de données Airflow.

Si ce problème se produit, le message d'erreur suivant s'affiche dans les journaux des tâches Airflow:

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

L'équipe Cloud Composer s'efforce de résoudre ce problème. En attendant, si vous pensez être fortement affecté par ce problème, vous pouvez le réduire en procédant comme suit:

1. Dans la console Google Cloud, accédez à la page Configuration de l'environnement des environnements Cloud Composer concernés.

2. Suivez le lien Afficher les détails du cluster pour accéder au cluster GKE sous-jacent de l'environnement.

3. Accédez à l'onglet Nœuds, puis cliquez sur default-pool dans la section Pools de nœuds.

   

   Figure 1 : default-pool dans la liste des pools de nœuds (cliquez pour agrandir)

4. Cliquez sur Modifier en haut de la page.

5. Définissez le type d'image sur Container-Optimized OS avec containerd et enregistrez la configuration:

   

   Figure 2 : Modifier le type d'image du pool de nœuds de Docker vers containerd (cliquez pour agrandir)

6. Une fois la modification envoyée, votre pool de nœuds default-pool sera reconfiguré pour utiliser containerd comme environnement d'exécution de conteneur. Certaines de vos tâches Airflow peuvent échouer pendant la reconfiguration du pool de nœuds. Si des tentatives sont configurées pour ces tâches, elles seront réexécutées par Airflow une fois l'opération sur le pool de nœuds terminée.

Erreur 504 lors de l'accès à l'interface utilisateur d'Airflow

L'erreur 504 Gateway Timeout peut s'afficher lorsque vous accédez à l'interface utilisateur d'Airflow. Cette erreur peut avoir plusieurs causes:

• Problème de communication temporaire. Dans ce cas, essayez d'accéder à l'interface utilisateur d'Airflow plus tard. Vous pouvez également redémarrer le serveur Web Airflow.

• (Cloud Composer 3 uniquement) Problème de connectivité. Si l'interface utilisateur d'Airflow est définitivement indisponible et que des erreurs de délai avant expiration ou 504 sont générées, assurez-vous que votre environnement peut accéder à *.composer.googleusercontent.com.

• (Cloud Composer 2 uniquement) Problème de connectivité. Si l'interface utilisateur d'Airflow est définitivement indisponible et que des erreurs de délai avant expiration ou 504 sont générées, assurez-vous que votre environnement peut accéder à *.composer.cloud.google.com. Si vous utilisez l'accès Google privé et que vous envoyez du trafic via des adresses IP virtuelles private.googleapis.com, ou si vous utilisez VPC Service Controls et que vous envoyez du trafic via des adresses IP virtuelles restricted.googleapis.com, assurez-vous que votre Cloud DNS est également configuré pour les noms de domaine *.composer.cloud.google.com.

• Serveur Web Airflow qui ne répond pas. Si l'erreur 504 persiste, mais que vous pouvez toujours accéder à l'interface utilisateur d'Airflow à certains moments, le serveur Web Airflow peut ne pas répondre, car il est surchargé. Essayez d'augmenter les paramètres de scaling et de performances du serveur Web.

Erreur 502 lors de l'accès à l'interface utilisateur d'Airflow

L'erreur 502 Internal server exception indique que l'interface utilisateur d'Airflow ne peut pas traiter les requêtes entrantes. Cette erreur peut avoir plusieurs causes:

• Problème de communication temporaire. Essayez d'accéder à l'interface utilisateur d'Airflow plus tard.

• Échec du démarrage du serveur Web. Pour démarrer, le serveur Web doit d'abord synchroniser les fichiers de configuration. Recherchez dans les journaux du serveur Web des entrées qui ressemblent à: GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp ou GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp. Si ces erreurs s'affichent, vérifiez si les fichiers mentionnés dans les messages d'erreur sont toujours présents dans le bucket de l'environnement.

  En cas de suppression accidentelle (par exemple, en raison de la configuration d'une règle de conservation), vous pouvez les restaurer:

  1. Définissez une nouvelle variable d'environnement dans votre environnement. Vous pouvez utiliser n'importe quel nom et valeur de variable.

  2. Remplacez une option de configuration Airflow. Vous pouvez utiliser une option de configuration Airflow inexistante.

L'interface utilisateur d'Airflow dans Airflow 2.2.3 ou version antérieure est vulnérable à la faille CVE-2021-45229

Comme indiqué dans CVE-2021-45229, l'écran "Trigger DAG with config" (Déclencher un DAG avec une configuration) était susceptible d'attaques XSS via l'argument de requête origin.

Recommandation: Passez à la dernière version de Cloud Composer compatible avec Airflow 2.2.5.

Déclenchement de DAG via des réseaux privés à l'aide de fonctions Cloud Run

Cloud Composer n'est pas compatible avec le déclenchement de DAG avec des fonctions Cloud Run via des réseaux privés à l'aide du connecteur VPC.

Recommandation: Utilisez des fonctions Cloud Run pour publier des messages sur Pub/Sub. Ces événements peuvent déclencher des capteurs Pub/Sub pour déclencher des DAG Airflow ou implémenter une approche basée sur des opérateurs différables.

Dossiers vides dans le programmeur et les nœuds de calcul

Cloud Composer ne supprime pas activement les dossiers vides des nœuds de calcul et des planificateurs Airflow. Ces entités peuvent être créées à la suite du processus de synchronisation du bucket d'environnement lorsque ces dossiers existaient dans le bucket et ont finalement été supprimés.

Recommandation: Ajustez vos DAG afin qu'ils soient prêts à ignorer ces dossiers vides.

Ces entités sont finalement supprimées des stockages locaux des planificateurs et des nœuds de calcul Airflow lorsque ces composants sont redémarrés (par exemple, en raison d'une réduction de l'échelle ou d'opérations de maintenance dans le cluster de votre environnement).

Compatibilité avec Kerberos

Cloud Composer n'est pas compatible avec la configuration Kerberos d'Airflow.

Compatibilité avec les opérateurs Google Campaign Manager 360

Les opérateurs Google Campaign Manager dans les versions Cloud Composer antérieures à 2.1.13 sont basés sur l'API Campaign Manager 360 v3.5, qui est obsolète et dont la date d'abandon est le 1er mai 2023.

Si vous utilisez des opérateurs Google Campaign Manager, mettez à niveau votre environnement vers la version 2.1.13 ou ultérieure de Cloud Composer.

Prise en charge des opérateurs Google Display et Video 360

Les opérateurs Google Display & Video 360 des versions Cloud Composer antérieures à 2.1.13 sont basés sur l'API Display & Video 360 v1.1, qui est obsolète et dont la date d'abandon est fixée au 27 avril 2023.

Si vous utilisez des opérateurs Google Display & Video 360, mettez à niveau votre environnement vers la version 2.1.13 ou ultérieure de Cloud Composer. De plus, vous devrez peut-être modifier vos DAG, car certains des opérateurs Google Display & Video 360 sont obsolètes et remplacés par de nouveaux.

• GoogleDisplayVideo360CreateReportOperator est désormais obsolète. Utilisez plutôt GoogleDisplayVideo360CreateQueryOperator. Cet opérateur renvoie query_id au lieu de report_id.
• GoogleDisplayVideo360RunReportOperator est désormais obsolète. Utilisez plutôt GoogleDisplayVideo360RunQueryOperator. Cet opérateur renvoie query_id et report_id au lieu de report_id uniquement, et nécessite query_id au lieu de report_id comme paramètre.
• Pour vérifier si un rapport est prêt, utilisez le nouveau capteur GoogleDisplayVideo360RunQuerySensor qui utilise les paramètres query_id et report_id. Le capteur GoogleDisplayVideo360ReportSensor obsolète ne nécessitait que report_id.
• GoogleDisplayVideo360DownloadReportV2Operator nécessite désormais les paramètres query_id et report_id.
• Dans GoogleDisplayVideo360DeleteReportOperator, aucune modification ne peut affecter vos DAG.

Restrictions concernant le nom de la plage secondaire

Remarque :La convention d'attribution de nom gke-.*-(pods|services)-.* est réservée aux plages secondaires de cluster GKE créées automatiquement. Vous ne pouvez pas utiliser de noms de plage secondaire dans ce format lorsque vous créez des instances Cloud Composer.

CVE-2023-29247 (la page d'informations sur l'instance de tâche de l'UI est vulnérable à une attaque XSS stockée)

L'interface utilisateur d'Airflow dans les versions d'Airflow allant de 2.0.x à 2.5.x est vulnérable à la faille CVE-2023-29247.

Remarque :La version 2.4.2 de Cloud Composer résout ce problème dans les versions 2.4.3 et 2.5.3 d'Airflow. Nous vous recommandons de mettre à jour votre environnement vers Cloud Composer 2.4.2 ou une version ultérieure. Ce problème n'affecte pas Airflow 2.6.x et versions ultérieures.

Si vous utilisez une version antérieure à la version 2.4.2 de Cloud Composer et que vous pensez que votre environnement est susceptible d'être vulnérable à l'exploitation, veuillez lire la description suivante et les solutions possibles.

Dans Cloud Composer, l'accès à l'interface utilisateur d'Airflow est protégé par IAM et le contrôle des accès à l'interface utilisateur d'Airflow.

Cela signifie que pour exploiter la faille de l'interface utilisateur Airflow, les pirates informatiques doivent d'abord accéder à votre projet, ainsi qu'aux autorisations et rôles IAM nécessaires.

Solution :

• Vérifiez les autorisations et les rôles IAM de votre projet, y compris les rôles Cloud Composer attribués à des utilisateurs individuels. Assurez-vous que seuls les utilisateurs approuvés peuvent accéder à l'interface utilisateur d'Airflow.

• Vérifiez les rôles attribués aux utilisateurs via le mécanisme de contrôle des accès à l'interface utilisateur d'Airflow (il s'agit d'un mécanisme distinct qui offre un accès plus précis à l'interface utilisateur d'Airflow). Assurez-vous que seuls les utilisateurs approuvés peuvent accéder à l'interface utilisateur d'Airflow et que tous les nouveaux utilisateurs sont enregistrés avec un rôle approprié.

• Envisagez de renforcer davantage la sécurité avec VPC Service Controls.

Il est impossible de réduire l'espace de stockage Cloud SQL

Cloud Composer utilise Cloud SQL pour exécuter la base de données Airflow. Au fil du temps, l'espace de stockage sur disque de l'instance Cloud SQL peut augmenter, car le disque est mis à l'échelle pour s'adapter aux données stockées par les opérations Cloud SQL lorsque la base de données Airflow augmente.

Vous ne pouvez pas réduire la taille du disque Cloud SQL.

Pour contourner ce problème, si vous souhaitez utiliser la plus petite taille de disque Cloud SQL, vous pouvez recréer des environnements Cloud Composer à l'aide de instantanés.

La métrique d'utilisation de l'espace disque de la base de données ne diminue pas après la suppression d'enregistrements de Cloud SQL

Les bases de données relationnelles, telles que Postgres ou MySQL, ne suppriment pas physiquement les lignes lorsqu'elles sont supprimées ou mises à jour. Au lieu de cela, il les marque comme "tuples morts" pour assurer la cohérence des données et éviter de bloquer les transactions simultanées.

MySQL et Postgres implémentent des mécanismes de récupération d'espace après la suppression d'enregistrements.

Bien qu'il soit possible de forcer la base de données à récupérer l'espace disque inutilisé, il s'agit d'une opération gourmande en ressources qui verrouille également la base de données, ce qui rend Cloud Composer indisponible. Il est donc recommandé de s'appuyer sur les mécanismes de compilation pour récupérer l'espace inutilisé.

Instances de tâche ayant réussi par le passé, marquées comme "ÉCHEC"

Dans certains cas et scénarios rares, les instances de tâche Airflow qui ont réussi par le passé peuvent être marquées comme FAILED.

Si cela se produit, il s'agit généralement d'une opération de mise à jour ou de mise à niveau de l'environnement, ou d'une maintenance GKE.

Remarque:Le problème lui-même n'indique aucun problème dans l'environnement et ne provoque aucun échec réel dans l'exécution des tâches.

Ce problème est résolu dans Cloud Composer version 2.6.5 ou ultérieure.

Les composants Airflow rencontrent des problèmes lors de la communication avec d'autres parties de la configuration Cloud Composer

Dans de très rares cas, la lenteur de la communication avec le serveur de métadonnées Compute Engine peut entraîner un fonctionnement non optimal des composants Airflow. Par exemple, le planificateur Airflow peut être redémarré, les tâches Airflow peuvent devoir être réessayées ou le temps de démarrage des tâches peut être plus long.

Symptômes :

Les erreurs suivantes s'affichent dans les journaux des composants Airflow (par exemple, les planificateurs Airflow, les nœuds de calcul ou le serveur Web):

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

Solution :

Définissez la variable d'environnement suivante: GCE_METADATA_TIMEOUT=30.

Diagrammes de durées d'analyse des DAG non continues et de taille des sacs de DAG dans la surveillance

Les temps d'analyse des DAG non continus et les diagrammes de taille de la poche DAG dans le tableau de bord de surveillance indiquent des problèmes liés à de longs temps d'analyse des DAG (plus de cinq minutes).

Figure 3 Graphiques de durée d'analyse des DAG non continue et de taille de sac des DAG (cliquez pour agrandir)

Solution:Nous vous recommandons de limiter la durée d'analyse totale du DAG à cinq minutes. Pour réduire le temps d'analyse des DAG, suivez les consignes d'écriture des DAG.

Il n'est pas possible de passer le cluster de l'environnement à l'édition GKE Enterprise.

Cette remarque s'applique à Cloud Composer 1 et à Cloud Composer 2.

Le cluster GKE de l'environnement Cloud Composer est créé dans l'édition standard de GKE.

Depuis décembre 2024, le service Cloud Composer n'est plus compatible avec la création d'environnements Cloud Composer avec des clusters dans l'édition Enterprise.

Les environnements Cloud Composer n'ont pas été testés avec l'édition Enterprise de GKE, qui dispose d'un modèle de facturation différent.

Attention :Ne mettez pas à niveau les clusters Cloud Composer vers l'édition Enterprise. Les environnements Cloud Composer n'ont pas été testés avec l'édition Enterprise, et des frais supplémentaires peuvent s'appliquer après la mise à niveau vers celle-ci. Si vous mettez à niveau le cluster de votre environnement vers l'édition Enterprise, il ne sera pas pris en charge par Google.

Nous vous communiquerons plus d'informations sur l'édition GKE Standard par rapport à l'édition Enterprise au cours du deuxième trimestre 2025.

L'environnement est à l'état "ERROR" (ERREUR) après la suppression ou la désactivation du compte de facturation du projet, ou la désactivation de l'API Cloud Composer

Les environnements Cloud Composer concernés par ces problèmes ne sont pas récupérables:

• Après la suppression ou la désactivation du compte de facturation du projet, même si un autre compte a été associé par la suite.
• Après que l'API Cloud Composer a été désactivée dans le projet, même si elle a été activée par la suite.

Pour résoudre le problème, procédez comme suit:

• Vous pouvez toujours accéder aux données stockées dans les buckets de votre environnement, mais ceux-ci ne sont plus utilisables. Vous pouvez créer un environnement Cloud Composer, puis transférer vos DAG et vos données.

• Si vous souhaitez effectuer l'une des opérations qui rendent vos environnements non récupérables, veillez à sauvegarder vos données, par exemple en créant un instantané d'un environnement. Vous pouvez ainsi créer un autre environnement et transférer ses données en chargeant cet instantané.

Mises en garde concernant le budget d'interruption de pods pour les clusters d'environnements

Vous pouvez voir les avertissements suivants dans l'interface utilisateur GKE pour les clusters d'environnement Cloud Composer:

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.

Il est impossible d'éliminer ces avertissements. Nous mettons tout en œuvre pour éviter la génération de ces avertissements.

Solutions possibles:

• Ignorez ces avertissements tant que le problème n'est pas résolu.

Étape suivante

• Résoudre les problèmes de création d'environnement
• Découvrez comment résoudre les problèmes liés aux DAG.
• Résoudre les problèmes liés à Airflow Scheduler