Problemas conhecidos

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Nesta página, você encontra uma lista de problemas conhecidos do Cloud Composer. Para informações sobre correções de problemas, consulte as notas da versão.

Alguns problemas afetam versões anteriores e podem ser corrigidos com o upgrade do seu ambiente.

Os intervalos de endereços não RFC 1918 são parcialmente compatíveis com pods e serviços

O Cloud Composer depende do GKE para oferecer suporte a endereços não RFC 1918 para pods e serviços. Apenas a seguinte lista de intervalos não RFC 1918 é compatível com o 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

Os rótulos de ambiente adicionados durante uma atualização não são totalmente propagados.

Quando você atualiza os rótulos do ambiente, eles não são aplicados às VMs do Compute Engine no cluster do ambiente. Como solução alternativa, você pode aplicar os rótulos manualmente.

Não é possível criar ambientes do Cloud Composer com a política da organização constraints/compute.disableSerialPortLogging aplicadas.

A criação do ambiente do Cloud Composer falhará se a política da organização constraints/compute.disableSerialPortLogging for aplicada ao projeto de destino.

Observação: esse problema só ocorre nos clusters criados antes da versão de 9 de novembro do Cloud Composer. Os ambientes do Cloud Composer criados após 9 de novembro de 2020 têm todos os nós do cluster do GKE criados com serial-logging-enable=false, o que impede a ocorrência desse problema.

Diagnóstico

Para determinar se você foi afetado por esse problema, siga este procedimento:

Acesse o menu do GKE no Google Cloud console. Acesse o menu do GKE

Em seguida, selecione o cluster recém-criado. Verifique o seguinte erro:

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

Alternativas:

1. Desative a política da organização no projeto em que o ambiente do Cloud Composer será criado.

   Uma política da organização sempre pode ser desativada para envolvidos no projeto, mesmo se os recursos pai (organização ou pasta) tiverem essa política ativada. Consulte a página Como personalizar políticas de restrições booleanas para mais detalhes.

2. Usar filtros de exclusão

   Usar um filtro de exclusão para registros de porta serial tem a mesma meta que a desativação da política organizacional, já que haverá registros do console serial no Logging. Para mais detalhes, consulte a página Filtros de exclusão.

Uso do Deployment Manager para gerenciar recursos Google Cloud protegidos pelo VPC Service Controls

As versões 1 e 2.0.x do Cloud Composer usam o Deployment Manager para criar componentes de ambientes do Cloud Composer.

Em dezembro de 2020, talvez você tenha recebido informações dizendo que precisa executar mais configurações do VPC Service Controls para poder gerenciar recursos protegidos pelo VPC Service Controls usando o Deployment Manager.

Queremos esclarecer que nenhuma ação é necessária da sua parte se você estiver usando o Cloud Composer e não estiver usando o Deployment Manager diretamente para gerenciar Google Cloud recursos mencionados no anúncio do Deployment Manager.

O Deployment Manager exibe informações sobre um recurso incompatível

O seguinte aviso pode ser exibido na guia "Deployment Manager":

The deployment uses actions, which are an unsupported feature. We recommend
that you avoid using actions.

Para as implantações do Deployment Manager de propriedade do Cloud Composer, ignore este aviso.

Não é possível excluir um ambiente após a exclusão do cluster

Esse problema se aplica ao Cloud Composer 1 e ao Cloud Composer 2 versões 2.0.x.

Se você excluir o cluster do GKE do ambiente antes do ambiente em si, as tentativas de excluir o ambiente vão resultar no seguinte erro:

 Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]

Para excluir um ambiente quando o cluster já foi excluído:

1. No console Google Cloud , acesse a página Deployment Manager.

   Acessar o Deployment Manager

2. Encontre todas as implantações marcadas com rótulos:

   • goog-composer-environment:<environment-name>
   • goog-composer-location:<environment-location>

   Você verá duas implantações marcadas com os rótulos descritos:

   • Uma implantação chamada <environment-location>-<environment-name-prefix>-<hash>-sd
   • Uma implantação chamada addons-<uuid>

