El 15 de septiembre de 2026, todos los entornos de Cloud Composer 1 y Cloud Composer 2 versión 2.0.x alcanzarán el final de su ciclo de vida previsto, y no podrás usarlos. Te recomendamos que planifiques la migración a Cloud Composer 3.
En esta página, se describe cómo solucionar problemas con las tareas que ejecuta KubernetesExecutor y se proporcionan soluciones para problemas habituales.
Enfoque general para solucionar problemas de KubernetesExecutor
Para solucionar problemas con una tarea ejecutada con KubernetesExecutor, realiza
las siguientes acciones en el orden indicado:
En la lista de entornos, haz clic en el nombre de tu entorno.
Se abrirá la página Detalles del entorno.
Ve a la pestaña Registros y revisa la sección Registros de Airflow>Programador.
Para un período determinado, inspecciona el pod de trabajador KubernetesExecutor que ejecutaba la tarea. Si el pod ya no existe, omite este paso. El pod tiene el prefijo airflow-k8s-worker y un DAG o un nombre de tarea en su nombre.
Busca cualquier problema informado, como una tarea que falló o que no se puede programar.
Situaciones comunes de solución de problemas de KubernetesExecutor
En esta sección, se enumeran las situaciones comunes de solución de problemas que puedes encontrar con KubernetesExecutor.
La tarea llega al estado Running y, luego, falla durante la ejecución.
Síntomas:
Hay registros de la tarea en la IU de Airflow y en la pestaña Logs de la sección Workers.
Solución: Los registros de tareas indican el problema.
La instancia de la tarea llega al estado queued y, luego, se marca como UP_FOR_RETRY o FAILED después de un tiempo.
Síntomas:
No hay registros de tareas en la IU de Airflow ni en la pestaña Logs de la sección Workers.
Hay registros en la pestaña Registros de la sección Programador con un mensaje que indica que la tarea está marcada como UP_FOR_RETRY o FAILED.
Solución:
Inspecciona los registros del programador para ver si hay detalles del problema.
Causas posibles:
Si los registros del programador contienen el mensaje Adopted tasks were still pending after... seguido de la instancia de tarea impresa, verifica que CeleryKubernetesExecutor esté habilitado en tu entorno.
La instancia de la tarea llega al estado Queued y se marca de inmediato como UP_FOR_RETRY o FAILED.
Síntomas:
No hay registros de la tarea en la IU de Airflow ni en la pestaña Logs de la sección Workers.
Los registros del programador en la pestaña Registros de la sección Programador tienen el mensaje Pod creation failed with reason ... Failing task y el mensaje de que la tarea está marcada como UP_FOR_RETRY o FAILED.
Solución:
Verifica los registros del programador para obtener la respuesta exacta y el motivo de la falla.
Posible motivo:
Si el mensaje de error es quantities must match the regular expression ..., es probable que el problema se deba a valores personalizados establecidos para los recursos de k8s (solicitudes o límites) de los pods de trabajadores de tareas.
Las tareas de KubernetesExecutor fallan sin registros cuando se ejecuta una gran cantidad de tareas.
Cuando tu entorno ejecuta una gran cantidad de tareas con KubernetesExecutor o KubernetesPodOperator al mismo tiempo, Cloud Composer 3 no acepta tareas nuevas hasta que se terminan algunas de las tareas existentes. Las tareas adicionales se marcan como fallidas, y Airflow las vuelve a intentar más adelante, si defines reintentos para las tareas (Airflow lo hace de forma predeterminada).
Síntoma: Las tareas que se ejecutan con KubernetesExecutor o KubernetesPodOperator fallan sin registros de tareas en la IU de Airflow o en la IU de DAG. En los registros del programador, puedes ver mensajes de error similares a los siguientes:
Ajusta el programa de ejecución de DAG para que las tareas se distribuyan de manera más uniforme con el tiempo.
Consolida las tareas pequeñas para reducir la cantidad de tareas.
Solución alternativa:
Si prefieres que las tareas permanezcan en el estado programado hasta que tu entorno pueda ejecutarlas, puedes definir un grupo de Airflow con la cantidad limitada de ranuras en la IU de Airflow y, luego, asociar todas las tareas basadas en contenedores con este grupo. Recomendamos establecer la cantidad de ranuras en el grupo en 50 o menos. Las tareas adicionales permanecerán en el estado programado hasta que el grupo de Airflow tenga un espacio libre para ejecutarlas. Si usas esta solución alternativa
sin aplicar posibles soluciones, es posible que experimentes una gran cola de tareas
en el grupo de Airflow.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)"]]
