Resolver problemas de extração de imagens

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

Esta página é destinada a desenvolvedores de aplicativos que querem garantir a implantação bem-sucedida dos apps e a administradores e operadores de plataforma que querem entender a causa raiz das falhas de extração de imagens e verificar a configuração da plataforma. Para saber mais sobre papéis comuns e tarefas de exemplo 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 imagens é como o Kubernetes e, portanto, o GKE recuperam imagens de contêiner de um registro. Quando um pull de imagem falha, você pode notar lentidão no app ou que ele não está funcionando de jeito nenhum.

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

• Configurações de autenticação: seu cluster não tem as permissões necessárias para acessar o registro de imagens de 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 isolamento de rede.
• Imagem não encontrada no registro: o nome ou a tag da imagem especificada está incorreta, a imagem foi excluída ou o registro não está disponível.
• Limitações de desempenho: tamanho grande da imagem, E/S de disco lenta ou congestionamento da rede podem causar extrações lentas ou tempos limite.
• 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 é compatível.

Se você já viu uma mensagem de evento específica, pesquise nesta página a mensagem e siga as etapas de solução de problemas listadas. Se você não recebeu uma mensagem, siga as seções abaixo em ordem. Se o problema persistir, entre em contato com o atendimento ao cliente do Cloud.

Entender os pull de imagens

Antes de começar a resolver 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 dele, 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 imagens 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 imagens exigir isso, o kubelet vai direcionar o ambiente de execução do contêiner (containerd) para extrair a imagem especificada do registro. Uma extração de imagem com falha impede que o contêiner no pod seja iniciado.

Após uma extração de imagem bem-sucedida, 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 coleta 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 Artifact Registry é o gerenciador de pacotes totalmente gerenciado do Google. O Artifact Registry se integra perfeitamente a outros serviços do 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: oferece mais controle, mas exige que você gerencie o registro. Considere essa opção se você tiver necessidades específicas de conformidade ou segurança que o Artifact Registry não pode atender.

Diagnosticar falha na extração de imagem

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

1. Confira o status e os eventos do pod.
2. Entenda o significado do status.
3. Use mensagens de eventos para encontrar a causa da falha no pull da imagem.
4. Confira os registros da Análise de registros.

Ver o status e os eventos do pod

Para ajudar você a verificar se uma extração de imagem falhou, o GKE registra os seguintes status para pods:

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

ImagePullBackOff e ErrImagePull são os mais comuns.

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

Para confirmar se o pull da imagem está falhando, 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 descrições a seguir:

• ImagePullBackOff: o kubelet não conseguiu extrair a imagem, mas vai continuar tentando com um atraso crescente (ou backoff) de até cinco minutos.
• ErrImagePull: um erro geral e não recuperável durante o processo de extração da 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. Esse geralmente é um problema de conectividade de rede.
• SignatureValidationFailed: não foi possível verificar a assinatura digital da imagem do contêiner.

Usar mensagens de eventos para encontrar a causa da falha de extração de imagens

A tabela a seguir lista as mensagens de eventos relacionadas a falhas de extração de imagens 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":

Essa 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 imagens, recomendamos que continue lendo o restante da página.

Ver registros da Análise de registros

Para examinar eventos históricos de extração de imagens ou correlacionar falhas de extração de imagens com outras atividades de componentes, consulte os registros com a Análise de registros:

1. No console Google Cloud , acesse a página 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 está sendo executado.

3. Clique em Executar consulta e analise 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, faça 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 da implantação.
3. Verifique o status ativo da conta de serviço do nó.
4. Verificar o escopo de acesso do nó para o repositório particular do Artifact Registry
5. 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 exigido varia dependendo do 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 da 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.

Verificar o status ativo da conta de serviço do nó

Se você encontrar um erro de extração de imagem 401 Unauthorized, verifique se a conta de serviço do nó está ativa. Mesmo que as permissões estejam configuradas corretamente, uma conta desativada vai apresentar esse erro. Para verificar o status ativo da conta de serviço do nó, selecione uma das seguintes opções:

Se a conta de serviço estiver desativada, ative-a.

Verificar o escopo de acesso do nó para o repositório particular do Artifact Registry

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

Para verificar o escopo de acesso e conceder 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 está com falha no pull da 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 da 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, você precisa recriar o nó com o escopo correto.

   Recomendamos que você crie o pool de nós com o escopo gke-default. Esse escopo fornece 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 somente a dados de leitura.

   gke-default

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

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --scopes="gke-default"
   

   Substitua:

   • NODE_POOL_NAME: o nome do novo pool de nós.
   • CLUSTER_NAME: o nome do cluster atual.
   • CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.

   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 \
       --location=CONTROL_PLANE_LOCATION \
       --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.
   • CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.

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 um 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, faça as investigações detalhadas nas seções a seguir:

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

Investigar a resolução de DNS

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

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

