A 15 de setembro de 2026, todos os ambientes do Cloud Composer 1 e do Cloud Composer 2 versão 2.0.x vão atingir o fim da vida útil planeado e não vai poder usá-los. Recomendamos que planeie a migração para o Cloud Composer 3.
Na lista de ambientes, clique no nome do seu ambiente.
É apresentada a página Detalhes do ambiente.
Aceda ao separador Registos e verifique os Registos do Airflow>
secção Agendador.
Para um determinado intervalo de tempo, inspecione o pod de trabalho do KubernetesExecutor que estava a executar a tarefa. Se o pod já não existir, ignore este passo. O pod tem o prefixo airflow-k8s-worker e um DAG ou um nome de tarefa no respetivo nome.
Procure problemas comunicados, como uma tarefa com falha ou uma tarefa que não pode ser agendada.
Cenários comuns de resolução de problemas para o KubernetesExecutor
Esta secção apresenta cenários de resolução de problemas comuns que pode encontrar com o KubernetesExecutor.
A tarefa atinge o estado Running e, em seguida, falha durante a execução.
Sintomas:
Existem registos da tarefa na IU do Airflow e no separador Registos na secção Trabalhadores.
Solução: os registos de tarefas indicam o problema.
A instância da tarefa atinge o estado queued e, em seguida, é marcada como UP_FOR_RETRY ou FAILED após algum tempo.
Sintomas:
Não existem registos para a tarefa na IU do Airflow e no separador Registos na secção Trabalhadores.
Existem registos no separador Registos na secção Agendador com uma mensagem a indicar que a tarefa está marcada como UP_FOR_RETRY ou FAILED.
Solução:
Inspeccione os registos do programador para ver detalhes do problema.
Causas possíveis:
Se os registos do agendador contiverem a mensagem Adopted tasks were still pending after... seguida da instância da tarefa impressa, verifique se o CeleryKubernetesExecutor está ativado no seu ambiente.
A instância da tarefa atinge o estado Queued e é imediatamente marcada como UP_FOR_RETRY ou FAILED
Sintomas:
Não existem registos para a tarefa na IU do Airflow e no separador Registos na secção Trabalhadores.
O programador inicia sessão no separador Registos na secção Programador com a mensagem Pod creation failed with reason ... Failing task e a mensagem de que a tarefa está marcada como UP_FOR_RETRY ou FAILED.
Solução:
Verifique os registos do programador para ver a resposta exata e o motivo da falha.
Motivo possível:
Se a mensagem de erro for quantities must match the regular expression ...,
o problema é provavelmente causado por valores personalizados definidos para recursos k8s (pedidos/limites) de pods de trabalhadores de tarefas.
As tarefas do KubernetesExecutor falham sem registos quando é executado um grande número de tarefas
Quando o seu ambiente executa um grande número de tarefas
com KubernetesExecutor ou KubernetesPodOperator ao mesmo
tempo, o Cloud Composer 3 não aceita novas tarefas até que algumas das
tarefas existentes estejam concluídas. As tarefas adicionais são marcadas como falhadas e o Airflow repete-as mais tarde, se definir repetições para as tarefas (o Airflow faz isto por predefinição).
Sintoma: as tarefas executadas com KubernetesExecutor ou KubernetesPodOperator falham sem registos de tarefas na IU do Airflow ou na IU do DAG. Nos registos do agendador, pode ver mensagens de erro semelhantes às seguintes:
Ajuste a programação de execução do DAG para que as tarefas sejam distribuídas de forma mais uniforme ao longo do tempo.
Reduza o número de tarefas consolidando tarefas pequenas.
Solução alternativa:
Se preferir que as tarefas permaneçam no estado agendado até que o seu ambiente as possa executar, pode definir um conjunto do Airflow com o número limitado de vagas na IU do Airflow e, em seguida, associar todas as tarefas baseadas em contentores a este conjunto. Recomendamos que defina o número de vagas no conjunto como 50 ou menos. As tarefas adicionais permanecem no estado agendado até que o conjunto do Airflow tenha uma vaga livre para as executar. Se usar esta solução alternativa sem aplicar possíveis soluções, ainda pode ter uma grande fila de tarefas no conjunto do Airflow.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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,["# Troubleshooting KubernetesExecutor tasks\n\n\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------------------------------------------------------\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-------------------------------------------------------\n\nThis section lists common troublehooting scenarions that you might encounter with KubernetesExecutor.\n\n### The 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\n### Task 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\n### The 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\n### KubernetesExecutor 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\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)"]]
