Resolva problemas de isolamento da rede no GKE

Esta página mostra-lhe como resolver problemas com o isolamento de rede do Google Kubernetes Engine (GKE).

O cluster do GKE não está a ser executado

A eliminação das regras de firewall que permitem o tráfego de entrada do plano de controlo do cluster para os nós na porta 10250 ou a eliminação da rota predefinida para o gateway de Internet predefinido faz com que um cluster deixe de funcionar. Se eliminar a rota predefinida, tem de garantir que o tráfego para os serviços necessários é encaminhado.Trusted Cloud Para mais informações, consulte o artigo sobre o encaminhamento personalizado.

Foi excedido o limite de tempo ao criar um cluster

Sintomas
Os clusters criados na versão 1.28 ou anterior com nós privados requerem uma rota de intercâmbio entre VPCs. No entanto, só pode ocorrer uma operação de peering de cada vez. Se tentar criar vários clusters com as características anteriores em simultâneo, a criação de clusters pode exceder o limite de tempo.
Resolução

Use uma das seguintes soluções:

  • Crie clusters na versão 1.28 ou anterior em série para que as rotas de peering de VPC já existam para cada cluster subsequente sem um ponto final externo. A tentativa de criar um único cluster também pode atingir o limite de tempo se houver operações em execução na sua VPC.

  • Crie clusters na versão 1.29 ou posterior.

A ligação de intercâmbio da rede da VPC é eliminada acidentalmente

Sintomas

Quando elimina acidentalmente uma ligação de interligação de redes VPC, o cluster entra num estado de reparação e todos os nós apresentam o estado UNKNOWN. Não vai poder realizar nenhuma operação no cluster, uma vez que a acessibilidade ao plano de controlo está desligada. Quando inspeciona o plano de controlo, os registos apresentam um erro semelhante ao seguinte:

error checking if node NODE_NAME is shutdown: unimplemented
Potenciais causas

Eliminou acidentalmente a ligação de intercâmbio de rede da VPC.

Resolução

  1. Crie um novo cluster do GKE com uma versão anterior à mudança do PSC e às respetivas configurações específicas. Esta ação é necessária para forçar a recriação da ligação de peering de VPC, o que restaura o funcionamento normal do cluster antigo.
    • Use as seguintes configurações específicas para o novo cluster:
      • Canal de lançamento: alargado
      • Versão do cluster: uma versão anterior a 1.29, como 1.28.15-gke.2403000
      • CIDR IPv4 principal: um intervalo de endereços IP específico, como --master-ipv4-cidr=172.16.0.192/28
  2. Monitorize o estado do cluster original.
    • Depois de o novo cluster ser criado (e, por conseguinte, o peering de VPC ser restabelecido), o cluster original deve recuperar do estado de reparação e os respetivos nós devem voltar ao estado Ready.
  3. Elimine o cluster do GKE criado temporariamente.
    • Depois de o cluster original ser totalmente restaurado e funcionar normalmente, pode eliminar o cluster do GKE criado temporariamente.

O ponto final do Private Service Connect e a regra de encaminhamento são eliminados acidentalmente

Sintomas

Quando elimina acidentalmente um ponto final ou uma regra de encaminhamento do Private Service Connect, o cluster entra num estado de reparação e todos os nós apresentam o estado UNKNOWN. Não vai poder realizar nenhuma operação no cluster, uma vez que o acesso ao plano de controlo está desligado. Quando inspeciona o plano de controlo, os registos apresentam um erro semelhante ao seguinte:

error checking if node NODE_NAME is shutdown: unimplemented
Potenciais causas

Eliminou acidentalmente o ponto final do Private Service Connect ou a regra de encaminhamento. Ambos os recursos têm o nome gke-[cluster-name]-[cluster-hash:8]-[uuid:8]-pe e permitem que o plano de controlo e os nós se liguem de forma privada.

Resolução

Rode o endereço IP do plano de controlo.

O cluster sobrepõe-se a um par ativo

Sintomas

A tentativa de criar um cluster sem um ponto final externo devolve um erro semelhante ao seguinte:

Google Compute Engine: An IP range in the peer network overlaps with an IP
range in an active peer of the local network.
Potenciais causas

