Resolva problemas com a obtenção de imagens

Quando os contentores não são iniciados no Google Kubernetes Engine (GKE), pode ver estados de pods como ErrImagePull ou ImagePullBackOff. A causa destes estados é, muitas vezes, um problema com o processo de obtenção de imagens, em que o Kubernetes tenta obter a imagem do contentor a partir de um registo. Uma falha neste processo pode impedir o início das suas apps ou causar atrasos na implementação.

Use esta página para diagnosticar e resolver as causas mais comuns de falhas de obtenção de imagens:

• Definições de autenticação: o seu cluster não tem as autorizações necessárias para aceder ao registo de imagens de contentores.
• Conetividade de rede: o cluster não consegue estabelecer ligação ao registo 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 registo: o nome ou a etiqueta da imagem especificada está incorreta, a imagem foi eliminada ou o registo não está disponível.
• Limitações de desempenho: o tamanho grande da imagem, a E/S de disco lenta ou o congestionamento da rede podem causar transferências lentas ou tempos limite.
• Arquitetura de imagem incompatível: a imagem foi criada para uma arquitetura de CPU diferente da do seu conjunto de nós do GKE.
• Versões de esquemas incompatíveis: pode estar a usar o containerd 2.0 ou posterior com um esquema Docker v1, que não é suportado.

Estas informações são importantes para os programadores de aplicações que precisam de resolver falhas de implementação verificando os nomes, as etiquetas e as arquiteturas das imagens nos respetivos manifestos. Também ajuda os administradores e os operadores da plataforma a depurar problemas ao nível do cluster, como configurar credenciais de obtenção de imagens para registos privados ou corrigir políticas de rede que bloqueiam o acesso a um registo de imagens. Para mais informações sobre as funções comuns e as tarefas de exemplo a que fazemos referência no Trusted Cloud by S3NS conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.

Se já viu uma mensagem de evento específica, pesquise esta página para encontrar a mensagem e siga os passos de resolução de problemas indicados. Se não tiver visto uma mensagem, siga as secções seguintes pela ordem apresentada. Se o problema persistir, contacte o apoio ao cliente da nuvem.

Compreenda as extrações de imagens

Antes de começar a resolver problemas, é útil saber um pouco mais sobre o ciclo de vida de uma imagem e onde pode alojar as suas imagens.

Ciclo de vida das imagens

Quando cria um Pod, o kubelet recebe a definição do Pod, que inclui a especificação da imagem. O kubelet precisa desta imagem para poder executar um contentor com base na imagem. Antes de extrair a imagem, o kubelet verifica o tempo de execução do contentor para ver se a imagem está presente. O kubelet também verifica a política de obtenção de imagens do pod. Se a imagem não estiver na cache do tempo de execução do contentor ou se a política de obtenção de imagens o exigir, o kubelet direciona o tempo de execução do contentor (containerd) para obter a imagem especificada do registo. Uma obtenção de imagem com falha impede o início do contentor no pod.

Após uma obtenção de imagem bem-sucedida, o tempo de execução do contentor descomprime a imagem para criar um sistema de ficheiros base só de leitura para o contentor. O tempo de execução do contentor armazena esta imagem e a imagem permanece presente enquanto os contentores em execução fizerem referência à mesma. Se nenhum contentor em execução fizer referência a uma imagem, a imagem torna-se elegível para a recolha de lixo e o kubelet acaba por removê-la.

Opções de alojamento de imagens

Recomendamos que use uma das seguintes opções para alojar as suas imagens:

• Artifact Registry: o Artifact Registry é o gestor de pacotes totalmente gerido da Google. O Artifact Registry integra-se estreitamente com outros serviços e oferece um controlo de acesso detalhado. Trusted Cloud by S3NSPara saber mais, consulte o artigo Trabalhe com imagens de contentores na documentação do Artifact Registry.

• Base de dados de registo alojada por si: uma base de dados de registo alojada por si oferece-lhe mais controlo, mas também requer que a faça a gestão. Considere esta opção se tiver necessidades específicas de conformidade ou segurança que o Artifact Registry não consegue satisfazer.