1. Resolva problemas do 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 falha no pull da imagem.
2. Se você usa o Cloud DNS para resolução de DNS, verifique se as zonas particulares gerenciadas, as zonas de encaminhamento, as zonas 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 saber 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 dicas sobre como solucionar 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 externo (o que é comum se você usar 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, oGoogle Cloud ativa o Acesso privado do Google automaticamente.

Investigar a configuração do firewall

Quando um problema com o firewall causa falha na extração da imagem, a seguinte mensagem de erro pode aparecer:

Failed to start Download and install k8s binaries and configurations

Diagnosticar problemas com o firewall

Se você estiver usando um cluster do Standard e quiser confirmar se um problema com seu firewall está causando problemas com extrações de imagens, siga estas etapas:

1. Use SSH para se conectar ao nó que está com 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 de quando o pull da imagem falhou, gere uma cópia completa deles:

   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ê vir i/o timeout na saída, o problema provavelmente está no firewall.

Resolver problemas com a configuração do firewall

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

1. Identifique e resolva 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 Google Cloud , acesse a página 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 Google Cloud projeto.
         • 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 externo (o que é comum se você usar 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, oGoogle Cloud ativa o Acesso privado do Google automaticamente.

Investigar a conectividade de Internet dos endpoints de registro externos

Se a configuração de 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 da imagem pode falhar, e um erro de pull da imagem i/o timeout é exibido.

Para verificar a conectividade de rede do endpoint do registro externo com o 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, revise as rotas da VPC:

1. No console 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 tem acesso ao registro. Trajetos com valores menores têm precedência.

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

Se você usa o isolamento de rede, pode ocorrer um erro em que a conexão com as APIs e os serviços do Google atinge o tempo limite, resultando em 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ê pode se conectar às APIs necessárias, tente as seguintes soluções:

1. Ative o Acesso privado do Google. Os nós sem endereços IP externo precisam do Acesso privado do Google para alcançar os endereços IP externo das APIs e serviços do Google.
2. Use um domínio aceito.

3. Revise suas políticas de firewall:

   1. No console Google Cloud , acesse "Políticas de 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 de VPC configuradas:

   1. No console 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 tiver uma rota padrão (destino 0.0.0.0/0 ou ::0/0) e o próximo salto dessa rota for o gateway de Internet padrão (Padrão da 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.

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

Quando o kubelet não consegue encontrar sua imagem, um erro image not found pode aparecer, e o pull da imagem pode falhar.

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 a tag da imagem estão escritos corretamente. Qualquer erro de ortografia ou formatação faz com que a extração da 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 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.

Investigue por que há tempos limite de extração de imagens ou extrações lentas

Se você usar uma imagem muito grande para sua carga de trabalho do GKE, o comando de extração de imagem poderá atingir o tempo limite 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 extrações de imagens que não falham, mas demoram muito mais do que o normal. Se você quiser ter uma visão geral dos seus tempos normais de extração de imagens, analise a entrada de registro Successfully pulled image. Por exemplo, a seguinte mensagem de registro mostra que a extração da imagem levou 30,313387996 segundos:

Successfully pulled image "IMAGE_ADDRESS" in 30.313387996s.

Os tempos limite e as extrações lentas de imagens compartilham muitas das mesmas causas. Para resolver esses problemas, tente o seguinte:

1. Verifique se há interrupções. Se você só notou esse problema durante um período específico, verifique se houve alguma Google Cloud interrupção.
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 dicas, consulte Resolver problemas de desempenho do disco.
3. Reduza o tamanho da imagem. Por exemplo, é possível mover alguns dados das imagens de contêiner para volumes permanentes.
4. Aproveite o cache de imagens para tempos de inicialização rápidos do pod. O GKE armazena imagens em cache nos 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 seu Dockerfile para colocar as 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. A modificação de papéis atribuídos à conta de serviço padrão pode interromper cargas de trabalho, incluindo extrações de imagens. Para mais orientações, consulte Identificar clusters com contas de serviço de nós que não têm permissões críticas.
7. Examine as configurações de proxy. Se houver um proxy entre o cluster do GKE e um repositório gerenciado que não é do Google, isso pode causar latência.
8. Verifique softwares de terceiros. Alguns softwares de terceiros podem interferir no puxão de imagens. Investigue se alguma ferramenta instalada recentemente pode estar causando conflitos.

Verifique se o manifesto da imagem usa a arquitetura certa

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

Para confirmar se o manifesto de imagem usa a arquitetura certa, siga estas etapas:

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

   docker manifest inspect --verbose IMAGE_NAME
   

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

   O resultado será assim:

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

   Neste exemplo, a arquitetura compatível é amd64.

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

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

   Substitua:

   • CLUSTER_NAME: o nome do cluster em que o pod com erros de extração de imagem é executado.
   • CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.

   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 eles 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 usasse t2a-standard-1 (um tipo de máquina baseado em Arm), isso causaria 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 v1 do Docker faz com que os pull de imagens falhem porque o containerd 2.0 removeu o suporte para pull de imagens do esquema 1 do Docker no GKE 1.33. Quando esse problema é a causa da falha no pull da imagem, você pode ver 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 Docker Schema 1.

A seguir

• Se você não encontrar uma solução para seu problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos:

  • Abrir um caso de suporte entrando em contato com o Cloud Customer Care.
  • Receber suporte da comunidade fazendo perguntas no StackOverflow e usando a tag google-kubernetes-engine para pesquisar problemas semelhantes. Você também pode participar do canal do Slack #kubernetes-engine para receber mais suporte da comunidade.
  • Abrir bugs ou solicitações de recursos usando o Issue Tracker público.