Configura un clúster privado

Esta página explica cómo crear un clúster privado en Google Kubernetes Engine.

Descripción general

En un clúster privado, los nodos tienen direcciones IP RFC 1918 internas únicamente, lo que garantiza que las cargas de trabajo se aíslen de la Internet pública.

Cada clúster tiene un servidor de API de Kubernetes denominado instancia principal. Las instancias principales se ejecutan en VM en proyectos que son propiedad de Google. En un clúster privado, puedes controlar el acceso a la instancia principal.

Un clúster privado puede usar un balanceador de cargas de HTTP(S) o un balanceador de cargas de red para aceptar el tráfico de contenido nuevo, incluso si los nodos del clúster no tienen una dirección IP pública. Un clúster privado también puede usar un balanceador de cargas interno para aceptar tráfico desde la red de VPC.

Funciones

Los clústeres privados usan las siguientes características de GCP:

Intercambio de tráfico entre redes de VPC: Los clústeres privados requieren intercambio de tráfico entre redes de VPC. La red de VPC contiene los nodos del clúster, pero una red de VPC independiente en un proyecto que es propiedad de Google contiene la instancia principal. Las dos redes de VPC se conectan mediante el intercambio de tráfico entre redes de VPC. El tráfico entre los nodos y la instancia principal se enruta por completo mediante las direcciones IP internas.
Acceso privado a Google: Los nodos privados no tienen acceso a la Internet saliente debido a que no tienen direcciones IP externas. El acceso privado a Google proporciona nodos privados y sus cargas de trabajo con acceso de salida limitado a las API y servicios de Google Cloud Platform en la red privada de Google. Por ejemplo, el acceso privado a Google hace posible que los nodos privados extraigan imágenes de contenedor desde Google Container Registry y envíen registros a Stackdriver.

Requisitos

Los clústeres privados cuentan con los siguientes requisitos:

VPC nativa: Un clúster privado debe ser un clúster nativo de VPC que tenga habilitados los rangos de IP de alias. Los clústeres nativos de VPC no son compatibles con las redes heredadas.
Kubernetes versión 1.8.14-gke.0 o posterior: Los nodos de un clúster privado deben ejecutar Kubernetes versión 1.8.14-gke.0 o posterior.

Restricciones

Los clústeres privados tienen las siguientes restricciones:

No puedes convertir un clúster público existente en un clúster privado.
No puedes usar el rango de IP de una instancia principal de clúster, nodo, pod o servicio que se superponga con 172.17.0.0/16.
Un clúster privado deja de funcionar si se borran el intercambio de tráfico de VPC entre la instancia principal y los nodos del clúster, las reglas de firewall que permiten la entrada de tráfico desde la instancia principal del clúster hasta los nodos en el puerto 10250 o la ruta predeterminada a la puerta de enlace predeterminada de Internet.

Limitaciones

Los clústeres privados tienen las siguientes limitaciones:

Cada clúster privado que creas usa un intercambio de tráfico de red de VPC exclusivo. Cada red de VPC puede intercambiar tráfico con otras 25 redes de VPC.
El tamaño del bloque RFC 1918 de la instancia principal del clúster debe ser de /28.
Si bien GKE puede detectar la superposición con el bloque de direcciones de instancia principal del clúster, no puede detectar la superposición dentro de una red de VPC compartida.

Limitaciones para clústeres regionales

Actualmente, no puedes usar un proxy para llegar a la instancia principal del clúster mediante la dirección IP privada.

Antes de comenzar

Sigue estos pasos a fin de prepararte para esta tarea:

Asegúrate de habilitar la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Asegúrate de instalar el SDK de Cloud.
Configura el ID del proyecto predeterminado:
```
gcloud config set project [PROJECT_ID]
```
Si trabajas con clústeres zonales, configura tu zona de procesamiento predeterminada:
```
gcloud config set compute/zone [COMPUTE_ZONE]
```
Si trabajas con clústeres regionales, configura tu región de procesamiento predeterminada:
```
gcloud config set compute/region [COMPUTE_REGION]
```
Actualiza gcloud a la versión más reciente:
```
gcloud components update
```

Nota: Puedes anular esta configuración predeterminada en los comandos de gcloud con las marcas operativas --project, --zone, y --region.

Acceso a la instancia principal

En un clúster privado, la instancia principal tiene dos extremos:

Extremo privado: Es la dirección IP interna de la instancia principal detrás de un balanceador de cargas interno en la red de VPC de esa instancia. Los nodos se comunican con la instancia principal mediante el extremo privado. Cualquier VM en la red de VPC y en la misma región que el clúster privado puede usar el extremo privado.
Extremo público: Es la dirección IP externa de la instancia principal. Puedes configurar el acceso al extremo público. En el caso más restringido, no habrá acceso a este extremo. Puedes moderar la restricción si autorizas el acceso de rangos de direcciones determinados. También puedes quitar todas las restricciones y permitir que cualquier persona acceda al extremo público.

Cómo determinar extremos de clúster

Describe el clúster con los siguientes comandos para determinar sus extremos:

gcloud container clusters describe [CLUSTER-NAME] \
    --zone=[ZONE] | --region=[REGION] \
    --format="get(privateClusterConfig.privateEndpoint)"

gcloud container clusters describe [CLUSTER-NAME] \
    --zone=[ZONE] | --region=[REGION] \
    --format="get(privateClusterConfig.publicEndpoint)"

Donde:

[CLUSTER-NAME] es el nombre del clúster.
[ZONE] es la zona de un clúster zonal o [REGION] es la región de un clúster regional.

Acceso a los extremos del clúster

Los clústeres privados tienen tres combinaciones de parámetros de configuración para controlar el acceso a los extremos del clúster. En la siguiente tabla se describen estos tres parámetros de configuración.

	Acceso al extremo público inhabilitado	Acceso al extremo público habilitado y redes autorizadas de instancia principal habilitadas	Acceso al extremo público habilitado y 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.
Opciones de configuración de GCP Console	Selecciona Habilitar nativo de VPC. Selecciona Clúster privado. Borra Acceder a la instancia principal mediante su dirección IP externa. Habilitar redes autorizadas de instancia principal está habilitada automáticamente.	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 VPC. Selecciona Clúster privado. Selecciona Acceder a la instancia principal mediante su dirección IP externa. Borra Habilitar redes autorizadas de instancia principal.
Marcas de creación de clúster `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	Necesario para acceder a las instancias principales desde direcciones IP internas que no sean nodos ni pods. No es necesario que autorices de manera explícita los rangos de direcciones IP internas de los nodos y pods. Esas direcciones internas siempre están autorizadas para comunicarse con el extremo privado. Usa `--master-authorized-networks` para especificar direcciones IP internas adicionales que puedan 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.	Necesario 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 y que puedan acceder a la instancia principal.	No se usa. 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` se debe configurar para que use 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 únicamente si están en la misma región que el clúster y si sus direcciones IP internas están incluidas en la lista de redes autorizadas de instancia principal. Desde direcciones IP públicas: Nunca.	Desde los nodos: Siempre se usa el extremo privado. `kubectl` se debe configurar para que use 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 únicamente si están en la misma región que el clúster y si sus direcciones IP internas están incluidas en la lista de redes autorizadas de instancia principal. 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 de instancia principal. Esto incluye máquinas fuera de GCP y VM de GCP con direcciones IP externas.	Desde los nodos: Siempre se usa el extremo privado. `kubectl` se debe configurar para que use 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 únicamente si están en la misma región que el clúster. 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 GCP y VM de GCP con direcciones IP externas.

Cómo crear un clúster privado con acceso limitado al extremo público

Cuando creas un clúster privado, debes especificar un rango de direcciones /28 RFC 1918 para que la instancia principal del clúster lo use. El rango que especifiques para la instancia principal del clúster no debe superponerse con ninguna subred en la red de VPC. Después de crear el clúster, no puedes cambiar el rango de direcciones de la instancia principal del clúster.

Cómo usar una subred generada automáticamente

En esta sección, podrás crear un clúster privado con el nombre private-cluster-0. GKE genera automáticamente una subred para los nodos del clúster. La subred tiene habilitado el acceso privado a Google. GKE crea automáticamente dos rangos secundarios en la subred: Uno para los pods y otro para los servicios.

gcloud

Ejecuta el siguiente comando:

gcloud container clusters create private-cluster-0 \
    --create-subnetwork name=my-subnet-0 \
    --enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --master-ipv4-cidr 172.16.0.0/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

Donde:

--enable-master-authorized-networks especifica que el acceso al extremo público está restringido a los rangos de direcciones IP que autorices.
--create-subnetwork name=my-subnet-0 hace que GKE cree automáticamente una subred con el nombre my-subnet-0.
--enable-ip-alias hace que el clúster sea nativo de VPC.
--enable-private-nodes indica que los nodos del clúster no tienen direcciones IP externas.
--master-ipv4-cidr 172.16.0.0/28 especifica un rango RFC 1918 para la instancia principal. Estos parámetros de configuración son permanentes para este clúster.

