Problèmes connus

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

Cette page répertorie les problèmes connus de Cloud Composer. Des correctifs pour ces problèmes sont en cours et seront disponibles dans les versions futures.

Certains problèmes affectent des versions plus anciennes 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. Actuellement, seuls les éléments suivants liste des plages d'adresses IP non-RFC 1918 est compatible avec 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 se produit dans un planificateur Airflow pour l'instance de tâche lors de l'exécution de la tâche. Toutefois, les journaux n'expliquent pas la cause de l'échec d'une tâche, et le nœud de calcul et le programmeur Airflow semblent relativement sains.

Le message d'erreur dans Airflow Scheduler peut ressembler à celui-ci :

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?

Il se peut également qu'une erreur semblable à celle ci-dessous s'affiche 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 face à 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 de la tâche et du 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.

GKE Workload Identity n'est pas compatible.

Ce problème ne s'applique qu'aux environnements Cloud Composer 1. Cloud Composer 2 utilisent Workload Identity.

Vous ne pouvez pas activer Workload Identity pour Clusters de l'environnement Cloud Composer. Il se peut donc que les Résultat WORKLOAD_IDENTITY_DISABLED dans Security Command Center.

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

Les libellés d'environnement mis à jour ne sont pas appliqués aux VM Compute Engine. Pour contourner ce problème, vous pouvez appliquer ces libellés manuellement.

Mises à niveau de GKE dans le contexte du problème CVE-2020-14386

Nous mettons tout en œuvre pour résoudre les CVE-2020-14386 pour tous les environnements Cloud Composer. Dans le cadre du tous les clusters GKE existants de Cloud Composer seront mis à jour une version plus récente.

Les clients qui décident de corriger immédiatement la faille peuvent mettre à niveau le cluster GKE de Cloud Composer à l'aide de ces instructions, en tenant compte des points suivants :

1. Si vous exécutez une version de Cloud Composer antérieure à la version 1.7.2, passez à une version plus récente. Si vous utilisez déjà la version 1.7.2 ou une version ultérieure, passez au point suivant.

Étape 2. Mettez à niveau le cluster GKE (maître et nœuds) vers la dernière version de correctif 1.15 contenant le correctif pour cette faille.

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 apporte des modifications incompatibles avec les versions antérieures au nom pour les 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 constraints/compute.disableSerialPortLogging est appliqué sur le projet cible.

Diagnostic

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

Accédez au menu GKE dans 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 ressources Google Cloud protégées par VPC Service Controls

Composer utilise 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 Composer et que vous n'utilisez pas Deployment Manager directement pour gérer les ressources Google Cloud mentionnées dans l'annonce de Deployment Manager.

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

Si vous supprimez le cluster 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 GKE est déjà supprimé :

  1. Ouvrez la page Deployment Manager dans la console Google Cloud.

    Ouvrir la page 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.

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.

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 avec des API Identity-Aware Proxy ajoutées au périmètre VPC Service Controls

Dans les projets où VPC Service Controls est activé, le compte cloud-airflow-prod@system.gserviceaccount.com nécessite une autorisation 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 ni API Identity-Aware Proxy TCP au périmètre de sécurité.

  • Ajouter le compte de service cloud-airflow-prod@system.gserviceaccount.com en tant que membre de votre périmètre de sécurité en utilisant la configuration suivante dans le fichier de conditions YAML:

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

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 de l'environnement Cloud Composer échoue lorsque la contrainte compute.vmExternalIpAccess est désactivée

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 é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. Ces synchronisations sont effectuées indépendamment. Si le programmeur 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 contourner ce problème, les environnements Airflow 2 dans Cloud Composer 1.17.0-preview.9 et versions ultérieures sont configurées 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 utiliser la solution à 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/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.

Mises à niveau de GKE dans le contexte du problème de sécurité CVE-2021-25741

Tous les clusters GKE de Cloud Composer existants seront automatiquement mis à niveau vers les versions les plus récentes de GKE. Cela corrigera les problèmes décrits dans la norme CVE-2021-25741.

Si vous souhaitez corriger cette faille immédiatement, mettez à niveau le cluster GKE de votre environnement en suivant les instructions de mise à niveau d'un cluster.

  • Si vous disposez d'un environnement Cloud Composer 1 et de la version GKE 1.18.x ou antérieure, passez à la version 1.18.20-gke.4501.

  • Si vous disposez d'un environnement Cloud Composer 1 et de la version 1.19.x de GKE, passez à la version 1.19.14-gke.301.

  • Si vous disposez d'un environnement Cloud Composer 2 et de la version 1.21.x de GKE, passez à la version 1.21.4-gke.301.

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

