Clústeres privados

En esta página se explica cómo funcionan los clústeres privados en Google Kubernetes Engine (GKE). También puedes obtener información para crear y administrar clústeres privados.

Un clúster privado es un tipo de clúster nativo de la VPC que solo depende de las direcciones IP internas. Los nodos, los Pods y los servicios en un clúster privado requieren rangos de direcciones IP de subred únicos.

Puedes crear y configurar clústeres privados en modo Standard o Autopilot.

Si deseas proporcionarles a ciertos nodos privados acceso saliente a Internet, puedes usar Cloud NAT o administrar tu propia puerta de enlace NAT.

Arquitectura

Los clústeres privados usan nodos que no tienen direcciones IP externas. Esto significa que los clientes en Internet no se pueden conectar a las direcciones IP de los nodos. Por ejemplo, los clientes externos no pueden acceder a un servicio de tipo NodePort alojado en un clúster privado porque el nodo no tiene una dirección IP pública enrutable por Internet.

A diferencia de un clúster público, un clúster privado tiene un extremo privado del plano de control y un extremo público del plano de control. Debes especificar un rango de direcciones IP /28 único para el extremo privado del plano de control, y puedes optar por inhabilitar el extremo público del plano de control.

En el siguiente diagrama, se proporciona una descripción general de la arquitectura de un clúster privado:

Arquitectura del clúster privado

Aunque los nodos usan direcciones IP internas, los clientes externos pueden conectarse a los servicios en el clúster. Por ejemplo:

  • Un cliente externo con una dirección IP de origen en Internet puede conectarse a un servicio externo de tipo LoadBalancer si omites spec.loadBalancerSourceRanges del manifiesto del servicio.

  • Puedes crear un servicio de tipo NodePort o ClusterIP y exponerlo a clientes externos mediante un Ingress externo.

Usa el Acceso privado a Google en clústeres privados

En el caso de los clústeres privados que usan redes de VPC en el mismo proyecto que el clúster, GKE garantiza que el Acceso privado a Google esté habilitado en la subred que usa el clúster privado cuando creas el clúster. Un administrador de red o un propietario o editor de un proyecto host de VPC compartida debe habilitar de forma manual el Acceso privado a Google en las subredes que usan los clústeres privados si estos se crean en proyectos de servicio de VPC compartida.

El Acceso privado a Google está habilitado de forma predeterminada en los clústeres privados, excepto en los clústeres de VPC compartida. Debes habilitar el Acceso privado a Google de forma manual para los clústeres de VPC compartida.

El Acceso privado a Google permite que los nodos privados y sus cargas de trabajo accedan a las API y los servicios de Google Cloud a través de la red privada de Google. Por ejemplo, el Acceso privado a Google es obligatorio para que los clústeres privados accedan a las imágenes de contenedor de Artifact Registry y envíen registros a Cloud Logging.

El plano de control en clústeres privados

Cada clúster de GKE tiene un servidor de la API de Kubernetes que administra el plano de control (instancia principal).

El plano de control se ejecuta en una máquina virtual (VM) que está en una red de VPC en un proyecto propiedad de Google. Un clúster regional tiene múltiples planos de control, cada uno de los cuales se ejecuta en su propia VM.

En clústeres privados, la red de VPC del plano de control se conecta a la red de VPC de tu clúster con el intercambio de tráfico entre redes de VPC. Tu red de VPC contiene los nodos del clúster, y la red de VPC de Google Cloud, que es propiedad de Google, contiene el plano de control del clúster.

El tráfico entre los nodos y el plano de control se enruta por completo mediante direcciones IP internas. Si usas el intercambio de tráfico entre redes de VPC para conectar la red de VPC de tu clúster a una tercera red, esta última no puede acceder a los recursos en la red de VPC del plano de control. Esto se debe a que el intercambio de tráfico entre redes de VPC solo admite la comunicación entre redes de intercambio de tráfico directo, y a que la tercera red no puede intercambiar tráfico con la red del plano de control. Para obtener más información, consulta Restricciones de intercambio de tráfico entre redes de VPC.

Vuelve a usar el intercambio de tráfico entre redes de VPC

