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

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.

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.

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

Dans les projets où VPC Service Controls est activé, le compte cloud-airflow-prod@system.gserviceaccount.com 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 cloud-airflow-prod@system.gserviceaccount.com 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@system.gserviceaccount.com

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

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 :

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.

Le cluster de l'environnement comporte des charges de travail dans l'état "Non planifiable"

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

Dans Cloud Composer 2, après la création d'un environnement, plusieurs charges de travail du cluster de l'environnement restent dans l'état "Non planifiable".

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 ce n'est pas fait, les pods restent à l'état "Non programmable" et n'exécutent aucune tâche.

Les charges de travail DaemonSet non planifiables 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 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 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.

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, configurez explicitement le fuseau horaire dans l'interface utilisateur d'Airflow.

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.

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

Symptômes:

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

  • 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.
  • Les exigences de mémoire des nœuds de calcul Airflow dans Airflow 2.6.3 avec Python 3.11 sont 10 % plus élevées par rapport aux nœuds de calcul des versions précédentes.
  • Les exigences de mémoire des nœuds de calcul Airflow dans Airflow 2.3 et les versions ultérieures sont 30 % plus élevées que celles des nœuds de calcul dans Airflow 2.2 ou Airflow 2.1.

Solutions :

  • Supprimez le forçage pour worker_concurrency afin que Cloud Composer 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 pouvez pas mettre à niveau votre environnement vers une version ultérieure en raison de ce problème, appliquez l'une des solutions proposées avant la mise à niveau.

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 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 de votre environnement).

Compatibilité avec Kerberos

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

Prise en charge des classes de calcul dans Cloud Composer 2 et Cloud Composer 3

Cloud Composer 3 et Cloud Composer 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 Équilibré ou Évolutif).

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 la section Demandes maximales de la 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 classe de calcul différente, qui n'est pas compatible avec les clusters Cloud Composer 3 et 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.

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

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.

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.

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 avec composer-2.1.4-airflow-2.4.3.

Solution :

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

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

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 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'UI Airflow dans Google Workspace.

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

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

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.

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

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

Vous pouvez parfois souhaiter 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 eux.

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

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

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

Les journaux des composants Cloud Composer 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 une situation où le journal au niveau de Cloud Composer peut être manquant 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 Cloud Composer chargé d'importer les journaux dans Cloud Logging.

Solutions :

  • Mettez à niveau votre environnement vers la version 2.10.0 ou ultérieure de Cloud Composer.

  • Dans les versions antérieures de Cloud Composer, la solution temporaire consiste à lancer une opération Cloud Composer qui redémarre les composants pour lesquels le journal est manquant.

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.

D'autres informations sur l'édition GKE Standard par rapport à l'édition Enterprise seront communiquées au cours du deuxième trimestre 2025.

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

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

Symptômes :

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

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:

  • Mettre à niveau vers Cloud Composer 2.9.11 ou

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

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 n'est pas possible 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