Diagnostique a falha de obtenção de imagens

Para diagnosticar falhas de obtenção de imagens, faça as investigações detalhadas nas secções seguintes:

1. Veja o estado e os eventos do Pod.
2. Compreenda o significado do estado.
3. Use mensagens de eventos para encontrar a causa da falha de obtenção de imagens.
4. Ver registos do Explorador de registos.

Veja o estado e os eventos do pod

Para ajudar a verificar se a obtenção de uma imagem falhou, o GKE regista os seguintes estados para os pods:

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

ImagePullBackOff e ErrImagePull são os mais comuns destes estados.

Além destes estados, os eventos do Kubernetes ajudam a encontrar a causa das falhas de obtenção de imagens.

Para confirmar se a obtenção de imagens está a falhar, verifique se existem mensagens de estado e, em seguida, leia as mensagens de eventos selecionando uma das seguintes opções:

Compreenda o significado do estado

Para compreender melhor o significado dos diferentes estados, consulte as seguintes descrições:

• ImagePullBackOff: o kubelet não conseguiu extrair a imagem, mas vai continuar a tentar com um atraso crescente (ou recuo) de até cinco minutos.
• ErrImagePull: um erro geral não recuperável durante o processo de obtenção de imagens.
• ImageInspectError: o tempo de execução do contentor encontrou um problema ao tentar inspecionar a imagem do contentor.
• InvalidImageName: o nome da imagem do contentor especificado na sua definição de pod não é válido.
• RegistryUnavailable: o registo não está acessível. Normalmente, trata-se de um problema de conetividade de rede.
• SignatureValidationFailed: não foi possível validar a assinatura digital da imagem do contentor.

Use mensagens de eventos para encontrar a causa da falha de obtenção de imagens

A tabela seguinte apresenta mensagens de eventos relacionadas com falhas de obtenção de imagens e os passos de resolução de problemas que deve seguir se encontrar uma destas mensagens.

As mensagens relacionadas com falhas de obtenção de imagens têm frequentemente 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: a morada completa da imagem. Por exemplo, us-west1-docker.pkg.dev/my-project/my-repo/test:staging.
• CODE: um código de erro associado à mensagem de registo. Por exemplo, NotFound ou Unknown.

Algumas causas de falhas de obtenção de imagens não têm uma mensagem de evento relacionada. Se não vir nenhuma das mensagens de eventos na tabela seguinte, mas continuar a ter problemas de obtenção de imagens, recomendamos que continue a ler o resto da página.

Veja os registos do Explorador de registos

Para examinar eventos de obtenção de imagens anteriores ou correlacionar falhas de obtenção de imagens com a atividade de outros componentes, veja os registos com o Explorador de registos:

1. Na Trusted Cloud consola, aceda à página Explorador de registos.

   Aceda ao Explorador de registos

2. No painel de consultas, introduza 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 no qual o pod com erros de obtenção de imagens é executado.

3. Clique em Executar consulta e reveja os resultados.

Investigue as definições de autenticação

As secções seguintes ajudam a verificar se o seu ambiente do GKE tem as definições de autenticação adequadas para extrair imagens do repositório.

Para verificar se tem problemas de autenticação que causam um problema de obtenção de imagens, faça as investigações detalhadas nas secções seguintes:

1. Valide o acesso à imagem.
2. Valide a configuração de imagePullSecret e a especificação de implementação.
3. Verifique o estado ativo da conta de serviço do nó.
4. Valide o âmbito de acesso do nó para o repositório privado do Artifact Registry
5. Valide as definições dos VPC Service Controls para aceder ao Artifact Registry.

Valide o acesso à imagem

Se encontrar um 403 Forbidden erro de obtenção de imagens, verifique se os componentes necessários podem aceder à imagem do contentor.

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

Valide a configuração de imagePullSecret e a especificação de implementação

