Problemas conhecidos

Cloud Composer 1 | Cloud Composer 2

Nesta página, listamos problemas conhecidos do Cloud Composer. Algumas correções para esses problemas estão em andamento e vão ser disponibilizadas em versões futuras.

Alguns problemas afetam versões mais antigas e podem ser corrigidos com o upgrade do 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. No momento, 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 de tarefa durante a programação no Cloud Composer

O problema é observado em um programador do Airflow para a instância de tarefa durante a execução da tarefa. No entanto, os registros não explicam a causa da falha da tarefa, e o worker e o programador do Airflow pareciam relativamente íntegros.

A mensagem de erro no programador do Airflow pode ser parecida com este:

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 algum erro no worker do Airflow semelhante ao seguinte:

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 de longa data no Airflow, é altamente recomendável implementar proativamente estratégias de nova tentativa adequadas nos níveis da tarefa e do DAG. Incorporando essas medidas, o sistema pode reduzir efetivamente o impacto desses erros, melhorando a confiabilidade e a resiliência gerais do fluxo de trabalho.

A Identidade da carga de trabalho do GKE não é compatível

Esse problema se aplica apenas aos ambientes do Cloud Composer 1. Os ambientes do Cloud Composer 2 usam a Identidade da carga de trabalho.

Não é possível ativar a Identidade da carga de trabalho nos clusters de ambiente do Cloud Composer. Como resultado, é possível que você veja a descoberta WORKLOAD_IDENTITY_DISABLED no Security Command Center.

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

Os rótulos de ambiente atualizados não são aplicados às VMs do Compute Engine. Como solução alternativa, esses rótulos podem ser aplicados manualmente.

Upgrades do GKE no contexto do problema CVE-2020-14386

Estamos trabalhando para resolver a vulnerabilidade CVE-2020-14386 em todos os ambientes do Cloud Composer. Como parte da correção, todos os clusters atuais do GKE do Cloud Composer serão atualizados para uma versão mais recente.

Os clientes que decidem resolver a vulnerabilidade imediatamente podem fazer upgrade do cluster do GKE do Composer seguindo estas instruções, considerando as seguintes considerações:

Etapa 1: Se você estiver executando uma versão do Cloud Composer anterior à 1.7.2, atualize para uma versão mais recente do Cloud Composer. Se você já tiver a versão 1.7.2 ou posterior, vá para o próximo ponto.

Etapa 2: Atualize o cluster do GKE (mestre e nós) para a versão de patch mais recente 1.15 que contém a correção da vulnerabilidade.

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 na convenção de nomenclatura de arquivos de registros. As informações de zona agora são 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 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 recursos do Google Cloud protegidos pelo VPC Service Controls

O Composer usa 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.

Gostaríamos de esclarecer que nenhuma ação será necessária se você estiver usando o Composer e não estiver usando o Deployment Manager diretamente para gerenciar os recursos do Google Cloud mencionados no anúncio do Deployment Manager.

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

Se você excluir o cluster 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 do GKE já for excluído:

1. Abra a página Deployment Manager no console do Google Cloud.

   Abra a página do 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.

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.

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.

Falha na criação do ambiente em projetos com APIs Identity-Aware Proxy adicionadas ao perímetro do VPC Service Controls

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

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

Para criar ambientes, você pode usar 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 perímetro de segurança usando a seguinte configuração no arquivo de condições YAML:

   - members:
      - serviceAccount:[e-mail]
  

A criação do ambiente 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, a operação de criação do ambiente do Cloud Composer 1 v1 falhará.

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

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

A criação ou o upgrade do ambiente do Cloud Composer falha quando o compute.vmExternalIpAccess está desativado.

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.

Observação: este comentário se aplica ao Cloud Composer 1 e ao Cloud Composer 2.

Falha na criação do ambiente do Cloud Composer 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 "Encaminhamento de IP" ativado. Para mais informações sobre essa política organizacional, consulte Restrições da política da organização.

Observação: este comentário se aplica apenas ao Cloud Composer 1.

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. Essas sincronizações são feitas de forma independente. 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 falhará.

Como solução alternativa, os ambientes do Airflow 2 no Cloud Composer 1.17.0-preview.9 e versions posteriores 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.

Para usar a solução alternativa para esse problema no Airflow 1, substituição core-default_task_retries Opção de configuração do Airflow e defini-la como um número maior ou igual a2 de dados.

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.

Falha nos operadores do Dataproc/Dataflow 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.

Upgrades do GKE no contexto do problema de segurança CVE-2021-25741

Todos os clusters do GKE existentes do Cloud Composer serão atualizados automaticamente para as versões mais recentes do GKE com uma correção para os problemas descritos na CVE-2021-25741.

Se você quiser corrigir essa vulnerabilidade imediatamente, faça upgrade do cluster do GKE do ambiente seguindo as instruções para fazer upgrade de um cluster.

• Se você tiver um ambiente do Cloud Composer 1 e o GKE versão 1.18.x ou anterior, faça upgrade para 1.18.20-gke.4501.

• Se você tiver um ambiente do Cloud Composer 1 e a versão 1.19.x do GKE, faça upgrade para 1.19.14-gke.301.

