Solucionar problemas de aislamiento de red en GKE

En esta página se explica cómo resolver problemas con el aislamiento de red de Google Kubernetes Engine (GKE).

El clúster de GKE no se está ejecutando

Si se eliminan las reglas de cortafuegos que permiten el tráfico entrante desde el plano de control del clúster a los nodos en el puerto 10250, o si se elimina la ruta predeterminada a la pasarela de Internet predeterminada, el clúster dejará de funcionar. Si eliminas la ruta predeterminada, debes asegurarte de que se enrute el tráfico a losGoogle Cloud servicios necesarios. Para obtener más información, consulta enrutamiento personalizado.

Tiempo de espera agotado al crear un clúster

Síntomas
Los clústeres creados en la versión 1.28 o anteriores con nodos privados requieren una ruta de peering entre VPCs. Sin embargo, solo se puede realizar una operación de emparejamiento a la vez. Si intentas crear varios clústeres con las características anteriores al mismo tiempo, es posible que se agote el tiempo de espera de la creación de clústeres.
Resolución

Usa una de las siguientes soluciones:

  • Crea clústeres en la versión 1.28 o en una anterior de forma secuencial para que las rutas de peering de VPC ya existan en cada clúster posterior sin un endpoint externo. Si intentas crear un solo clúster, también puede agotarse el tiempo de espera si hay operaciones en curso en tu VPC.

  • Crea clústeres con la versión 1.29 o una posterior.

Se elimina por error una conexión de emparejamiento entre redes de VPC

Síntomas

Si eliminas por error una conexión de emparejamiento de redes VPC, el clúster pasa a un estado de reparación y todos los nodos muestran el estado UNKNOWN. No podrás realizar ninguna operación en el clúster, ya que se ha desconectado la accesibilidad al plano de control. Cuando inspeccione el plano de control, los registros mostrarán un error similar al siguiente:

error checking if node NODE_NAME is shutdown: unimplemented
Posibles causas

Has eliminado por error la conexión de intercambio de tráfico entre redes de VPC.

Resolución

  1. Crea un clúster de GKE con una versión anterior al cambio de PSC y sus configuraciones específicas. Esta acción es necesaria para forzar la recreación de la conexión de peering de VPC, lo que restaurará el funcionamiento normal del clúster antiguo.
    • Usa las siguientes configuraciones específicas para el nuevo clúster:
      • Canal de lanzamiento: ampliado
      • Versión del clúster: una versión anterior a la 1.29, como la 1.28.15-gke.2403000
      • CIDR de IPv4 de la instancia maestra: un intervalo de direcciones IP específico, como --master-ipv4-cidr=172.16.0.192/28.
  2. Monitoriza el estado del clúster original.
    • Una vez que se haya creado el nuevo clúster (y, por lo tanto, se haya restablecido el peering de VPC), el clúster original debería recuperarse de su estado de reparación y sus nodos deberían volver al estado Ready.
  3. Elimina el clúster de GKE que has creado temporalmente.
    • Una vez que el clúster original se haya restaurado por completo y funcione con normalidad, puedes eliminar el clúster de GKE que has creado temporalmente.

Se eliminan por error el endpoint y la regla de reenvío de Private Service Connect

Síntomas

Si eliminas por error un punto final o una regla de reenvío de Private Service Connect, el clúster pasará a un estado de reparación y todos los nodos mostrarán el estado UNKNOWN. No podrás realizar ninguna operación en el clúster, ya que el acceso al plano de control se ha desconectado. Cuando inspeccione el plano de control, los registros mostrarán un error similar al siguiente:

error checking if node NODE_NAME is shutdown: unimplemented
Posibles causas

Has eliminado por error el endpoint o la regla de reenvío de Private Service Connect. Ambos recursos se denominan gke-[cluster-name]-[cluster-hash:8]-[uuid:8]-pe y permiten que el plano de control y los nodos se conecten de forma privada.

Resolución

Rota la dirección IP del plano de control.

El clúster se superpone con un elemento del mismo nivel activo

Síntomas

Si intentas crear un clúster sin un endpoint externo, se devolverá un error similar al siguiente:

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

Has elegido un CIDR del plano de control superpuesto.

Resolución

Usa una de las siguientes soluciones:

  • Elimina el clúster y vuelve a crearlo con otro CIDR del plano de control.
  • Vuelve a crear el clúster en la versión 1.29 e incluye la marca --enable-private-nodes.

