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:
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 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:
No console do Google Cloud, acesse a página Deployment Manager.
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
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:
- Desative a salvação de registros no bucket do ambiente. Essa opção já está desativada por padrão se um ambiente é criado usando o Cloud Composer 2.8.0 ou versões mais recentes.
- Faça upgrade para o Cloud Composer 2.8.0 ou uma versão mais recente.
- Reduza
[celery]worker_concurrency
e aumente o número de workers do Airflow. - Reduza a quantidade de registros produzidos no código da DAG.
- Siga as recomendações e práticas recomendadas para implementar DAGs e ativar as tentativas de repetição de tarefas.
Às vezes, a interface do Airflow não recarrega um plug-in depois que ele é alterado.
Se um plug-in consistir em muitos arquivos que importam outros módulos, a interface do Airflow poderá não reconhecer que um plug-in precisa ser recarregado. Nesse caso, reinicie o servidor da Web do Airflow do seu ambiente.
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 virtuaisprivate.googleapis.com
ou o VPC Service Controls e envia tráfego por IPs virtuaisrestricted.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
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, porque uma política de retenção foi configurada), é possível restaurá-los:
Defina uma nova variável de 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 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 avisosOOMKilling
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, useGoogleDisplayVideo360CreateQueryOperator
. Esse operador retornaquery_id
em vez dereport_id
. - O
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 o novo sensor
GoogleDisplayVideo360RunQuerySensor
que usa os parâmetrosquery_id
ereport_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 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:
Se as vinculações de acesso com reconhecimento de contexto do Chrome Enterprise Premium forem usadas com níveis de acesso que dependem de atributos do dispositivo e o Apache Airflow no app do Cloud Composer não estiver isento, não será possível acessar a interface do Airflow devido a um loop de login. Para permitir o acesso, siga as etapas fornecidas em Permitir o acesso à interface do Airflow em vinculações de acesso baseado no contexto.
Se as regras de entrada estiverem configuradas em um perímetro do VPC Service Controls que protege o projeto e a regra de entrada que permite o acesso ao serviço do Cloud Composer usa o tipo de identidade
ANY_SERVICE_ACCOUNT
ouANY_USER_ACCOUNT
, os usuários não poderão acessar a interface do Airflow, resultando em um ciclo de login. Para mais informações sobre como resolver esse cenário, consulte Permitir acesso à interface do Airflow nas regras de entrada do VPC Service Controls.
Instâncias de tarefas que tiveram sucesso no passado marcadas como FALHA
Em algumas circunstâncias e cenários raros, as instâncias de 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](https://cloud.google.com/static/composer/docs/images/composer-non-continuous-dag-parse-times.png?authuser=5&hl=pt)
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
- Como resolver problemas da criação de ambientes
- Como resolver problemas de DAGs
- Como solucionar problemas do Airflow Scheduler