• Se você tiver um ambiente do Cloud Composer 2 e a versão 1.21.x do GKE, faça upgrade para 1.21.4-gke.301

O Cloud Composer não pode 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 o Cloud Composer não está vulnerável a essa exploração.

Cloud Composer 2: os workers ou programadores do Airflow podem ter problemas ao acessar os buckets do Cloud Storage

Em algumas situações esporádicas, no caso de ambientes do Cloud Composer 2 quando o worker ou o programador do Airflow é reiniciado, ele pode apresentar falhas e ter problemas ao acessar o conteúdo do bucket do Cloud Storage.

Nessa situação, talvez apareçam erros que começam com: Transport endpoint is not connected nos registros do Airflow.

Por exemplo, o registro de erros do worker do Airflow pode ser assim:

[Errno 107] Transport endpoint is not connected: '/home/airflow/gcs/logs/airflow_monitoring/echo/2022-01-11T22:50:48+00:00'

Solução:

• Faça upgrade para o Cloud Composer 2.0.26 ou uma versão mais recente

Às vezes, a interface do Airflow pode não recarregar um plug-in depois da alteração

Se um plug-in consiste em muitos arquivos que importam outros módulos, a interface do Airflow pode não ser capaz de reconhecer o fato de que um plug-in precisa ser recarregado. Nesse caso, é preciso acionar uma reinicialização do servidor da Web do Airflow. Você pode fazer isso adicionando uma variável de ambiente ou por meio da instalação ou desinstalação de dependências PYPI. Também é possível reiniciar o servidor da Web do Airflow.

Problemas intermitentes ao se comunicar com o banco de dados de metadados do Airflow

Esse problema conhecido se aplica apenas ao Cloud Composer 1.

Alguns ambientes mais antigos do Cloud Composer 1 (1.16.3 ou anteriores) criados antes de 12 de agosto de 2021 podem enfrentar problemas temporários relacionados à comunicação com bancos de dados de metadados 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ê acha que foi muito afetado por esse problema, faça o seguinte para eliminá-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 navegar até o cluster do GKE subjacente do ambiente.
3. Acesse a guia Nós e clique no default-pool na seção Pools de nós.
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 conforme mostrado abaixo.
6. Depois que a alteração 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 tarefas do Airflow podem falhar durante a reconfiguração do pool de nós. 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.

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 é escalonado, novos pods de worker são criados e o Kubernetes tenta executá-los. Se não houver recursos livres 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.

As cargas de trabalho DaemonSet não programáveis chamadas 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 o ambiente.

Se o problema persistir por muito tempo (mais de 1 hora), verifique os registros do escalonador automático de cluster. É possível 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 para mais ou para menos.

Erro 504 ao acessar a interface do Airflow

O erro 504 Gateway Timeout pode aparecer quando você acessa a interface do Airflow. Esse erro pode ter várias causas:

• Problema de comunicação temporário. Nesse caso, tente acessar a IU do Airflow mais tarde. Também é possível reiniciar o servidor da Web do Airflow.
• (Apenas no Cloud Composer 2) Problema de conectividade. Se a interface do Airflow estiver permanentemente indisponível e o tempo limite ou erros 504 forem gerados, verifique se o ambiente pode acessar *.composer.cloud.google.com. Se você usar o Acesso privado do Google, enviar tráfego por IPs virtuais private.googleapis.com ou VPC Service Controls e enviar 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.
• O servidor da Web do Airflow não responde. Se o erro 504 persistir, mas você ainda conseguir acessar a IU do Airflow em certos momentos, o servidor da Web do Airflow poderá 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 exibir as 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. Procure nos registros do servidor da Web entradas de registro semelhantes a: GCS sync exited with 1: gsutil -m cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp ou GCS sync exited with 1: gsutil -m 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á-la:

  1. Defina uma nova variável de ambiente no ambiente. É possível usar qualquer nome e valor de variável.

  2. Substituir uma opção de configuração do Airflow. A opção de configuração do Airflow pode ser inexistente.

A interface do Airflow no Airflow 2.2.3 ou versões anteriores está vulnerável à vulnerabilidade CVE-2021-45229

Conforme mencionado em CVE-2021-45229, a tela "Acionar DAG com configuração" era suscetível a ataques XSS por meio do argumento de consulta origin.

Recomendação: faça upgrade para a versão mais recente do Cloud Composer 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 workers do Airflow estão no status CrashLoopBackOff e não executam tarefas. Você também vai ver avisos OOMKilling gerados se esse problema afetar você.

• 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 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 de workers do Airflow no Airflow 2.6.3 com Python 3.11 são 10% maiores em comparação com os workers de versões anteriores.
• Os requisitos de memória de workers do Airflow no Airflow 2.3 e versões posteriores 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. Use 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 posterior por causa desse problema, aplique uma das soluções propostas antes do upgrade.

Acionamento de DAG por redes privadas usando o Cloud Functions

O Cloud Composer não aceita DAGs com o Cloud Functions por meio de redes privadas usando o conector VPC.

Recomendação: use o Cloud Functions 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.

Problema com os comandos do gcloud composer na versão 410.0.0

