Soluciona problemas de aislamiento de red en GKE

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

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

El clúster de GKE no se está ejecutando

Un clúster deja de funcionar si se borran las reglas de firewall que permiten la entrada de tráfico desde el plano de control del clúster a los nodos en el puerto 10250 o la ruta predeterminada a la puerta de enlace predeterminada de Internet. Si borras la ruta predeterminada, debes asegurarte de que se enrute el tráfico a los servicios necesarios deGoogle Cloud . Para obtener más información, consulta enrutamiento personalizado.

Se agota el tiempo de espera cuando se crea un clúster

Síntomas
Los clústeres creados en la versión 1.28 o anterior con nodos privados requieren una ruta de intercambio de tráfico entre las VPC. Sin embargo, solo se puede realizar una operación de vinculación 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 creación del clúster.
Solución

Utiliza una de las siguientes soluciones:

  • Crea clústeres en la versión 1.28 o anterior de manera serial para que las rutas de intercambio de tráfico entre VPC ya existan en cada clúster posterior sin un extremo externo. Si intentas crear un solo clúster, es posible que también se agote el tiempo de espera si hay operaciones en ejecución en la VPC.

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

La conexión de intercambio de tráfico entre redes de VPC se borra por accidente

Síntomas

Cuando borras una conexión de intercambio de tráfico entre redes de VPC por accidente, el clúster entra en un estado de reparación y todos los nodos muestran un estado UNKNOWN. No podrás realizar ninguna operación en el clúster, ya que se desconecta la accesibilidad del plano de control. Cuando inspeccionas el plano de control, los registros mostrarán un error similar al siguiente:

error checking if node NODE_NAME is shutdown: unimplemented
Causas posibles

Borraste por accidente la conexión de intercambio de tráfico entre redes de VPC.

Solución

Lleva a cabo los pasos siguientes:

  1. Crea un clúster nuevo de intercambio de tráfico entre redes de VPC temporal. La creación del clúster hace que la recreación del intercambio de tráfico entre redes de VPC y el clúster anterior se restablezca a su funcionamiento normal.

  2. Borra el clúster de intercambio de tráfico entre redes de VPC creado de forma temporal después de que el clúster anterior se restablezca a su funcionamiento normal.

Se borran accidentalmente el extremo y la regla de reenvío de Private Service Connect

Síntomas

Cuando borras por accidente un extremo o una regla de reenvío de Private Service Connect, el clúster entra en un estado de reparación y todos los nodos muestran un estado UNKNOWN. No podrás realizar ninguna operación en el clúster, ya que se desconecta el acceso al plano de control. Cuando inspeccionas el plano de control, los registros mostrarán un error similar al siguiente:

error checking if node NODE_NAME is shutdown: unimplemented
Causas posibles

Borraste accidentalmente el extremo de Private Service Connect o la regla de reenvío. 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.

Solución

Rota la dirección IP del plano de control.

El clúster se superpone con el intercambio de tráfico

Síntomas

Si intentas crear un clúster sin un extremo externo, se muestra 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.
Causas posibles

Elegiste un CIDR del plano de control superpuesto.

Solución

Utiliza una de las siguientes soluciones:

  • Borra y vuelve a crear el clúster mediante otro CIDR del plano de control.
  • Vuelve a crear el clúster en la versión 1.29 y, además, incluye la marca --enable-private-nodes.

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

Aumenta la probabilidad de que se pueda acceder al plano de control del clúster mediante la implementación de cualquiera de las opciones de configuración de acceso del extremo del clúster. Si deseas obtener más información, consulta el acceso a los extremos del clúster.

Síntomas

Después de crear un clúster sin un extremo externo, si se intenta ejecutar los comandos kubectl en el clúster, se muestra 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.
Causas posibles

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

Solución

Utiliza una de las siguientes soluciones:

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

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

  • Verifica que se permita el acceso al plano de control mediante su dirección IP externa. La inhabilitación del acceso externo al plano de control del clúster aísla el clúster de Internet. Con esta configuración, solo los rangos de CIDR de red interna autorizados o la red reservada 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

      Reemplaza lo siguiente:

      Si la dirección IP de origen no está autorizada, el resultado que se muestra puede estar vacío (solo aparecen llaves) o contener rangos CIDR que no incluyen la 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. Agrega redes autorizadas al plano de control de acceso.

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

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

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

      Reemplaza lo siguiente:

      Un resultado correcto es similar al siguiente:

        enabled: true

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

No se puede crear el clúster debido a la superposición del bloque CIDR de IPv4

Síntomas

gcloud container clusters create muestra 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.
Causas posibles

Especificaste un bloque CIDR del plano de control que se superpone con una subred existente en tu VPC.

Solución

