Problemas conhecidos

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Esta página lista os 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

A IU do Airflow não mostra registros de tarefas quando a serialização do DAG está ativada no Composer 1.10.2 e no Composer 1.10.3

A ativação da serialização de DAG em ambientes usando as versões 1.10.2 e 1.10.3 do Composer impede a exibição dos registros no servidor da Web do Airflow. Faça upgrade para a versão 1.10.4 (ou mais recente) para corrigir esse problema.

Falha intermitente da tarefa durante a programação no Cloud Composer

O problema é visto no programador do Airflow para a instância da tarefa durante a execução de uma tarefa. No entanto, os registros não explicam a causa da falha da tarefa, e o worker e o programador do Airflow pareciam relativamente saudáveis.

A mensagem de erro no agendador do Airflow pode ser semelhante a esta:

Executor reports task instance <TaskInstance: xx.xxxx
scheduled__2022-04-21T06:00:00+00:00 [queued]> finished (failed) although the
task says its queued. (Info: None) Was the task killed externally?

Ou pode haver um erro no worker do Airflow semelhante a esta mensagem de erro:

Log file is not found: gs://$BUCKET_NAME/logs/$DAG_NAME/$TASK_NAME/
2023-01-25T05:01:17.044759+00:00/1.log.
The task might not have been executed or worker executing it might have
finished abnormally (e.g. was evicted).

Para garantir a robustez contra esses erros decorrentes de um problema antigo no Airflow, é altamente recomendado implementar proativamente estratégias de nova tentativa adequadas nos níveis de tarefa e DAG. Ao incorporar essas medidas, o sistema pode mitigar o impacto desses erros, melhorando a confiabilidade geral e a resiliência do fluxo de trabalho.

A Federação de Identidade da Carga de Trabalho do GKE não é compatível com o GKE

No Cloud Composer 1, não é possível ativar a Federação de identidade da carga de trabalho para o GKE em clusters de ambiente do Cloud Composer. Como resultado, é possível que a descoberta WORKLOAD_IDENTITY_DISABLED apareça no Security Command Center.

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

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

Os registros de tarefas do Airflow não estão disponíveis no servidor da Web do Airflow após o upgrade do Airflow 1.9.0 para o Airflow 1.10.x.

O Airflow 1.10.x introduziu alterações incompatíveis com versões anteriores da convenção de nomenclatura para arquivos de registro. As informações de zona agora foram adicionadas aos nomes de registro para tarefas do Airflow.

O Airflow 1.9.0 armazena e espera que os nomes dos registros estejam no seguinte formato: BUCKET/logs/DAG/2020-03-30T10:29:06/1.log O Airflow 1.10.x armazena e espera que os nomes dos registros estejam no seguinte formato: BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Como resultado, se você fizer upgrade do Airflow 1.9.0 para o Airflow 1.10.x e quiser ler o registro de uma tarefa executada com o Airflow 1.9.0, o servidor da Web do Airflow exibirá a seguinte mensagem de erro : Unable to read remote log from BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Solução alternativa: renomeie os registros gerados pelo Airflow 1.9.0 no bucket do Cloud Storage usando o formato: BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

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 console do Google Cloud. 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 Google Cloud recursos protegidos pelo VPC Service Controls

As versões 2.0.x do Cloud Composer 1 e do Cloud Composer 2 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 usar o Deployment Manager para gerenciar recursos protegidos pelo VPC Service Controls.

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 recursos Google Cloud mencionados no anúncio do Deployment Manager.

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

O seguinte aviso pode aparecer 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 próprio ambiente, as tentativas de excluir o ambiente resultarão 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 do 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 do 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 do ambiente falha em projetos com APIs de proxy cientes de identidade adicionadas ao perímetro do VPC Service Controls.

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

Em projetos com os controles de serviço da VPC ativados, a conta [e-mail] exige acesso explícito no seu perímetro de segurança para criar ambientes.

Para criar ambientes, use uma destas 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 de ambientes do Cloud Composer 1 falha quando a política compute.requireOsLogin está ativada.

Se a política compute.requireOsLogin for definida como true no projeto, as operações de criação do ambiente do Cloud Composer 1 v1 vão falhar.

Para criar ambientes do Cloud Composer 1, desative essa política no seu projeto.