Console

Sigue los siguientes pasos:

Visita el menú de GKE en Google Cloud Platform Console.

Visita el menú de GKE.
Haz clic en Crear clúster.
Elige la plantilla Clúster estándar o elige una plantilla adecuada para tu carga de trabajo.
Para Nombre del clúster ingresa my-subnet-0.
Haz clic en Opciones avanzadas en la parte inferior del menú.
En Nativo de VPC, selecciona la casilla de verificación Habilitar nativo de VPC (con IP de alias). Permite que el menú desplegable de Red se configure a default y el menú desplegable de Subred de nodos a default. Esto hace que GKE genere una subred para el clúster.
En Seguridad de red, selecciona la casilla de verificación Clúster privado.
Para crear una instancia principal a la que se pueda acceder desde los rangos de IP externa autorizados, mantén seleccionada la casilla de verificación Acceso a la instancia principal con su dirección IP externa.
Configura el rango de IP de instancia principal a 172.16.0.0/28.
Mantén seleccionada la casilla de verificación __Habilitar redes autorizadas de instancia principal.
Desmarca la casilla de verificación Habilitar panel de Kubernetes.
Desmarca la casilla de verificación Emitir certificado de cliente.
Haz clic en Crear.

API

Especifica el campo privateClusterConfig en el recurso de API Cluster:

{
  "name": "private-cluster-0",
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
  },
  ...
    "privateClusterConfig" {
      "enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
      "enablePrivateEndpoint": boolean # false creates a cluster master with a publicly-reachable endpoint
      "masterIpv4CidrBlock": string # CIDR block for the cluster master
      "privateEndpoint": string # Output only
      "publicEndpoint": string # Output only
  }
}

En este punto, estas son las únicas direcciones IP que tienen acceso a la instancia principal del clúster:

El rango principal de my-subnet-0
El rango secundario que se usa para los pods

Supongamos que tienes un grupo de máquinas fuera de la red de VPC que tienen direcciones en el rango 203.0.113.0/29. Puedes autorizar a esas máquinas el acceso al extremo público si ingresas este comando:

gcloud container clusters update private-cluster-0 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

Ahora, estas son las únicas direcciones IP que tienen acceso a la instancia principal del clúster:

El rango principal de my-subnet-0
El rango secundario que se usa para los pods
Los rangos de direcciones autorizados, por ejemplo, 203.0.113.0/29

Cómo usar una subred personalizada

En esta sección, podrás crear un clúster privado con el nombre private-cluster-1. Crearás una red my-net-1 y, luego, una subred my-subnet-1 con el rango principal 192.168.0.0/20 para los nodos del clúster. La subred tendrá dos rangos de direcciones secundarios: my-pods-1 para la dirección IP del pod y my-services-1 para la dirección IP del servicio.

gcloud

Crear una red

Primero, crea una red para el clúster. El siguiente comando crea una red my-net-1:

gcloud compute networks create my-net-1 \
    --subnet-mode custom

Crear una subred y rangos secundarios

A continuación, crea una subred my-subnet-1 en la red my-net-1 con rangos secundarios my-pods-1 para los pods y my-services-1 para los servicios:

gcloud compute networks subnets create my-subnet-1 \
    --network my-net-1\
    --region us-central1 \
    --range 192.168.0.0/20 \
    --secondary-range my-pods-1=10.4.0.0/14,my-services-1=10.0.32.0/20 \
    --enable-private-ip-google-access

Crear un clúster privado

Ahora, crea un clúster privado private-cluster-1 con la red, la subred y los rangos secundarios que creaste.

gcloud container clusters create private-cluster-1 \
    --zone us-central1-c \
    --enable-master-authorized-networks \
    --enable-ip-alias \
    --network my-net-1 \
    --subnetwork my-subnet-1 \
    --cluster-secondary-range-name my-pods-1 \
    --services-secondary-range-name my-services-1 \
    --enable-private-nodes \
    --master-ipv4-cidr 172.16.0.16/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

Console

Crear una red, subred y rangos secundarios

Visita la página “Redes de VPC” de GCP Console.

