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 RFC 1918 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 Google Container Registry y envíen registros a Cloud Logging.

La instancia principal en clústeres privados

Cada clúster de GKE tiene un servidor de la API de Kubernetes llamado instancia principal. Se ejecuta en una VM que está en una red de VPC en el proyecto de Google. Un clúster regional tiene varias instancias principales, y cada una de ellas se ejecuta en su propia VM.

En los clústeres privados, la red de VPC de la instancia principal está conectada 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 la instancia principal del clúster. La red de VPC de la instancia principal se encuentra en un proyecto controlado por Google. El tráfico entre los nodos y la instancia principal 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

La instancia principal de un clúster privado tiene un extremo privado además de uno público. La instancia principal 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 de la instancia principal. En un clúster privado, los nodos siempre se comunican con el extremo privado de la instancia principal. 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 de la instancia principal. De forma predeterminada, herramientas como kubectl se comunican con la instancia principal en su extremo público. Puedes controlar el acceso a este extremo mediante las redes autorizadas de instancia principal 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 todo el acceso desde Internet a la instancia principal. 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 de la instancia principal 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 de la instancia principal deben ser direcciones IP RFC 1918.

  • Acceso al extremo público habilitado, redes autorizadas de la instancia principal habilitadas: El uso de clústeres privados con redes autorizadas de la instancia principal proporciona un acceso restringido a la instancia principal desde las direcciones IP de origen que definas. 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 al extremo público habilitado, redes autorizadas de la instancia principal inhabilitadas: Esta es la opción predeterminada y también la menos restrictiva. Debido a que las redes autorizadas de la instancia principal 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 a extremo público habilitado,
redes autorizadas de instancia principal habilitadas
Acceso a extremo público habilitado,
redes autorizadas de instancia principal inhabilitadas
Seguridad El nivel más alto de acceso restringido a la instancia principal. El acceso del cliente al extremo público de la instancia principal está bloqueado. Se debe acceder a la instancia principal desde direcciones IP internas. Acceso restringido a la instancia principal desde las direcciones IP internas y externas que definas. Acceso a la instancia principal 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 Selecciona Habilitar nativo de VPC.
Selecciona Clúster privado.
Borra Acceder a la instancia principal con su dirección IP externa.
La opción Habilitar redes autorizadas de la instancia principal está habilitada de forma automática.
Selecciona Habilitar nativo de VPC.
Selecciona Clúster privado.
Selecciona Acceder a la instancia principal mediante su dirección IP externa.
Selecciona Habilitar redes autorizadas de instancia principal.
Selecciona Habilitar nativo de la VPC.
Selecciona Clúster privado.
Selecciona Acceder a la instancia principal mediante su dirección IP externa.
Desmarca la opción Habilitar redes autorizadas de la 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 la instancia principal y los nodos

Los nodos siempre se comunican con la instancia principal mediante el extremo privado.

Redes autorizadas principales

Se requieren para acceder a las instancias principales 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 a la instancia principal. No puedes incluir direcciones IP externas en la lista de redes autorizadas de instancia principal, ya que el acceso al extremo público está inhabilitado.

Se requieren para acceder a la instancia principal desde direcciones IP externas y 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 a la instancia principal.

No se usan.

Si habilitas el acceso al extremo público de la instancia principal sin habilitar las redes autorizadas de la instancia principal, el acceso al extremo público de la instancia 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 están incluidas en la lista de redes autorizadas de la instancia principal. 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