Problèmes connus

Managed Airflow (3e génération) | Managed Airflow (2e génération) | Managed Airflow (ancienne 1re génération)

Cette page liste les problèmes connus liés à Managed Airflow. Pour en savoir plus sur les corrections de problèmes, consultez les notes de version.

Certains problèmes affectent les 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.

Managed Airflow dépend de GKE pour assurer la compatibilité avec les adresses non-RFC 1918 pour les pods et les services. Seule la liste suivante de plages non RFC 1918 est compatible avec Managed Airflow :

  • 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

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

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

Impossible de créer des environnements Managed Airflow avec les contraintes de règle d'administration constraints/compute.disableSerialPortLogging appliquées

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

Diagnostic

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

Accédez au menu GKE dans la consoleGoogle 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:
[CONDITION_NOT_MET]: Instance '<generated instance name>' creation failed:
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 Managed Airflow 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.

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

Les versions 2.0.x de Managed Airflow (ancienne 1re génération) et Managed Airflow (2e génération) utilisent Deployment Manager pour créer des composants d'environnements Managed Airflow.

En décembre 2020, vous avez peut-être reçu des informations indiquant que vous deviez effectuer une configuration supplémentaire de VPC Service Controls pour pouvoir utiliser Deployment Manager afin de gérer les ressources protégées par VPC Service Controls.

Nous tenons à préciser qu'aucune action n'est requise de votre part si vous utilisez Managed Airflow et que vous n'utilisez pas Deployment Manager directement pour gérer les ressources Google Cloud 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 Deployment Manager appartenant à Managed Airflow, vous pouvez ignorer cet avertissement.

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

Ce problème concerne les versions 2.0.x de Managed Airflow (ancienne 1re génération) et de Managed Airflow (2e génération).

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 qu'ils ont créées.

    • 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 Managed Airflow.

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 Managed Airflow pour supprimer ces avertissements des journaux Airflow.

Échec de la création de l'environnement dans les projets avec des API Identity-Aware Proxy ajoutées au périmètre VPC Service Controls

Dans les projets pour lesquels VPC Service Controls est activé, le compte cloud-airflow-prod@ 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 ni l'API Identity-Aware Proxy TCP au périmètre de sécurité.

  • Ajoutez le compte de service cloud-airflow-prod@ 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:cloud-airflow-prod@

Échec de la création ou de la mise à niveau de l'environnement Managed Airflow lorsque la règle compute.vmExternalIpAccess est désactivée

Ce problème concerne les environnements Managed Airflow (ancienne 1re génération) et Managed Airflow (2e génération).

Les clusters GKE appartenant à Managed Airflow et configurés en mode 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 Contraintes liées aux règles d'administration.

La première exécution de DAG pour un fichier 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 programmeur obtient le fichier DAG et planifie son exécution par un nœud de calcul, et si le nœud de calcul ne dispose pas encore du fichier DAG, l'exécution de la tâche échoue.

Pour résoudre ce problème, les environnements avec Airflow 2 sont configurés pour effectuer deux nouvelles tentatives pour une tâche ayant échoué par défaut. Si une tâche échoue, elle est relancée deux fois à cinq minutes d'intervalle.

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

Managed Airflow gère les clusters GKE sous-jacents appartenant à Managed Airflow. À 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. Managed Airflow se charge des migrations, si nécessaire.

Managed Airflow 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), Managed Airflow a mené une enquête détaillée et nous pensons que Managed Airflow n'est pas vulnérable à cette faille.

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

Managed Airflow utilise gcsfuse pour accéder au dossier /data dans le bucket de l'environnement et pour enregistrer les journaux des tâches Airflow dans le répertoire /logs (si cette option est activée). Si gcsfuse est surchargé ou si le bucket de l'environnement n'est pas disponible, vous pouvez rencontrer des échecs d'instance de tâche Airflow et voir des erreurs Transport endpoint is not connected dans les journaux Airflow.

Solutions :