No se puede acceder al plano de control de un clúster sin endpoint externo

Aumenta la probabilidad de que se pueda acceder al plano de control del clúster implementando cualquiera de las configuraciones de acceso al endpoint del clúster. Para obtener más información, consulta el artículo sobre el acceso a endpoints de clústeres.

Síntomas

Después de crear un clúster sin endpoint externo, si intentas ejecutar comandos kubectl en el clúster, se devolverá un error similar a uno de los siguientes:

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.
Posibles causas

kubectl no puede comunicarse con el plano de control del clúster.

Resolución

Usa una de las siguientes soluciones:

  • Habilita el acceso DNS para acceder de forma segura y sencilla a tu clúster. Para obtener más información, consulta Punto final basado en DNS.

  • Verifica que se hayan generado las credenciales del clúster para kubeconfig o que se haya activado el contexto correcto. Para obtener más información sobre cómo definir las credenciales del clúster, consulta Generar entrada kubeconfig.

  • Verifica que se permite acceder al plano de control con su dirección IP externa. Si inhabilitas el acceso externo al plano de control del clúster, el clúster se aísla de Internet. Con esta configuración, solo las redes internas autorizadas o las redes reservadas tienen acceso al plano de control.

    1. Verifica que la dirección IP de origen esté autorizada para acceder al plano de control:

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

      Haz los cambios siguientes:

      Si tu dirección IP de origen no está autorizada, la salida puede devolver un resultado vacío (solo llaves) o intervalos CIDR que no incluyan tu dirección IP de origen.

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

    2. Añade redes autorizadas para acceder al plano de control.

  • Si ejecutas el comando kubectl desde un entorno on-premise o una región diferente a la ubicación del clúster, asegúrate de que el acceso global al endpoint privado del plano de control esté habilitado. Para obtener más información, consulta Acceder con la dirección IP interna del plano de control desde cualquier región.

    1. Describe el clúster para ver la respuesta de configuración del control de acceso:

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

      Haz los cambios siguientes:

      El resultado correcto es similar al siguiente:

        enabled: true

    2. Si se devuelve null, habilita el acceso mediante la dirección IP interna del plano de control desde cualquier región.

No se puede crear el clúster porque el bloque CIDR IPv4 se superpone

Síntomas

gcloud container clusters create devuelve un error similar al siguiente:

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

Has especificado un bloque CIDR del plano de control que se solapa con una subred de tu VPC.

Resolución

Especifica un bloque CIDR para --master-ipv4-cidr que no se solape con ninguna subred.

No se puede crear el clúster porque el intervalo de servicios ya lo está usando otro clúster

Síntomas

Si intentas crear un clúster, se devuelve un error similar al siguiente:

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

Las siguientes configuraciones pueden provocar este error:

  • Has elegido un intervalo de servicio que sigue en uso en otro clúster o el clúster no se ha eliminado.
  • Había un clúster que usaba ese intervalo de servicios que se eliminó, pero los metadatos de los intervalos secundarios no se limpiaron correctamente. Los intervalos secundarios de un clúster de GKE se guardan en los metadatos de Compute Engine y se deben eliminar cuando se elimine el clúster. Aunque un clúster se elimine correctamente, es posible que los metadatos no se quiten.
Resolución

Sigue estos pasos:

  1. Comprueba si el intervalo de servicios lo está usando un clúster. Puedes usar el comando gcloud container clusters list con la marca filter para buscar el clúster. Si hay un clúster que utiliza los intervalos de servicios, debes eliminarlo o crear un nuevo intervalo de servicios.
  2. Si el intervalo de servicios no lo utiliza ningún clúster, elimina manualmente la entrada de metadatos que coincida con el intervalo de servicios que quieras usar.

No se puede crear una subred

Síntomas

Cuando intentes crear un clúster con una subred automática o una subred personalizada, es posible que se produzca alguno de los siguientes errores:

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.
Posibles causas

El intervalo CIDR del plano de control que has especificado se solapa con otro intervalo de IP del clúster. Este error de creación de subred también puede producirse si intentas reutilizar los CIDRs master-ipv4-cidr utilizados en un clúster eliminado recientemente.

Resolución

Prueba a usar otro intervalo CIDR.

No se puede extraer la imagen de Docker Hub público

Síntomas

Un pod que se ejecuta en tu clúster muestra una advertencia en 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)
Posibles causas

