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

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.

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.

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.

Em projetos com os controles de serviço da VPC ativados, a conta cloud-airflow-prod@system.gserviceaccount.com 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 cloud-airflow-prod@system.gserviceaccount.com como membro do seu perímetro de segurança usando a seguinte configuração no arquivo de condições YAML:

     - members:
        - serviceAccount:cloud-airflow-prod@system.gserviceaccount.com
    

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

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:

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

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 é dimensionado, novos pods de worker são criados e o Kubernetes tenta executá-los. Se não houver recursos disponíveis para executá-los, os pods de worker 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.

Cargas de trabalho de DaemonSet não programáveis com os nomes composer-gcsfuse e composer-fluentd que não podem ser iniciadas em nós em que os componentes do Airflow não estão presentes não afetam seu ambiente.

Se o problema persistir por muito tempo (mais de uma hora), verifique os registros do escalonador automático de clusters. Eles podem ser encontrados 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>"

Ela contém informações sobre as decisões tomadas pelo escalonador automático de cluster: abra qualquer noDecisionStatus para saber por que o cluster não pode ser aumentado 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 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.

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

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

No Airflow 2, a visualização em árvore na interface do Airflow pode não funcionar corretamente quando um fuso horário diferente do 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 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.

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 do Airflow estão no status CrashLoopBackOff e não executam tarefas. Você também pode conferir os avisos 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 [celery]worker_concurrency do Airflow e as configurações de memória personalizadas para workers do Airflow, poderá ocorrer esse problema 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 na versão 2.3 e mais recentes são 30% maiores em comparação com os workers no Airflow 2.2 ou 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, é possível aumentar 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

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 a classes de computação no Cloud Composer 2 e 3

O Cloud Composer 3 e o Cloud Composer 2 oferecem suporte apenas à 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 a execução de 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 os clusters do Cloud Composer 3 e do Cloud Composer 2.

Recomendação: use GKEStartPodOperator para executar pods do Kubernetes em um cluster diferente que ofereça suporte à 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

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

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.

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.

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 uma atualização de ambiente seria copiar o DAG airflow_monitoring de outro ambiente com a mesma versão.

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.

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 que os usuários acessem apps de terceiros estiver ativada no Google Workspace e o Apache Airflow no app Cloud Composer não for permitido explicitamente, os usuários não poderão acessar a interface do Airflow, a menos que permitam o aplicativo explicitamente.

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

Loop de login ao acessar a interface do Airflow

Esse problema pode ter as seguintes causas:

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.

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 quase totalmente somente leitura, e o Cloud Composer não sincroniza a pasta data/ com esse componente.

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

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

Tempos de análise de DAG do Airflow e gráficos de tamanho do pacote de DAG mostrando uma série de intervalos não contínuos
Figura 1. 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.

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 dos componentes do Airflow para o Cloud Logging. Às vezes, esse bug leva a uma situação em que o registro do nível do Cloud Composer pode estar ausente para um componente do Airflow. O mesmo registro ainda está disponível no nível do componente do Kubernetes.

Ocorrência do problema: muito raro, esporádico

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 para essa situação é iniciar uma operação do Cloud Composer que reinicia os componentes para os quais o registro está ausente.

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.

Outras comunicações relacionadas à edição GKE Standard em comparação com a 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 falha na resolução de DNS, 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 o 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.

Soluções possíveis:

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