Se usar um imagePullSecret, certifique-se de que criou um segredo que contém as credenciais de autenticação para extrair imagens e que todas as implementações especificam o segredo que definiu. Para mais informações, consulte o artigo Especificar imagePullSecrets num pod na documentação do Kubernetes.

Valide o estado ativo da conta de serviço do nó

Se encontrar um 401 Unauthorized erro de obtenção de imagens, verifique se a conta de serviço do nó está ativa. Mesmo que as autorizações estejam configuradas corretamente, uma conta desativada manifesta este erro. Para validar o estado ativo da conta de serviço do nó, selecione uma das seguintes opções:

Se a conta de serviço estiver desativada, ative a conta de serviço do nó.

Valide o âmbito de acesso do nó para o repositório privado do Artifact Registry

Se armazenar a imagem do contentor num repositório privado do Artifact Registry, o nó pode não ter o âmbito de acesso correto. Quando isto acontece, pode ver um erro de obtenção de imagens 401 Unauthorized.

Para validar o âmbito de acesso e concedê-lo, se necessário, siga estes passos:

1. Identifique o nó que está a executar o pod:

   kubectl describe pod POD_NAME | grep "Node:"
   

   Substitua POD_NAME pelo nome do pod que tem uma falha de obtenção de imagens.

2. Verifique se o nó que identificou no passo anterior tem o âmbito de armazenamento correto:

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

   Substitua o seguinte:

   • NODE_NAME: o nome do nó que identificou no passo anterior.
   • COMPUTE_ZONE: a zona do Compute Engine à qual o nó pertence.

   A saída deve conter, pelo menos, um dos seguintes âmbitos 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 contiver um destes âmbitos, a obtenção da imagem falha.

3. Recrie o node pool ao qual o nó pertence com âmbito suficiente. Como não é possível modificar os nós existentes, tem de recriar o nó com o âmbito correto.

   Recomendamos que crie o conjunto de nós com o âmbito gke-default. Este âmbito fornece acesso aos seguintes âmbitos:

   • 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 âmbito gke-default não for adequado, conceda ao conjunto de nós o âmbito devstorage.read_only, que permite o acesso apenas para ler dados.

   gke-default

   Crie um node pool com o âmbito gke-default:

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

   Substitua o seguinte:

   • NODE_POOL_NAME: o nome do novo node pool.
   • CLUSTER_NAME: o nome do cluster existente.
   • CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.

   devstorage.read_only

   Crie um node pool com o âmbito 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 o seguinte:

   • NODE_POOL_NAME: o nome do novo node pool.
   • CLUSTER_NAME: o nome do cluster existente.
   • CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.

Valide as definições do VPC Service Controls para aceder ao Artifact Registry

Se usar os VPC Service Controls, certifique-se de que os perímetros de serviço permitem o acesso ao Artifact Registry. Para saber mais, consulte o artigo Proteja repositórios num perímetro de serviço na documentação do Artifact Registry.

Investigue a conetividade de rede

Durante uma obtenção de imagens, a conetividade de rede pode impedir a conclusão do processo.

Para verificar se os problemas de conetividade de rede estão a causar um problema de obtenção de imagens, faça as investigações detalhadas nas secções seguintes:

1. Investigue a resolução de DNS.
2. Investigue a configuração da firewall.
3. Investigue a conetividade à Internet dos pontos finais do registo externo.
4. Investigue se a ligação às APIs Google está a atingir o limite de tempo.

Investigue a resolução de DNS

Se vir um erro de obtenção de imagens server misbehaving, a resolução de DNS pode ser a causa da falha na obtenção de imagens.

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