Los nodos con direcciones IP privadas solo necesitan una configuración adicional para cumplir los requisitos de acceso a Internet. Sin embargo, los nodos pueden acceder a las APIs y los servicios de Google Cloud , incluido Artifact Registry, si has habilitado Acceso privado de Google y cumples sus requisitos de red.

Resolución

Usa una de las siguientes soluciones:

  • Copia las imágenes de tu clúster de Docker Hub a Artifact Registry. Para obtener más información, consulta el artículo Migrar contenedores desde un registro de terceros.

  • GKE comprueba automáticamente mirror.gcr.io si hay copias en caché de imágenes de Docker Hub a las que se accede con frecuencia.

  • Si debes extraer imágenes de Docker Hub u otro repositorio público, usa Cloud NAT o un proxy basado en instancias que sea el destino de una ruta 0.0.0.0/0 estática.

Solicitud de API que provoca que se agote el tiempo de espera del webhook de admisión

Síntomas

Una solicitud de API que activa un webhook de admisión configurado para usar un servicio con un targetPort distinto de 443 agota el tiempo de espera, lo que provoca que la solicitud falle:

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

De forma predeterminada, el cortafuegos no permite conexiones TCP a nodos, excepto en los puertos 443 (HTTPS) y 10250 (kubelet). Un webhook de admisión que intente comunicarse con un pod en un puerto distinto del 443 fallará si no hay una regla de cortafuegos personalizada que permita el tráfico.

Resolución

Añade una regla de cortafuegos para tu caso práctico específico.

No se puede crear el clúster porque falla la comprobación del estado

Síntomas

Después de crear un clúster estándar con grupos de nodos privados, se queda bloqueado en el paso de comprobación del estado y muestra un error similar a uno de los siguientes:

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
Posibles causas

Las siguientes configuraciones pueden provocar este error:

  • Los nodos del clúster no pueden descargar los archivos binarios necesarios de la API de Cloud Storage (storage.googleapis.com).
  • Reglas de cortafuegos que restringen el tráfico de salida.
  • Los permisos de IAM de la VPC compartida son incorrectos.
  • Para usar Acceso privado de Google, debes configurar el DNS de *.gcr.io.
Resolución

Usa una de las siguientes soluciones:

kubelet no ha podido crear el entorno aislado del pod

Síntomas

Después de crear un clúster con nodos privados, se muestra un error similar a uno de los siguientes:

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
Posibles causas

El calico-node o el netd Pod no pueden acceder a *.gcr.io.

Resolución

Asegúrate de haber completado la configuración necesaria de Container Registry o Artifact Registry.

Se han creado nodos privados, pero no se unen al clúster

En los clústeres que usan nodos con direcciones IP privadas únicamente, a menudo cuando se usan rutas personalizadas y dispositivos de red de terceros en la VPC, la ruta predeterminada (0.0.0.0/0) se redirige al dispositivo en lugar de a la puerta de enlace de Internet predeterminada. Además de la conectividad del plano de control, debes asegurarte de que se pueda acceder a los siguientes destinos:

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

Configura el acceso privado de Google para los tres dominios. Esta práctica recomendada permite que los nuevos nodos se inicien y se unan al clúster, al tiempo que se restringe el tráfico vinculado a Internet.

Las cargas de trabajo de los clústeres de GKE no pueden acceder a Internet

Los pods que se ejecutan en nodos con direcciones IP privadas no pueden acceder a Internet. Por ejemplo, después de ejecutar el comando apt update desde el pod exec shell, se muestra un error similar al siguiente:

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

Si el intervalo de direcciones IP secundarias de la subred que se usa para los pods del clúster no está configurado en la pasarela Cloud NAT, los pods no podrán conectarse a Internet, ya que no tienen ninguna dirección IP externa configurada para la pasarela Cloud NAT.

Asegúrate de configurar la pasarela Cloud NAT para que aplique al menos los siguientes intervalos de direcciones IP de subred a la subred que usa tu clúster:

  • Intervalo de direcciones IP principales de la subred (usado por los nodos)
  • Intervalo de direcciones IP secundarias de la subred que se usa para los pods del clúster.
  • Intervalo de direcciones IP secundarias de la subred que se usa para los servicios del clúster.

Para obtener más información, consulta cómo añadir un intervalo de IP de subred secundaria usado para pods.

El acceso directo por IP no se puede inhabilitar en clústeres públicos

Síntomas

Después de inhabilitar el endpoint de la dirección IP, aparece un mensaje de error similar al siguiente:

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