Los clústeres privados creados después del 15 de enero de 2020 usan una conexión de intercambio de tráfico de red de VPC común si están en la misma ubicación y usan la misma red de VPC. En este contexto, el término ubicación hace referencia de forma exclusiva a una región o zona de Google Cloud.

  • Para los clústeres zonales, el primer clúster privado que creas en una zona genera una nueva conexión de intercambio de tráfico entre redes de VPC a la red de VPC del clúster. Los clústeres privados zonales adicionales que creas en la misma zona y red de VPC usan la misma conexión de intercambio de tráfico.

  • Para los clústeres regionales, el primer clúster privado que creas en una región genera una nueva conexión de intercambio de tráfico entre redes de VPC a la red de VPC del clúster. Los clústeres privados regionales adicionales que creas en la misma región y red de VPC usan la misma conexión de intercambio de tráfico.

  • GKE no usa un intercambio de tráfico común para clústeres zonales y regionales, incluso cuando los clústeres zonales pertenecen a la misma región que los clústeres regionales.

En los siguientes ejemplos, se aclara este comportamiento. En cada ejemplo, se usa una conexión de intercambio de tráfico entre redes de VPC:

  • Dos o más clústeres privados zonales en la zona us-east1-b que usan la misma red de VPC.

  • Dos o más clústeres privados regionales en la región us-east1 que usan la misma red de VPC.

Sin embargo, uno o más clústeres privados zonales en us-east1-b y uno o más clústeres regionales en us-east1 que usan la misma red de VPC requieren dos conexiones de intercambio de tráfico entre redes de VPC.

Para obtener más información sobre conexiones y clústeres privados, consulta Reutilización del intercambio de tráfico entre redes de VPC.

Extremos en clústeres privados

El plano de control de un clúster privado tiene un extremo privado además de uno público. El plano de control de un clúster no privado solo tiene un extremo público.

Extremo privado
El extremo privado es una dirección IP interna en la red de VPC del plano de control. En un clúster privado, los nodos siempre se comunican con el extremo privado del plano de control. Según la configuración, puedes administrar el clúster con herramientas como kubectl, que también se conectan al extremo privado. Cualquier VM que use la misma subred que tu clúster privado también puede acceder al extremo privado.
Extremo público
Esta es la dirección IP externa del plano de control. De forma predeterminada, herramientas como kubectl se comunican con el plano de control en su extremo público.

Acceso a los extremos del clúster

Puedes controlar el acceso a los extremos usando una de las siguientes opciones de configuración:

  • Acceso al extremo público inhabilitado: Esta es la opción más segura, ya que impide el acceso a Internet al plano de control. Esta es una buena opción si configuraste tu red local para conectarte a Google Cloud mediante Cloud Interconnect y Cloud VPN.

    Si inhabilitas el acceso al extremo público, debes configurar las redes autorizadas para el extremo privado. De lo contrario, solo podrás conectarte al extremo privado desde los nodos del clúster o las VM que estén en la misma subred que el clúster. Con esta configuración, las redes autorizadas deben ser direcciones IP internas.

  • Acceso de extremo público habilitado, redes autorizadas habilitadas: En esta configuración, las redes autorizadas se aplican al extremo público del plano de control. Esta es una buena opción si necesitas administrar el clúster desde redes de origen que no están conectadas a la red de VPC de tu clúster mediante Cloud Interconnect o Cloud VPN.

  • Acceso al extremo público habilitado, redes autorizadas inhabilitadas: Esta es la opción predeterminada y también la menos restrictiva. Debido a que las redes autorizadas no están habilitadas, siempre que te autentiques, puedes administrar el clúster desde cualquier dirección IP de origen.

En la siguiente tabla, se resumen las diferentes maneras en las que puedes acceder a los extremos:

Acceso al extremo público inhabilitado Acceso al extremo público habilitado,
redes autorizadas habilitadas
Acceso al extremo público habilitado,
redes autorizadas inhabilitadas
Seguridad El nivel más alto de acceso restringido al plano de control. El acceso del cliente al extremo público del plano de control está bloqueado. El acceso al plano de control debe ser de direcciones IP internas. Acceso restringido al plano de control desde las direcciones IP internas y externas que definas. Acceso al plano de control desde cualquier dirección IP.
Pasos detallados de la configuración Crea un clúster privado sin acceso de clientes al extremo público. Crea un clúster privado con acceso limitado al extremo público. Crea un clúster privado con acceso ilimitado al extremo público.
Opciones de configuración de Cloud Console
  1. Selecciona Habilitar nativo de VPC.
  2. Selecciona Clúster privado.
  3. Borra Permitir el acceso al plano de control mediante su dirección IP externa.
    La opción Habilita las redes autorizadas del plano de control se habilita automáticamente.
  1. Selecciona Habilitar nativo de VPC.
  2. Selecciona Clúster privado.
  3. Permitir el acceso al plano de control mediante su dirección IP externa.
  4. Seleccione Habilita las redes autorizadas del plano de control.
  1. Selecciona Habilitar nativo de VPC.
  2. Selecciona Clúster privado.
  3. Permitir el acceso al plano de control mediante su dirección IP externa.
  4. Borra Habilita las redes autorizadas del plano de control.