1. Resolva problemas do servidor de metadados. O servidor de metadados do nó resolve todas as consultas de DNS. Quaisquer problemas que envolvam este servidor podem interromper a resolução de nomes, impedindo a ligação ao repositório e fazendo com que a obtenção da imagem falhe.
2. Se usar o Cloud DNS para a resolução de DNS, certifique-se de que as zonas privadas geridas, as zonas de encaminhamento, as zonas de peering e as políticas de resposta do Cloud DNS estão configuradas corretamente. As configurações incorretas nestas áreas podem interromper a resolução de DNS. Para saber mais sobre o Cloud DNS, consulte o artigo Usar o Cloud DNS para o GKE. Para obter aconselhamento sobre como resolver problemas do Cloud DNS no GKE, consulte o artigo Resolva problemas do Cloud DNS no GKE.
3. Se usar o kube-dns para a resolução de DNS, certifique-se de que está a funcionar corretamente. Para obter aconselhamento sobre a resolução de problemas do kube-dns, consulte o artigo Resolva problemas do kube-dns no GKE.
4. Se os nós do cluster não tiverem endereços IP externos (o que é comum se usar o isolamento de rede), ative o acesso privado à Google na sub-rede usada pelo cluster e certifique-se de que cumpre os requisitos de rede. Se usar a NAT na nuvem, Trusted Cloud by S3NS ativa automaticamente o Acesso privado do Google.

Investigue a configuração da firewall

Quando um problema com a firewall faz com que a obtenção de imagens falhe, pode ver a seguinte mensagem de erro:

Failed to start Download and install k8s binaries and configurations

Diagnostique problemas com a sua firewall

Se estiver a usar um cluster Standard e quiser confirmar se um problema com a sua firewall está a causar problemas com a obtenção de imagens, siga estes passos:

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

   gcloud compute ssh NODE_NAME --zone=ZONE_NAME
   

   Substitua o seguinte:

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

2. Envie os registos mais recentes dos serviços kube-node-installation.service e kube-node-configuration.service para ficheiros de texto denominados 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 estes registos não incluírem informações do momento em que o pedido de obtenção da imagem falhou, gere uma cópia completa dos registos:

   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. Reveja o conteúdo da pasta kube-node-installation_status.txtekube-node-configuration_status.txt e os ficheiros. Se vir i/o timeout no resultado, o problema é provavelmente com a sua firewall.

Resolva problemas com a configuração da firewall

Para resolver problemas com a firewall, experimente as seguintes soluções:

1. Identifique e resolva quaisquer regras de firewall que estejam a bloquear o tráfego de rede. Por exemplo, pode ter uma regra que bloqueie o tráfego para o registo que armazena a sua imagem.

   1. Aceda aos registos de fluxo da VPC:

      1. Na Trusted Cloud consola, aceda à página Explorador de registos.

         Aceda ao Explorador de registos

      2. No painel de consultas, introduza 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 o seguinte:

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

         Para saber mais, consulte o artigo Aceda aos registos de fluxo através de consultas na documentação da VPC.

   2. Se encontrar regras de firewall que estejam a bloquear 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 usar o isolamento de rede), ative o acesso privado à Google na sub-rede usada pelo cluster e certifique-se de que cumpre os requisitos de rede. Se usar a NAT na nuvem, Trusted Cloud by S3NS ativa automaticamente o Acesso privado do Google.

Investigue a conetividade à Internet dos pontos finais do registo externo

Se a configuração da sua rede direcionar o tráfego através de um ponto final de registo externo, esse ponto final pode não ter ligação à Internet. Quando o ponto final não tem acesso, a obtenção de imagens pode falhar e é apresentado um erro de obtenção de imagens i/o timeout.

Para verificar a conetividade de rede do ponto final do registo externo ao registo, use ping ou traceroute:

ping REGISTRY_ENDPOINT

Ou

traceroute REGISTRY_ENDPOINT

Substitua REGISTRY_ENDPOINT pelo ponto final do registo. Este valor pode ser um nome de anfitrião ou um endereço IP.

Se encontrar um erro com a conetividade, reveja as rotas da VPC:

1. Na Trusted Cloud consola, aceda a Rotas.

   Aceda a Trajetos

2. Reveja a coluna Prioridade e certifique-se de que o caminho com a prioridade mais elevada está a direcionar para uma origem que tem acesso ao registo. As rotas com valores mais baixos têm precedência.

Investigue se a ligação às APIs Google está a atingir o limite de tempo