Especifica un bloque CIDR para --master-ipv4-cidr que no se superponga con una subred existente.

No se puede crear el clúster debido a que otro clúster ya usa el rango de servicios

Síntomas

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

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

Las siguientes configuraciones pueden causar este error:

  • Elegiste un rango de servicios que aún está en uso por otro clúster o el clúster no se borró.
  • Hubo un clúster con ese rango de servicios que se borró, pero los metadatos de rangos secundarios no se borraron de forma correcta. Los rangos secundarios de un clúster de GKE se guardan en los metadatos de Compute Engine y deben quitarse una vez que se borra el clúster. Incluso cuando un clúster se borra de forma correcta, es posible que los metadatos no se quiten.
Solución

Lleva a cabo los pasos siguientes:

  1. Comprueba si un clúster existente está usando el rango de servicios. Puedes usar el comando gcloud container clusters list con la marca filter para buscar el clúster. Si hay un clúster existente que usa los rangos de servicios, debes borrar ese clúster o crear un rango de servicios nuevo.
  2. Si un clúster existente no usa el rango de servicios, quita manualmente la entrada de metadatos que coincida con el rango de servicios que deseas usar.

No se puede crear una subred

Síntomas

Cuando intentas crear un clúster con una subred automática o crear una subred personalizada, puedes encontrar cualquiera 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.
Causas posibles

El rango CIDR del plano de control que especificaste se superpone con otro rango de IP en el clúster. Este error de creación de subred también puede ocurrir si intentas volver a usar los CIDR de master-ipv4-cidr que se usaron en un clúster borrado recientemente.

Solución

Usa otro rango de 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)
Causas posibles

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

Solución

Utiliza una de las siguientes soluciones:

  • Copia las imágenes de tu clúster de Docker Hub a Artifact Registry. Consulta la página sobre cómo migrar contenedores desde un registro de terceros para obtener más información.

  • GKE busca de forma automática mirror.gcr.io para las copias almacenadas en caché de las imágenes de Docker Hub a las que se accede con frecuencia.

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

Solicitud a la API que activa el agotamiento del tiempo de espera del webhook de admisión

Síntomas

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

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

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

Solución

Agrega una regla de firewall para tu caso de uso específico.

No se puede crear el clúster porque falla la verificación de estado

Síntomas

Después de crear un clúster estándar con grupos de nodos privados, se atasca en el paso de verificación de estado y se informa 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
Causas posibles

Las siguientes configuraciones pueden causar este error:

  • Los nodos del clúster no pueden descargar objetos binarios obligatorios de la API de Cloud Storage (storage.googleapis.com).
  • Reglas de firewall que restringen el tráfico de salida.
  • Los permisos de IAM de VPC compartida son incorrectos.
  • El acceso privado a Google requiere que configures el DNS para *.gcr.io.
Solución

Utiliza una de las siguientes soluciones:

kubelet no pudo crear una zona de pruebas de Pod

Síntomas

Después de crear un clúster con nodos privados, se informa 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
Causas posibles

El Pod calico-node o netd no puede alcanzar *.gcr.io.

Solución

Asegúrate de que completaste la configuración requerida para Container Registry o Artifact Registry.

Se crearon nodos privados, pero no se unieron al clúster

En el caso de los clústeres que usan solo nodos con direcciones IP privadas, 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 redirecciona 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 sea posible acceder a los siguientes destinos:

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

Configura el Acceso privado a Google en los tres dominios. Con esta práctica recomendada, se permite que los nodos nuevos se inicien y se unan al clúster, y se mantiene restringido 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 informa 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 rango de direcciones IP secundario de la subred que se usa para los Pods en el clúster no está configurado en la puerta de enlace de Cloud NAT, los Pods no pueden conectarse a Internet, ya que no tienen configurada una dirección IP externa para la puerta de enlace de Cloud NAT.

Asegúrate de configurar la puerta de enlace de Cloud NAT a fin de aplicar al menos los siguientes rangos de direcciones IP de subred para la subred que usa tu clúster:

  • Rango de direcciones IP principal de la subred (para los nodos)
  • Rango de direcciones IP secundario de la subred utilizado para los Pods del clúster
  • Rango de direcciones IP secundario de la subred utilizado para los servicios del clúster

Si quieres obtener más información, consulta cómo agregar un rango de IP de subred secundario usado para los Pods.

No se puede inhabilitar el acceso directo a la IP para los clústeres públicos.

Síntomas

Después de inhabilitar el extremo de la dirección IP, verás un mensaje de error similar al siguiente:

Direct IP access can't be disabled for public clusters
Causas posibles

Tu clúster usa una red heredada.

Solución

Migra tus clústeres a Private Service Connect. Para obtener más información sobre el estado de la migración, comunícate con el equipo de asistencia .