Ir a la página Redes de VPC
Haz clic en Crear red de VPC.
En Nombre, ingresa my-net-1.
Asegúrate de que el Modo de creación de subred esté configurado en Personalizado.
En nueva Subred, en Nombre, ingresa my-subnet-1.
En el menú desplegable de Región, selecciona la región que desees.
Para el rango de direcciones IP, ingresa 192.168.0.0/20.
Haz clic en Crear rango de IP secundario. En el nombre del rango de la Subred ingresa my-services-1, y en el rango de IP secundario ingresa 10.0.32.0/20.
Haz clic en Agregar rango de IP. En el nombre del rango de la Subred ingresa my-pods-1, y en el rango de IP secundario ingresa 10.4.0.0/14.
En acceso privado a Google, haz clic en Activar.
Haz clic en Listo.
Haz clic en Crear.

Crear un clúster privado

Crea un clúster privado que use la subred:

Visita el menú de GKE en GCP Console.

Visita el menú de GKE.
Haz clic en Crear clúster.
Elige la plantilla Clúster estándar o elige una plantilla adecuada para tu carga de trabajo.
Para Nombre del clúster ingresa private-cluster-1.
Haz clic en Opciones avanzadas en la parte inferior del menú.
En Nativo de VPC, selecciona la casilla de verificación Habilitar nativo de VPC (con IP de alias).
En el menú desplegable de Red, selecciona my-net-1.
En el menú desplegable de Red de nodos, selecciona my-subnet-1.
Desactiva la casilla de verificación Crear rangos secundarios automáticamente.
En el menú desplegable de Rango de CIDR secundario de pods, selecciona my-pods-1.
En el menú desplegable de Rango de CIDR secundario de servicios, selecciona my-services-1.
En Seguridad de red, selecciona la casilla de verificación Clúster privado.
Configura el rango de IP de instancia principal a 172.16.0.16/28.
Mantén seleccionada la casilla de verificación __Habilitar redes autorizadas de instancia principal.
Desmarca la casilla de verificación Habilitar panel de Kubernetes.
Desmarca la casilla de verificación Emitir certificado de cliente.
Haz clic en Crear.

En este punto, estas son las únicas direcciones IP que tienen acceso a la instancia principal del clúster:

El rango principal de my-subnet-1
El rango secundario my-pods-1

Supongamos que tienes un grupo de máquinas fuera de my-net-1 y que tienen direcciones en el rango 203.0.113.0/29. Puedes autorizar a esas máquinas el acceso al extremo público si ingresas este comando:

gcloud container clusters update private-cluster-1 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

En este punto, estas son las únicas direcciones IP que tienen acceso a la instancia principal del clúster:

El rango principal de my-subnet-1
El rango secundario my-pods-1
Los rangos de direcciones autorizados, por ejemplo, 203.0.113.0/29

Cómo usar Cloud Shell para acceder a un clúster privado

El clúster privado private-cluster-1 que creaste en el ejercicio anterior cuenta con un extremo público y tiene habilitadas las redes autorizadas de instancia principal. Si deseas usar Cloud Shell para acceder al clúster, debes agregar la dirección IP pública de Cloud Shell a la lista de clústeres de redes autorizadas de instancia principal.

En la ventana de línea de comandos de Cloud Shell, usa dig para buscar tu dirección IP externa de Cloud Shell:

dig +short myip.opendns.com @resolver1.opendns.com

Agrega la dirección externa de Cloud Shell a la lista del clúster de redes autorizadas de instancia principal:

gcloud container clusters update private-cluster-1 \
    --zone us-central1-c \
    --enable-master-authorized-networks \
    --master-authorized-networks [EXISTING_AUTH_NETS],[SHELL_IP]/32

Donde:

[EXISTING_AUTH_NETS] es la lista existente de redes autorizadas de instancia principal.
[SHELL_IP] es la dirección IP externa de Cloud Shell.

Obtén credenciales a fin de usar kubectl para acceder al clúster:

gcloud container clusters get-credentials private-cluster-1 \
    --zone us-central1-a \
    --project [PROJECT_ID]

Donde [PROJECT_ID] es el ID del proyecto.

Ahora, puedes usar kubectl en Cloud Shell para acceder al clúster privado. Por ejemplo:

kubectl get nodes

Cómo crear un clúster privado sin acceso de clientes al extremo público

En esta sección, podrás crear un clúster privado con nodos privados y sin acceso al extremo público. Solo se puede acceder a la instancia principal del clúster desde la red de VPC. No podrás acceder a la instancia principal desde el exterior de la red de VPC.

gcloud