En réponse à la faille CVE-2021-44228 d'Apache Log4j 2. Cloud Composer a mené une enquête approfondie et nous pensons que Cloud Composer n'est pas vulnérable à cette attaque.

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 répertoire bucket de l'environnement et d'enregistrer les journaux des 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 :

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, il est nécessaire de déclencher un redémarrage du serveur Web Airflow. Pour ce faire, ajoutez une variable d'environnement ou installez ou désinstallez des dépendances PYPI. Vous pouvez également redémarrer le serveur Web Airflow.

Problèmes intermittents lors de la communication avec la base de données de métadonnées Airflow

Ce problème connu ne s'applique qu'à Cloud Composer 1.

Certains anciens environnements Cloud Composer 1 (1.16.3 ou antérieurs) créés avant le Le 12 août 2021, il est possible que vous rencontriez des problèmes temporaires liés à la communication avec Bases de données de métadonnées Airflow.

Si vous rencontrez ce problème, les journaux des tâches Airflow indiqueront le message d'erreur suivant:

"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 procéder comme suit pour le résoudre :

  1. Dans la console Google Cloud, accédez à la page Configuration de l'environnement des environnements Cloud Composer concernés.
  2. Cliquez sur le lien Afficher les détails du cluster pour naviguer. au cluster GKE sous-jacent de l'environnement.

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

    &quot;default-pool&quot; dans la liste des 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. Modifiez le type d'image sur Container-Optimized OS avec containerd et enregistrez la configuration. comme indiqué ci-dessous.

    Changer le type d&#39;image du pool de nœuds de Docker à containerd
    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 de nouvelles tentatives sont configurées pour ces tâches, sera réexécuté par Airflow, une fois l'opération terminée sur le pool de nœuds.

Le cluster de l'environnement comporte des charges de travail à l'état "Non programmable"

Ce problème connu ne s'applique qu'à Cloud Composer 2.

Dans Cloud Composer 2, après la création d'un environnement, plusieurs charges de travail dans le le cluster reste à l'état "Non programmable".

Lorsqu'un environnement est mis à l'échelle, de nouveaux pods de nœuds de calcul sont créés et Kubernetes tente de les exécuter. Si aucune ressource disponible ne permet de les exécuter, les pods de travail sont marqués comme non planifiables.

Dans ce cas, l'autoscaler de cluster ajoute des nœuds, ce qui prend quelques minutes. Tant que cette opération n'est pas terminée, les pods restent à l'état "Non programmable" et n'exécutent aucune tâche.

Les charges de travail DaemonSet non programmables nommées composer-gcsfuse et composer-fluentd qui ne sont pas démarrer sur des nœuds où les composants Airflow ne sont pas présents n'affectent pas votre environnement.