Il peut arriver que l'UI Airflow ne recharge pas 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'UI Airflow risque de ne pas reconnaître qu'un plug-in doit être actualisé. Dans ce cas, redémarrez le serveur Web Airflow de votre environnement.

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

Ce problème connu ne s'applique qu'à Managed Airflow (2e génération).

Dans Managed Airflow (Gen 2), après la création d'un environnement, plusieurs charges de travail du cluster de l'environnement restent à l'état "Non programmable".

Lorsqu'un environnement effectue un scaling à la hausse, de nouveaux pods de nœuds de calcul sont créés et Kubernetes tente de les exécuter. Si aucune ressource n'est disponible pour les exécuter, les pods de nœuds de calcul sont marqués comme non programmables.

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 peuvent pas démarrer sur des nœuds où les composants Airflow ne sont pas présents n'affectent pas votre environnement.

Si ce problème persiste pendant une longue période (plus d'une heure), vous pouvez consulter les journaux de l'autoscaler de cluster. Vous pouvez les trouver dans la visionneuse de journaux à l'aide du 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 n'importe quel noDecisionStatus pour voir pourquoi le cluster ne peut pas être mis à l'échelle à la hausse ou à la baisse.

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

Vous pouvez obtenir l'erreur 504 Gateway Timeout lorsque vous accédez à l'UI Airflow. Cette erreur peut avoir plusieurs causes :

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

  • (Managed Airflow (3e génération) uniquement) Problème de connectivité. Si l'UI Airflow est indisponible de manière permanente et que des erreurs de délai d'expiration ou 504 sont générées, assurez-vous que votre environnement peut accéder à *.composer.googleusercontent.com.

  • (Managed Airflow (Gen 2) uniquement) Problème de connectivité. Si l'UI Airflow est indisponible de manière permanente et que des erreurs de délai d'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 privé à Google et envoyez du trafic via des adresses IP virtuelles private.googleapis.com, ou VPC Service Controls et 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 que vous pouvez toujours accéder à l'UI Airflow à certains moments, il est possible que le serveur Web Airflow ne réponde pas, car il est surchargé. Essayez d'augmenter les paramètres d'échelle 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'UI Airflow ne peut pas diffuser les requêtes entrantes. Cette erreur peut avoir plusieurs causes :

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

  • Échec du démarrage du serveur Web. Pour démarrer, le serveur Web nécessite que les fichiers de configuration soient d'abord synchronisés. Recherchez dans les journaux de serveur Web des 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 vous rencontrez ce type d'erreur, 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.

Erreur 500 lors de l'accès à l'interface utilisateur Airflow après le remplacement de [webserver]analytics_tool

Dans les environnements avec Airflow 2, si vous remplacez l'option de configuration Airflow [webserver]analytics_tool pour acheminer les données d'utilisation anonymes de l'UI Airflow vers un service d'analyse (tel que Google Analytics, Segment, MetaRouter ou Matomo), l'accès à l'UI Airflow après la mise à jour de l'environnement peut renvoyer une réponse (500) Internal Server Error, avec l'une des erreurs suivantes dans les journaux du serveur Web Airflow :

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config

Lorsque [webserver]analytics_tool est défini dans Airflow 2, le serveur Web Airflow nécessite que les options d'analyse associées dans la section [webserver] soient également définies lors de l'affichage de l'UI Airflow.

Dans Airflow 3, les options de configuration [webserver]analytics_tool, [webserver]analytics_id et [webserver]analytics_url sont supprimées.

Solutions :

  • Supprimez le remplacement de l'option de configuration Airflow [webserver]analytics_tool.
  • Spécifiez toutes les options de configuration Airflow requises :
    • [webserver]analytics_tool
    • [webserver]analytics_id
    • [webserver]analytics_url (obligatoire dans Airflow 2.9 et versions ultérieures, même si votre outil d'analyse n'utilise pas d'URL personnalisée)

Le pointage sur une instance de tâche dans la vue arborescente génère une erreur TypeError non interceptée

Dans Airflow 2, il arrive que la vue arborescente de l'UI Airflow ne fonctionne pas correctement lorsqu'un fuseau horaire autre que celui par défaut est utilisé. Pour contourner ce problème, configurez explicitement le fuseau horaire dans l'interface utilisateur d'Airflow.

L'UI Airflow dans Airflow 2.2.3 ou versions antérieures est vulnérable à la faille CVE-2021-45229

Comme indiqué dans la section CVE-2021-45229, l'écran "Déclencher un DAG avec une configuration" était susceptible de subir des attaques XSS via l'argument de requête origin.

Recommandation : Passez à la dernière version de Managed Airflow 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

Symptômes :

  • Dans votre environnement Managed Airflow (Gen 2), toutes les charges de travail du cluster de l'environnement des nœuds de calcul Airflow sont à l'état CrashLoopBackOff et n'exécutent pas de tâches. Vous pouvez également voir les avertissements OOMKilling générés si vous êtes concerné 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 des 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.
  • Les besoins en mémoire des nœuds de calcul Airflow dans Airflow 2.6.3 avec Python 3.11 sont 10 % plus élevés que ceux des nœuds de calcul des versions antérieures.
  • Les besoins en mémoire des nœuds de calcul Airflow dans Airflow 2.3 et versions ultérieures sont 30 % plus élevés que ceux des nœuds de calcul dans Airflow 2.2 ou Airflow 2.1.

Solutions :

  • Supprimez le remplacement pour worker_concurrency afin que Managed Airflow calcule automatiquement cette valeur.
  • 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 parvenez pas à mettre à niveau votre environnement vers une version ultérieure en raison de ce problème, appliquez l'une des solutions proposées avant de procéder à la mise à niveau.

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

Le déclenchement de DAG avec des fonctions Cloud Run via des réseaux privés à l'aide d'un connecteur VPC n'est pas compatible avec Managed Airflow.

Recommandation : Utilisez Cloud Run Functions pour publier des messages sur Pub/Sub. Ces événements peuvent actionner des capteurs Pub/Sub pour déclencher des DAG Airflow ou mettre en œuvre une approche basée sur des opérateurs différables.

Dossiers vides dans Scheduler et Workers

Managed Airflow ne supprime pas activement les dossiers vides des nœuds de calcul et des programmeurs 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, à la suite d'opérations de scaling à la baisse ou de maintenance dans le cluster de votre environnement).

Compatibilité avec Kerberos

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

Compatibilité avec les classes de calcul dans Managed Airflow (2e génération) et Managed Airflow (3e génération)

Managed Airflow (Gen 3) et Managed Airflow (Gen 2) ne sont compatibles qu'avec la classe de calcul à usage général. Cela signifie qu'il n'est pas possible d'exécuter des pods qui demandent d'autres classes de calcul (telles que Balanced ou Scale-Out).

La classe à usage général permet d'exécuter des pods demandant jusqu'à 110 Go de mémoire et jusqu'à 30 processeurs (comme décrit dans Nombre maximal de requêtes de classe de calcul).

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 les clusters Managed Airflow (Gen 3) et Managed Airflow (Gen 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 Managed Airflow.

Compatibilité avec les opérateurs Google Campaign Manager 360

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

Si vous utilisez des opérateurs Google Campaign Manager, mettez à niveau votre environnement vers Managed Airflow version 2.1.13 ou ultérieure.

Assistance pour les opérateurs Google Display & Video 360

Les opérateurs Google Display & Video 360 dans les versions de Managed Airflow antérieures à la version 2.1.13 sont basés sur l'API Display & Video 360 v1.1, qui est obsolète et dont la date d'arrêt est fixée au 27 avril 2023.

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

  • 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

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'UI Airflow dans les versions d'Airflow de 2.0.x à 2.5.x est vulnérable à la faille CVE-2023-29247.

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

Dans Managed Airflow, 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'UI Airflow, les pirates informatiques doivent d'abord accéder à votre projet, ainsi qu'aux autorisations et rôles IAM nécessaires.

Solution :

Le DAG de surveillance Airflow de l'environnement Composer Managed Airflow (Gen 2) n'est pas recréé après sa suppression

Le DAG de surveillance Airflow n'est pas recréé automatiquement s'il est supprimé par l'utilisateur ou déplacé du bucket dans les environnements 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. L'approche suggérée consiste à 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 de la même version.

Il n'est pas possible de réduire l'espace de stockage Cloud SQL

Managed Airflow 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 s'agrandit.

Il n'est pas possible de 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 Managed Airflow avec des instantanés.

La métrique d'utilisation du 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 tous deux 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 Managed Airflow indisponible. Par conséquent, il est 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, la boîte de dialogue 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 Managed Airflow n'est pas explicitement autorisée, les utilisateurs ne peuvent pas accéder à l'UI Airflow, sauf s'ils autorisent explicitement l'application.

Pour autoriser l'accès, suivez la procédure décrite dans Autoriser l'accès à l'UI Airflow dans Google Workspace.

Boucle de connexion lors de l'accès à l'UI d'Airflow

Ce problème peut être dû aux causes suivantes :

Tâches ayant réussi par le passé marquées comme ÉCHOUÉES

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

Si cela se produit, c'est généralement parce qu'il a été déclenché par une opération de mise à jour ou de mise à niveau de l'environnement, ou par une maintenance GKE.

Remarque : Le problème lui-même n'indique aucun problème dans l'environnement et ne provoque aucune défaillance réelle lors de l'exécution de la tâche.

Le problème est résolu dans Managed Airflow 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 Managed Airflow

Ce problème ne concerne que les versions 2.10.2 et antérieures de Managed Airflow (Gen 2).

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 programmeur Airflow peut être redémarré, les tâches Airflow peuvent devoir être relancé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 programmeurs, les nœuds de calcul ou le serveur Web Airflow) :

Authentication failed using Compute Engine authentication due to unavailable metadata server

Compute Engine Metadata server unavailable on attempt 1 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 2 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 3 of 3. Reason: timed out

Solution :

  • Mettez à niveau votre environnement vers une version ultérieure de Managed Airflow. Ce problème est résolu à partir de la version 2.11.0 de Managed Airflow.

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

Dans Managed Airflow (Gen 2) et Managed Airflow (Gen 3), le serveur Web Airflow est censé être un composant en lecture seule, et Managed Airflow ne synchronise pas le dossier data/ avec ce composant.

Il peut arriver que vous souhaitiez partager des fichiers communs entre tous les composants Airflow, y compris le serveur Web Airflow.

Solution :

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

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

Diagrammes non continus des temps d'analyse des DAG et de la taille des sacs de DAG dans la surveillance

Les diagrammes de temps d'analyse des DAG et de taille du sac de DAG non continus sur le tableau de bord de surveillance indiquent des problèmes de temps d'analyse des DAG longs (plus de cinq minutes).

Graphiques des temps d'analyse des DAG Airflow et de la taille du sac de DAG montrant une série d'intervalles non continus
Figure 1. Graphiques non continus des temps d'analyse des DAG et de la taille de sac du DAG (cliquez pour agrandir)

Solution : Nous vous recommandons de maintenir le temps d'analyse total du DAG en dessous de cinq minutes. Pour réduire le temps d'analyse des DAG, suivez les consignes d'écriture des DAG.

Les journaux des composants Managed Airflow sont manquants dans Cloud Logging

Un problème est survenu dans le composant de l'environnement chargé d'importer les journaux des composants Airflow dans Cloud Logging. Ce bug entraîne parfois l'absence de journal au niveau de Managed Airflow pour un composant Airflow. Le même journal est toujours disponible au niveau du composant Kubernetes.

Fréquence du problème : très rare, sporadique

Cause :

Comportement incorrect du composant Managed Airflow chargé d'importer les journaux dans Cloud Logging.

Solutions :

  • Mettez à niveau votre environnement vers Managed Airflow version 2.10.0 ou ultérieure.

  • Dans les versions antérieures de Managed Airflow, la solution temporaire lorsque vous rencontrez cette situation consiste à lancer une opération Managed Airflow qui redémarre les composants pour lesquels le journal est manquant.

Le passage du cluster de l'environnement à GKE Enterprise Edition n'est pas possible

Cette remarque s'applique à Managed Airflow 1 et Managed Airflow 2.

Le cluster GKE de l'environnement Managed Airflow est créé dans GKE Standard Edition.

Depuis décembre 2024, le service Managed Airflow ne permet pas de créer des environnements Managed Airflow avec des clusters dans l'édition Enterprise.

Les environnements Managed Airflow n'ont pas été testés avec GKE Enterprise et ont un modèle de facturation différent.

Nous vous communiquerons plus d'informations sur les éditions GKE Standard et Enterprise au deuxième trimestre 2025.

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

Dans certains cas, en raison d'un échec de résolution DNS, les composants Airflow peuvent rencontrer des problèmes lors de la communication avec d'autres composants Managed Airflow ou des points de terminaison de service en dehors de l'environnement Managed Airflow.

Symptômes :

Les erreurs suivantes peuvent apparaître dans les journaux des composants Airflow (tels que les planificateurs, les nœuds de calcul ou le serveur Web Airflow) :

google.api_core.exceptions.ServiceUnavailable: 503 DNS resolution failed ...
... Timeout while contacting DNS servers

ou

Could not access *.googleapis.com: HTTPSConnectionPool(host='www.googleapis.com', port=443): Max retries exceeded with url: / (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7c5ef5adba90>: Failed to resolve 'www.googleapis.com' ([Errno -3] Temporary failure in name resolution)"))

ou

redis.exceptions.ConnectionError: Error -3 connecting to
airflow-redis-service.composer-system.svc.cluster.local:6379.
Temporary failure in name resolution.

Solutions possibles :

  • Passez à Managed Airflow 2.9.11 ou

  • Définissez la variable d'environnement suivante : GCE_METADATA_HOST=169.254.169.254.

L'environnement est à l'état 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 Managed Airflow 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é ultérieurement.
  • Après la désactivation de l'API Cloud Composer dans le projet, même si elle a été activée ultérieurement.

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 les environnements eux-mêmes ne sont plus utilisables. Vous pouvez créer un environnement Managed Airflow, 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é de l'environnement. De cette façon, vous pouvez créer un autre environnement et transférer ses données en chargeant cet instantané.

Avertissements concernant le budget d'interruption de pods pour les clusters d'environnement

Les avertissements suivants peuvent s'afficher dans l'interface utilisateur de GKE pour les clusters d'environnement 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.

Il n'est pas possible de les éliminer. Nous nous efforçons d'empêcher la génération de ces avertissements.

Solutions possibles :

  • Ignorez ces avertissements jusqu'à ce que le problème soit résolu.

Impossible de supprimer une valeur de champ dans une connexion Airflow

Cause :

L'interface utilisateur d'Apache Airflow présente une limite : il n'est pas possible de mettre à jour les champs de connexion avec des valeurs vides. Si vous essayez de le faire, le système rétablit les paramètres précédemment enregistrés.

Solutions possibles :

Bien qu'Apache Airflow version 2.10.4 inclue un correctif permanent, une solution de contournement temporaire existe pour les utilisateurs de versions antérieures. Pour ce faire, supprimez la connexion, puis recréez-la en laissant les champs obligatoires vides. L'interface de ligne de commande est l'approche recommandée pour supprimer la connexion :

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

Après avoir supprimé la connexion, recréez-la à l'aide de l'interface utilisateur d'Airflow, en vous assurant que les champs que vous souhaitez laisser vides sont bien vides. Vous pouvez également créer la connexion en exécutant la commande connections add de la CLI Airflow avec la Google Cloud CLI.

Les journaux des tâches Airflow ne sont pas collectés si [core]execute_tasks_new_python_interpreter est défini sur "True"

Managed Airflow ne collecte pas les journaux des tâches Airflow si l'option de configuration Airflow [core]execute_tasks_new_python_interpreter est définie sur True.

Solution possible :

  • Supprimez le remplacement de cette option de configuration ou définissez sa valeur sur False.

Points de données manquants dans les métriques, ValueError: Cannot determine path without bucket name

Les environnements utilisant les versions 2.16.0 et 2.16.1 de Managed Airflow (Gen 2) peuvent rencontrer un problème connu concernant la création de rapports sur les métriques. Vous pouvez observer quelques points de données ignorés dans les métriques signalées et voir des messages d'erreur concernant les redémarrages du pod airflow-monitoring dans les journaux d'environnement.

Exemple de message d'erreur : ValueError: Cannot determine path without bucket name error.

Ce problème n'affecte pas le fonctionnement de l'environnement. L'environnement est toujours opérationnel, et les informations sur l'état et la surveillance de l'environnement sont correctement signalées. Vous pouvez ignorer les messages d'erreur.

Performances dégradées de l'environnement dans plusieurs versions du package google-api-core

Versions de 2.28.0 à 2.30.2

Les versions de package google-api-core préinstallées de 2.28.0 à 2.30.2 peuvent entraîner une dégradation des performances de l'environnement, ce qui peut allonger le temps d'exécution d'une tâche et le temps nécessaire pour faire passer une tâche de l'état "en file d'attente" à l'état "en cours d'exécution".

Builds Managed Airflow (Gen 3) concernés :

  • composer-3-airflow-3.1.7-build.0 à composer-3-airflow-3.1.7-build.5
  • composer-3-airflow-3.1.0-build.5 à composer-3-airflow-3.1.0-build.10
  • composer-3-airflow-2.11.1-build.0
  • composer-3-airflow-2.10.5-build.22 vers composer-3-airflow-2.10.5-build.33
  • composer-3-airflow-2.9.3-build.42 vers composer-3-airflow-2.9.3-build.53

Builds Managed Airflow (Gen 2) concernés :

  • composer-2.16.10-airflow-2.11.1
  • composer-2.16.0-airflow-2.10.5 vers composer-2.16.10-airflow-2.10.5
  • composer-2.16.0-airflow-2.9.3 vers composer-2.16.10-airflow-2.9.3

Mettez à niveau votre environnement vers l'un des builds suivants, qui incluent la version 2.27.0 de google-api-core préinstallée et ne sont pas concernés par ce problème :

  • composer-3-airflow-2.11.1-build.1
  • composer-3-airflow-2.10.5-build.34
  • composer-3-airflow-2.9.3-build.54
  • composer-2.16.11-airflow-2.11.1
  • composer-2.16.11-airflow-2.10.5
  • composer-2.16.11-airflow-2.9.3

Vous pouvez également passer à une image incluant google-api-core 2.43.1 ou une version ultérieure, ou installer manuellement une version compatible.

Sur Python 3.11, les versions 2.30.3 à 2.43.0 de google-api-core entraînent un problème de performances distinct à partir du 24 octobre 2026. Si votre environnement exécute Python 3.11, appliquez l'une des solutions listées dans Versions 2.30.3 à 2.43.0 sur Python 3.11.

Versions de 2.30.3 à 2.43.0 sur Python 3.11

À partir du 24 octobre 2026, les versions 2.30.3 à 2.43.0 du package google-api-core exécuteront une vérification d'obsolescence de Python 3.11 qui analysera les métadonnées des packages installés chaque fois qu'une bibliothèque cliente Google Cloud sera importée dans un nouveau sous-processus Python.

Dans les environnements Managed Airflow qui exécutent Python 3.11, ce comportement peut dégrader les performances. Ce problème est plus grave dans les environnements comportant de nombreux DAG, des tâches fréquentes de courte durée ou l'intégration de la traçabilité des données activée.

Les symptômes sont les suivants :

  • Augmentation des temps d'analyse des DAG et de l'utilisation du processeur sur les processeurs de DAG Airflow.
  • Temps d'exécution des tâches plus longs et utilisation plus élevée du processeur sur les nœuds de calcul Airflow.
  • Entrées de journal FutureWarning fréquentes de google/api_core/_python_version_support.py indiquant que la compatibilité avec Python 3.11 prendra fin le 24 octobre 2027.

Ce problème affecte tous les environnements Python 3.11 dans lesquels la version 2.30.3 à 2.43.0 de google-api-core est préinstallée ou installée manuellement, y compris les builds suivants.

Ce problème affecte les builds Managed Airflow (3e génération) suivants :

  • composer-3-airflow-3.3.1-build.0 à composer-3-airflow-3.3.1-build.5
  • composer-3-airflow-3.2.2-build.0 à composer-3-airflow-3.2.2-build.9
  • composer-3-airflow-3.1.8-build.0 à composer-3-airflow-3.1.8-build.4
  • composer-3-airflow-3.1.7-build.7 à composer-3-airflow-3.1.7-build.13
  • composer-3-airflow-2.11.1-build.3 à composer-3-airflow-2.11.1-build.22
  • composer-3-airflow-2.10.5-build.36 à composer-3-airflow-2.10.5-build.52

Builds Managed Airflow (Gen 2) concernés :

  • composer-2.17.0-airflow-2.11.1 à composer-2.17.16-airflow-2.11.1
  • composer-2.17.0-airflow-2.10.5 à composer-2.17.13-airflow-2.10.5

Solutions :

Choisissez l'une des options suivantes en fonction de la version d'image de votre environnement :

  • Option 1. Builds Managed Airflow (Gen 3) compatibles avec Airflow 3 uniquement : installez le package PyPI google-api-core avec la contrainte de version >=2.43.1.

    Builds Managed Airflow (3e génération) compatibles :

    • composer-3-airflow-3.3.1-build.0 à composer-3-airflow-3.3.1-build.5
    • composer-3-airflow-3.2.2-build.1 à composer-3-airflow-3.2.2-build.9
    • composer-3-airflow-3.1.8-build.3 vers composer-3-airflow-3.1.8-build.4

    N'utilisez pas cette option sur les builds Airflow 2 ou les builds Airflow 3 antérieurs, y compris composer-3-airflow-3.2.2-build.0 et composer-3-airflow-3.1.8-build.0 à build.2. Dans ces builds, google-api-core 2.43.1 entraîne des conflits de dépendances, car il nécessite opentelemetry-api>=1.44.0. Pour ces builds, utilisez l'option 2.

  • Option 2. Tous les builds Managed Airflow (3e génération) et Managed Airflow (2e génération) concernés : appliquez un correctif d'exécution sitecustomize.py.

    1. Téléchargez sitecustomize.py depuis GitHub.

    2. Importez sitecustomize.py dans le dossier dags/patches du bucket de votre environnement.

    3. Définissez la variable d'environnement PYTHONPATH sur /home/airflow/gcs/dags/patches.

      Si PYTHONPATH est déjà défini, ajoutez /home/airflow/gcs/dags/patches: à la valeur existante. Exemple : /home/airflow/gcs/dags/patches:PREVIOUS_PYTHONPATH_VALUE

    Nettoyage après une mise à niveau : dans les prochaines versions de Managed Airflow, le package google-api-core version 2.43.1 ou ultérieure sera préinstallé. Après avoir effectué la mise à niveau vers une image avec google-api-core 2.43.1 ou version ultérieure, vous pouvez supprimer le remplacement PYTHONPATH et supprimer dags/patches/sitecustomize.py.

Étapes suivantes