Resolver problemas de extração de imagens

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Esta página ajuda a resolver problemas com o processo de extração de imagem no Google Kubernetes Engine (GKE). Se você usa o streaming de imagem, consulte Resolver problemas com o streaming de imagem para receber conselhos. Esta página se concentra em extrações de imagem padrão.

Esta página é destinada a desenvolvedores de aplicativos que querem garantir que os apps sejam implantados com sucesso e a administradores e operadores de plataforma que querem entender a causa raiz de falhas de extração de imagem e verificar a configuração da plataforma. Para saber mais sobre papéis comuns e exemplos de tarefas referenciados no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE Enterprise.

O processo de extração de imagem é como o Kubernetes, e, portanto, o GKE, recupera imagens de contêineres de um registro. Quando um pull de imagem falha, o app pode ficar lento ou não funcionar de jeito nenhum.

Para determinar se os downloads de imagens são a causa do problema do app, esta página ajuda a diagnosticar a falha de download de imagens encontrando e entendendo mensagens de erro relevantes. Em seguida, você vai aprender a resolver as seguintes causas comuns de falhas de extração de imagens:

• Configurações de autenticação: seu cluster não tem as permissões necessárias para acessar o registro de imagem do contêiner.
• Conectividade de rede: o cluster não consegue se conectar ao registro devido a problemas de DNS, regras de firewall ou falta de acesso à Internet em clusters que usam o isolamento de rede.
• Imagem não encontrada no registro: o nome ou a tag da imagem especificada estão incorretos, a imagem foi excluída ou o registro está indisponível.
• Limitações de desempenho: tamanho de imagem grande, E/S de disco lento ou congestionamento da rede podem causar puxagens lentas ou timeouts.
• Arquitetura de imagem incompatível: a imagem foi criada para uma arquitetura de CPU diferente do seu pool de nós do GKE.
• Versões de esquema incompatíveis: talvez você esteja usando o containerd 2.0 ou mais recente com um esquema do Docker v1, que não tem suporte.

Se você já recebeu uma mensagem de evento específica, pesquise-a nesta página e siga as etapas de solução de problemas listadas. Se você não tiver recebido uma mensagem, siga as seções a seguir na ordem. Se o problema persistir, entre em contato com o Cloud Customer Care.

Entender os pulls de imagem

Antes de começar a solução de problemas, é útil entender um pouco mais sobre o ciclo de vida de uma imagem e onde você pode hospedar suas imagens.

Ciclo de vida da imagem

Quando você cria um pod, o kubelet recebe a definição do pod, que inclui a especificação da imagem. O kubelet precisa dessa imagem para executar um contêiner com base nela. Antes de extrair a imagem, o kubelet verifica o runtime do contêiner para ver se a imagem está presente. O kubelet também verifica a política de extração de imagem do pod. Se a imagem não estiver no cache do ambiente de execução do contêiner ou se a política de extração de imagem exigir isso, o kubelet vai direcionar o ambiente de execução do contêiner (containerd) para extrair a imagem especificada do registro. Uma falha no pull de imagem impede a inicialização do contêiner no pod.

Após a extração da imagem, o ambiente de execução do contêiner descompacta a imagem para criar um sistema de arquivos de base somente leitura para o contêiner. O ambiente de execução do contêiner armazena essa imagem, que permanece presente enquanto os contêineres em execução a referenciam. Se nenhum contêiner em execução referenciar uma imagem, ela vai se qualificar para a coleção de lixo e o kubelet vai removê-la.

Opções de hospedagem de imagens

Recomendamos que você use uma das seguintes opções para hospedar suas imagens:

• Artifact Registry: é o gerenciador de pacotes totalmente gerenciado do Google. O Artifact Registry se integra de perto a outros serviços Google Cloud e oferece controle de acesso refinado. Para saber mais, consulte Trabalhar com imagens de contêiner na documentação do Artifact Registry.

• Registro auto-hospedado: um registro auto-hospedado oferece mais controle, mas também exige que você o gerencie. Considere essa opção se você tiver necessidades específicas de compliance ou segurança que o Artifact Registry não pode atender.

Diagnosticar falhas de extração de imagem

Para diagnosticar falhas de extração de imagem, realize as investigações detalhadas nas seções a seguir:

1. Conferir o status e os eventos do pod.
2. Entender o significado do status.
3. Use as mensagens de evento para encontrar a causa da falha de extração de imagem.
4. Acesse os registros do Explorador de registros.

Conferir o status e os eventos do pod