Escolheu um CIDR do plano de controlo sobreposto.

Resolução

Use uma das seguintes soluções:

  • Elimine e recrie o cluster com um CIDR do plano de controlo diferente.
  • Recrie o cluster na versão 1.29 e inclua a flag --enable-private-nodes.

Não é possível alcançar o plano de controlo de um cluster sem um ponto final externo

Aumente a probabilidade de o plano de controlo do cluster estar acessível implementando qualquer uma das configurações de acesso ao ponto final do cluster. Para mais informações, consulte o artigo sobre o acesso a pontos finais de cluster.

Sintomas

Depois de criar um cluster sem um ponto final externo, a tentativa de executar comandos kubectl no cluster devolve um erro semelhante a um dos seguintes:

Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection
timed out.

Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
Potenciais causas

kubectl não consegue comunicar com o plano de controlo do cluster.

Resolução

Use uma das seguintes soluções:

  • Ative o acesso DNS para uma forma simplificada de aceder ao seu cluster de forma segura. Para mais informações, consulte o artigo Ponto final baseado em DNS.

  • Verifique se foram geradas credenciais para o cluster para o kubeconfig ou se o contexto correto está ativado. Para mais informações sobre como definir as credenciais do cluster, consulte o artigo Gere uma entrada kubeconfig.

  • Verifique se o acesso ao plano de controlo através do respetivo endereço IP externo é permitido. A desativação do acesso externo ao painel de controlo do cluster isola o cluster da Internet. Com esta configuração, apenas os intervalos CIDR da rede interna autorizados ou a rede reservada têm acesso ao plano de controlo.

    1. Verifique se o endereço IP de origem está autorizado a alcançar o plano de controlo:

        gcloud container clusters describe CLUSTER_NAME \
      --format="value(controlPlaneEndpointsConfig.ipEndpointsConfig.authorizedNetworksConfig)"\
      --location=COMPUTE_LOCATION

      Substitua o seguinte:

      Se o seu endereço IP de origem não estiver autorizado, o resultado pode devolver um resultado vazio (apenas chavetas) ou intervalos CIDR que não incluem o seu endereço IP de origem

      cidrBlocks:
  cidrBlock: 10.XXX.X.XX/32
  displayName: jumphost
  cidrBlock: 35.XXX.XXX.XX/32
  displayName: cloud shell
enabled: true

    2. Adicione redes autorizadas para aceder ao plano de controlo.

  • Se executar o comando kubectl a partir de um ambiente no local ou de uma região diferente da localização do cluster, certifique-se de que o acesso global do ponto final privado do plano de controlo está ativado. Para mais informações, consulte o artigo Aceda através do endereço IP interno do plano de controlo a partir de qualquer região.

    1. Descreva o cluster para ver a resposta da configuração de acesso de controlo:

      gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --flatten "controlPlaneEndpointsConfig.ipEndpointsConfig.globalAccess"

      Substitua o seguinte:

      Um resultado bem-sucedido é semelhante ao seguinte:

        enabled: true

    2. Se for devolvido null, ative o acesso através do endereço IP interno do plano de controlo a partir de qualquer região.

Não é possível criar o cluster devido ao bloco CIDR IPv4 sobreposto

Sintomas

gcloud container clusters create devolve um erro semelhante ao seguinte:

The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network
10.128.0.0/20.
Potenciais causas

Especificou um bloco CIDR do plano de controlo que se sobrepõe a uma sub-rede existente na sua VPC.

Resolução

Especifique um bloco CIDR para --master-ipv4-cidr que não se sobreponha a uma sub-rede existente.

Não é possível criar o cluster porque o intervalo de serviços já está a ser usado por outro cluster

Sintomas

A tentativa de criar um cluster devolve um erro semelhante ao seguinte:

Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork
[SUBNET_NAME] is already used by another cluster.
Potenciais causas