3. Exclua manualmente os recursos que ainda estão listados nessas duas implantações e existem no projeto, como tópicos e assinaturas do Pub/Sub. Para fazer isso, siga estas etapas:

   1. Selecione as implantações.

   2. Clique em Excluir.

   3. Selecione a opção Excluir 2 implantações e todos os recursos criados por elas, como VMs, balanceadores de carga e discos e clique em Excluir tudo.

   A operação de exclusão falha, mas os recursos restantes são excluídos.

4. Exclua as implantações usando uma destas opções:

   • No console Google Cloud , selecione as duas implantações novamente. Clique em Excluir e selecione a opção Excluir duas implantações, mas manter os recursos criados por elas.

   • Execute um comando gcloud para excluir as implantações com a política 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. Exclua o ambiente do Cloud Composer.

Avisos sobre entradas duplicadas da tarefa "echo" pertencente ao DAG "echo-airflow_monitoring"

Você talvez veja a seguinte entrada nos registros do 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'")

Ignore essas entradas de registro, porque esse erro não afeta o DAG do Airflow e o processamento de tarefas.

Estamos trabalhando para melhorar o serviço do Cloud Composer e remover esses avisos dos registros do Airflow.

A criação de ambientes falha em projetos com APIs do Identity-Aware Proxy adicionadas ao perímetro do VPC Service Controls

Observação: esse problema afeta as versões 2.0.* do Cloud Composer.

Em projetos com o VPC Service Controls ativado, a conta [e-mail] precisa de acesso explícito no perímetro de segurança para criar ambientes.

Para criar ambientes, use uma das seguintes soluções:

• Não adicione a API Cloud Identity-Aware Proxy e a API Identity-Aware Proxy TCP ao perímetro de segurança.

• Adicione a conta de serviço [e-mail] como membro do seu perímetro de segurança usando a seguinte configuração no arquivo de condições YAML:

   - members:
      - serviceAccount:[e-mail]
  

A criação ou o upgrade do ambiente do Cloud Composer falha quando a política compute.vmExternalIpAccess está desativada

Esse problema se aplica aos ambientes do Cloud Composer 1 e do Cloud Composer 2.

Os clusters do GKE de propriedade do Cloud Composer configurados no modo IP público exigem conectividade externa para as VMs. Por isso, a política compute.vmExternalIpAccess não pode proibir a criação de VMs com endereços IP externos. Para mais informações sobre essa política organizacional, consulte Restrições da política da organização.

A primeira execução de DAG para um arquivo DAG enviado tem várias tarefas com falha

Quando você faz o upload de um arquivo DAG, às vezes as primeiras tarefas da primeira execução do DAG falham com o erro Unable to read remote log.... Esse problema ocorre porque o arquivo DAG é sincronizado entre o bucket do ambiente, os workers do Airflow e os programadores do Airflow do ambiente. Se o programador receber o arquivo DAG e programá-lo para ser executado por um worker, e se o worker ainda não tiver o arquivo DAG, a execução da tarefa vai falhar.

Para minimizar esse problema, os ambientes com o Airflow 2 são configurados para executar duas novas tentativas de uma tarefa com falha por padrão. Se uma tarefa falhar, ela será repetida duas vezes com intervalos de cinco minutos.

Anúncios sobre a remoção do suporte para APIs Beta obsoletas das versões do GKE

O Cloud Composer gerencia clusters subjacentes do GKE do Cloud Composer. A menos que você use explicitamente essas APIs nos DAGs e no código, ignore os avisos sobre as suspensões de uso da API GKE. O Cloud Composer cuida de todas as migrações, se necessário.

O Cloud Composer não deve ser afetado pela vulnerabilidade do Apache Log4j 2 (CVE-2021-44228)

Em resposta à vulnerabilidade do Apache Log4j 2 (CVE-2021-44228), o Cloud Composer realizou uma investigação detalhada e acreditamos que ele não está vulnerável a esse exploit.

Os workers ou programadores do Airflow podem ter problemas ao acessar o bucket do Cloud Storage do ambiente.