Se usar o isolamento de rede, pode ocorrer um erro em que a ligação às APIs e aos serviços Google expira, o que leva a um erro de obtenção de imagens i/o timeout.

Este erro ocorre porque os seus nós não conseguiram alcançar uma das seguintes APIs quando tentaram obter imagens do registo:

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

Para se certificar de que consegue estabelecer ligação às APIs necessárias, experimente as seguintes soluções:

1. Ative o acesso privado do Google. Os nós sem endereços IP externos precisam de acesso privado à Google para alcançar os endereços IP externos das APIs e dos serviços Google.
2. Use um domínio suportado.

3. Reveja as suas políticas de firewall:

   1. Na Trusted Cloud consola, aceda a Políticas de firewall.

      Aceder a Políticas de firewall

   2. Verifique se 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 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 à Google e o acesso restrito à Google, respetivamente. O tráfego TCP na porta 443 para estes intervalos destina-se ao acesso a APIs e serviços Google.

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

4. Se usar o Artifact Registry, certifique-se de que o seu ambiente cumpre os 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. Na Trusted Cloud consola, aceda a Redes VPC.

      Aceda a redes de VPC

   2. Na coluna Nome, clique em predefinição.

   3. Na página de detalhes da rede VPC, clique no separador Rotas.

   4. Reveja a tabela de rotas.

      Se a sua rede VPC contiver uma rota predefinida (destino 0.0.0.0/0 ou ::0/0) e o próximo salto dessa rota for o gateway de Internet predefinido (predefinição de rede), use essa rota para que os VIPs acedam às APIs e aos serviços Google.

      Se substituiu uma rota predefinida por uma rota personalizada cujo próximo salto não é a gateway de Internet predefinida, cumpra os requisitos de encaminhamento para as APIs e os serviços Google usando o encaminhamento personalizado.

Investigue o motivo pelo qual o kubelet não consegue encontrar a sua imagem

Quando o kubelet não consegue encontrar a sua imagem, pode ver um erro image not found e ter falhas na obtenção de imagens.

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

1. Reveja o manifesto do seu pod e certifique-se de que o nome da imagem e a etiqueta da imagem estão escritos corretamente. Quaisquer erros de ortografia ou formatação fazem com que a obtenção da imagem falhe.
2. Verifique se a imagem ainda existe no registo no qual a armazenou. Se a imagem tiver um caminho de registo completo, verifique se existe no registo do Docker que usa. Se fornecer apenas o nome da imagem, verifique o registo do Docker Hub.
3. Se o cluster usar o isolamento de rede, experimente as seguintes soluções:
   1. Ative o acesso privado do Google.
   2. Verifique se o perímetro de serviço está configurado corretamente.

Investigue o motivo pelo qual existem tempos limite de obtenção de imagens ou obtenções de imagens lentas

Se usar uma imagem muito grande para a sua carga de trabalho do GKE, o pedido de obtenção de imagens pode exceder o tempo limite e causar um erro context cancelled. Embora as imagens não tenham um limite de tamanho definido, o erro context cancelled indica frequentemente que o tamanho da imagem é a causa.

Também pode reparar que as obtenções de imagens não falham, mas demoram muito mais tempo do que o habitual. Se quiser ter uma base de referência dos seus tempos de obtenção de imagens normais, reveja a entrada do registo Successfully pulled image. Por exemplo, a seguinte mensagem de registo mostra que a obtenção da imagem demorou 30,313387996 segundos:

Successfully pulled image "IMAGE_ADDRESS" in 30.313387996s.

Os limites de tempo e as obtenções lentas de imagens partilham muitas das mesmas causas. Para resolver estes problemas, experimente as seguintes soluções:

1. Verifique se existem interrupções. Se só reparou neste problema durante um período específico, verifique se houve alguma Trusted Cloud by S3NS indisponibilidade.
2. Verifique o desempenho do disco. A lentidão da E/S do disco pode aumentar os tempos de obtenção de imagens. Pondere atualizar para discos persistentes com SSDs (pd-ssd) ou usar discos maiores para melhorar o desempenho. Para mais sugestões, consulte o artigo Resolva problemas de desempenho do disco.
3. Reduza o tamanho da imagem. Por exemplo, pode mover alguns dados das imagens de contentores para volumes persistentes.
4. Tire partido do armazenamento em cache de imagens para tempos de arranque rápidos dos pods. O GKE armazena imagens em cache nos nós. Durante uma obtenção de imagens, o tempo de execução do contentor transfere apenas as camadas que ainda não estão presentes na cache. Para maximizar a eficácia deste mecanismo de colocação em cache e minimizar os tempos de obtenção de imagens, estruture o seu Dockerfile de forma a colocar as partes da imagem que mudam com frequência (como o código da sua aplicação) no final do ficheiro e use imagens base mais pequenas.
5. Ative o streaming de imagens. Esta funcionalidade pode acelerar o início do pod e as transferências de imagens. Para saber mais, consulte o artigo Use o streaming de imagens para extrair imagens de contentores.
6. Certifique-se de que a conta de serviço predefinida tem as autorizações necessárias. A modificação das funções atribuídas à conta de serviço predefinida pode interromper as cargas de trabalho, incluindo as obtenções de imagens. Para mais sugestões, consulte o artigo Identifique clusters com contas de serviço de nós que não têm autorizações críticas.
7. Examine as configurações de proxy. Se existir um proxy entre o seu cluster do GKE e um repositório não gerido pela Google, pode introduzir latência.
8. Verifique o software de terceiros. Alguns softwares de terceiros podem interferir com as transferências de imagens. Investigue se alguma ferramenta instalada recentemente pode estar a causar conflitos.

Verifique se o manifesto de imagens usa a arquitetura correta

Se a imagem que está a tentar extrair tiver sido criada para uma arquitetura de computador diferente da usada pelos seus conjuntos de nós, a extração da imagem falha.

Para confirmar se o manifesto de imagens usa a arquitetura correta, siga estes passos:

1. Para confirmar que arquitetura a sua imagem usa, veja o manifesto da imagem. 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 quer ver.

   O resultado é semelhante ao seguinte:

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

   Neste exemplo, a arquitetura suportada é amd64.

2. Reveja o tipo de máquina que os seus conjuntos de nós usam:

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

   Substitua o seguinte:

   • CLUSTER_NAME: o nome do cluster no qual o pod com erros de obtenção de imagens é executado.
   • CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.

   O resultado é semelhante ao seguinte:

   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 certifique-se de que ambos os valores são compatíveis. Por exemplo, se a imagem tiver uma arquitetura amd64, é compatível com um conjunto de nós que usa e2-standard-2 como tipo de máquina. No entanto, se o conjunto de nós usasse um tipo de máquina baseado em Arm, este tipo de máquina causaria uma falha.t2a-standard-1

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

Valide a compatibilidade da versão do esquema de imagens

A utilização do containerd 2.0 com uma imagem de esquema do Docker v1 faz com que as obtenções de imagens falhem, porque o containerd 2.0 removeu o suporte para a obtenção de imagens do esquema do Docker 1 no GKE 1.33. Quando este problema é a causa da falha na obtenção da imagem, 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 este problema, identifique e migre estas imagens seguindo as instruções em Migre de imagens do esquema 1 do Docker.

O que se segue?

• Se não conseguir encontrar uma solução para o seu problema na documentação, consulte a secção Obtenha apoio técnico para receber mais ajuda, incluindo aconselhamento sobre os seguintes tópicos:

  • Abrindo um registo de apoio técnico através do contacto com o Cloud Customer Care.
  • Receber apoio técnico da comunidade fazendo perguntas no StackOverflow e usando a etiqueta google-kubernetes-engine para pesquisar problemas semelhantes. Também pode juntar-se ao #kubernetes-engine canal do Slack para receber mais apoio técnico da comunidade.
  • Abrir erros ou pedidos de funcionalidades através do rastreador de problemas público.