Na versão 410.0.0 da gcloud, você pode usar os seguintes comandos do Cloud Composer:

• gcloud composer environments run
• gcloud composer environments list-packages

retorne um código de erro diferente de zero e exiba esta mensagem de erro:

  (ERROR: gcloud crashed (TypeError): 'NoneType' object is not callable)

Esse comportamento ocorre além da saída normal produzida pelos comandos da gcloud e não afeta a funcionalidade deles.

Se esse problema não afetar suas operações, continue usando a versão 410.0.0 e ignore a mensagem de erro incorreta. Se você precisar usar a versão 410.0.0 e o comando gcloud de maneira programática, implemente uma lógica adicional para ignorar o código de erro diferente de zero e as informações sobre o stack trace de erro na saída. Você também pode consultar a seção Solução para obter outras soluções alternativas.

Solução

• Evite fazer upgrade para a versão 410.0.0. Use a versão 409.0.0 ou anterior.
• Se já tiver feito upgrade, faça downgrade para uma versão anterior (por exemplo, 409.0.0). Para mais informações, consulte Como usar arquivos com controle de versão.

Pastas vazias no programador e nos workers

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

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

Em algum momento, 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 Cloud Composer).

Suporte para Kerberos

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

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

O Cloud Composer 2 é compatível 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 da classe do Compute.

Se você quiser usar a 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 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 2.

Suporte para operadores do Google Campaign Manager 360

Os operadores do Google Campaign Manager nas versões do Cloud Composer anteriores à 2.1.13 são baseados na API Campaign Manager 360 v3.5, que foi descontinuada, e a data de desativação é 1o de maio de 2023.

Se você usar os operadores do Google Campaign Manager, faça upgrade do seu ambiente para a versão 2.1.13 ou posterior 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 a data de desativação é 27 de abril de 2023.

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

• O uso de GoogleDisplayVideo360CreateReportOperator foi descontinuado. Em vez disso, use GoogleDisplayVideo360CreateQueryOperator. Esse operador retorna query_id em vez de report_id.
• O uso de GoogleDisplayVideo360RunReportOperator foi descontinuado. Em vez disso, use GoogleDisplayVideo360RunQueryOperator. Esse operador retorna query_id e report_id em vez de apenas report_id e requer query_id em vez de report_id como um 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á alterações que possam afetar os DAGs.

Restrições de nome de intervalo secundário

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

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

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

Observação: o Cloud Composer versão 2.4.2 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 versão posterior. 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 diferente da 2.4.2 e suspeite que seu ambiente pode estar vulnerável à exploração, 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 IU do Airflow, os invasores precisam ter acesso ao 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 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 por meio do mecanismo de controle de acesso à interface do Airflow. Esse é um mecanismo separado que fornece 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 um papel adequado.

• Considere o aumento da proteção com o VPC Service Controls.

O DAG de monitoramento do fluxo de ar 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 excluído pelo usuário ou movido do bucket em ambientes do Composer com composer-2.1.4-airflow-2.4.3.

Solução:

• Isso foi corrigido em versões posteriores, como composer-2.4.2-airflow-2.5.3. A abordagem sugerida é fazer upgrade do ambiente para uma versão mais recente.
• Uma alternativa temporária ou alternativa 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 ambiente.

As operações de upgrade poderão falhar se o Sentry estiver ativado

A operação de upgrade de um ambiente do Cloud Composer pode falhar se você tiver configurado o Sentry no ambiente e definir a configuração [sentry]sentry_on como true.

Solução:

• Desative o Sentry no ambiente, faça o upgrade e configure o Sentry novamente.

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 para a instância do Cloud SQL pode aumentar porque o disco é escalonado verticalmente para se ajustar aos dados armazenados pelas operações do Cloud SQL quando o banco de dados do Airflow aumenta.

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 de disco do banco de dados não diminui após a remoção de registros do Cloud SQL

Os 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, ela as marca como "tuplas inativas" 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 registros excluídos.

É possível forçar o banco de dados a recuperar o espaço em disco não utilizado, mas essa é uma operação que consome muitos recursos e bloqueia o banco de dados, tornando o Cloud Composer indisponível. Portanto, é recomendável confiar nos mecanismos de compilaçã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 mostrar 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 explicitamente permitido, os usuários não poderão acessar a IU do Airflow, a menos que eles permitam o aplicativo explicitamente.

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

As instâncias de tarefas que já foram bem-sucedidas foram marcadas como FAILED (FALHA).

Em algumas circunstâncias e em cenários raros, as instâncias de tarefas do Airflow que foram bem-sucedidas no passado podem ser marcadas como FAILED.

Se acontecer, geralmente ele foi 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 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

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

Sintomas:

Os erros a seguir aparecem nos registros dos componentes do Airflow (como programadores, workers ou o servidor da Web do Airflow):

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, o servidor da Web do Airflow foi projetado como um componente somente leitura, e o Cloud Composer não sincroniza a pasta data/ com esse componente.

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

Solução:

• Una 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 for instalado no ambiente, os arquivos serão adicionados às imagens dos componentes do Airflow e ficarão disponíveis para eles.

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

A seguir

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