No se puede inhabilitar el acceso directo a la IP para los clústeres en medio de la migración de PSC.

Síntomas

Después de inhabilitar el extremo de la dirección IP, verás un mensaje de error similar al siguiente:

Direct IP access can't be disabled for public clusters
Causas posibles

Tu clúster usa una red heredada.

Solución

Utiliza una de las siguientes soluciones:

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

No se puede habilitar el extremo interno del plano de control

Síntomas

Cuando intentas habilitar el extremo interno del plano de control de tu clúster, verás mensajes de error similares al siguiente:

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
Causas posibles

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

Solución

Utiliza una de las siguientes soluciones:

La creación de clústeres falla cuando se definen políticas de la organización.

Síntomas

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

compute.disablePrivateServiceConnectCreationForConsumers violated for projects
Causas posibles

Una política de la organización de consumidores bloquea el extremo o el backend del clúster.

Solución

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

Es posible que el extremo de Private Service Connect tenga filtraciones durante la eliminación del clúster.

Síntomas

Después de crear un clúster, es posible que veas uno de los siguientes síntomas:

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

  • No puedes borrar la subred ni la red de VPC asignadas para el extremo interno en un clúster que usa Private Service Connect. Aparecerá 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>
Causas posibles

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

Solución

Para evitar que se filtre el extremo de Private Service Connect antes de borrar el clúster, completa los siguientes pasos:

  1. Asigna 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 rechacen de forma explícita desde la cuenta de servicio de GKE.

Si ves que se filtró el extremo de Private Service Connect, comunícate 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. Aparecerá un mensaje de error similar al siguiente:

Unable to parse cluster.master_ipv4_cidr "" into a valid IP address and mask
Causas posibles

Tu proyecto de Google Cloud usa webhooks privados basados en IP. Por lo tanto, no puedes crear un clúster con Private Service Connect. En su lugar, tu clúster usa el intercambio de tráfico entre redes de VPC, que analiza la marca master-ipv4-cidr.

Solución

Utiliza una de las siguientes soluciones:

  • Continúa creando tu clúster de intercambio de tráfico de red de VPC y, luego, incluye el master-ipv4-cidr para definir CIDR válidos. Esta solución tiene las siguientes limitaciones:

    • La marca master-ipv4-cidr dejó de estar disponible en la consola de Google Cloud . Para actualizar esta marca, solo puedes usar Google Cloud CLI o Terraform.
    • El intercambio de tráfico de redes de VPC dejó de estar disponible en la versión 1.29 de GKE o versiones posteriores.

  • Para migrar tus webhooks basados en IP privadas, completa los pasos que se indican en Limitaciones de Private Service Connect. Luego, comunícate con el equipo de asistencia para habilitar el uso de clústeres con Private Service Connect.

No se puede definir el rango de direcciones IP internas en clústeres con nodos públicos.

Síntomas

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

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

Estás definiendo un rango 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 configurarlo para aprovisionar nodos con direcciones IP internas (nodos privados) con la marca enable-private-nodes.

Solución

Utiliza 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

    Reemplaza lo siguiente:

    • CLUSTER_NAME: El nombre de tu clúster.
    • CLUSTER_NAME: Es el rango de direcciones IP internas para el plano de control.

  • Actualiza el clúster para aprovisionar nodos con solo direcciones IP. Para obtener más información, consulta Cómo configurar tu 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 con el nodeSelector cloud.google.com/private-node=false.
Causas posibles
La configuración de la marca private-node establecida como false en el nodeSelector del pod solo está disponible en clústeres de la versión 1.30.3 o posterior.
Solución
Actualiza tu clúster a la versión 1.30 o una posterior.

El acceso al extremo basado en DNS está inhabilitado

Síntomas

Si intentas ejecutar comandos kubectl en el clúster, se muestra 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
Causas posibles

Se inhabilitó el acceso basado en DNS en tu clúster.

Solución

Habilita el acceso al plano de control con el extremo basado en DNS del plano de control. Para obtener más información, consulta Cómo modificar el acceso al plano de control.

Los nodos no pueden asignar direcciones IP durante el escalamiento

Síntomas

Si intentas expandir el rango de direcciones IP principal de la subred a la lista de redes autorizadas, se muestra un error similar al siguiente:

 authorized networks fields cannot be mutated if direct IP access is disabled
Causas posibles

Inhabilitaste el extremo basado en IP del clúster.

Solución

Inhabilita y habilita el extremo basado en IP del clúster con la marca enable-ip-access.

Demasiados bloques CIDR

gcloud muestra el siguiente error cuando intenta 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 resolver este problema, realiza las siguientes acciones:

No se puede establecer una conexión con el servidor

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

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

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