Le 15 septembre 2026, tous les environnements Cloud Composer 1 et Cloud Composer 2 version 2.0.x atteindront leur fin de vie prévue et vous ne pourrez plus les utiliser. Nous vous recommandons de planifier la migration vers Cloud Composer 3.
Dans la liste des environnements, cliquez sur le nom de votre environnement.
La page Détails de l'environnement s'ouvre.
Accédez à l'onglet Journaux, puis vérifiez la section Journaux Airflow>Planificateur.
Pour une période donnée, inspectez le pod de worker KubernetesExecutor qui exécutait la tâche. Si le pod n'existe plus, ignorez cette étape. Le pod comporte le préfixe airflow-k8s-worker et un nom de DAG ou de tâche.
Recherchez d'éventuels problèmes signalés, tels qu'une tâche ayant échoué ou une tâche non planifiable.
Scénarios de dépannage courants pour KubernetesExecutor
Cette section répertorie les scénarios de dépannage courants que vous pouvez rencontrer avec KubernetesExecutor.
La tâche passe à l'état Running, puis échoue lors de l'exécution.
Symptômes :
Des journaux sont disponibles pour la tâche dans l'UI d'Airflow et dans l'onglet Logs (Journaux) de la section Workers (Nœuds de calcul).
Solution: Les journaux des tâches indiquent le problème.
L'instance de tâche passe à l'état queued, puis est marquée comme UP_FOR_RETRY ou FAILED au bout d'un certain temps.
Symptômes :
Aucun journal de tâche n'est disponible dans l'UI d'Airflow ni dans l'onglet Logs (Journaux) de la section Workers (Nœuds de calcul).
Des journaux sont disponibles dans l'onglet Journaux de la section Planificateur, avec un message indiquant que la tâche est marquée comme UP_FOR_RETRY ou FAILED.
Solution :
Examinez les journaux du planificateur pour obtenir des informations sur le problème.
Causes possibles :
Si les journaux du planificateur contiennent le message Adopted tasks were still pending after... suivi de l'instance de tâche imprimée, vérifiez que CeleryKubernetesExecutor est activé dans votre environnement.
L'instance de tâche atteint l'état Queued et est immédiatement marquée comme UP_FOR_RETRY ou FAILED.
Symptômes :
Aucun journal de la tâche n'est disponible dans l'interface utilisateur d'Airflow ni dans l'onglet Journals de la section Nœuds de calcul.
Les journaux du planificateur dans l'onglet Journaux de la section Planificateur contiennent le message Pod creation failed with reason ... Failing task et le message indiquant que la tâche est marquée comme UP_FOR_RETRY ou FAILED.
Solution :
Consultez les journaux du planificateur pour obtenir la réponse exacte et la raison de l'échec.
Cause possible:
Si le message d'erreur est quantities must match the regular expression ..., le problème est très probablement dû à des valeurs personnalisées définies pour les ressources k8s (requêtes/limites) des pods de nœuds de travail de tâche.
Les tâches KubernetesExecutor échouent sans journaux lorsqu'un grand nombre de tâches sont exécutées
Lorsque votre environnement exécute un grand nombre de tâches avec KubernetesExecutor ou KubernetesPodOperator en même temps, Cloud Composer 3 n'accepte pas de nouvelles tâches tant que certaines des tâches existantes ne sont pas terminées. Les tâches supplémentaires sont marquées comme ayant échoué, et Airflow les réessaie plus tard, si vous définissez des tentatives pour les tâches (Airflow le fait par défaut).
Symptôme:les tâches exécutées avec KubernetesExecutor ou KubernetesPodOperator échouent sans journaux de tâches dans l'interface utilisateur d'Airflow ou de DAG. Dans les journaux de l'ordonnanceur, vous pouvez voir des messages d'erreur semblables à ceux-ci:
Ajustez la planification d'exécution du DAG afin que les tâches soient réparties de manière plus uniforme au fil du temps.
Réduisez le nombre de tâches en regroupant les petites tâches.
Solution :
Si vous préférez que les tâches restent à l'état planifié jusqu'à ce que votre environnement puisse les exécuter, vous pouvez définir un pool Airflow avec un nombre limité d'emplacements dans l'interface utilisateur Airflow, puis associer toutes les tâches basées sur des conteneurs à ce pool. Nous vous recommandons de définir le nombre d'emplacements du pool sur 50 ou moins. Les tâches supplémentaires resteront à l'état planifié jusqu'à ce que le pool Airflow dispose d'un espace libre pour les exécuter. Si vous utilisez cette solution de contournement sans appliquer les solutions possibles, vous pouvez toujours rencontrer une longue file d'attente de tâches dans le pool Airflow.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/29 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/08/29 (UTC)."],[[["\u003cp\u003eThis page provides troubleshooting guidance for tasks run by KubernetesExecutor in Cloud Composer 3, outlining a step-by-step approach to identify and resolve issues.\u003c/p\u003e\n"],["\u003cp\u003eA common issue addressed is when tasks get stuck in the \u003ccode\u003equeued\u003c/code\u003e state and are then marked as \u003ccode\u003eUP_FOR_RETRY\u003c/code\u003e or \u003ccode\u003eFAILED\u003c/code\u003e, often with no logs, and the solution involves inspecting scheduler logs.\u003c/p\u003e\n"],["\u003cp\u003eAnother issue covered is when tasks fail immediately after entering the \u003ccode\u003eQueued\u003c/code\u003e state, in which case checking scheduler logs for error messages is key to discovering the solution.\u003c/p\u003e\n"],["\u003cp\u003eThe document covers issues that might occur when a large amount of tasks are executed concurrently, leading to tasks failing without logs, with solutions such as adjusting DAG schedules and using Airflow pools.\u003c/p\u003e\n"],["\u003cp\u003eThe page indicates that when tasks get to the running state, and then fail, the solution is found in the task logs, either in the Airflow UI, or in the "Workers" section of the logs tab.\u003c/p\u003e\n"]]],[],null,["\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\n**Cloud Composer 3** \\| Cloud Composer 2 \\| Cloud Composer 1\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nThis page describes how to troubleshoot issues with\n[tasks run by KubernetesExecutor](/composer/docs/composer-3/use-celery-kubernetes-executor) and provides solutions for common\nissues.\n\nGeneral approach to troubleshooting KubernetesExecutor\n\nTo troubleshoot issues with a task executed with KubernetesExecutor, do\nthe following actions in the listed order:\n\n1. Check logs of the task in the [DAG UI](/composer/docs/composer-3/view-dags#runs-history) or\n [Airflow UI](/composer/docs/composer-3/access-airflow-web-interface).\n\n2. Check scheduler logs in Google Cloud console:\n\n 1. In Google Cloud console, go to the **Environments** page.\n\n [Go to Environments](https://console.cloud.google.com/composer/environments)\n 2. In the list of environments, click the name of your environment.\n The **Environment details** page opens.\n\n 3. Go to the **Logs** tab and check the **Airflow logs** \\\u003e\n **Scheduler** section.\n\n 4. For a given time range, inspect the KubernetesExecutor worker pod that was\n running the task. If the pod no longer exists, skip this step. The pod\n has the `airflow-k8s-worker` prefix and a DAG or a task name in its name.\n Look for any reported issues such as a failed task or the task being\n unschedulable.\n\nCommon troubleshooting scenarios for KubernetesExecutor\n\nThis section lists common troublehooting scenarions that you might encounter with KubernetesExecutor.\n\nThe task gets to the `Running` state, then fails during the execution.\n\nSymptoms:\n\n- There are logs for the task in Airflow UI and on the **Logs** tab in the **Workers** section.\n\nSolution: The task logs indicate the problem.\n\nTask instance gets to the `queued` state, then it is marked as `UP_FOR_RETRY` or `FAILED` after some time.\n\nSymptoms:\n\n- There are no logs for task in Airflow UI and on the **Logs** tab in the **Workers** section.\n- There are logs on the **Logs** tab in the **Scheduler** section with a message that the task is marked as `UP_FOR_RETRY` or `FAILED`.\n\nSolution:\n\n- Inspect scheduler logs for any details of the issue.\n\nPossible causes:\n\n- If the scheduler logs contain the `Adopted tasks were still pending after...` message followed by the printed task instance, check that CeleryKubernetesExecutor is enabled in your environment.\n\nThe task instance gets to the `Queued` state and is immediately marked as `UP_FOR_RETRY` or `FAILED`\n\nSymptoms:\n\n- There are no logs for the task in Airflow UI and on the **Logs** tab in the **Workers** section.\n- The scheduler logs on the **Logs** tab in the **Scheduler** section has the `Pod creation failed with reason ... Failing task` message, and the message that the task is marked as `UP_FOR_RETRY` or `FAILED`.\n\nSolution:\n\n- Check scheduler logs for the exact response and failure reason.\n\nPossible reason:\n\nIf the error message is `quantities must match the regular expression ...`,\nthen the issue is most-likely caused by a custom values set for k8s\nresources (requests/limits) of task worker pods.\n\nKubernetesExecutor tasks fail without logs when a large number of tasks is executed\n\nWhen your environment executes a large number of tasks\n[with KubernetesExecutor](/composer/docs/composer-3/use-celery-kubernetes-executor) or [KubernetesPodOperator](/composer/docs/composer-3/use-kubernetes-pod-operator) at the same\ntime, Cloud Composer 3 doesn't accept new tasks until some of the\nexisting tasks are finished. Extra tasks are marked as failed, and Airflow\nretries them later, if you define retries for the tasks (Airflow does this by\ndefault).\n\n**Symptom:** Tasks executed with KubernetesExecutor or KubernetesPodOperator\nfail without task logs in Airflow UI or DAG UI. In the\n[scheduler's logs](/composer/docs/composer-3/view-logs#streaming), you can see error messages similar\nto the following: \n\n pods \\\"airflow-k8s-worker-*\\\" is forbidden: exceeded quota: k8s-resources-quota,\n requested: pods=1, used: pods=*, limited: pods=*\",\"reason\":\"Forbidden\"\n\n**Possible solutions:**\n\n- Adjust the DAG run schedule so that tasks are distributed more evenly over time.\n- Reduce the number of tasks by consolidating small tasks.\n\n**Workaround:**\n\nIf you prefer tasks to stay in the scheduled state until your environment can\nexecute them, you can define an [Airflow pool](https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/pools.html) with the\nlimited number of slots in the Airflow UI and then associate all\ncontainer-based tasks with this pool. We recommend to set the number of slots\nin the pool to 50 or less. Extra tasks will stay in the scheduled state until\nthe Airflow pool has a free slot to execute them. If you use this workaround\nwithout applying possible solutions, you can still experience a large queue of\ntasks in the Airflow pool.\n\nWhat's next\n\n- [Use CeleryKubernetesExecutor](/composer/docs/composer-3/use-celery-kubernetes-executor)\n- [Use KubernetesPodOperator](/composer/docs/composer-3/use-kubernetes-pod-operator)\n- [Troubleshooting scheduling](/composer/docs/composer-3/troubleshooting-scheduling)\n- [Troubleshooting DAGs](/composer/docs/composer-3/troubleshooting-dags)"]]