O Cloud Composer usa o gcsfuse para acessar a pasta /data no bucket do ambiente e salvar os registros de tarefas do Airflow no diretório /logs (se ativado). Se o gcsfuse estiver sobrecarregado ou o bucket do ambiente estiver indisponível, você poderá ter falhas na instância de tarefa do Airflow e ver erros Transport endpoint is not connected nos registros do Airflow.

Soluções:

• Desative o salvamento de registros no bucket do ambiente. Essa opção já está desativada por padrão se um ambiente for criado usando o Cloud Composer 2.8.0 ou versões mais recentes.
• Faça upgrade para o Cloud Composer 2.8.0 ou uma versão mais recente.
• Reduza [celery]worker_concurrency e aumente o número de workers do Airflow.
• Reduza a quantidade de registros produzidos no código do DAG.
• Siga as recomendações e práticas recomendadas para implementar DAGs e ativar novas tentativas de tarefas.

Às vezes, a interface do Airflow não recarrega um plug-in depois que ele é alterado.

Se um plug-in consistir em muitos arquivos que importam outros módulos, a interface do Airflow talvez não consiga reconhecer que um plug-in precisa ser recarregado. Nesse caso, reinicie o servidor da Web do Airflow do seu ambiente.

O cluster do ambiente tem cargas de trabalho no estado "Não programável"

Esse problema conhecido se aplica apenas ao Cloud Composer 2.

No Cloud Composer 2, depois que um ambiente é criado, várias cargas de trabalho no cluster do ambiente permanecem no estado "Não programável".

Quando um ambiente aumenta a escala, novos pods de worker são criados e o Kubernetes tenta executá-los. Se não houver recursos gratuitos disponíveis para executá-los, os pods de trabalhador serão marcados como "Não programáveis".

Nessa situação, o escalonador automático de cluster adiciona mais nós, o que leva alguns minutos. Até que isso seja feito, os pods permanecem no estado "Não programável" e não executam nenhuma tarefa.

As cargas de trabalho do DaemonSet não programáveis chamadas composer-gcsfuse e composer-fluentd que não podem ser iniciadas em nós sem componentes do Airflow não afetam seu ambiente.

Se o problema persistir por muito tempo (mais de uma hora), verifique os registros do autoescalador de cluster. Você pode encontrá-los no visualizador de registros com o seguinte filtro:

resource.type="k8s_cluster"
logName="projects/<project-name>/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
resource.labels.cluster_name="<cluster-name>"

Ele contém informações sobre as decisões tomadas pelo escalonador automático de cluster: expanda qualquer noDecisionStatus para ver o motivo pelo qual o cluster não pode ser escalonado verticalmente ou reduzido.

Erro 504 ao acessar a interface do Airflow

Você pode receber o erro 504 Gateway Timeout ao acessar a interface do Airflow. Esse erro pode ter várias causas:

• Problema de comunicação temporário. Nesse caso, tente acessar a interface do Airflow mais tarde. Também é possível reiniciar o servidor da Web do Airflow.

• (Somente no Cloud Composer 3) Problema de conectividade. Se a interface do Airflow estiver permanentemente indisponível e forem gerados erros de tempo limite ou 504, verifique se o ambiente pode acessar *.composer.googleusercontent.com.

• (Somente no Cloud Composer 2) Problema de conectividade. Se a interface do Airflow estiver permanentemente indisponível e forem gerados erros de tempo limite ou 504, verifique se o ambiente pode acessar *.composer.cloud.google.com. Se você usa o Acesso privado do Google e envia tráfego por IPs virtuais private.googleapis.com ou o VPC Service Controls e envia tráfego por IPs virtuais restricted.googleapis.com, verifique se o Cloud DNS também está configurado para nomes de domínio *.composer.cloud.google.com.

• Servidor da Web do Airflow que não responde. Se o erro 504 persistir, mas você ainda conseguir acessar a interface do Airflow em determinados momentos, o servidor da Web do Airflow poderá estar sem resposta por estar sobrecarregado. Tente aumentar os parâmetros de escala e desempenho do servidor da Web.

Erro 502 ao acessar a interface do Airflow

O erro 502 Internal server exception indica que a interface do Airflow não pode atender às solicitações recebidas. Esse erro pode ter várias causas:

• Problema de comunicação temporário. Tente acessar a interface do Airflow mais tarde.

