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 sobre cómo crear y administrar clústeres privados.

Los clústeres privados te permiten aislar los nodos de la conectividad entrante y saliente a la Internet pública. Este aislamiento se logra porque los nodos solo tienen direcciones IP internas.

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

Aunque las direcciones IP de los nodos son privadas, los clientes externos pueden llegar a los Services en el clúster. Por ejemplo, puedes crear un Service de tipo LoadBalancer, y los clientes externos pueden llamar a la dirección IP de este balanceador de cargas. También puedes crear un Service de tipo NodePort y, luego, crear un Ingress. GKE usa la información del Service y del Ingress para configurar un balanceador de cargas de HTTP(S). Los clientes externos pueden llamar a la dirección IP externa del balanceador de cargas de HTTP(S).

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

Arquitectura del clúster privado

Usa el Acceso privado a Google en clústeres privados

De forma predeterminada, el Acceso privado a Google está habilitado. Este proporciona nodos privados y sus cargas de trabajo con acceso de salida limitado a las API y los servicios de Google Cloud mediante la red privada de Google. Por ejemplo, el Acceso privado a Google permite que los nodos privados extraigan imágenes de contenedor de Container 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 VM que está en una red de VPC en un proyecto de Google. Un clúster regional tiene varios 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 una red de VPC de Google Cloud independiente contiene el plano de control de tu clúster. La red de VPC del plano de control se encuentra en un proyecto controlado por Google. El tráfico entre los nodos y el plano de control se enruta por completo mediante direcciones IP internas.

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

Todos los clústeres privados creados recientemente vuelven a usar de forma automática las conexiones de intercambio de tráfico entre redes de VPC existentes. El primer clúster privado zonal o regional que crees generará una nueva conexión de intercambio de tráfico entre redes de VPC. Los clústeres privados adicionales en la misma zona o región y en la misma red pueden usar el mismo intercambio de tráfico, sin necesidad de crear conexiones adicionales de este tipo. Por ejemplo, si creas dos clústeres privados de una sola zona en la zona us-east1-b y tres clústeres privados regionales en la región asia-east1, solo se crean dos conexiones de intercambio de tráfico. Sin embargo, si creas un clúster regional y un clúster zonal en la misma región (por ejemplo, asia-east1 y asia-east1-a), se crean dos conexiones de intercambio de tráfico diferentes. Puedes comprobar si tu clúster privado vuelve a usar las conexiones.

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. Puedes controlar el acceso a este extremo mediante las redes autorizadas o puedes inhabilitar el acceso al extremo público.

Acceso a los extremos del clúster

Puedes controlar el nivel de acceso a los extremos mediante 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 alternativa si configuraste tu red local para conectarte a Google Cloud mediante Cloud Interconnect y Cloud VPN. Esas tecnologías conectan de forma efectiva la red de tu empresa con tu VPC sin que el tráfico tenga que atravesar la Internet pública.

    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. Además, las redes autorizadas deben ser direcciones IP internas.

  • Acceso de extremo público habilitado, redes autorizadas habilitadas: El uso de clústeres privados con redes autorizadas habilitadas proporciona acceso restringido al plano de control desde las direcciones IP de origen que defines. Esta es una buena opción si no tienes una infraestructura de VPN existente o si tienes usuarios remotos o sucursales que se conectan a través de la Internet pública en lugar de la VPN empresarial, Cloud Interconnect o Cloud VPN.

  • Acceso de extremo público habilitado, redes autorizadas inhabilitadas: Esta es la opción predeterminada y también la opción menos restrictiva. Debido a que las redes autorizadas no están habilitadas, siempre que 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 de 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 Acceder a la instancia principal mediante su dirección IP externa.
    La opción Habilitar redes autorizadas de la instancia principal está habilitada de forma automática.
  1. Selecciona Habilitar nativo de VPC.
  2. Selecciona Clúster privado.
  3. Selecciona Acceder a la instancia principal mediante su dirección IP externa.
  4. Selecciona Habilitar redes autorizadas de instancia principal.
  1. Selecciona Habilitar nativo de VPC.
  2. Selecciona Clúster privado.
  3. Selecciona Acceder a la instancia principal mediante su dirección IP externa.
  4. Borra Habilitar redes autorizadas de instancia principal.
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 nodos y servidor de API

Los webhooks que usan un servicio con un targetPort que no sea 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 principales

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

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 y que puedan 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, o bien las direcciones IP internas se incluyen en la lista de redes autorizadas o se encuentran en la misma subred que 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, o bien las direcciones IP internas se incluyen en la lista de redes autorizadas o se encuentran en la misma subred que 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.

Próximos pasos