Si le problème persiste pendant une longue période (plus d'une heure), vous pouvez vérifier l'état du cluster Journaux de l'autoscaler. Vous les trouverez dans la visionneuse de journaux avec le filtre suivant :

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

Il contient des informations sur les décisions prises par l'autoscaler de cluster : développez tout noDecisionStatus pour voir pourquoi le cluster ne peut pas être mis à l'échelle.

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 2 uniquement) Problème de connectivité. Si l'interface utilisateur d'Airflow est de manière permanente et que des erreurs d'expiration de délai ou de code 504 sont générées, assurez-vous que votre 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.
  • Le serveur Web Airflow ne répond pas. Si l'erreur 504 persiste, mais vous pouvez toujours accéder à l'interface utilisateur d'Airflow à certains moments, puis le serveur Web Airflow risque de 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 commencer, le serveur Web requiert de configuration doivent être synchronisés en premier. Recherchez dans les journaux du serveur Web Entrées de journal semblables à: 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ésentes dans le bucket de l'environnement.

    En cas de suppression accidentelle (par exemple, parce qu'une a été configurée), vous pouvez les restaurer:

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

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

Pointer sur une instance de tâche dans la vue Arborescence génère une erreur TypeError non détectée

Dans Airflow 2, l'affichage en arborescence de l'interface utilisateur d'Airflow peut parfois ne pas fonctionner correctement lorsqu'un fuseau horaire autre que celui par défaut est utilisé. Pour contourner ce problème, problème, configurer explicitement le fuseau horaire dans l'interface utilisateur d'Airflow.

Dans Airflow 2.2.3 ou les versions antérieures, l'interface utilisateur d'Airflow est vulnérable à la CVE-2021-45229.

Comme indiqué dans CVE-2021-45229, "Déclencher le DAG avec la configuration" était sensible aux attaques XSS via l'argument de requête origin.

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

Les nœuds de calcul nécessitent plus de mémoire que dans les versions précédentes d'Airflow

Problèmes constatés:

  • Dans votre environnement Cloud Composer 2, toutes les charges de travail de cluster de l'environnement Les nœuds de calcul Airflow sont à l'état CrashLoopBackOff et ne s'exécutent pas tâches. Vous pouvez également voir OOMKilling avertissements générés si vous concernés par ce problème.

  • Ce problème peut empêcher les mises à niveau de l'environnement.

Cause:

  • Si vous utilisez une valeur personnalisée pour l'option de configuration Airflow [celery]worker_concurrency et les paramètres de mémoire personnalisés pour les nœuds de calcul Airflow, vous pouvez rencontrer ce problème lorsque la consommation de ressources approche de la limite.
  • Exigences de mémoire des nœuds de calcul Airflow dans Airflow 2.6.3 avec Python 3.11 : 10% plus élevée par rapport aux nœuds de calcul des versions précédentes.
  • Exigences de mémoire des nœuds de calcul Airflow dans Airflow 2.3 et versions ultérieures : 30% plus élevée qu'avec les nœuds de calcul Airflow 2.2 ou Airflow 2.1.

Solutions :

  • Supprimez le forçage pour worker_concurrency afin que : Cloud Composer calcule cette valeur automatiquement.
  • Si vous utilisez une valeur personnalisée pour worker_concurrency, définissez-la sur une valeur inférieure. Vous pouvez utiliser la valeur calculée automatiquement comme point de départ.
  • Vous pouvez également augmenter la quantité de mémoire disponible pour les nœuds de calcul Airflow.
  • Si vous ne pouvez pas mettre à niveau votre environnement vers une version ultérieure pour cette raison , puis appliquez l'une des solutions proposées avant de procéder à la mise à niveau.

Déclenchement des 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 les capteurs Pub/Sub pour déclencher des DAG Airflow ou implémenter une approche basée sur des opérateurs différables.

Problème lié aux commandes gcloud composer dans la version 410.0.0

Dans la version 410.0.0 de gcloud, les commandes Cloud Composer suivantes :

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

renvoie un code d'erreur non nul et affiche le message d'erreur suivant :

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

Ce comportement se produit en plus de la sortie régulière générée par les commandes gcloud et n'a aucune incidence sur leur fonctionnalité.

Si ce problème n'affecte pas vos opérations, vous pouvez continuer à utiliser la version 410.0.0 et ignorer le message d'erreur incorrect. Si vous devez utiliser la version 410.0.0 et que vous utilisez la commande gcloud de manière programmatique, veuillez implémenter une logique supplémentaire pour ignorer les codes d'erreur non nuls et les informations sur la trace de la pile d'erreurs dans le résultat. Vous pouvez également consulter la section "Solution" pour découvrir d'autres solutions de contournement.

Solution

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. De telles entités peuvent être créées en raison de l'environnement de synchronisation du bucket lorsque ces dossiers existent dans le bucket. et ont finalement été supprimées.

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

Ces entités sont finalement supprimées des espaces de stockage 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 Cloud Composer).

Compatibilité avec Kerberos

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

Prise en charge des classes de calcul dans Cloud Composer 2

Cloud Composer 2 n'est compatible qu'avec la classe de calcul à usage général. Cela signifie qu'il est impossible d'exécuter des pods qui demandent d'autres classes de calcul (telles que Équilibré ou Évolutif).

La classe à usage général permet d'exécuter des pods demandant jusqu'à 110 Go de données et jusqu'à 30 CPU (comme décrit dans Requêtes Compute Class Max.

Si vous souhaitez utiliser une architecture ARM ou si vous avez besoin de plus de processeurs et de mémoire, vous devez utiliser une autre classe de calcul, qui n'est pas compatible avec Clusters Cloud Composer 2.

Recommandation: Utilisez GKEStartPodOperator pour exécuter des pods Kubernetes sur un autre cluster compatible avec la classe de calcul sélectionnée. Si vous exécutez des pods personnalisés nécessitant une classe de calcul différente, ils doivent également s'exécuter sur un cluster autre que Cloud Composer 2.

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.

Compatibilité avec les opérateurs Google Display & Video 360

Opérateurs Google Display & Video 360 dans les versions Cloud Composer antérieures à la version 2.1.13 sont basées sur l'API Display & Video 360 version 1.1, obsolète et sa date d'abandon est le 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. À la place, utiliser 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 à la fois query_id et report_id.
  • Dans GoogleDisplayVideo360DeleteReportOperator, aucune modification ne peut affecter vos DAG.

Restrictions liées au nom de la plage secondaire

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

Dans les versions 2.0.x à 2.5.x, l'interface utilisateur d'Airflow est vulnérable aux CVE-2023-29247

Si vous utilisez une version de Cloud Composer antérieure à la version 2.4.2 et que suspect que votre environnement est vulnérable, veuillez consulter 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.