• Falha ao iniciar o servidor da Web. Para começar, o servidor da Web precisa que os arquivos de configuração sejam sincronizados primeiro. Verifique os registros do servidor da Web para entradas de registro semelhantes a: 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. Se você encontrar esses erros, verifique se os arquivos mencionados nas mensagens de erro ainda estão presentes no bucket do ambiente.

  Em caso de remoção acidental (por exemplo, porque uma política de retenção foi configurada), é possível restaurá-los:

  1. Defina uma nova variável de ambiente no seu ambiente. Você pode usar qualquer nome e valor de variável.

  2. Substitua uma opção de configuração do Airflow. Você pode usar uma opção de configuração do Airflow que não existe.

Passar o cursor sobre a instância da tarefa na visualização em árvore gera um TypeError não capturado

No Airflow 2, a visualização em árvore na interface do Airflow às vezes não funciona corretamente quando um fuso horário não padrão é usado. Como solução alternativa para esse problema, configure o fuso horário explicitamente na interface do Airflow.

A interface do Airflow no Airflow 2.2.3 ou versões anteriores é vulnerável a CVE-2021-45229.

Conforme apontado em CVE-2021-45229, a tela "Acionar DAG com configuração" estava sujeita a ataques XSS pelo argumento de consulta origin.

Recomendação: faça upgrade para a versão mais recente do Cloud Composer que seja compatível com o Airflow 2.2.5.

Os workers exigem mais memória do que nas versões anteriores do Airflow

Sintomas:

• No ambiente do Cloud Composer 2, todas as cargas de trabalho do cluster de ambiente dos workers do Airflow estão no status CrashLoopBackOff e não executam tarefas. Você também pode ver avisos de OOMKilling gerados se for afetado por esse problema.

• Esse problema pode impedir upgrades do ambiente.

Causa:

• Se você usar um valor personalizado para a opção de configuração do Airflow [celery]worker_concurrency e configurações de memória personalizadas para workers do Airflow, esse problema poderá ocorrer quando o consumo de recursos se aproximar do limite.
• Os requisitos de memória do worker do Airflow no Airflow 2.6.3 com Python 3.11 são 10% maiores em comparação com os workers em versões anteriores.
• Os requisitos de memória do worker do Airflow no Airflow 2.3 e versões mais recentes são 30% maiores em comparação com os workers no Airflow 2.2 ou Airflow 2.1.

Soluções:

• Remova a substituição de worker_concurrency para que o Cloud Composer calcule esse valor automaticamente.
• Se você usar um valor personalizado para worker_concurrency, defina um valor mais baixo. Você pode usar o valor calculado automaticamente como ponto de partida.
• Como alternativa, aumente a quantidade de memória disponível para os workers do Airflow.
• Se não for possível fazer upgrade do ambiente para uma versão mais recente devido a esse problema, aplique uma das soluções propostas antes de fazer upgrade.

Acionamento de DAGs em redes particulares usando funções do Cloud Run

Não é possível acionar DAGs com funções do Cloud Run em redes particulares usando o conector VPC no Cloud Composer.

Recomendação: use funções do Cloud Run para publicar mensagens no Pub/Sub. Esses eventos podem acionar sensores do Pub/Sub para acionar DAGs do Airflow ou implementar uma abordagem baseada em operadores adiáveis.

Pastas vazias no programador e nos workers

O Cloud Composer não remove ativamente pastas vazias dos workers e programadores do Airflow. Essas entidades podem ser criadas como resultado do processo de sincronização do bucket de ambiente quando essas pastas existiam no bucket e foram removidas.

Recomendação: ajuste os DAGs para que eles estejam preparados para ignorar essas pastas vazias.

Essas entidades são removidas dos armazenamentos locais de programadores e workers do Airflow quando esses componentes são reiniciados (por exemplo, como resultado de operações de redução ou manutenção no cluster do ambiente).

Suporte para Kerberos

O Cloud Composer não é compatível com a configuração do Kerberos do Airflow.

Suporte para classes de computação no Cloud Composer 2 e no Cloud Composer 3