Para ajudar a verificar se o pull de uma imagem falhou, o GKE registra os seguintes status para pods:

• ImagePullBackOff
• ErrImagePull
• ImageInspectError
• InvalidImageName
• RegistryUnavailable
• SignatureValidationFailed

ImagePullBackOff e ErrImagePull são os status mais comuns.

Além desses status, os eventos do Kubernetes ajudam a encontrar a causa de falhas de extração de imagem.

Para confirmar se o pull de imagem está com falha, verifique as mensagens de status e leia as mensagens de evento selecionando uma das seguintes opções:

Entender o significado do status

Para entender melhor o que os diferentes status significam, consulte as seguintes descrições:

• ImagePullBackOff: o kubelet não conseguiu extrair a imagem, mas ele vai continuar tentando com um atraso cada vez maior (ou backoff) de até cinco minutos.
• ErrImagePull: um erro geral e irrecuperável durante o processo de extração de imagem.
• ImageInspectError: o ambiente de execução do contêiner encontrou um problema ao tentar inspecionar a imagem do contêiner.
• InvalidImageName: o nome da imagem do contêiner especificado na definição do pod não é válido.
• RegistryUnavailable: o registro não está acessível. Isso geralmente é um problema de conectividade de rede.
• SignatureValidationFailed: a assinatura digital da imagem do contêiner não pôde ser verificada.

Usar mensagens de evento para encontrar a causa da falha de extração de imagem

A tabela a seguir lista as mensagens de evento relacionadas a falhas de recuperação de imagem e as etapas de solução de problemas que você precisa seguir se encontrar uma dessas mensagens.

As mensagens relacionadas a falhas de extração de imagens geralmente têm o seguinte prefixo:

Failed to pull image "IMAGE_ADDRESS": rpc error: code = CODE = failed to pull and unpack image "IMAGE_ADDRESS": failed to resolve reference "IMAGE_ADDRESS":

Esta mensagem inclui os seguintes valores:

• IMAGE_ADDRESS: o endereço completo da imagem. Por exemplo, us-west1-docker.pkg.dev/my-project/my-repo/test:staging.
• CODE: um código de erro associado à mensagem de registro. Por exemplo, NotFound ou Unknown.

Algumas causas de falhas de pull de imagem não têm uma mensagem de evento relacionada. Se você não encontrar nenhuma das mensagens de evento na tabela a seguir, mas ainda tiver problemas de extração de imagem, recomendamos que continue lendo o restante da página.

Conferir os registros da Análise de registros

Para examinar eventos de extração de imagem históricos ou correlacionar falhas de extração de imagem com outra atividade do componente, acesse os registros com o Explorador de registros:

1. No console do Google Cloud, acesse a página do Explorador de registros.

   Acessar o Explorador de registros

2. No painel de consulta, digite a seguinte consulta:

   log_id("events")
   resource.type="k8s_pod"
   resource.labels.cluster_name="CLUSTER_NAME"
   jsonPayload.message=~"Failed to pull image"
   

   Substitua CLUSTER_NAME pelo nome do cluster em que o pod com erros de extração de imagem é executado.

3. Clique em Executar consulta e confira os resultados.

Investigar as configurações de autenticação

As seções a seguir ajudam você a verificar se o ambiente do GKE tem as configurações de autenticação adequadas para extrair imagens do repositório.

Para verificar se você tem problemas de autenticação que causam um problema de extração de imagem, realize as investigações detalhadas nas seções a seguir:

1. Verifique o acesso à imagem.
2. Verifique a configuração do imagePullSecret e a especificação de implantação.
3. Verifique o escopo de acesso do nó para o repositório particular do Artifact Registry
4. Verifique as configurações do VPC Service Controls para acessar o Artifact Registry.

Verificar o acesso à imagem

Se você encontrar um erro de extração de imagem 403 Forbidden, verifique se os componentes necessários podem acessar a imagem do contêiner.

O método para verificar e aplicar as funções necessárias para conceder o acesso necessário varia de acordo com o tipo de repositório que armazena suas imagens. Para verificar e conceder acesso, selecione uma das seguintes opções:

Verificar a configuração do imagePullSecret e a especificação de implantação

Se você usar um imagePullSecret, verifique se criou um secret que contém as credenciais de autenticação para extrair imagens e se todas as implantações especificam o secret definido. Para mais informações, consulte Como especificar imagePullSecrets em um pod na documentação do Kubernetes.

Verifique o escopo de acesso do nó para o repositório particular do Registro de artefatos