Le DAG de surveillance d'Airflow de l'environnement Cloud Composer 2 n'est pas recréé après sa suppression

Le DAG de surveillance d'Airflow n'est pas automatiquement recréé s'il est supprimé par l'utilisateur ou déplacé du bucket dans les environnements Composer avec composer-2.1.4-airflow-2.4.3.

Solution :

  • Ce problème a été résolu dans les versions ultérieures, telles que composer-2.4.2-airflow-2.5.3. Nous vous recommandons de mettre à niveau votre environnement vers une version plus récente.
  • Une solution alternative ou temporaire à une mise à niveau de l'environnement consiste à copier le DAG airflow_monitoring à partir d'un autre environnement avec la même version.

Les opérations de mise à niveau peuvent échouer si Sentry est activé

L'opération de mise à niveau d'un environnement Cloud Composer peut échouer si vous avez configuré Sentry dans votre environnement et défini le paramètre [sentry]sentry_on sur true.

Solution :

  • Désactivez Sentry dans votre environnement, effectuez la mise à niveau, puis configurez Sentry à nouveau.

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-dessus l'espace de stockage sur le disque de l'instance Cloud SQL peut augmenter, car le disque est ajusté pour s'adapter aux données stockées par les opérations Cloud SQL lorsque La base de données Airflow croît.

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

Accès bloqué : erreur d'autorisation

Si ce problème affecte un utilisateur, le Accès bloqué: Erreur d'autorisation contient le Message Error 400: admin_policy_enforced.

Si l'option Contrôles des API > Applications tierces non configurées > Ne pas autoriser les utilisateurs à accéder aux applications tierces est activée dans Google Workspace et que l'application Apache Airflow dans Cloud Composer n'est pas explicitement autorisée, les utilisateurs ne peuvent pas accéder à l'interface utilisateur d'Airflow, sauf s'ils autorisent explicitement l'application.

Pour autoriser l'accès, suivez les étapes décrites dans la section Autoriser l'accès à l'interface utilisateur Airflow dans Google Workspace.

Les instances de tâche qui ont réussi sont marquées comme ayant échoué.

Dans certains cas et de rares cas, les instances de tâches Airflow qui ont réussi peuvent être marqués comme FAILED.

Si cela se produit, il est généralement déclenché par une mise à jour de l’environnement ou de mise à niveau ou de maintenance de GKE.

Remarque:Le problème en lui-même n'indique pas l'existence d'un problème au niveau de l'environnement et il n'entraîne aucun échec réel de l'exécution des tâches.

Le 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 communication avec Compute Engine Le serveur de métadonnées peut empêcher les composants Airflow de fonctionner de manière optimale. 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 (tels que 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.

Le dossier /data n'est pas disponible dans le serveur Web Airflow

Dans Cloud Composer 2, le serveur Web Airflow est principalement destiné à être un composant en lecture seule, et Cloud Composer ne synchronise pas le dossier data/ avec ce composant.

Dans certains cas, vous souhaiterez peut-être partager des fichiers communs entre tous les y compris le serveur Web Airflow.

Solution :

  • Encapsulez les fichiers à partager avec le serveur Web dans un module PYPI et l’installer en tant que package PYPI normal. Une fois le module PYPI installé dans l'environnement, les fichiers sont ajoutés aux images des composants Airflow et sont disponibles pour eux.

  • Ajoutez des fichiers au dossier plugins/. Ce dossier est synchronisé avec le serveur Web Airflow.

Temps d'analyse non continue des DAG et diagrammes de taille de sac des DAG dans la surveillance

Temps d'analyse non continue des DAG et diagrammes de taille de sac des DAG sur la surveillance indiquent des problèmes avec des temps d'analyse longs des DAG (plus de 5 minutes).

Graphiques des temps d&#39;analyse des DAG Airflow et de la taille des sacs DAG montrant une série d&#39;intervalles non continus
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 DAG durée d'analyse, suivez les consignes de rédaction du DAG.

Les journaux des tâches s'affichent avec des retards

Ce problème connu s'applique à Cloud Composer 3.

Symptôme :

  • Dans Cloud Composer 3, les journaux des tâches Airflow ne s'affichent pas immédiatement et sont en retard de quelques minutes.

Cause :

Si votre environnement exécute un grand nombre de tâches en même temps, les journaux des tâches peut être retardée, car la taille de l'infrastructure de l'environnement n'est pas suffisante traiter tous les journaux assez rapidement.

Solutions :

  • Envisagez d'augmenter la taille de l'infrastructure de l'environnement pour améliorer les performances.
  • Distribuez les exécutions de DAG au fil du temps afin que les tâches ne soient pas exécutées en même temps.

Étape suivante