Ejecuta el siguiente comando:

gcloud container clusters create private-cluster-2 \
    --create-subnetwork name=my-subnet-2 \
    --enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --enable-private-endpoint \
    --master-ipv4-cidr 172.16.0.32/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

Donde:

--enable-master-authorized-networks especifica que el acceso al extremo público está restringido a los rangos de direcciones IP que autorices.
--create-subnetwork name=my-subnet-2 hace que GKE cree automáticamente una subred con el nombre my-subnet-2.
--enable-ip-alias hace que el clúster sea nativo de VPC.
--enable-private-nodes indica que los nodos del clúster no tienen direcciones IP externas.
--master-ipv4-cidr 172.16.0.32/28 especifica un rango RFC 1918 para la instancia principal. Estos parámetros de configuración son permanentes para este clúster.

Console

Sigue los siguientes pasos:

Visita el menú de GKE en Google Cloud Platform Console.

Visita el menú de GKE.
Haz clic en Crear clúster.
Elige la plantilla Clúster estándar o elige una plantilla adecuada para tu carga de trabajo.
Para Nombre del clúster ingresa my-subnet-2.
Haz clic en Opciones avanzadas en la parte inferior del menú.
En Nativo de VPC, selecciona la casilla de verificación Habilitar nativo de VPC (con IP de alias). Permite que el menú desplegable de Red se configure a default y el menú desplegable de Subred de nodos a default. Esto hace que GKE genere una subred para el clúster.
En Seguridad de red, selecciona la casilla de verificación Clúster privado.
Borra la casilla de verificación Acceder a la instancia principal mediante su dirección IP externa. Ten en cuenta que __ Habilitar instancia principal está autorizada.
Configura el rango de IP de instancia principal a 172.16.0.32/28.
La casilla de verificación __Habilitar redes autorizadas de instancia principal está seleccionada automáticamente.
Desmarca la casilla de verificación Habilitar panel de Kubernetes.
Desmarca la casilla de verificación Emitir certificado de cliente.
Haz clic en Crear.

API

Para crear un clúster con una instancia principal de acceso público, especifica el campo enablePrivateEndpoint: true en el recurso privateClusterConfig.

En este punto, estas son las únicas direcciones IP que tienen acceso a la instancia principal del clúster:

El rango principal de my-subnet-2
El rango secundario que se usa para los pods

Por ejemplo, supongamos que creaste una VM en el rango principal de my-subnet-2. En esa VM, puedes configurar kubectl para usar la dirección IP interna de la instancia principal.

Si deseas acceder a la instancia principal del clúster desde el exterior de my-subnet-2, debes autorizar al menos un rango de direcciones para tener acceso al extremo privado.

Supongamos que tienes una VM que se encuentra en la red predeterminada en la misma región que el clúster, pero no en my-subnet-2.

Por ejemplo:

my-subnet-2: 10.0.0.0/22
Rango secundario del pod: 10.52.0.0/14
Dirección de la VM: 10.128.0.3

Puedes autorizar a la VM el acceso a la instancia principal con este comando:

gcloud container clusters update private-cluster-2 \
    --enable-master-authorized-networks \
    --master-authorized-networks 10.128.0.3/32

Cómo crear un clúster privado en una red de VPC compartida

Para obtener información sobre cómo crear un clúster privado en una red de VPC compartida, consulta la documentación de VPC compartida.

Notas sobre las redes autorizadas de instancia principal

Las redes autorizadas tienen las siguientes las limitaciones:

Puedes agregar hasta 20 redes autorizadas (bloques CIDR incluidos en la lista blanca) a un proyecto.

Para obtener más información, consulta Cómo agregar una red autorizada a un clúster existente.

Cómo verificar que los nodos no tengan IP externas

Después de crear un clúster privado, debes verificar que los nodos del clúster no tengan direcciones IP externas.

gcloud

Ejecuta el siguiente comando para verificar que los nodos del clúster no tengan direcciones IP externas:

kubectl get nodes --output wide

La columna EXTERNAL-IP de los resultados está vacía:

STATUS ... VERSION   EXTERNAL-IP  OS-IMAGE ...
Ready      v.8.7-gke.1                 Container-Optimized OS from Google
Ready      v1.8.7-gke.1                Container-Optimized OS from Google
Ready      v1.8.7-gke.1                Container-Optimized OS from Google

Console

Sigue estos pasos para verificar que los nodos del clúster no tengan direcciones IP externas:

Visita el menú de GKE en GCP Console.