Se você armazenar a imagem do contêiner em um repositório particular do Artifact Registry, é possível que o nó não tenha o escopo de acesso correto. Quando isso acontece, você pode notar um erro de extração de imagem 401 Unauthorized.

Para verificar e conceder o escopo de acesso, se necessário, siga estas etapas:

1. Identifique o nó que executa o pod:

   kubectl describe pod POD_NAME | grep "Node:"
   

   Substitua POD_NAME pelo nome do pod que apresenta uma falha de extração de imagem.

2. Verifique se o nó identificado na etapa anterior tem o escopo de armazenamento correto:

   gcloud compute instances describe NODE_NAME \
       --zone="COMPUTE_ZONE \
       --format="flattened(serviceAccounts[].scopes)"
   

   Substitua:

   • NODE_NAME: o nome do nó que você identificou na etapa anterior.
   • COMPUTE_ZONE: a zona do Compute Engine a que o nó pertence.

   A saída precisa conter pelo menos um dos seguintes escopos de acesso:

   • serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/devstorage.read_only
   • serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/cloud-platform

   Se o nó não tiver um desses escopos, o pull de imagem vai falhar.

3. Recrie o pool de nós ao qual o nó pertence com escopo suficiente. Como não é possível modificar os nós atuais, é necessário recriar o nó com o escopo correto.

   Recomendamos que você crie o pool de nós com o escopo gke-default. Esse escopo oferece acesso aos seguintes escopos:

   • https://www.googleapis.com/auth/devstorage.read_only
   • https://www.googleapis.com/auth/logging.write
   • https://www.googleapis.com/auth/monitoring
   • https://www.googleapis.com/auth/service.management.readonly
   • https://www.googleapis.com/auth/servicecontrol
   • https://www.googleapis.com/auth/trace.append

   Se o escopo gke-default não for adequado, conceda ao pool de nós o escopo devstorage.read_only, que permite acesso apenas para ler dados.

   gke-default

   Crie um pool de nós com o escopo gke-default:

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --zone=COMPUTE_ZONE \
       --scopes="gke-default"
   

   Substitua:

   • NODE_POOL_NAME: o nome do novo pool de nós.
   • CLUSTER_NAME: o nome do cluster atual.
   • COMPUTE_ZONE: a zona do Compute Engine a que o novo pool de nós pertence.

   devstorage.read_only

   Crie um pool de nós com o escopo devstorage.read_only:

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --zone=COMPUTE_ZONE \
       --scopes="https://www.googleapis.com/auth/devstorage.read_only"
   

   Substitua:

   • NODE_POOL_NAME: o nome do novo pool de nós.
   • CLUSTER_NAME: o nome do cluster atual.
   • COMPUTE_ZONE: a zona do Compute Engine a que o novo pool de nós pertence.

Verificar as configurações do VPC Service Controls para acessar o Artifact Registry

Se você usa o VPC Service Controls, verifique se os perímetros de serviço permitem o acesso ao Artifact Registry. Para saber mais, consulte Proteger repositórios em um perímetro de serviço na documentação do Artifact Registry.

Investigar a conectividade de rede

Durante o pull de imagem, a conectividade de rede pode impedir a conclusão do processo.

Para verificar se problemas de conectividade de rede estão causando um problema de extração de imagem, realize as investigações detalhadas nas seções a seguir:

1. Investigar a resolução de DNS.
2. Investigue a configuração do firewall.
3. Investigue a conectividade de Internet dos endpoints de registro externos.
4. Verifique se a conexão com as APIs do Google está expirando.

Investigar a resolução de DNS

Se você notar um erro de extração de imagem server misbehaving, a resolução de DNS pode ser a causa da falha de extração de imagem.

Para investigar problemas com a resolução de DNS, tente as seguintes soluções:

1. Resolver problemas no servidor de metadados. O servidor de metadados do nó resolve todas as consultas DNS. Qualquer problema que envolva esse servidor pode interromper a resolução de nomes, impedindo a conexão com o repositório e causando a falha do pull de imagem.
2. Se você usa o Cloud DNS para resolução de DNS, verifique se as zonas particulares gerenciadas, de encaminhamento, de peering e as políticas de resposta do Cloud DNS estão configuradas corretamente. Configurações incorretas nessas áreas podem interromper a resolução de DNS. Para saber mais sobre o Cloud DNS, consulte Como usar o Cloud DNS para GKE. Para receber conselhos sobre como resolver problemas do Cloud DNS no GKE, consulte Resolver problemas do Cloud DNS no GKE.
3. Se você usa o kube-dns para resolução de DNS, verifique se ele está funcionando corretamente. Para receber conselhos sobre como resolver problemas do kube-dns, consulte Resolver problemas do kube-dns no GKE.
4. Se os nós do cluster não tiverem endereços IP externos (o que é comum se você usar o isolamento de rede), ative o Acesso privado do Google na sub-rede usada pelo cluster e verifique se você atende aos requisitos de rede. Se você usa o Cloud NAT, Google Cloud ativa o Acesso privado do Google automaticamente.