Tu clúster usa una red antigua.

Resolución

Migra tus clústeres a Private Service Connect. Para obtener más información sobre el estado de la migración, ponte en contacto con el equipo de Asistencia .

No se puede inhabilitar el acceso directo por IP en los clústeres que estén en mitad de la migración de PSC

Síntomas

Después de inhabilitar el endpoint de la dirección IP, aparece un mensaje de error similar al siguiente:

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

Tu clúster usa una red antigua.

Resolución

Usa una de las siguientes soluciones:

  • Vuelve a crear manualmente todos los grupos de nodos en otra versión.
  • Espere a que GKE actualice automáticamente los grupos de nodos durante un evento de mantenimiento.

No se puede habilitar el endpoint interno del plano de control

Síntomas

Cuando intentas habilitar el endpoint interno del plano de control de tu clúster, ves mensajes de error similares a los siguientes:

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
Posibles causas

Tu clúster debe rotar las direcciones IP o actualizar la versión.

Resolución

Usa una de las siguientes soluciones:

No se puede crear un clúster cuando se definen políticas de organización

Síntomas

Cuando intentas crear un clúster, aparece un mensaje de error similar al siguiente:

compute.disablePrivateServiceConnectCreationForConsumers violated for projects
Posibles causas

El endpoint o el backend del clúster están bloqueados por una política de la organización de consumidor.

Resolución

Para permitir que las instancias creen endpoints con la restricción compute.restrictPrivateServiceConnectProducer, sigue los pasos que se indican en Políticas de la organización del lado del consumidor.

El endpoint de Private Service Connect puede tener fugas durante la eliminación del clúster

Síntomas

Después de crear un clúster, puede que se produzca uno de los siguientes síntomas:

  • No puedes ver un punto final conectado en Private Service Connect en tu clúster basado en Private Service Connect.

  • No puedes eliminar la subred ni la red de VPC asignadas al endpoint interno de un clúster que use Private Service Connect. Aparece un mensaje de error similar al siguiente:

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

En los clústeres de GKE que usan Private Service Connect, GKE despliega un endpoint de Private Service Connect mediante una regla de reenvío que asigna una dirección IP interna para acceder al plano de control del clúster en la red del plano de control. Para proteger la comunicación entre el plano de control y los nodos mediante Private Service Connect, GKE mantiene el endpoint invisible y no puedes verlo en la consola ni en la CLI de gcloud.Google Cloud

Resolución

Para evitar que se filtre el punto final de Private Service Connect antes de eliminar el clúster, sigue estos pasos:

  1. Asigna el Kubernetes Engine Service Agent role a la cuenta de servicio de GKE.
  2. Asegúrate de que los permisos compute.forwardingRules.* y compute.addresses.* no se hayan denegado explícitamente a la cuenta de servicio de GKE.

Si ves que se ha filtrado el endpoint de Private Service Connect, ponte en contacto con el equipo de Asistencia .

No se puede analizar la red autorizada del clúster

Síntomas

No puedes crear un clúster en la versión 1.29 o posterior. Aparece un mensaje de error similar al siguiente:

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

Tu proyecto Google Cloud usa webhooks basados en IPs privadas. Por lo tanto, no puedes crear un clúster con Private Service Connect. En su lugar, el clúster utiliza el emparejamiento entre redes de VPC, que analiza la marca master-ipv4-cidr.

Resolución

Usa una de las siguientes soluciones:

  • Continúa creando tu clúster de emparejamiento entre redes de VPC e incluye el master-ipv4-cidr para definir CIDRs válidos. Esta solución tiene las siguientes limitaciones:

    • La marca master-ipv4-cidr se ha retirado de la consola Google Cloud . Para actualizar esta marca, solo puedes usar la CLI de Google Cloud o Terraform.
    • El emparejamiento entre redes de VPC está obsoleto en GKE 1.29 o versiones posteriores.

  • Migra tus webhooks basados en IP privadas siguiendo los pasos que se indican en Limitaciones de Private Service Connect. A continuación, ponte en contacto con el servicio de asistencia para habilitar el uso de clústeres con Private Service Connect.

No se puede definir un intervalo de direcciones IP internas en clústeres con nodos públicos

Síntomas

No puedes definir un intervalo de direcciones IP internas con la marca --master-ipv4-cidr. Aparece un mensaje de error similar al siguiente:

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