Visita el menú de GKE.
En la lista de clústeres, haz clic en el clúster que desees.
En Grupo de nodos, haz clic en el nombre del grupo de instancias. Por ejemplo, gke-private-cluster-0-default-pool-5c5add1f-grp.
En la lista de instancias, verifica que las instancias no tengan direcciones IP externas.

Cómo ver la subred y los rangos de direcciones secundarios del clúster

Después de crear el clúster privado, podrás ver la subred y los rangos de direcciones secundarios que tú o GKE aprovisionaron para el clúster.

gcloud

Agrega todas las subredes a la lista

Ejecuta el siguiente comando para agregar las subredes de la red del clúster a la lista:

gcloud compute networks subnets list --network [NETWORK]

Donde [NETWORK] es la red del clúster privado. Si creaste el clúster con una subred creada automáticamente, usa default.

En el resultado del comando, busca el nombre de la subred del clúster.

Visualiza la subred del clúster

Obtén información sobre la subred creada automáticamente:

gcloud compute networks subnets describe [SUBNET_NAME]

Donde [SUBNET_NAME] es el nombre de la subred.

En el resultado, se muestra el rango de direcciones principal para los nodos (el primer campo ipCidrRange) y los rangos secundarios para los pods y servicios (en secondaryIpRanges):

...
ipCidrRange: 10.0.0.0/22
kind: compute#subnetwork
name: gke-private-cluster-1-subnet-163e3c97
...
privateIpGoogleAccess: true
...
secondaryIpRanges:
- ipCidrRange: 10.40.0.0/14
  rangeName: gke-private-cluster-1-pods-163e3c97
- ipCidrRange: 10.0.16.0/20
  rangeName: gke-private-cluster-1-services-163e3c97
...

Console

Visita la página “Redes de VPC” de GCP Console.

Ir a la página Redes de VPC
Haz clic en el nombre de la subred. Por ejemplo, gke-private-cluster-0-subnet-163e3c97.
En el Rango de direcciones IP, podrás ver el rango de direcciones principal de la subred. Este es el rango que se usa para los nodos.
En Rangos de IP secundarios, podrás ver el rango de direcciones IP para los pods y servicios.

Cómo ver los extremos del clúster privado

Puedes ver los extremos de un clúster privado con la herramienta de línea de comandos de gcloud o GCP Console.

gcloud

Ejecuta el siguiente comando:

gcloud container clusters describe [CLUSTER_NAME]

En el resultado, se muestran los extremos privados y públicos:

...
privateClusterConfig:
enablePrivateEndpoint: true
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.0.32/28
privateEndpoint: 172.16.0.34
publicEndpoint: 35.239.154.67

Console

Sigue los siguientes pasos:

Visita el menú de GKE en GCP Console.

Visita el menú de GKE.
En la lista, haz clic en el clúster que desees.
En la pestaña Detalles, en Clúster, busca el campo Extremo.

Extrae imágenes de contenedor desde un registro de imágenes

En un clúster privado, el entorno de ejecución del contenedor puede extraer imágenes de contenedor de Container Registry: No puede extraer imágenes de ningún otro registro de imágenes de contenedor en la Internet. Esto se debe a que los nodos de un clúster privado no tienen direcciones IP externas, por lo que no pueden comunicarse con servicios fuera de la red de Google, según la configuración predeterminada.

Los nodos de un clúster privado pueden comunicarse con los servicios de Google, como Container Registry, si se encuentran en una subred que tenga habilitado el acceso privado a Google.

Los siguientes comandos crean una implementación que extrae una imagen de muestra de un repositorio de Container Registry que es propiedad de Google:

kubectl run hello-deployment --image gcr.io/google-samples/hello-app:2.0

Otros parámetros de configuración del clúster privado

Además de los parámetros de configuración anteriores, puedes ejecutar clústeres privados con los siguientes parámetros.

Cómo otorgar a los nodos privados acceso a Internet saliente

Los nodos privados no tienen acceso a Internet saliente debido a que no tienen direcciones IP externas. Si deseas proporcionarles acceso a Internet saliente, puedes usar Cloud NAT o administrar tu propia puerta de enlace NAT.

Cómo ejecutar un clúster privado con proxies de red para la instancia principal

Puedes crear clústeres privados con proxies de red, de modo que no se pueda acceder a la instancia principal del clúster desde el exterior de tu red, excepto mediante un proxy que crees y un host en un espacio de IP privada.