Investigar a configuração do firewall

Quando um problema com o firewall causa uma falha no download da imagem, você pode receber a seguinte mensagem de erro:

Failed to start Download and install k8s binaries and configurations

Diagnosticar problemas com o firewall

Se você estiver usando um cluster padrão e quiser confirmar se um problema com o firewall está causando problemas com os downloads de imagem, siga estas etapas:

1. Use o SSH para se conectar ao nó que tem problemas:

   gcloud compute ssh NODE_NAME --zone=ZONE_NAME
   

   Substitua:

   • NODE_NAME: o nome do nó.
   • ZONE_NAME: a zona do Compute Engine em que o nó foi criado.

2. Envie os registros mais recentes dos serviços kube-node-installation.service e kube-node-configuration.service para arquivos de texto chamados kube-node-installation_status.txt e kube-node-configuration_status.txt:

   systemctl status kube-node-installation.service > kube-node-installation_status.txt
   systemctl status kube-node-configuration.service > kube-node-configuration_status.txt
   

   Se esses registros não incluírem informações sobre quando o pull de imagem falhou, gere uma cópia completa dos registros:

   sudo journalctl -u kube-node-installation.service > kube-node-installation_logs.txt
   sudo journalctl -u kube-node-configuration.service > kube-node-configuration_logs.txt
   

3. Revise o conteúdo dos arquivos kube-node-installation_status.txt e kube-node-configuration_status.txt. Se você encontrar i/o timeout na saída, o problema provavelmente está no firewall.

Resolver problemas com a configuração do firewall

Para resolver problemas com o firewall, tente as seguintes soluções:

1. Identifique e resolva todas as regras de firewall que estão bloqueando o tráfego de rede. Por exemplo, você pode ter uma regra que bloqueia o tráfego para o registro que armazena sua imagem.

   1. Acesse os registros de fluxo de VPC:

      1. No console do Google Cloud, acesse a página do Explorador de registros.

         Acessar o Explorador de registros

      2. No painel de consulta, digite a seguinte consulta:

         resource.type="gce_subnetwork"
         logName="projects/PROJECT_ID/logs/[compute.googleapis.com%2Fvpc_flows](http://compute.googleapis.com%2Fvpc_flows)"
         resource.labels.subnetwork_name="SUBNET_NAME",
         

         Substitua:

         • PROJECT_ID: o ID do seu projeto do Google Cloud.
         • SUBNET_NAME: o nome da sub-rede.

         Para saber mais, consulte Acessar registros de fluxo usando consultas na documentação da VPC.

   2. Se você encontrar regras de firewall que estão bloqueando o tráfego necessário, atualize-as.

2. Se os nós do cluster não tiverem endereços IP externos (o que é comum se você usar o isolamento de rede), ative o Acesso privado do Google na sub-rede usada pelo cluster e verifique se você atende aos requisitos de rede. Se você usa o Cloud NAT, Google Cloud ativa o Acesso privado do Google automaticamente.

Investigar a conectividade de Internet dos endpoints de registro externos

Se a configuração da rede direcionar o tráfego por um endpoint de registro externo, ele poderá não ter conectividade com a Internet. Quando o endpoint não tem acesso, o pull de imagem pode falhar, e você vai encontrar um erro de pull de imagem i/o timeout.

Para verificar a conectividade de rede do endpoint do registro externo ao registro, use ping ou traceroute:

ping REGISTRY_ENDPOINT

Ou

traceroute REGISTRY_ENDPOINT

Substitua REGISTRY_ENDPOINT pelo endpoint do registro. Esse valor pode ser um nome de host ou um endereço IP.

Se você encontrar um erro na conectividade, analise as rotas da VPC:

1. No console do Google Cloud, acesse Rotas.

   Acessar a página Rotas

2. Analise a coluna Prioridade e verifique se a rota de maior prioridade está indo para uma origem que tenha acesso ao registro. As rotas com valores mais baixos têm precedência.