O Cloud Composer 3 e o Cloud Composer 2 são compatíveis apenas com a classe de computação de uso geral. Isso significa que não é possível executar pods que solicitam outras classes de computação, como Balanced ou Scale-Out.

A classe de uso geral permite executar pods que solicitam até 110 GB de memória e até 30 CPUs, conforme descrito em Solicitações máximas de classe de computação.

Se você quiser usar uma arquitetura baseada em ARM ou precisar de mais CPU e memória, use uma classe de computação diferente, que não é compatível com clusters do Cloud Composer 3 e do Cloud Composer 2.

Recomendação: use GKEStartPodOperator para executar pods do Kubernetes em um cluster diferente que seja compatível com a classe de computação selecionada. Se você executar pods personalizados que exigem uma classe de computação diferente, eles também precisarão ser executados em um cluster que não seja do Cloud Composer.

Suporte para operadores do Google Campaign Manager 360

Os operadores do Google Campaign Manager em versões do Cloud Composer anteriores a 2.1.13 são baseados na API Campaign Manager 360 v3.5, que está descontinuada e será desativada em 1º de maio de 2023.

Se você usa operadores do Google Campaign Manager, faça upgrade do ambiente para a versão 2.1.13 ou mais recente do Cloud Composer.

Suporte para operadores do Google Display & Video 360

Os operadores do Google Display & Video 360 em versões do Cloud Composer anteriores à 2.1.13 são baseados na API Display & Video 360 v1.1, que foi descontinuada e será desativada em 27 de abril de 2023.

Se você usa operadores do Google Display & Video 360, faça upgrade do ambiente para a versão 2.1.13 ou mais recente do Cloud Composer. Além disso, talvez seja necessário mudar seus DAGs porque alguns operadores do Google Display & Video 360 foram descontinuados e substituídos por novos.

• O GoogleDisplayVideo360CreateReportOperator foi descontinuado. Em vez disso, use GoogleDisplayVideo360CreateQueryOperator. Esse operador retorna query_id em vez de report_id.
• O GoogleDisplayVideo360RunReportOperator foi descontinuado. Em vez disso, use GoogleDisplayVideo360RunQueryOperator. Esse operador retorna query_id e report_id em vez de apenas report_id e exige query_id em vez de report_id como parâmetro.
• Para verificar se um relatório está pronto, use o novo sensor GoogleDisplayVideo360RunQuerySensor que usa os parâmetros query_id e report_id. O sensor GoogleDisplayVideo360ReportSensor descontinuado exigia apenas report_id.
• GoogleDisplayVideo360DownloadReportV2Operator agora exige os parâmetros query_id e report_id.
• Em GoogleDisplayVideo360DeleteReportOperator, não há mudanças que possam afetar seus DAGs.

Restrições de nomenclatura do intervalo secundário

Observação: a convenção de nomenclatura gke-.*-(pods|services)-.* é reservada para intervalos secundários de cluster do GKE criados automaticamente. Não é possível usar nomes de intervalos secundários nesse formato ao criar instâncias do Cloud Composer.

CVE-2023-29247 (a página de detalhes da instância da tarefa na UI está vulnerável a um XSS armazenado)

A interface do Airflow nas versões 2.0.x a 2.5.x está vulnerável a CVE-2023-29247.

Observação: a versão 2.4.2 do Cloud Composer corrige esse problema nas versões 2.4.3 e 2.5.3 do Airflow. Recomendamos atualizar seu ambiente para o Cloud Composer 2.4.2 ou uma versão mais recente. Esse problema não afeta o Airflow 2.6.x e versões mais recentes.

Se você usa uma versão do Cloud Composer anterior à 2.4.2 e suspeita que seu ambiente possa estar vulnerável ao exploit, leia a descrição a seguir e as possíveis soluções.

No Cloud Composer, o acesso à interface do Airflow é protegido com o IAM e o controle de acesso da interface do Airflow.

Isso significa que, para explorar a vulnerabilidade da interface do Airflow, os invasores primeiro precisam acessar seu projeto com as permissões e os papéis necessários do IAM.

Solução:

• Verifique as permissões e os papéis do IAM no seu projeto, incluindo os papéis do Cloud Composer atribuídos a usuários individuais. Verifique se apenas usuários aprovados podem acessar a interface do Airflow.

• Verifique os papéis atribuídos aos usuários pelo mecanismo de controle de acesso à interface do Airflow. Esse é um mecanismo separado que oferece acesso mais granular à interface do Airflow. Verifique se apenas usuários aprovados podem acessar a interface do Airflow e se todos os novos usuários estão registrados com uma função adequada.

• Considere um reforço adicional com o VPC Service Controls.

O DAG de monitoramento do Airflow do ambiente do Cloud Composer 2 não é recriado após a exclusão

O DAG de monitoramento do Airflow não é recriado automaticamente se for excluído pelo usuário ou movido do bucket em ambientes com composer-2.1.4-airflow-2.4.3.

Solução:

• Isso foi corrigido em versões mais recentes, como composer-2.4.2-airflow-2.5.3. A abordagem sugerida é fazer upgrade do ambiente para uma versão mais recente.
• Uma solução alternativa ou temporária para um upgrade de ambiente seria copiar o DAG airflow_monitoring de outro ambiente com a mesma versão.

Observação: não exclua o DAG de monitoramento. Ele é usado pelo Cloud Composer para monitorar a integridade do seu ambiente.

Não é possível reduzir o armazenamento do Cloud SQL

O Cloud Composer usa o Cloud SQL para executar o banco de dados do Airflow. Com o tempo, o armazenamento em disco da instância do Cloud SQL pode aumentar porque o disco é escalonado para se ajustar aos dados armazenados pelas operações do Cloud SQL quando o banco de dados do Airflow cresce.

Não é possível reduzir o tamanho do disco do Cloud SQL.

Como alternativa, se você quiser usar o menor tamanho de disco do Cloud SQL, recrie os ambientes do Cloud Composer com snapshots.

A métrica de uso do disco do banco de dados não diminui após a remoção de registros do Cloud SQL

Os bancos de dados relacionais, como o Postgres ou o MySQL, não removem fisicamente as linhas quando elas são excluídas ou atualizadas. Em vez disso, ele os marca como "tuplas mortas" para manter a consistência dos dados e evitar o bloqueio de transações simultâneas.

O MySQL e o Postgres implementam mecanismos de recuperação de espaço após a exclusão de registros.

Embora seja possível forçar o banco de dados a recuperar espaço em disco não utilizado, essa é uma operação que consome muitos recursos e bloqueia o banco de dados, tornando o Cloud Composer indisponível. Portanto, é recomendável usar os mecanismos de build para recuperar o espaço não utilizado.

Acesso bloqueado: erro de autorização

Se esse problema afetar um usuário, a caixa de diálogo Acesso bloqueado: erro de autorização vai conter a mensagem Error 400: admin_policy_enforced.

Se a opção Controles de API > Apps de terceiros não configurados > Não permitir o acesso de usuários a apps de terceiros estiver ativada no Google Workspace e o app Apache Airflow no Cloud Composer não estiver explicitamente permitido, os usuários não poderão acessar a interface do Airflow, a menos que permitam explicitamente o aplicativo.

Para permitir o acesso, siga as etapas em Permitir acesso à interface do Airflow no Google Workspace.

Loop de login ao acessar a interface do Airflow

Esse problema pode ter as seguintes causas:

• Se as vinculações de acesso baseado no contexto do Chrome Enterprise Premium forem usadas com níveis de acesso que dependem de atributos do dispositivo, e o app Apache Airflow no Cloud Composer não for isento, não será possível acessar a interface do Airflow devido a um loop de login. Para permitir o acesso, siga as etapas em Permitir acesso à interface do Airflow em vinculações do Acesso baseado no contexto.

• Se as regras de entrada estiverem configuradas em um perímetro do VPC Service Controls que protege o projeto, e a regra de entrada que permite o acesso ao serviço do Cloud Composer usar o tipo de identidade ANY_SERVICE_ACCOUNT ou ANY_USER_ACCOUNT, os usuários não poderão acessar a interface do Airflow, o que vai resultar em um loop de login. Para mais informações sobre como resolver esse cenário, consulte Permitir acesso à interface do Airflow nas regras de entrada do VPC Service Controls.