Estás definiendo un intervalo de direcciones IP internas para el plano de control con la marca master-ipv4-cidr en un clúster sin la marca enable-private-nodes habilitada. Para crear un clúster con master-ipv4-cidr definido, debes configurar el clúster para aprovisionar nodos con direcciones IP internas (nodos privados) mediante la marca enable-private-nodes.

Resolución

Usa una de las siguientes soluciones:

  • Crea un clúster con el siguiente comando:

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

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre de tu clúster.
    • CLUSTER_NAME: el intervalo de direcciones IP internas del plano de control.

  • Actualiza tu clúster para aprovisionar nodos solo con direcciones IP. Para obtener más información, consulta el artículo Configurar un clúster.

No se pueden programar cargas de trabajo públicas en clústeres de Autopilot

Síntomas
En los clústeres de Autopilot, si tu clúster solo usa nodos privados, no puedes programar cargas de trabajo en pods públicos mediante el cloud.google.com/private-node=falsenodeSelector
.
Posibles causas
La configuración de la marca private-node definida como false en el nodeSelector del pod solo está disponible en clústeres con la versión 1.30.3 o posterior.
Resolución
Actualiza el clúster a la versión 1.30 o a una posterior.

El acceso al endpoint basado en DNS está inhabilitado

Síntomas

Si intentas ejecutar comandos de kubectl en el clúster, se devuelve un error similar al siguiente:

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

Se ha inhabilitado el acceso basado en DNS en tu clúster.

Resolución

Habilita el acceso al plano de control mediante el endpoint basado en DNS del plano de control. Para obtener más información, consulta Modificar el acceso al plano de control.

Los nodos no pueden asignar direcciones IP durante el escalado

Síntomas

Si intentas ampliar el intervalo de direcciones IP principal de una subred a la lista de redes autorizadas, se devuelve un error similar al siguiente:

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

Has inhabilitado el endpoint basado en IP del clúster.

Resolución

Para inhabilitar y habilitar el endpoint basado en IP del clúster, usa la marca enable-ip-access.

Demasiados bloques CIDR

gcloud devuelve el siguiente error al intentar crear o actualizar un clúster con más de 50 bloques CIDR:

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

Para solucionar este problema, prueba lo siguiente:

No se puede establecer conexión con el servidor

Los comandos kubectl agotan el tiempo de espera debido a que los bloques CIDR no están configurados correctamente:

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

Cuando crees o actualices un clúster, asegúrate de especificar los bloques CIDR correctos.

Los nodos pueden acceder a imágenes de contenedor públicas a pesar del aislamiento de la red

Síntomas

Puede que observes que, en un clúster de GKE configurado para el aislamiento de red, se puede extraer una imagen pública común, como redis, pero no se puede extraer una imagen menos común o privada.

Este comportamiento es el esperado debido a la configuración predeterminada de GKE y no indica que GKE haya eludido el aislamiento de tu red.

Posibles causas

Este comportamiento se debe a la combinación de dos funciones:

  • Acceso privado de Google: esta función permite que los nodos con direcciones IP internas se conecten a las APIs y los servicios de Google Cloud sin necesidad de direcciones IP públicas. La función Acceso privado de Google se activa en la subred del clúster dentro de la VPC que usan los nodos del clúster. Cuando se crea o actualiza un clúster o un grupo de nodos con la marca --enable-private-nodes, GKE habilita automáticamente el acceso privado a Google en esta subred. La única excepción es si usas una VPC compartida, en cuyo caso debes habilitar manualmente el acceso privado a Google.
  • Mirror de imágenes de Google (mirror.gcr.io): de forma predeterminada, GKE configura sus nodos para que primero intenten extraer imágenes de mirror.gcr.io, un Artifact Registry gestionado por Google que almacena en caché las imágenes de contenedor públicas solicitadas con frecuencia.

Cuando intentas extraer una imagen como redis, tu nodo usa la ruta privada de Acceso privado de Google para conectarse a mirror.gcr.io. Como redis es una imagen muy común, existe en la caché y la extracción se realiza correctamente. Sin embargo, si solicitas una imagen que no esté en esta caché pública, la extracción fallará porque tu nodo aislado no tiene otra forma de acceder a su fuente original.

Resolución

Si una imagen que necesitas no está disponible en la caché de mirror.gcr.io, aloja la imagen en tu propio repositorio privado de Artifact Registry. Tus nodos aislados de la red pueden acceder a este repositorio mediante el acceso privado a Google.

Siguientes pasos