Para mais informações sobre essa política organizacional, consulte Restrições da política da organização.

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 criação de ambiente do Cloud Composer 1 falha quando a política compute.vmCanIpForward está desativada.

Os ambientes do Cloud Composer 1 criados no modo não nativo de VPC (usando o IP do alias) exigem essa política para permitir a criação de VMs com o recurso de encaminhamento de IP ativado. 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 mitigar esse problema, os ambientes com o Airflow 2 são configurados para realizar 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.

Para reduzir esse problema no Airflow 1, substitua a opção de configuração [core]default_task_retries do Airflow e defina-a como um número maior ou igual a 2.

A tarefa falha com "OSError: [Errno 5] erro de entrada/saída" no Airflow 1.10.15 ou versões anteriores.

Um bug nas versões do Airflow 1 faz com que as tarefas sejam colocadas na fila do Redis duas vezes em alguns casos raros.

Às vezes, pode levar a uma disputa no arquivo de registros e a uma falha de tarefa subsequente. As tarefas falham com OSError: [Errno 5] Input/output error no Cloud Logging e Task is in the 'running' state which is not a valid state for execution. no registro de tentativas da tarefa.

Esse bug foi corrigido no Airflow 2. Se encontrar esse problema no Airflow 1 em uma tarefa de longa duração, aumente o valor da opção de configuração [celery_broker_transport_options]visibility_timeout do Airflow (o valor padrão). é o 604800 para o Composer 1.17.0, 21600 para ambientes mais antigos. Para tarefas de curta duração, considere adicionar novas tentativas às tarefas afetadas ou migrar seu ambiente para o Airflow 2.

Os operadores do Dataproc e do Dataflow falham com Negsignal.SIGSEGV

Esse é um problema intermitente da biblioteca grcpio, quando usado por um worker do Celery. Esse problema afeta o Airflow 1.10.14 e versões posteriores.

A solução é alterar a estratégia de pesquisa grpcio adicionando a seguinte variável de ambiente ao seu ambiente: GRPC_POLL_STRATEGY=epoll1. Essa solução já está aplicada ao Cloud Composer 1.17.1 e versões posteriores.

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 é 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 é 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 se o bucket do ambiente estiver indisponível, você poderá encontrar falhas na instância da tarefa do Airflow e erros Transport endpoint is not connected nos registros do Airflow.

Soluções:

• Desative a salvação de registros no bucket do ambiente. Essa opção já está desativada por padrão se um ambiente é 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 da DAG.
• Siga as recomendações e práticas recomendadas para implementar DAGs e ativar as tentativas de repetição 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 poderá não reconhecer que um plug-in precisa ser recarregado. Nesse caso, reinicie o servidor da Web do Airflow do seu ambiente.

Problemas intermitentes ao se comunicar com o banco de dados do ambiente

Esse problema conhecido se aplica apenas ao Cloud Composer 1.

Alguns ambientes anteriores do Cloud Composer 1 (1.16.3 ou anterior) criados antes de 12 de agosto de 2021 podem apresentar problemas temporários relacionados à comunicação com o banco de dados do Airflow.

Se você tiver esse problema, a seguinte mensagem de erro vai aparecer nos registros de tarefas do Airflow:

"Can't connect to MySQL server on 'airflow-sqlproxy-service.default.svc.cluster.local' (104)"

A equipe do Cloud Composer está trabalhando para resolver esse problema. Enquanto isso, se você acredita que esse problema afeta muito você, siga estas instruções para mitigá-lo:

1. No console do Google Cloud, acesse a página Configuração do ambiente dos ambientes do Cloud Composer afetados.

2. Siga o link ver detalhes do cluster para acessar o cluster do GKE subjacente do ambiente.

3. Navegue até a guia Nós e clique em default-pool, que aparece na seção Pools de nós.

   

   Figura 1. default-pool na lista de pools de nós (clique para ampliar)

4. Clique em Editar no topo da página.

5. Mude o tipo de imagem para Container-Optimized OS com containerd e salve a configuração:

   

   Figura 2. Mude o tipo de imagem do pool de nós de Docker para containerd (clique para ampliar)