As seguintes configurações podem causar este erro:

  • Escolheu um intervalo de serviços que ainda está a ser usado por outro cluster ou o cluster não foi eliminado.
  • Existia um cluster que usava esse intervalo de serviços que foi eliminado, mas os metadados dos intervalos secundários não foram limpos corretamente. Os intervalos secundários de um cluster do GKE são guardados nos metadados do Compute Engine e devem ser removidos assim que o cluster for eliminado. Mesmo quando um cluster é eliminado com êxito, os metadados podem não ser removidos.
Resolução

Siga estes passos:

  1. Verifique se o intervalo de serviços está a ser usado por um cluster existente. Pode usar o comando gcloud container clusters list com a flag filter para pesquisar o cluster. Se existir um cluster que use os intervalos de serviços, tem de eliminar esse cluster ou criar um novo intervalo de serviços.
  2. Se o intervalo de serviços não estiver a ser usado por um cluster existente, então remova manualmente a entrada de metadados que corresponda ao intervalo de serviços que quer usar.

Não é possível criar uma sub-rede

Sintomas

Quando tenta criar um cluster com uma sub-rede automática ou criar uma sub-rede personalizada, pode ocorrer qualquer um dos seguintes erros:

An IP range in the peer network overlaps
with an IP range in one of the active peers of the local network.

Error: Error waiting for creating GKE cluster: Invalid value for field
PrivateClusterConfig.MasterIpv4CidrBlock: x.x.x.x/28 conflicts with an
existing subnet in one of the peered VPCs.
Potenciais causas

O intervalo CIDR do plano de controlo que especificou sobrepõe-se a outro intervalo de IP no cluster. Este erro de criação de sub-rede também pode ocorrer se estiver a tentar reutilizar os CIDRs usados num cluster eliminado recentemente.master-ipv4-cidr

Resolução

Experimente usar um intervalo CIDR diferente.

Não é possível extrair a imagem do Docker Hub público

Sintomas

Um Pod em execução no seu cluster apresenta um aviso em kubectl describe:

Failed to pull image: rpc error: code = Unknown desc = Error response
from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled
while waiting for connection (Client.Timeout exceeded while awaiting
headers)
Potenciais causas

Os nós com endereços IP privados só precisam de configuração adicional para cumprir os requisitos de acesso à Internet. No entanto, os nós podem aceder a APIs e serviços, incluindo o Artifact Registry, se tiver ativado o acesso privado à Google e cumprido os respetivos requisitos de rede. Trusted Cloud

Resolução

Use uma das seguintes soluções:

  • Copie as imagens no cluster do Docker Hub para o Artifact Registry. Consulte o artigo Migrar contentores de um registo de terceiros para mais informações.

  • O GKE verifica automaticamente mirror.gcr.io se existem cópias em cache de imagens do Docker Hub acedidas com frequência.

  • Se tiver de extrair imagens do Docker Hub ou de outro repositório público, use o Cloud NAT ou um proxy baseado em instâncias que seja o destino de uma rota 0.0.0.0/0 estática.

Pedido API que faz com que o webhook de admissão exceda o tempo limite

Sintomas

Um pedido de API que aciona um webhook de admissão configurado para usar um serviço com uma porta targetPort diferente de 443 excede o tempo limite, o que faz com que o pedido falhe:

Error from server (Timeout): request did not complete within requested timeout 30s
Potenciais causas

Por predefinição, a firewall não permite ligações TCP a nós, exceto nas portas 443 (HTTPS) e 10250 (kubelet). Uma tentativa de webhook de admissão de comunicação com um pod numa porta diferente de 443 falha se não existir uma regra de firewall personalizada que permita o tráfego.

Resolução

Adicione uma regra de firewall para o seu exemplo de utilização específico.

Não é possível criar o cluster porque a verificação de funcionamento falhou

Sintomas

Depois de criar um cluster padrão com pools de nós privados, este fica bloqueado no passo de verificação de estado e comunica um erro semelhante a um dos seguintes:

All cluster resources were brought up, but only 0 of 2 have registered.

All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy
Potenciais causas

As seguintes configurações podem causar este erro:

  • Os nós do cluster não conseguem transferir binários necessários da API Cloud Storage (storage.googleapis.com).
  • Regras de firewall que restringem o tráfego de saída.
  • As autorizações de IAM da VPC partilhada estão incorretas.
  • O acesso privado da Google requer que configure o DNS para *.gcr.io.
