Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
Esta página lista os problemas conhecidos do Cloud Composer. Algumas correções para esses problemas estão em andamento e estarão disponíveis em versões futuras.
Alguns problemas afetam versões mais antigas 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 para endereços não RFC 1918 para pods e serviços. Atualmente, apenas os seguintes 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 é visto em um Airflow Scheduler para a instância da tarefa durante a execução dela. No entanto, os registros não explicam a causa da falha na tarefa, e o Airflow Worker e o Airflow Scheduler pareciam relativamente íntegros.
A mensagem de erro no Airflow Scheduler 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 algum erro no Airflow Worker 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 antigo no Airflow, recomendamos 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 e a resiliência geral do fluxo de trabalho.
A Identidade da carga de trabalho do GKE não é compatível
Esse problema se aplica apenas a ambientes do Cloud Composer 1. Cloud Composer 2 de nuvem usam a Identidade da carga de trabalho.
Não é possível ativar a Identidade da carga de trabalho para
clusters do ambiente do Cloud Composer. Como resultado, você poderá ver
WORKLOAD_IDENTITY_DISABLED
descoberta 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 CVE-2020-14386 de vulnerabilidades em todos os ambientes do Cloud Composer. Como parte do todos os clusters do GKE do Cloud Composer serão atualizados para uma versão mais recente.
Os clientes que decidirem resolver a vulnerabilidade imediatamente podem fazer upgrade Cluster do GKE do Composer seguindo estas instruções com 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 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
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 em 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:
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.
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 você não precisa fazer nada. se você usa o Composer e não usa o Deployment Manager diretamente para gerenciar os recursos do Google Cloud mencionados anúncio.
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:
Abra a página do Deployment Manager no console do Google Cloud.
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>
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:
Selecione as implantações.
Clique em Excluir.
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.
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
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.
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 o VPC Service Controls ativado,
a conta cloud-airflow-prod@system.gserviceaccount.com
exige conteúdo explícito
no 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 API TCP do Identity-Aware Proxy ao perímetro de segurança.
Adicione a conta de serviço
cloud-airflow-prod@system.gserviceaccount.com
como membro do 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 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, 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 na sua 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.
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.
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 versões 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 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
na
do ambiente de execução e salvar os registros de tarefas do Airflow no diretório /logs
(se
ativado). Se o gcsfuse estiver sobrecarregado ou o bucket do ambiente não estiver disponível,
podem ocorrer falhas na instância de tarefa do Airflow e ver
Erros Transport endpoint is not connected
nos registros do Airflow.
Soluções:
- Desative a salvamento de registros no bucket do ambiente. Esta opção já fica desativada por padrão quando 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 permitir novas tentativas de tarefas.
Às vezes, a interface do Airflow pode não recarregar 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, é necessário reiniciar o servidor da Web do Airflow. Para fazer isso, adicione uma variável de ambiente ou instale ou desinstale as dependências do PyPI. Você também pode reiniciar o servidor da Web do Airflow.
Problemas intermitentes na comunicação 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 O dia 12 de agosto de 2021 poderá ter problemas temporários relacionados à comunicação com bancos de dados de metadados do Airflow.
Se esse problema ocorrer, você verá nos registros de tarefas do Airflow esta mensagem de erro:
"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 está afetando você, siga estas etapas para eliminá-lo:
- No console do Google Cloud, acesse a página Configuração do ambiente. dos ambientes do Cloud Composer afetados.
- Siga o link ver detalhes do cluster para navegar ao cluster do GKE subjacente do ambiente.
Acesse a guia Nós e clique no default-pool que aparece na seção Pools de nós.
Clique em Editar no topo da página.
Mude o tipo de imagem para Container-Optimized OS com containerd e salve a configuração. conforme mostrado abaixo.
Depois que a mudança for enviada, o pool de nós default-pool será reconfigurado para usar o containerd como ambiente de execução de contêiner. Algumas das 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 só se aplica 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 trabalho 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 chamadas composer-gcsfuse
e composer-fluentd
que não são
que podem ser inicializados em nós onde não há componentes do Airflow não afetam seu ambiente.
Se o problema persistir por muito tempo (mais de uma hora), verifique os registros do autoescalador de clusters. É 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: abra qualquer noDecisionStatus para saber por que o cluster não pode ser escalonado.
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. Você também pode reinicie o servidor da Web do Airflow.
- (Somente no 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ê usar Acesso privado do Google e enviar tráfego porprivate.googleapis.com
IPs virtuais ou VPC Service Controls e enviar tráfego porrestricted.googleapis.com
IPs virtuais, verifique se o Cloud DNS está configurado para nomes de domínio*.composer.cloud.google.com
. - Servidor da Web do Airflow que não responde. Se o erro 504 persistir, mas você ainda conseguir acessar a interface do Airflow em determinados momentos, o servidor da Web do Airflow 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 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
ouGCS 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, devido a uma retenção política foi configurada), é possível restaurá-los:
Defina uma nova variável de ambiente no ambiente. É possível usar qualquer nome e valor de variável.
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 capturado.
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 problema, configurar 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 apontado em 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 de cluster do Os workers do Airflow estão no status
CrashLoopBackOff
e não são executados tarefas. Você também pode conferir os avisosOOMKilling
gerados se for afetado por esse problema.Esse problema pode impedir upgrades de 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 calcula esse valor automaticamente. - Se você usar um valor personalizado para
worker_concurrency
, defina-o com um valor menor. 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 por redes particulares usando funções do Cloud Run
Como acionar DAGs com funções do Cloud Run por redes privadas usando o O conector de VPC não é compatível com o Cloud Composer.
Recomendação: use funções do Cloud Run para publicar mensagens no Pub/Sub. Esses eventos podem ativar os sensores do Pub/Sub para acionar os DAGs do Airflow ou implementar uma abordagem com base em operadores adiáveis.
Problema com os comandos do gcloud composer na versão 410.0.0
Na política 410.0.0 versão da gcloud, use os seguintes comandos do Cloud Composer:
gcloud composer environments run
gcloud composer environments list-packages
retornar um código de erro diferente de zero e exibir esta mensagem de erro:
(ERROR: gcloud crashed (TypeError): 'NoneType' object is not callable)
Esse comportamento ocorre além da saída regular produzida pelo comandos gcloud e não impacta 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. Caso você precise usar a versão 410.0.0 e usar o comando gcloud de forma programática, implemente uma lógica adicional para ignorar códigos de erro diferentes de zero e informações sobre o stack trace de erro na saída. Você também pode conferir a seção "Solução" para ver 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 você já fez o 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 dos workers e programadores do Airflow. Essas entidades podem ser criadas como resultado do ambiente o processo de sincronização de bucket quando essas pastas já existiam no bucket e acabaram sendo removidos.
Recomendação: ajuste os DAGs para que estejam preparados para pular esses dados vazios pastas.
Em algum momento, essas entidades são removidas dos armazenamentos locais dos programadores do Airflow e workers quando esses componentes forem reiniciados (por exemplo, como resultado do escalonamento operações de manutenção ou desativação no cluster do Cloud Composer).
Suporte ao Kerberos
O Cloud Composer ainda não é compatível com a configuração do Kerberos do Airflow.
Suporte a 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 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 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
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ê usar operadores do Google Campaign Manager, faça upgrade do seu ambiente usando 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 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 uso de
GoogleDisplayVideo360CreateReportOperator
foi descontinuado. Em vez disso, useGoogleDisplayVideo360CreateQueryOperator
. Esse operador retornaquery_id
em vez dereport_id
. - O uso de
GoogleDisplayVideo360RunReportOperator
foi descontinuado. Em vez disso, useGoogleDisplayVideo360RunQueryOperator
. Esse operador retornaquery_id
ereport_id
em vez de apenasreport_id
e exigequery_id
em vez dereport_id
como parâmetro. - Para verificar se um relatório está pronto, use a nova
Sensor
GoogleDisplayVideo360RunQuerySensor
que usaquery_id
e Parâmetrosreport_id
. O sensorGoogleDisplayVideo360ReportSensor
descontinuado exigia apenasreport_id
. GoogleDisplayVideo360DownloadReportV2Operator
agora exige os parâmetrosquery_id
ereport_id
.- Em
GoogleDisplayVideo360DeleteReportOperator
, não há mudanças que possam afetar seus DAGs.
Restrições de nome do intervalo secundário
CVE-2023-29247 (a página de detalhes da instância de tarefa na UI 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 que a 2.4.2 e suspeita que seu ambiente esteja vulnerável ao ataque, leia a descrição a seguir e as possíveis soluções.
No Cloud Composer, o acesso à interface do Airflow é protegido com IAM e 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 os papéis atribuídos aos usuários no Controle de acesso à interface do Airflow (um mecanismo separado que fornece acesso mais granular à interface do Airflow). Garanta que apenas usuários aprovados possam acessar interface do Airflow e que todos os novos usuários sejam registrados com um papel adequado.
Considere o aumento da proteção com o VPC Service Controls.
O DAG de monitoramento de Airflow do ambiente do Cloud Composer 2 do Composer 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 do Composer com o composer-2.1.4-airflow-2.4.3.
Solução:
- Isso foi corrigido em versões mais recentes, como composer-2.4.2-airflow-2.5.3. A abordagem sugerida é fazer upgrade do ambiente para uma versão mais recente.
- Uma solução alternativa ou temporária para um upgrade de ambiente seria copiar o DAG airflow_monitoring de outro ambiente com a mesma versão.
As operações de upgrade podem falhar se o Sentry estiver ativado
A operação de upgrade para um ambiente do Cloud Composer pode falhar
se você configurou o Sentry no ambiente e definiu o [sentry]sentry_on
como true
.
Solução:
- Desative o Sentry no seu 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 um 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 diminui após a remoção de registros do Cloud SQL.
Os bancos de dados relacionais, como o Postgres ou o MySQL, não removem linhas fisicamente ao eles são excluídos ou atualizados. Em vez disso, eles são marcados como "tuplas inativas". de manter consistência de 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 registros.
Embora seja possível forçar o banco de dados a recuperar o espaço em disco não utilizado, isso é uma operação que consome muitos recursos e bloqueia o banco de dados Cloud Composer indisponível. Portanto, é recomendável usar criar mecanismos para recuperar o espaço inutilizado.
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 explicitamente o aplicativo.
Para permitir o acesso, siga as etapas indicadas em Permitir o acesso à interface do Airflow no Google Workspace.
Instâncias de tarefas que tiveram sucesso no passado marcadas como FALHA
Em algumas circunstâncias e cenários raros, instâncias de tarefas do Airflow que funcionaram
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. ele não causa falhas reais na execução da tarefa.
O problema foi corrigido no Cloud Composer versão 2.6.5 ou posterior.
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 Compute Engine O servidor de metadados pode fazer com que os componentes do Airflow não funcionem de maneira ideal. Por exemplo, se o programador do Airflow for reiniciado, as tarefas do Airflow podem precisar ou o tempo de inicialização da tarefa pode ser mais longo.
Sintomas:
Os erros a seguir aparecem nos componentes do Airflow de registros (como Airflow 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, o servidor da Web do Airflow é destinado a ser um componente quase totalmente somente leitura, e o Cloud Composer não sincroniza a pasta data/
com esse componente.
Às vezes, talvez você queira compartilhar arquivos comuns entre todos os componentes, incluindo o servidor da Web Airflow.
Solução:
Una os arquivos a serem compartilhados com o servidor da Web em um módulo PYPI e instalá-lo 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/
. Esta pasta está sincronizada com no servidor da Web do Airflow.
Tempos de análise de DAG não contínuos e diagramas de tamanho de pacote do DAG no monitoramento
Tempos de análise de DAG não contínuos e diagramas de tamanho de pacote do DAG no monitoramento indicam problemas com longos tempos de análise do DAG (mais de cinco minutos).
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 tarefas aparecem com atraso
Esse problema conhecido se aplica ao Cloud Composer 3.
Sintoma:
- No Cloud Composer 3, os registros de tarefas do Airflow não aparecem imediatamente e atrasado por alguns minutos.
Causa:
Se o ambiente executar um grande número de tarefas ao mesmo tempo, os registros de tarefas poderão ser atrasados porque o tamanho da infraestrutura do ambiente não é suficiente para processar todos os registros com rapidez suficiente.
Soluções:
- Considere aumentar o tamanho da infraestrutura do ambiente para melhorar a performance.
- Distribua as execuções de DAG ao longo do tempo para que as tarefas não sejam executadas ao mesmo tempo.
A seguir
- Como resolver problemas da criação de ambientes
- Como resolver problemas de DAGs
- Como solucionar problemas do Airflow Scheduler