Instâncias de tarefas que tiveram sucesso no passado marcadas como "FALHA"

Em algumas circunstâncias e cenários raros, as instâncias de tarefa do Airflow que foram concluídas no passado podem ser marcadas como FAILED.

Se isso acontecer, geralmente foi acionado por uma atualização ou operação de upgrade do ambiente ou pela manutenção do GKE.

Observação:o problema em si não indica nenhum problema no ambiente e não causa falhas na execução da tarefa.

O problema foi corrigido na versão 2.6.5 ou mais recente do Cloud Composer.

Os componentes do Airflow têm problemas ao se comunicar com outras partes da configuração do Cloud Composer.

Esse problema se aplica apenas às versões 2.10.2 e anteriores do Cloud Composer 2.

Em casos muito raros, a lentidão da comunicação com o servidor de metadados do Compute Engine pode fazer com que os componentes do Airflow não funcionem de maneira ideal. Por exemplo, o programador do Airflow pode ser reiniciado, as tarefas do Airflow podem precisar ser repetidas ou o tempo de inicialização da tarefa pode ser maior.

Sintomas:

Os seguintes erros aparecem nos registros dos componentes do Airflow, como programadores, workers ou servidor da 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

Solução:

• (Recomendado) Faça upgrade do seu ambiente para uma versão mais recente do Cloud Composer. Esse problema foi corrigido a partir da versão 2.11.0 do Cloud Composer.

• Como solução temporária, defina a seguinte variável de ambiente: GCE_METADATA_TIMEOUT=30. Não se esqueça de remover essa configuração quando estiver tudo pronto para fazer upgrade do ambiente.

A pasta /data não está disponível no servidor da Web do Airflow

No Cloud Composer 2 e no Cloud Composer 3, o servidor da Web do Airflow é um componente principalmente somente leitura, e o Cloud Composer não sincroniza a pasta data/ com ele.

Às vezes, você pode querer compartilhar arquivos comuns entre todos os componentes do Airflow, incluindo o servidor da Web do Airflow.

Solução:

• Encapsule os arquivos a serem compartilhados com o servidor da Web em um módulo PYPI e instale-o como um pacote PYPI comum. Depois que o módulo PYPI é instalado no ambiente, os arquivos são adicionados às imagens dos componentes do Airflow e ficam disponíveis para eles.

• Adicione arquivos à pasta plugins/. Essa pasta é sincronizada com o servidor da Web do Airflow.

Diagramas de tempos de análise do DAG não contínuos e tamanho do pacote do DAG no monitoramento

Diagramas não contínuos de tempos de análise do DAG e tamanho do pacote de DAG no painel de monitoramento indicam problemas com tempos de análise longos (mais de 5 minutos).

Figura 1. Gráficos de tempos de análise do DAG não contínuos e tamanho do repositório do DAG (clique para ampliar)

Solução:Recomendamos manter o tempo total de análise do DAG abaixo de 5 minutos. Para reduzir o tempo de análise do DAG, siga as diretrizes de gravação de DAGs.

Os registros de componentes do Cloud Composer estão ausentes no Cloud Logging

Há um problema no componente do ambiente responsável por fazer upload dos registros de componentes do Airflow para o Cloud Logging. Esse bug às vezes leva a uma situação em que o registro no nível do Cloud Composer pode estar faltando para um componente do Airflow. O mesmo registro ainda está disponível no nível do componente do Kubernetes.

Ocorrência do problema: muito rara, esporádica

Causa:

Comportamento incorreto do componente do Cloud Composer responsável por fazer upload de registros para o Cloud Logging.

Soluções:

• Faça upgrade do ambiente para a versão 2.10.0 ou mais recente do Cloud Composer.

• Em versões anteriores do Cloud Composer, a solução temporária quando você encontra essa situação é iniciar uma operação do Cloud Composer que reinicia os componentes para os quais o registro está faltando.

Não é possível mudar o cluster do ambiente para a edição do GKE Enterprise.

Esta observação se aplica ao Cloud Composer 1 e ao Cloud Composer 2.

