Soluciona problemas de clústeres privados en GKE

En esta página, se muestra cómo resolver problemas con los clústeres privados de Google Kubernetes Engine (GKE).

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

El clúster privado no se está ejecutando

Un clúster privado deja de funcionar si se borra el intercambio de tráfico de VPC entre el plano de control y los nodos del clúster, las reglas de firewall que permiten el tráfico de entrada del 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 de Google Cloud necesarios. Para obtener más información, consulta Enrutamiento personalizado.

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

Cada clúster privado requiere una ruta de intercambio de tráfico entre las VPC, pero solo puede ocurrir una operación de intercambio de tráfico a la vez. Si intentas crear varios clústeres privados al mismo tiempo, es posible que se agote el tiempo de espera de creación del clúster. Para evitar esto, crea clústeres privados nuevos de manera serial para que las rutas de intercambio de tráfico entre VPC ya existan en cada clúster privado posterior. Si intentas crear un único clúster privado, es posible que también se agote el tiempo de espera si hay operaciones en ejecución en la VPC.

La conexión de intercambio de tráfico entre redes de VPC en un clúster privado 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:

  • 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.

  • Borra el clúster de intercambio de tráfico entre redes de VPC creado de forma temporal después de que los clústeres anteriores restablezcan su funcionamiento normal.

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

Síntomas

Si intentas crear un clúster privado, 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

Borra y vuelve a crear el clúster mediante otro CIDR del plano de control.

No se puede acceder al plano de control de un clúster privado

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 privado, 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

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. Esta configuración es inmutable después de la creación del clúster. 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(masterAuthorizedNetworksConfig)"\
      --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 al extremo privado del plano de control de forma global.

  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 "privateClusterConfig.masterGlobalAccessConfig"

    Reemplaza lo siguiente:

    Un resultado correcto es similar al siguiente:

      enabled: true

  2. Si se muestra null, habilita el acceso global al plano de control.

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 privado, 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

Cualquiera de las siguientes opciones:

  • 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:

  • 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.
  • 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 la subred

Síntomas

Cuando intentas crear un clúster privado con una subred automática o crear una subred personalizada, puedes encontrar el siguiente error:

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

El rango CIDR del plano de control que especificaste se superpone con otro rango de IP en el clúster. Esto también puede ocurrir si borraste un clúster privado hace poco y ahora intentas crear uno nuevo con el mismo CIDR del plano de control.

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 de un clúster privado no tienen direcciones IP externas, por lo que no cumplen con los requisitos de acceso a Internet. Sin embargo, los nodos pueden acceder a los servicios y las APIs de Google, incluido Artifact Registry, si habilitaste el Acceso privado a Google y cumpliste con los requisitos de la red.

Solución

Utiliza una de las siguientes soluciones:

  • Copia las imágenes de tu clúster privado 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 privado, se atasca en el paso de verificación de estado e informa un error similar al siguiente:

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

Cualquiera de los siguientes:

  • 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 privado, 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

Utiliza una de las siguientes soluciones:

Nodos de clúster privado que se crearon, pero no se unieron al clúster

A menudo, cuando se usan rutas personalizadas y dispositivos de red de terceros en la VPC que usa el clúster privado, la ruta predeterminada (0.0.0.0/0) se redirecciona al dispositivo, en lugar de 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 clústeres de GKE privados no pueden acceder a Internet

Los Pods en clústeres de GKE privados 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.