Para obtener información, consulta Cómo crear clústeres privados de Google Kubernetes Engine con los proxies de red para el acceso externo.

Cómo agregar reglas de firewall para casos prácticos específicos

Según la configuración predeterminada, las reglas de firewall restringen la instancia principal del clúster para iniciar únicamente conexiones TCP a los nodos en los puertos 443 (HTTPS) y 10250 (kubelet). Para algunas funciones de Kubernetes, es posible que debas agregar reglas de firewall a fin de permitir el acceso a puertos adicionales. Por ejemplo, en Kubernetes 1.9 y versiones anteriores, kubectl top accede a heapster, que requiere una regla de firewall para permitir que se realicen las conexiones TCP en el puerto 8080. Para otorgar este acceso, puedes agregar reglas de firewall.

En las siguientes secciones, se explica cómo agregar una regla de firewall a un clúster privado.

Cómo ver el bloque CIDR de la instancia principal del clúster

El bloque CIDR de la instancia principal del clúster es necesario para agregar una regla de firewall.

gcloud

Ejecuta el siguiente comando:

gcloud container clusters describe [CLUSTER_NAME]

En el resultado del comando, anota el valor en el campo masterIpv4CidrBlock.

Console

Visita el menú de GKE en GCP Console.

Visita el menú de GKE.
Selecciona el clúster que desees.

En la pestaña Detalles, en Clúster, anota el valor en el campo Rango de direcciones de la instancia principal.

Cómo ver las reglas de firewall existentes

Debes especificar el destino (en este caso, los nodos de destino) que usan las reglas de firewall existentes del clúster.

gcloud

Ejecuta el siguiente comando:

gcloud compute firewall-rules list \
    --filter 'name~^gke-[CLUSTER_NAME]' \
    --format 'table(
        name,
        network,
        direction,
        sourceRanges.list():label=SRC_RANGES,
        allowed[].map().firewall_rule().list():label=ALLOW,
        targetTags.list():label=TARGET_TAGS
    )'

En el resultado del comando, anota el valor en el campo Destinos.

Console

Sigue los siguientes pasos:

Visita el menú de Reglas de firewall en GCP Console.

Visita el menú de Reglas de firewall.
Llena el cuadro Filtrar recursos con gke-[CLUSTER_NAME].

En los resultados, anota el valor en el campo Destinos.

Cómo agregar una regla de firewall

gcloud

Ejecuta el siguiente comando:

gcloud compute firewall-rules create [FIREWALL_RULE_NAME] \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges [MASTER_CIDR_BLOCK] \
    --rules [PROTOCOL]:[PORT] \
    --target-tags [TARGET]

Donde:

[FIREWALL_RULE_NAME] es el nombre que elegiste para la regla de firewall.
[MASTER_CIDR_BLOCK] es el bloque CIDR de la instancia principal del clúster que recolectaste anteriormente.
[PROTOCOL]:[PORT] es el puerto deseado y su protocolo, tcp o udp.
[TARGET] es el destino con valor que recopilaste anteriormente.

Console

Sigue los siguientes pasos:

Visita el menú de Reglas de firewall en GCP Console.

Visita el menú de Reglas de firewall.
Haz clic en Crear regla de firewall.
Llena el cuadro Nombre con el nombre que desees para la regla de firewall.
En el menú desplegable de Red, selecciona la red correspondiente.
En Dirección del tráfico, haz clic en Ingress.
En Acción en caso de coincidencia, haz clic en Permitir.
En el menú desplegable de Destinos, selecciona Etiquetas de destino especificadas.
Llena el cuadro Etiquetas de destino con el valor del destino que recopilaste anteriormente.
En el menú desplegable de Filtro de fuente, selecciona rangos de IP.
Llena el cuadro rangos de IP fuente con el bloque CIDR de la instancia principal del clúster que recopilaste anteriormente.
En Protocolos y puertos, haz clic en Protocolos y puertos especificados, marca la casilla del protocolo correspondiente (TCP o UDP) y llena el cuadro con el puerto deseado.
Haz clic en Crear.

Limpieza

Después de completar las tareas de esta página, sigue estos pasos para quitar los recursos a continuación y evitar que se hagan cargos no deseados a tu cuenta:

Borrar los clústeres

gcloud

gcloud container clusters delete -q private-cluster-0 private-cluster-1

Console

Visita el menú de GKE en GCP Console.

Visita el menú de GKE.
Selecciona cada clúster.
Haz clic en Borrar.