Marcas de creación de clústeres de gcloud --enable-ip-alias
--enable-private-nodes
--enable-private-endpoint
--enable-master-authorized-networks
--enable-ip-alias
--enable-private-nodes
--enable-master-authorized-networks
--enable-ip-alias
--enable-private-nodes
--no-enable-master-authorized-networks
Comunicación entre los nodos y el plano de control

Los nodos siempre se comunican con el plano de control mediante el extremo privado.

Comunicación de webhook entre los nodos y el servidor de la API

Los webhooks que usan un servicio con un targettarget diferente de 443 requieren una regla de firewall para permitir esto. Consulta Agrega reglas de firewall para casos prácticos específicos a fin de obtener más información.

Redes autorizadas del plano de control (instancia principal)

Son necesarias para acceder al plano de control desde direcciones IP internas que no sean nodos ni pods.

No es necesario que autorices de forma explícita el rango de direcciones IP internas de los nodos. Las direcciones en el rango de direcciones IP principales de la subred del clúster siempre están autorizadas para comunicarse con el extremo privado.

Usa --master-authorized-networks para especificar direcciones IP internas adicionales que pueden acceder al plano de control. No puedes incluir direcciones IP externas en la lista de redes autorizadas, ya que el acceso al extremo público está inhabilitado.

Son necesario para acceder al plano de control desde direcciones IP externas y desde direcciones IP internas que no sean nodos ni pods.

Usa --master-authorized-networks para especificar direcciones IP internas y externas (que no sean nodos ni pods) que pueden acceder al plano de control.

No se usa.

Si habilitas el acceso al extremo público del plano de control sin habilitar las redes autorizadas, el acceso al extremo público del plano de control no estará restringido.

Acceso mediante kubectl

Desde los nodos: Siempre se usa el extremo privado. kubectl debe estar configurado para usar el extremo privado.

Desde otras VM en la red de VPC del clúster: Otras VM pueden usar kubectl para comunicarse con el extremo privado solo si están en la misma región que el clúster y sus direcciones IP internas se incluyen en la lista de redes autorizadas de la instancia principal o están ubicadas en la misma subred en la que están los nodos del clúster. kubectl debe estar configurado para usar el extremo privado.

Desde direcciones IP públicas: Nunca.

Desde los nodos: Siempre se usa el extremo privado. kubectl debe estar configurado para usar el extremo privado.

Desde otras VM en la red de VPC del clúster: Otras VM pueden usar kubectl para comunicarse con el extremo privado solo si están en la misma región que el clúster y sus direcciones IP internas se incluyen en la lista de redes autorizadas de la instancia principal o están ubicadas en la misma subred en la que están los nodos del clúster. kubectl debe estar configurado para usar el extremo privado.

Desde direcciones IP públicas: Las máquinas con direcciones IP públicas pueden usar kubectl para comunicarse con el extremo público solo si sus direcciones IP públicas se incluyen en la lista de redes autorizadas. Esto incluye máquinas fuera de Google Cloud y VM de Google Cloud con direcciones IP externas.

Desde los nodos: Siempre se usa el extremo privado. kubectl debe estar configurado para usar el extremo privado.

Desde otras VM en la red de VPC del clúster: Otras VM pueden usar kubectl para comunicarse con el extremo privado solo si están en la misma región que el clúster. kubectl debe estar configurado para usar el extremo privado.

Desde direcciones IP públicas: Cualquier máquina con una dirección IP pública puede usar kubectl para comunicarse con el extremo público. Esto incluye máquinas fuera de Google Cloud y VM de Google Cloud con direcciones IP externas.

¿Qué sigue?