O cluster do GKE do ambiente do Cloud Composer é criado na edição Standard do GKE.

Desde dezembro de 2024, o serviço do Cloud Composer não é compatível com a criação de ambientes do Cloud Composer com clusters na Enterprise Edition.

Os ambientes do Cloud Composer não foram testados com a edição GKE Enterprise e têm um modelo de faturamento diferente.

Atenção: não faça upgrade dos clusters do Cloud Composer para a Enterprise Edition. Os ambientes do Cloud Composer não foram testados com a Enterprise Edition, e você pode receber cobranças adicionais após o upgrade. Se você fizer upgrade do cluster do seu ambiente para a Enterprise Edition, ele não terá suporte do Google.

Outras comunicações relacionadas à edição GKE Standard e à edição Enterprise serão feitas no segundo trimestre de 2025.

Componentes do Airflow com problemas ao se comunicar com outras partes da configuração do Cloud Composer

Em alguns casos, devido a uma resolução de DNS com falha, os componentes do Airflow podem ter problemas ao se comunicar com outros componentes do Cloud Composer ou endpoints de serviço fora do ambiente do Cloud Composer.

Sintomas:

Os seguintes erros podem aparecer nos registros dos componentes do Airflow, como programadores, workers ou servidor da 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.

Possíveis soluções:

• Faça upgrade para o Cloud Composer 2.9.11 ou

• Defina a seguinte variável de ambiente: GCE_METADATA_HOST=169.254.169.254.

O ambiente está no estado ERROR depois que a conta de faturamento do projeto foi excluída ou desativada, ou a API Cloud Composer foi desativada.

Os ambientes do Cloud Composer afetados por esses problemas não podem ser recuperados:

• Depois que a conta de faturamento do projeto foi excluída ou desativada, mesmo que outra conta tenha sido vinculada depois.
• Depois que a API Cloud Composer foi desativada no projeto, mesmo que tenha sido ativada depois.

Para resolver o problema, faça o seguinte:

• Você ainda poderá acessar os dados armazenados nos buckets do ambiente, mas os ambientes em si não poderão mais ser usados. Você pode criar um novo ambiente do Cloud Composer e transferir seus DAGs e dados.

• Se você quiser realizar alguma das operações que tornam seus ambientes irrecuperáveis, faça backup dos dados, por exemplo, criando um snapshot do ambiente. Assim, é possível criar outro ambiente e transferir os dados dele carregando esse snapshot.

Avisos sobre o orçamento de interrupção de pods para clusters de ambiente

Os seguintes avisos podem aparecer na interface do GKE para clusters de ambiente do 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.

Não é possível eliminar esses avisos. Estamos trabalhando para impedir que esses avisos sejam gerados.

Possíveis soluções:

• Ignore esses avisos até que o problema seja corrigido.

Não é possível remover um valor de campo em uma conexão do Airflow

Causa:

A interface do usuário do Apache Airflow tem uma limitação que impede a atualização dos campos de conexão para valores vazios. Quando você tenta fazer isso, o sistema reverte para as configurações salvas anteriormente.

Possíveis soluções:

Embora a versão 2.10.4 do Apache Airflow inclua uma correção permanente, há uma solução alternativa temporária para usuários de versões anteriores. Isso envolve excluir a conexão e recriá-la, deixando os campos obrigatórios vazios. A interface de linha de comando é a abordagem recomendada para excluir a conexão:

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

Depois de excluir a conexão, recrie-a usando a interface do Airflow, garantindo que os campos que você pretende deixar vazios estejam realmente em branco. Também é possível criar a conexão executando o comando da CLI do Airflow connections add com a Google Cloud CLI.

Os registros das tarefas do Airflow não são coletados se [core]execute_tasks_new_python_interpreter estiver definido como "True"

O Cloud Composer não coleta registros de tarefas do Airflow se a opção de configuração do Airflow [core]execute_tasks_new_python_interpreter estiver definida como True.

Possível solução:

• Remova a substituição dessa opção de configuração ou defina o valor dela como False.

A seguir

• Como resolver problemas da criação de ambientes
• Como resolver problemas de DAGs
• Como solucionar problemas do Airflow Scheduler