6. Depois que a mudança for enviada, o pool de nós default-pool será reconfigurado para usar o containerd como o ambiente de execução do contêiner. Algumas das suas tarefas do Airflow podem falhar enquanto o pool de nós está sendo reconfigurado. Se essas tarefas tiverem novas tentativas configuradas, elas serão executadas novamente pelo Airflow assim que a operação no pool de nós for concluída.

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 Cloud Composer 3) Problema de conectividade. Se a interface do Airflow estiver permanentemente indisponível e erros de tempo limite ou 504 forem gerados, verifique se o ambiente pode acessar *.composer.googleusercontent.com.

• (Somente Cloud Composer 2) Problema de conectividade. Se a interface do Airflow estiver permanentemente indisponível e erros de tempo limite ou 504 forem gerados, verifique se o ambiente pode acessar *.composer.cloud.google.com. Se você usa o Google Access privado 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 está configurado também para nomes de domínio *.composer.cloud.google.com.

• O servidor da Web do Airflow 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 pode não responder porque está 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 exige que os arquivos de configuração sejam sincronizados primeiro. Verifique se há entradas de registro semelhantes a esta nos registros do servidor da Web: 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 esses erros aparecerem, 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. É possível usar qualquer nome e valor de variável.

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

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

Conforme indicado no CVE-2021-45229, a tela "Trigger DAG with config" era suscetível a ataques XSS pelo argumento de consulta origin.

Recomendação: faça upgrade para a versão mais recente do Cloud Composer que oferece suporte ao Airflow 2.2.5.

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

O Cloud Composer não oferece suporte para acionar DAGs com funções do Cloud Run por redes privadas com o uso do conector VPC.

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 do ambiente quando essas pastas existiram no bucket e foram removidas.

Recomendação: ajuste seus DAGs para que eles ignorem 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 seu ambiente).

Suporte ao Kerberos

O Cloud Composer não oferece suporte à configuração do Kerberos do Airflow.

Suporte para operadores do Google Campaign Manager 360

As operadoras do Google Campaign Manager em versões do Cloud Composer anteriores à 2.1.13 são baseadas na API Campaign Manager 360 v3.5, que foi descontinuada e vai 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 nas 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 e do 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 outros 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 nome de intervalo secundário

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

CVE-2023-29247: a página de detalhes da instância da tarefa na interface está vulnerável a um XSS armazenado.

A interface do Airflow nas versões 2.0.x a 2.5.x é 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 anterior do Cloud Composer anterior à 2.4.2 e suspeite que seu ambiente pode 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 à interface do Airflow.

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

Solução:

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

• Verifique as funções atribuídas 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 o aumento da proteção com o VPC Service Controls.

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 é dimensionado 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 solução 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 é reduzida após a remoção de registros do Cloud SQL.

Bancos de dados relacionais, como Postgres ou MySQL, não removem fisicamente as linhas quando elas são excluídas ou atualizadas. Em vez disso, ele as marca como "tuplas inválidas" 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 o espaço em disco não utilizado, essa é uma operação que consome recursos e, além disso, bloqueia o banco de dados, o que torna o Cloud Composer indisponível. Portanto, é recomendável usar os mecanismos de construção para recuperar o espaço não utilizado.

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

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

Se isso acontecer, geralmente é acionado por uma operação de atualização ou 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 reais na execução de tarefas.

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

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 da maneira ideal. Por exemplo, o programador do Airflow pode ser reiniciado, as tarefas do Airflow podem precisar ser refeitas 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 o 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:

Defina a seguinte variável de ambiente: GCE_METADATA_TIMEOUT=30.

Tempos de análise de DAG não contínuos e diagramas de tamanho de pacotes de DAG no monitoramento

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

Figura 3. Tempos de análise de DAG não contínuos e gráficos de 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 escrita de DAGs.

Não é possível mudar o cluster do ambiente para o GKE Enterprise Edition

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 padrão do GKE.

A partir de dezembro de 2024, o serviço do Cloud Composer não vai mais oferecer suporte à criação de ambientes do Cloud Composer com clusters na edição Enterprise.

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

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

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

O ambiente está no estado ERROR depois que a conta de faturamento do projeto foi excluída ou desativada ou que 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 for excluída ou desativada, mesmo que outra conta seja vinculada mais tarde.
• Depois que a API Cloud Composer for desativada no projeto, mesmo que ela seja ativada mais tarde.

Faça o seguinte para resolver o problema:

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

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

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

Os seguintes avisos aparecem 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 alertas sejam gerados.

Soluções possíveis:

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

A seguir

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