Borrar la red

gcloud

gcloud compute networks delete net-0

Console

Ve a la página Redes de VPC en GCP Console.

Ir a la página Redes de VPC
En la lista de redes, en net-0, haz clic en el ícono de la papelera.
Junto a cada subred, haz clic en el ícono de la papelera.

Solución de problemas

En las siguientes secciones, se explica cómo resolver problemas comunes relacionados con los clústeres privados.

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

Síntomas: Cuando se intenta crear un clúster privado, se muestra un error similar a 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 de instancia principal superpuesto.
Resolución: Borra y vuelve a crear el clúster con otro CIDR de instancia principal.

No se puede llegar a la instancia principal

Síntomas: Después de crear un clúster privado, cuando se intentan ejecutar los comandos kubectl en el clúster, se muestra un error como Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed out o Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
Causas posibles: kubectl no puede comunicarse con la instancia principal del clúster.
Resolución: Debes agregar redes autorizadas para que el clúster incluya en la lista blanca las direcciones IP de tu red.

No se puede crear el clúster debido a una marca omitida

Síntomas: gcloud container clusters create muestra un error como Cannot specify --enable-private-endpoint without --enable-private-nodes.
Causas posibles: No especificaste una marca necesaria.
Resolución: Asegúrate de haber especificado las marcas necesarias. No puedes habilitar un extremo privado para la instancia principal del clúster sin habilitar los nodos privados.

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

Síntomas: gcloud container clusters create muestra un error como 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 de instancia principal que se superpone con una subred existente en VPC.
Resolución: Especifica un bloque CIDR para --master-ipv4-cidr que no se superponga con una subred existente.

No se puede crear la subred

Síntomas: Si intentas crear una subred personalizada o un clúster privado con una subred automática, es posible que recibas este 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 de CIDR de instancia principal que especificaste se superpone con otro rango de IP en el clúster. Esto también puede ocurrir si recientemente borraste un clúster privado y ahora intentas crear uno nuevo con el mismo CIDR de instancia principal.
Resolució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 el clúster muestra una advertencia en kubectl describe como 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 acceso saliente a la Internet pública. Tienen acceso limitado a las API y servicios de Google, incluido Container Registry.
Resolución: A fin de usar imágenes de Docker Hub en un clúster privado, configura el daemon de Docker para recuperar imágenes desde la duplicación de Docker Hub de Container Registry. Luego, recuperarás imágenes de la duplicación en lugar de Docker Hub directamente.

Descripción general

Funciones

Requisitos

Restricciones

Limitaciones

Limitaciones para clústeres regionales

Antes de comenzar

Acceso a la instancia principal

Cómo determinar extremos de clúster

Acceso a los extremos del clúster

Cómo crear un clúster privado con acceso limitado al extremo público

Cómo usar una subred generada automáticamente

gcloud

Console

API

Cómo usar una subred personalizada

gcloud

Crear una red

Crear una subred y rangos secundarios

Crear un clúster privado

Console

Crear una red, subred y rangos secundarios

Crear un clúster privado

Cómo usar Cloud Shell para acceder a un clúster privado

Cómo crear un clúster privado sin acceso de clientes al extremo público

gcloud

Console

API

Cómo crear un clúster privado en una red de VPC compartida

Notas sobre las redes autorizadas de instancia principal

Cómo verificar que los nodos no tengan IP externas

gcloud

Console

Cómo ver la subred y los rangos de direcciones secundarios del clúster

gcloud

Agrega todas las subredes a la lista

Visualiza la subred del clúster

Console

Cómo ver los extremos del clúster privado

gcloud

Console

Extrae imágenes de contenedor desde un registro de imágenes

Otros parámetros de configuración del clúster privado

Cómo otorgar a los nodos privados acceso a Internet saliente

Cómo ejecutar un clúster privado con proxies de red para la instancia principal

Cómo agregar reglas de firewall para casos prácticos específicos

Cómo ver el bloque CIDR de la instancia principal del clúster

gcloud

Console

Cómo ver las reglas de firewall existentes

gcloud

Console

Cómo agregar una regla de firewall

gcloud

Console

Limpieza

Borrar los clústeres

gcloud

Console

Borrar la red

gcloud

Console

Solución de problemas

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

No se puede llegar a la instancia principal

No se puede crear el clúster debido a una marca omitida

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

No se puede crear la subred

No se puede extraer la imagen de Docker Hub público

¿Qué sigue?

Enviar comentarios sobre...