Resolução

Use uma das seguintes soluções:

kubelet Failed to create pod sandbox

Sintomas

Depois de criar um cluster com nós privados, é comunicado um erro semelhante a um dos seguintes:

Warning  FailedCreatePodSandBox  12s (x9 over 4m)      kubelet  Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://registry.k8s.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Potenciais causas

O calico-node ou o Pod netd não conseguem aceder a *.gcr.io.

Resolução

Certifique-se de que concluiu a configuração necessária para o Container Registry ou o Artifact Registry.

Nós privados criados, mas não a juntarem-se ao cluster

Para clusters que usam nós apenas com endereços IP privados, muitas vezes quando usam o encaminhamento personalizado e os dispositivos de rede de terceiros na VPC, a rota predefinida (0.0.0.0/0) é redirecionada para o dispositivo em vez do gateway de Internet predefinido. Além da conetividade do plano de controlo, tem de garantir que os seguintes destinos estão acessíveis:

  • *.googleapis.com
  • *.gcr.io
  • gcr.io

Configure o acesso privado à Google para todos os três domínios. Esta prática recomendada permite que os novos nós sejam iniciados e se juntem ao cluster, mantendo o tráfego associado à Internet restrito.

As cargas de trabalho em clusters do GKE não conseguem aceder à Internet

Os pods executados em nós com endereços IP privados não podem aceder à Internet. Por exemplo, depois de executar o comando apt update a partir do Pod exec shell, é comunicado um erro semelhante ao seguinte:

0% [Connecting to deb.debian.org (199.232.98.132)] [Connecting to security.debian.org (151.101.130.132)]

Se o intervalo de endereços IP secundários da sub-rede usado para os pods no cluster não estiver configurado no gateway de NAT da nuvem, os pods não conseguem estabelecer ligação à Internet, uma vez que não têm um endereço IP externo configurado para o gateway de NAT da nuvem.

Certifique-se de que configura o gateway Cloud NAT para aplicar, pelo menos, os seguintes intervalos de endereços IP de sub-rede para a sub-rede que o cluster usa:

  • Intervalo de endereços IP principal da sub-rede (usado pelos nós)
  • Intervalo de endereços IP secundários da sub-rede usado para pods no cluster
  • Intervalo de endereços IP secundários da sub-rede usado para serviços no cluster

Para saber mais, consulte o artigo como adicionar o intervalo de IPs da sub-rede secundária usado para pods.

Não é possível desativar o acesso direto por IP para clusters públicos

Sintomas

Depois de desativar o ponto final do endereço IP, é apresentada uma mensagem de erro semelhante à seguinte:

Direct IP access can't be disabled for public clusters
Potenciais causas

O seu cluster usa a rede antiga.

Resolução

Migre os seus clusters para o Private Service Connect. Para mais informações sobre o estado da migração, contacte o apoio técnico.

Não é possível desativar o acesso direto por IP para clusters no meio da migração do PSC

Sintomas

Depois de desativar o ponto final do endereço IP, é apresentada uma mensagem de erro semelhante à seguinte:

Direct IP access can't be disabled for public clusters
Potenciais causas

O seu cluster usa a rede antiga.

Resolução

Use uma das seguintes soluções:

  • Recriar manualmente todos os conjuntos de nós numa versão diferente.
  • Aguarde até que o GKE atualize automaticamente os conjuntos de nós durante um evento de manutenção.

Não é possível ativar o ponto final interno do plano de controlo

Sintomas

Quando tenta ativar o ponto final interno do plano de controlo do cluster, vê mensagens de erro semelhantes às seguintes:

private_endpoint_enforcement_enabled can't be enabled when envoy is disabled

private_endpoint_enforcement_enabled is unsupported. Please upgrade to the minimum support version
Potenciais causas

O seu cluster tem de fazer a rotação do endereço IP ou uma atualização da versão.

Resolução

Use uma das seguintes soluções:

A criação de clusters falha quando as políticas da organização estão definidas

Sintomas

Quando tenta criar um cluster, é apresentada uma mensagem de erro semelhante à seguinte:

compute.disablePrivateServiceConnectCreationForConsumers violated for projects
Potenciais causas