Investigar se a conexão com as APIs do Google está expirando

Se você usar o isolamento de rede, poderá ocorrer um erro em que o tempo limite da conexão com as APIs e os serviços do Google se esgota, levando a um erro de extração de imagem i/o timeout.

Esse erro ocorre porque os nós não conseguiram acessar uma das seguintes APIs ao tentar extrair imagens do registro:

• containerregistry.googleapis.com
• artifactregistry.googleapis.com

Para garantir que você possa se conectar às APIs necessárias, tente estas soluções:

1. Ative o Acesso privado do Google. Os nós sem endereços IP externos precisam do Acesso privado do Google para acessar os endereços IP externos das APIs e dos serviços do Google.
2. Use um domínio compatível.

3. Revise suas políticas de firewall:

   1. No console do Google Cloud, acesse as políticas do Firewall.

      Acesse as políticas de firewall

   2. Verifique se você tem regras que bloqueiam o tráfego TCP de saída na porta 443 para 199.36.153.4/30, 199.36.153.8/30 ou qualquer intervalo de endereços IP usado pelo domínio escolhido para APIs e serviços do Google. Os intervalos de endereços IP 199.36.153.4/30 e 199.36.153.8/30 são usados para o Acesso privado do Google e o Acesso restrito do Google, respectivamente. O tráfego TCP na porta 443 para esses intervalos é usado para acessar APIs e serviços do Google.

      Se você encontrar alguma dessas regras, crie uma regra de firewall de saída para permitir esse tráfego.

4. Se você usa o Artifact Registry, verifique se o ambiente atende aos requisitos para usar o Artifact Registry com isolamento de rede.

5. Verifique se os endereços IP virtuais (VIPs) (199.36.153.4/30 ou 199.36.153.8/30) têm rotas VPC configuradas:

   1. No console do Google Cloud, acesse "Redes VPC".

      Acessar redes VPC

   2. Na coluna Nome, clique em padrão.

   3. Na página de detalhes da rede VPC, clique na guia Rotas.

   4. Revise a tabela de rotas.

      Se a rede VPC contém uma rota padrão (destino 0.0.0.0/0 ou ::0/0) e o próximo salto dessa rota é o gateway de Internet padrão (Padrão de rede), use essa rota para que os VIPs acessem as APIs e os serviços do Google.

      Se você substituiu uma rota padrão por uma rota personalizada em que o próximo salto não é o gateway de Internet padrão, atenda aos requisitos de roteamento para APIs e serviços do Google usando o roteamento personalizado.

Investigar por que o kubelet não consegue encontrar sua imagem

Quando o kubelet não encontra sua imagem, pode aparecer um erro image not found e falhas de pull de imagem.

Para ajudar o kubelet a encontrar sua imagem, tente as seguintes soluções:

1. Revise o manifesto do seu pod e verifique se o nome da imagem e da tag de imagem estão escritos corretamente. Qualquer erro de ortografia ou formatação faz com que a extração de imagem falhe.
2. Verifique se a imagem ainda existe no registro em que você a armazenou. Se a imagem tiver um caminho de registro completo, verifique se ela existe no registro do Docker que você usa. Se você fornecer apenas o nome da imagem, verifique o registro do Docker Hub.
3. Se o cluster usar o isolamento de rede, tente as seguintes soluções:
   1. Ative o Acesso privado do Google.
   2. Verifique se o perímetro de serviço está configurado corretamente.

Investigar por que há tempo limite ou extração lenta de imagens

Se você usar uma imagem muito grande para sua carga de trabalho do GKE, o pull de imagem poderá expirar e causar um erro context cancelled. Embora as imagens não tenham um limite de tamanho definido, o erro context cancelled geralmente indica que o tamanho da imagem é a causa.

Você também pode notar que as transferências de imagem não falham, mas demoram muito mais do que o normal. Se você quiser ter uma referência dos seus tempos normais de extração de imagem, confira a entrada de registro Successfully pulled image. Por exemplo, a mensagem de registro a seguir mostra que a extração de imagem levou 30,313387996 segundos:

Successfully pulled image "IMAGE_ADDRESS" in 30.313387996s.

Os tempos limite e as transferências de imagens lentas têm muitas das mesmas causas. Para resolver esses problemas, tente as seguintes soluções:

1. Verifique se há interrupções. Se você notou esse problema apenas durante um período específico, verifique se houve Google Cloud interrupções.
2. Verifique o desempenho do disco. A E/S lenta do disco pode aumentar os tempos de extração de imagens. Considere fazer upgrade para discos permanentes com SSDs (pd-ssd) ou usar discos maiores para melhorar o desempenho. Para mais conselhos, consulte Resolver problemas de desempenho do disco.
3. Reduza o tamanho da imagem. Por exemplo, talvez seja possível mover alguns dados das imagens do contêiner para volumes persistentes.
4. Aproveite o armazenamento em cache de imagens para tempos de inicialização rápidos do pod. O GKE armazena em cache as imagens em nós. Durante um pull de imagem, o ambiente de execução do contêiner só faz o download de camadas que ainda não estão presentes no cache. Para maximizar a eficácia desse mecanismo de armazenamento em cache e minimizar os tempos de extração de imagens, estruture o Dockerfile para colocar partes da imagem que mudam com frequência (como o código do aplicativo) no final do arquivo e use imagens de base menores.
5. Ative o streaming de imagens. Esse recurso pode acelerar a inicialização do pod e os downloads de imagens. Para saber mais, consulte Usar o streaming de imagem para extrair imagens de contêiner.
6. Verifique se a conta de serviço padrão tem as permissões necessárias. Modificar papéis atribuídos à conta de serviço padrão pode interromper cargas de trabalho, incluindo transferências de imagem. Para mais conselhos, consulte Identificar clusters com contas de serviço de nó que não têm permissões essenciais.
7. Examine as configurações de proxy. Se um proxy existir entre o cluster do GKE e um repositório não gerenciado pelo Google, isso poderá causar latência.
8. Verifique se há softwares de terceiros. Alguns softwares de terceiros podem interferir na extração de imagens. Investigue se alguma ferramenta instalada recentemente pode estar causando conflitos.

Verificar se o manifesto de imagem usa a arquitetura correta

Se a imagem que você está tentando extrair foi criada para uma arquitetura de computador diferente da usada pelos pools de nós, o extração de imagem vai falhar.

Para confirmar se o manifesto da imagem usa a arquitetura correta, siga estas etapas:

1. Para confirmar qual arquitetura sua imagem usa, confira o manifesto dela. Por exemplo, para conferir uma imagem do Docker, execute o seguinte comando:

   docker manifest inspect --verbose IMAGE_NAME
   

   Substitua IMAGE_NAME pelo nome da imagem que você quer ver.

   O resultado será assim:

   ...
   "Platform": {
             "architecture": "amd64",
             "os": "linux"
     }
   ...
   

   Neste exemplo, a arquitetura com suporte é amd64.

2. Confira o tipo de máquina usado pelos pools de nós:

   gcloud container node-pools list --cluster CLUSTER_NAME --location LOCATION
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster em que o pod com erros de extração de imagem é executado.
   • LOCATION: a zona ou região do Compute Engine em que o nó foi criado. Por exemplo, us-central1-a ou us-central1.

   O resultado será assim:

   NAME: example-node-pool
   MACHINE_TYPE: e2-standard-2
   DISK_SIZE_GB: 100
   NODE_VERSION: 1.30.8-gke.1162000
   

   Neste exemplo, o tipo de máquina é e2-standard-2.

3. Compare os valores nos campos architecture e MACHINE_TYPE e verifique se ambos são compatíveis. Por exemplo, se a imagem tiver uma arquitetura amd64, ela será compatível com um pool de nós que usa e2-standard-2 como tipo de máquina. No entanto, se o pool de nós usar t2a-standard-1 (um tipo de máquina baseado em Arm), esse tipo de máquina vai causar uma falha.

4. Se a arquitetura da imagem não for compatível com o tipo de máquina do pool de nós, recrie a imagem para direcionar a arquitetura necessária.

Verificar a compatibilidade da versão do esquema de imagem

O uso do containerd 2.0 com uma imagem do esquema do Docker v1 faz com que os downloads de imagem falhem porque o containerd 2.0 removeu o suporte para downloads de imagens do esquema 1 do Docker no GKE 1.33. Quando esse problema é a causa da falha de extração da imagem, você pode receber a seguinte mensagem de erro:

Failed to get converter for "IMAGE_ADDRESS": Pulling Schema 1 images have been deprecated and disabled by default since containerd v2.0. As a workaround you may set an environment variable `CONTAINERD_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE=1`, but this will be completely removed in containerd v2.1.

Para resolver esse problema, identifique e migre essas imagens seguindo as instruções em Migrar de imagens do esquema 1 do Docker.

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.