O ponto final ou o back-end do cluster está bloqueado por uma política da organização do consumidor.

Resolução

Permita que as instâncias criem pontos finais com a restrição compute.restrictPrivateServiceConnectProducer concluindo os passos nas políticas da organização do lado do consumidor.

O ponto final do Private Service Connect pode ter fugas durante a eliminação do cluster

Sintomas

Depois de criar um cluster, pode ver um dos seguintes sintomas:

  • Não consegue ver um ponto final ligado em Private Service Connect no seu cluster baseado no Private Service Connect.

  • Não pode eliminar a sub-rede nem a rede VPC atribuída ao ponto final interno num cluster que usa o Private Service Connect. É apresentada uma mensagem de erro semelhante à seguinte:

    projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
Potenciais causas

Nos clusters do GKE que usam o Private Service Connect, o GKE implementa um ponto final do Private Service Connect através de uma regra de encaminhamento que atribui um endereço IP interno para aceder ao plano de controlo do cluster numa rede do plano de controlo. Para proteger a comunicação entre o plano de controlo e os nós através do Private Service Connect, o GKE mantém o ponto final invisível, e não o pode ver naTrusted Cloud consola nem na CLI gcloud.

Resolução

Para evitar a fuga do ponto final do Private Service Connect antes da eliminação do cluster, conclua os seguintes passos:

  1. Atribua o papel Kubernetes Engine Service Agent role à conta de serviço do GKE.
  2. Certifique-se de que as autorizações compute.forwardingRules.* e compute.addresses.* não são explicitamente recusadas à conta de serviço do GKE.

Se vir o ponto final do Private Service Connect divulgado, contacte o apoio técnico.

Não é possível analisar a rede autorizada do cluster

Sintomas

Não pode criar um cluster na versão 1.29 ou posterior. É apresentada uma mensagem de erro semelhante à seguinte:

Unable to parse cluster.master_ipv4_cidr "" into a valid IP address and mask
Potenciais causas

O seu Trusted Cloud projeto usa webhooks baseados em IP privado. Por conseguinte, não pode criar um cluster com o Private Service Connect. Em alternativa, o cluster usa o peering de rede VPC que analisa a flag master-ipv4-cidr.

Resolução

Use uma das seguintes soluções:

  • Continue a criar o cluster de intercâmbio de redes VPC e inclua o elemento master-ipv4-cidr para definir CIDRs válidos. Esta solução tem as seguintes limitações:

    • O sinalizador master-ipv4-cidr foi descontinuado na consola Trusted Cloud . Para atualizar esta flag, só pode usar a Google Cloud CLI ou o Terraform.
    • O intercâmbio da rede da VPC está descontinuado na versão 1.29 ou posterior do GKE.

  • Migre os seus webhooks baseados em IP privado concluindo os passos descritos em Limitações do Private Service Connect. Em seguida, contacte o apoio técnico para ativar a utilização de clusters com o Private Service Connect.

Não é possível definir o intervalo de endereços IP internos em clusters com nós públicos

Sintomas

Não pode definir um intervalo de endereços IP internos através da flag --master-ipv4-cidr. É apresentada uma mensagem de erro semelhante à seguinte:

ERROR: (gcloud.container.clusters.create) Cannot specify --master-ipv4-cidr
  without --enable-private-nodes
Potenciais causas

Está a definir um intervalo de endereços IP internos para o plano de controlo com a flag master-ipv4-cidr num cluster sem a flag enable-private-nodes ativada. Para criar um cluster com master-ipv4-cidr definido, tem de configurar o cluster para aprovisionar nós com endereços IP internos (nós privados) através da flag enable-private-nodes.

Resolução

Use uma das seguintes soluções:

  • Crie um cluster com o seguinte comando:

    gcloud container clusters create-auto CLUSTER_NAME \
    --enable-private-nodes \
    --master-ipv4-cidr CP_IP_RANGE

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster.
    • CLUSTER_NAME: o intervalo de endereços IP internos para o plano de controlo.

  • Atualize o cluster para aprovisionar nós apenas com endereços IP. Para saber mais, consulte o artigo Configure o seu cluster.

Não é possível agendar cargas de trabalho públicas em clusters do Autopilot

Sintomas
Nos clusters do Autopilot, se o seu cluster usar apenas nós privados, não pode agendar cargas de trabalho em pods públicos através do cloud.google.com/private-node=falsenodeSelector
.
Potenciais causas
A configuração da flag private-node definida como false no nodeSelector do pod só está disponível em clusters na versão 1.30.3 ou posterior.
Resolução
Atualize o cluster para a versão 1.30 ou posterior.

O acesso ao ponto final baseado em DNS está desativado

Sintomas

A tentativa de executar comandos kubectl no cluster devolve um erro semelhante ao seguinte:

couldn't get current server API group list:
control_plane_endpoints_config.dns_endpoint_config.allow_external_traffic is
disabled
Potenciais causas

O acesso baseado em DNS foi desativado no seu cluster.

Resolução

Ative o acesso ao plano de controlo através do ponto final baseado em DNS do plano de controlo. Para saber mais, consulte o artigo Modifique o acesso ao plano de controlo.

Os nós não conseguem atribuir o endereço IP durante o dimensionamento

Sintomas

A tentativa de expandir o intervalo de endereços IP principal da sub-rede para a lista de redes autorizadas devolve um erro semelhante ao seguinte:

 authorized networks fields cannot be mutated if direct IP access is disabled
Potenciais causas

Desativou o ponto final baseado em IP do cluster.

Resolução

Desative e ative o ponto final baseado em IP do cluster através da flag enable-ip-access.

Demasiados blocos CIDR

gcloud devolve o seguinte erro quando tenta criar ou atualizar um cluster com mais de 50 blocos CIDR:

ERROR: (gcloud.container.clusters.update) argument --master-authorized-networks: too many args

Para resolver este problema, experimente o seguinte:

Não é possível ligar ao servidor

Os comandos kubectl excedem o tempo limite devido a blocos CIDR configurados incorretamente:

Unable to connect to the server: dial tcp MASTER_IP: getsockopt: connection timed out

Quando cria ou atualiza um cluster, certifique-se de que especifica os blocos CIDR corretos.

Os nós podem aceder a imagens de contentores públicos apesar do isolamento da rede

Sintomas

Pode observar que, num cluster do GKE configurado para isolamento de rede, a obtenção de uma imagem pública comum, como redis, funciona, mas a obtenção de uma imagem menos comum ou privada falha.

Este comportamento é esperado devido à configuração predefinida do GKE e não indica que o GKE tenha ignorado o isolamento da sua rede.

Potenciais causas

Este comportamento ocorre devido à interação de duas funcionalidades:

  • Acesso privado à Google: esta funcionalidade permite que os nós com endereços IP internos se liguem às APIs e aos serviços do Google Cloud sem necessitarem de endereços IP públicos. O acesso privado à Google está ativado na sub-rede do cluster na VPC usada pelos nós no cluster. Quando um cluster ou um conjunto de nós é criado ou atualizado com a flag --enable-private-nodes, o GKE ativa automaticamente o acesso privado à Google nesta sub-rede. A única exceção aplica-se se usar uma VPC partilhada, em que tem de ativar manualmente o acesso privado à Google.
  • Imagem espelhada da Google (mirror.gcr.io): por predefinição, o GKE configura os respetivos nós para tentar primeiro obter imagens de mirror.gcr.io, um Artifact Registry gerido pela Google que armazena em cache imagens de contentores públicos pedidas com frequência.

Quando tenta obter uma imagem como redis, o seu nó usa o caminho privado do acesso privado à Google para se ligar a mirror.gcr.io. Uma vez que redis é uma imagem muito comum, existe na cache e a obtenção é bem-sucedida. No entanto, se pedir uma imagem que não esteja nesta cache pública, a obtenção falha porque o seu nó isolado não tem outra forma de aceder à sua origem original.

Resolução

Se uma imagem de que precisa não estiver disponível na mirror.gcr.iocache, hospede-a no seu próprio repositório privado do Artifact Registry. Os seus nós isolados da rede podem aceder a este repositório através do acesso privado do Google.

O que se segue?