Crea un clúster privado

En esta página, se explica cómo crear un clúster privado de Google Kubernetes Engine (GKE), que es un tipo de clúster nativo de la VPC. En un clúster privado, los nodos solo tienen direcciones IP internas, lo que significa que los nodos y los Pods están aislados de la Internet de forma predeterminada.

Las direcciones IP internas de los nodos provienen del rango de direcciones IP principal de la subred que eliges para el clúster. Las direcciones IP de los Pods y de los servicios provienen de dos rangos de direcciones IP secundarios de esa misma subred. Consulta Rangos de IP para clústeres nativos de la VPC si deseas obtener más detalles.

La versión 1.14.2 y posteriores de GKE admiten cualquier rango de direcciones IP internas, incluidos los rangos privados (RFC 1918 y otros rangos privados) y los rangos de direcciones IP públicas utilizados de forma privada. Consulta la documentación de VPC para obtener una lista de los rangos de direcciones IP internas válidos.

Para obtener más información sobre cómo funcionan los clústeres privados, consulta Clústeres privados.

Antes de comenzar

Familiarízate con los requisitos, las restricciones y las limitaciones antes de avanzar al siguiente paso.

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Asegúrate de que habilitaste la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Asegúrate de que instalaste el SDK de Cloud.

Establece la configuración de gcloud predeterminada mediante uno de los siguientes métodos:

Usa gcloud init si deseas ver una explicación sobre cómo configurar parámetros predeterminados.
Usa gcloud config para establecer el ID, la zona y la región del proyecto de manera individual.

Usa gcloud init

Si recibes el error One of [--zone, --region] must be supplied: Please specify location, completa esta sección.

Ejecuta gcloud init y sigue las instrucciones:
```
gcloud init
```
Si usas SSH en un servidor remoto, usa la marca --console-only para evitar que el comando abra un navegador:
```
gcloud init --console-only
```
Sigue las instrucciones a fin de autorizar a gcloud para que use tu cuenta de Google Cloud.
Crea una configuración nueva o selecciona una existente.
Elige un proyecto de Google Cloud.
Elige una zona predeterminada de Compute Engine.

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

Usa gcloud config

Establece tu ID del proyecto predeterminado:
```
gcloud config set project PROJECT_ID
```
Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada:
```
gcloud config set compute/zone COMPUTE_ZONE
```
Si trabajas con clústeres regionales, establece 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 mediante las marcas --project, --zone y --region.

Asegúrate de tener el permiso correcto para crear clústeres. Como mínimo, debes ser un administrador de clústeres de Kubernetes Engine.

Accede al plano de control

En los clústeres privados, el plano de control (principal) tiene un extremo público y uno privado. Existen tres combinaciones de configuración para controlar el acceso a los extremos de los clústeres:

Acceso al extremo público inhabilitado: crea un clúster privado sin acceso de clientes al extremo público.
Acceso de extremo público habilitado, redes autorizadas habilitadas: crea un clúster privado con acceso limitado al extremo público.
Acceso al extremo público habilitado, redes autorizadas inhabilitadas: crea un clúster privado con acceso sin restricciones al extremo público.

Consulta Acceso a los extremos del clúster para obtener una descripción general de las diferencias entre las opciones de configuración anteriores.

Crea un clúster privado sin acceso de clientes al extremo público

En esta sección, crearás un clúster privado llamado private-cluster-0 que tenga nodos privados y que no tenga acceso de clientes al extremo público.

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 \
    --enable-private-endpoint \
    --master-ipv4-cidr 172.16.0.32/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

En el ejemplo anterior, se ilustra lo siguiente:

--create-subnetwork name=my-subnet-0 hace que GKE cree de forma automática una subred llamada my-subnet-0.
--enable-master-authorized-networks especifica que el acceso al extremo público está restringido a los rangos de direcciones IP que autorices.
--enable-ip-alias hace que el clúster sea nativo de la VPC.
--enable-private-nodes indica que los nodos del clúster no tienen direcciones IP externas.
--enable-private-endpoint indica que el clúster se administra mediante la dirección IP privada del extremo de la API del plano de control.
--master-ipv4-cidr 172.16.0.32/28 especifica un rango de direcciones IP internas para el plano de control. Esta configuración es permanente para este clúster. Se admite el uso de direcciones IP internas que no sean RFC 1918.
--no-enable-basic-auth indica que se debe inhabilitar la autenticación básica del clúster.
--no-issue-client-certificate inhabilita la emisión de un certificado de cliente.

Console

Ve al menú de Google Kubernetes Engine en Cloud Console.

Ir al menú Google Kubernetes Engine
Haz clic en Crear.
En Nombre, ingresa private-cluster-0.
En el panel de navegación, en Clúster, haz clic en Redes.
Selecciona Clúster privado.
Borra la casilla de verificación Acceder a la instancia principal mediante su dirección IP externa.
Configura el Rango de IP principal como 172.16.0.32/28.
Deja la Red y la Subred del nodo establecidas en default. Esto hace que GKE genere una subred para el clúster. La subred my-subnet-0 que se menciona a continuación hace referencia a la subred default creada en este paso.
En el panel de navegación, en Clúster, haz clic en Seguridad.
Asegúrate de que la casilla de verificación Emitir un certificado de cliente no esté marcada.
Haga clic en Crear.

API

Para crear un clúster con un plano de control accesible de forma pública, especifica el campo enablePrivateEndpoint: true en el recurso privateClusterConfig.

En este punto, estas son las únicas direcciones IP que tienen acceso al plano de control:

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

Por ejemplo, supongamos que creaste una VM en el rango primario de my-subnet-0. Luego, en esa VM, puedes configurar kubectl para usar la dirección IP interna del plano de control.

Si deseas acceder al plano de control desde fuera de my-subnet-0, debes autorizar al menos un rango de direcciones para que tenga acceso al extremo privado.

Supongamos que tienes una VM que está en la red predeterminada, en la misma región que tu clúster, pero no en my-subnet-0.

Por ejemplo:

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

Si deseas autorizar a la VM para que acceda al plano de control, ejecuta el siguiente comando:

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

Crea un clúster privado con acceso limitado al extremo público

Cuando creas un clúster privado con esta configuración, puedes optar por usar una subred generada automáticamente o una subred personalizada.

Usa una subred generada automáticamente

En esta sección, crearás un clúster privado llamado private-cluster-1 en el que GKE generará de forma automática una subred para los nodos de 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-1 \
    --create-subnetwork name=my-subnet-1 \
    --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

En el ejemplo anterior, se ilustra lo siguiente:

--create-subnetwork name=my-subnet-1 hace que GKE cree de forma automática una subred llamada my-subnet-1.
--enable-master-authorized-networks especifica que el acceso al extremo público está restringido a los rangos de direcciones IP que autorices.
--enable-ip-alias hace que el clúster sea nativo de la 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 de direcciones IP internas para el plano de control. Esta configuración es permanente para este clúster. Se admite el uso de direcciones IP internas que no sean RFC 1918.
--no-enable-basic-auth inhabilita la autenticación básica para el clúster.
--no-issue-client-certificate inhabilita la emisión de un certificado de cliente.

Console

Ve al menú de Google Kubernetes Engine en Cloud Console.

Ir al menú Google Kubernetes Engine
Haz clic en Crear.
En Nombre, ingresa my-subnet-1.
En el panel de navegación, en Clúster, haz clic en Redes.
Selecciona Clúster privado.
Para crear un plano de control accesible desde los rangos de IP externos autorizados, mantén seleccionada la casilla de verificación Acceder a la instancia principal con su dirección IP externa.
Configura el Rango de IP principal como 172.16.0.0/28.
Deja la Red y la Subred del nodo establecidas en default. Esto hace que GKE genere una subred para el clúster. La subred my- subnet-1 que se menciona a continuación hace referencia a la subred creada en este paso.
Selecciona la casilla de verificación Habilitar redes autorizadas de la instancia principal.
En el panel de navegación, en Clúster, haz clic en Seguridad.
Asegúrate de que la casilla de verificación Emitir un certificado de cliente no esté marcada.
Haga clic en Crear.

API

Especifica el campo privateClusterConfig en el recurso de la API de Cluster:

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

En este punto, estas son las únicas direcciones IP que tienen acceso al plano de control del clúster:

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

Supongamos que tienes un grupo de máquinas fuera de tu red de VPC que tienen direcciones en el rango 203.0.113.0/29. Si deseas autorizar a esas máquinas a que accedan al extremo público, ejecuta este comando:

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

Ahora estas son las únicas direcciones IP que tienen acceso al plano de control:

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

Usa una subred personalizada

En esta sección, debes crear un clúster privado llamado private-cluster-2. Debes crear una red, my-net-0. Debes crear una subred, my-subnet-2, con rango primario 192.168.0.0/20, para tus nodos de clúster. Tu subred tiene dos rangos de direcciones secundarios: my-pods-1 para las direcciones IP de pod y my-services-1 para las direcciones IP de servicio.

gcloud

Crea una red

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

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

Crea una subred y rangos secundarios

Luego, crea una subred, my-subnet-2, en la red my-net-0, con rangos secundarios my-pods-2 para pods y my-services-2 para servicios:

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

Crea 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 \
    --network my-net-0 \
    --subnetwork my-subnet-2 \
    --cluster-secondary-range-name my-pods-2 \
    --services-secondary-range-name my-services-2 \
    --enable-private-nodes \
    --enable-ip-alias \
    --master-ipv4-cidr 172.16.0.16/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

Console

Crea una red, subred y rangos secundarios

Visita la página de redes de VPC en Cloud Console.

Visitar la página de redes de VPC
Haga clic en Crear red de VPC.
En Nombre, ingresa my-net-0.
Asegúrate de que el Modo de creación de subred esté configurado en Personalizado.
Dentro de la sección Subred nueva, en Nombre, ingresa my-subnet-2.
En la lista desplegable Región, selecciona la región deseada.
En Rango de direcciones IP, ingresa 192.168.0.0/20.
Haz clic en Crear rango de IP secundario. En Nombre de rango de subred, ingresa my-services-1 y, en Rango de IP secundario , ingresa 10.0.32.0/20.
Haz clic en Agregar rango de IP. En Nombre de rango de subred, ingresa my-pods-1 y, en Rango de IP secundario, ingresa 10.4.0.0/14.
Configura el Acceso privado a Google como Activado.
Haga clic en Listo.
Haga clic en Crear.

Crear un clúster privado

Crea un clúster privado que use tu subred:

Ve al menú de Google Kubernetes Engine en Cloud Console.

Ir al menú Google Kubernetes Engine
Haz clic en Crear.
En Nombre, ingresa private-cluster-2.
En el panel de navegación, en Clúster, haz clic en Redes.
Selecciona Clúster privado.
Para crear un plano de control accesible desde los rangos de IP externos autorizados, mantén seleccionada la casilla de verificación Acceder a la instancia principal con su dirección IP externa.
Configura el Rango de IP principal como 172.16.0.16/28.
En la lista desplegable Red, selecciona my-net-1.
En la lista desplegable Subred de nodo, selecciona my-subnet-2.
Desmarca la casilla de verificación Crear rangos secundarios automáticamente.
En la lista desplegable Rango de CIDR secundario del pod, selecciona my-pods-1.
En la lista desplegable Rango de CIDR secundario de servicios, selecciona my-services-1.
Selecciona la casilla de verificación Habilitar redes autorizadas de la instancia principal.
En el panel de navegación, en Clúster, haz clic en Seguridad.
Asegúrate de que la casilla de verificación Emitir un certificado de cliente no esté marcada.
Haga clic en Crear.

En este punto, estas son las únicas direcciones IP que tienen acceso al plano de control:

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

Supongamos que tienes un grupo de máquinas fuera de my-net-0, que tienen direcciones en el rango 203.0.113.0/29. Si deseas autorizar a esas máquinas a que accedan al extremo público, ejecuta 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 al plano de control:

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

Usa Cloud Shell para acceder a un clúster privado

El clúster privado que creaste en el ejercicio anterior, private-cluster-1, cuenta con un extremo público y tiene habilitadas las redes autorizadas. 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 redes autorizadas del clúster.

Para ello, haz lo siguiente:

En la ventana de línea de comandos de Cloud Shell, usa dig para encontrar la dirección IP externa de tu Cloud Shell:
```
dig +short myip.opendns.com @resolver1.opendns.com
```
Agrega la dirección externa de Cloud Shell a la lista de redes autorizadas del clúster:
```
gcloud container clusters update private-cluster-1 \
    --zone us-central1-c \
    --enable-master-authorized-networks \
    --master-authorized-networks EXISTING_AUTH_NETS,SHELL_IP/32
```
Reemplaza lo siguiente:
- EXISTING_AUTH_NETS: Es la lista existente de redes autorizadas. Puedes encontrar las redes autorizadas en Console o mediante la ejecución del siguiente comando:
```
gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"
```
- SHELL_IP: Es la dirección IP externa de tu Cloud Shell.
Obtén credenciales de modo que puedas usar kubectl para acceder al clúster:
```
gcloud container clusters get-credentials private-cluster-1 \
    --zone us-central1-a \
    --project PROJECT_ID
```
Reemplaza PROJECT_ID con el ID del proyecto.

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

kubectl get nodes

Crea un clúster privado con acceso ilimitado al extremo público

En esta sección, crearás un clúster privado en el que cualquier dirección IP pueda acceder al plano de control.

gcloud

Ejecuta el siguiente comando:

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

En el ejemplo anterior, se ilustra lo siguiente:

--create-subnetwork name=my-subnet-3 hace que GKE cree de forma automática una subred llamada my-subnet-3.
--no-enable-master-authorized-networks inhabilita las redes autorizadas para el clúster.
--enable-ip-alias hace que el clúster sea nativo de la 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 de direcciones interno para el plano de control. Esta configuración es permanente para este clúster. Se admite el uso de direcciones IP internas que no sean RFC 1918.
--no-enable-basic-auth indica que se debe inhabilitar la autenticación básica del clúster.
--no-issue-client-certificate inhabilita la emisión de un certificado de cliente.

Console

Ve al menú de Google Kubernetes Engine en Cloud Console.

Ir al menú Google Kubernetes Engine
Haz clic en Crear.
En Nombre, ingresa private-cluster-2.
En el panel de navegación, en Clúster, haz clic en Redes.
Selecciona Clúster privado.
Deja seleccionada la casilla de verificación Acceder a la instancia principal con su dirección IP externa.
Configura el Rango de IP principal como 172.16.0.32/28.
Deja la Red y la Subred del nodo establecidas en default. Esto hace que GKE genere una subred para el clúster.
Desmarca la casilla de verificación Habilitar redes autorizadas de la instancia principal.
En el panel de navegación, en Clúster, haz clic en Seguridad.
Asegúrate de que la casilla de verificación Emitir un certificado de cliente no esté marcada.
Haga clic en Crear.

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.

Otorga acceso a Internet saliente a los nodos privados

Para proporcionar acceso a Internet saliente a tus nodos privados, puedes usar Cloud NAT o administrar tu propia puerta de enlace NAT.

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

Implementa una aplicación de contenedor de Windows Server en un clúster privado

Para obtener información sobre cómo implementar una aplicación de contenedor de Windows Server en un clúster privado, consulta la documentación del grupo de nodos de Windows.

Accede al extremo privado del plano de control de forma global

El balanceador de cargas de TCP/UDP interno implementa el extremo privado del plano de control en la red de VPC del plano de control. Los clientes internos o conectados mediante túneles de Cloud VPN y adjuntos de VLAN de Cloud Interconnect pueden acceder a los balanceadores de cargas de TCP/UDP internos.

De forma predeterminada, estos clientes deben estar ubicados en la misma región que el balanceador de cargas.

Cuando habilitas el acceso global del plano de control, se puede acceder al balanceador de cargas de TCP/UDP interno de forma global: las VM del cliente y los sistemas locales pueden conectarse al extremo privado del plano de control, sujetos a la configuración de las redes autorizadas de cualquier región.

Para obtener más información sobre los balanceadores de cargas TCP/UDP internos y el acceso global, consulta Balanceadores de cargas internos y redes conectadas.

Habilita el acceso global al extremo privado del plano de control

De forma predeterminada, el acceso global no está habilitado para el extremo privado del plano de control cuando creas un clúster privado. Para habilitar el acceso global al plano de control, usa gcloud o Google Cloud Console.

gcloud

Agrega la marca enable-master-global-access para crear un clúster privado con acceso global al extremo privado habilitado del plano de control:

gcloud container clusters create CLUSTER_NAME \
  --enable-private-nodes \
  --enable-ip-alias \
  --master-ipv4-cidr=172.16.16.0/28 \
  --enable-master-global-access

También puedes habilitar el acceso global al extremo privado del plano de control para un clúster privado existente:

gcloud container clusters update CLUSTER_NAME \
  --enable-master-global-access

Console

Para crear un clúster privado nuevo con el acceso global al plano de control habilitado, sigue estos pasos:

Ve al menú de Google Kubernetes Engine en Cloud Console.

Ir al menú Google Kubernetes Engine
Haz clic en Crear.
Ingresa un Nombre.
En el panel de navegación, en Clúster, haz clic en Redes.
Selecciona Clúster privado.
Selecciona la casilla de verificación Acceso global principal.
Configura otros campos como desees.
Haga clic en Crear.

Para habilitar el acceso global al plano de control de un clúster privado existente, sigue estos pasos:

Ve al menú de Google Kubernetes Engine en Cloud Console.

Ir al menú Google Kubernetes Engine
Junto al clúster que deseas editar, haz clic en Acciones y, luego, en Editar.
En la sección Herramientas de redes, junto a Acceso global principal, haz clic en Editar.
En el cuadro de diálogo Editar acceso global principal, selecciona la casilla de verificación Habilitar el acceso global principal.
Haz clic en Guardar cambios.

Verifica el acceso global al extremo del plano de control

Para verificar que el acceso global al extremo privado del plano de control esté habilitado, ejecuta el siguiente comando y observa su resultado.

gcloud container clusters describe CLUSTER_NAME

En el resultado, se incluye una sección privateClusterConfig en la que puedes ver el estado de masterGlobalAccessConfig.

privateClusterConfig:
  enablePrivateNodes: true
  masterIpv4CidrBlock: 172.16.1.0/28
  peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
  privateEndpoint: 172.16.1.2
  publicEndpoint: 34.68.128.12
  masterGlobalAccessConfig:
    enabled: true

Conéctate al extremo privado del plano de control desde redes locales

Cuando creas un clúster privado de GKE e inhabilitas el extremo público del plano de control, aún puedes conectarte al extremo privado del plano de control desde una red local mediante herramientas como kubectl. En esta sección, se describen los requisitos de red necesarios para acceder al extremo privado del plano de control desde una red local.

En el siguiente diagrama, se muestra el enrutamiento entre los nodos de una red local y del plano de control de GKE:

Diagrama que muestra el enrutamiento entre la VPC local y el plano de control del clúster

Para conectarte al extremo privado de un plano de control desde la red local, completa las siguientes tareas:

Identifica el intercambio de tráfico entre la red de VPC de tu clúster y la del plano de control:
```
gcloud container clusters describe CLUSTER_NAME
```
En el resultado de este comando, se incluye el campo privateClusterConfig.peeringName del clúster. Este es el nombre del intercambio de tráfico entre tu clúster y la red de VPC del plano de control. Por ejemplo:
```
privateClusterConfig:
  enablePrivateNodes: true
  masterIpv4CidrBlock: 172.16.1.0/28
  peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
  privateEndpoint: 172.16.1.2
  publicEndpoint: 34.68.128.12
```
Configura la red de VPC para exportar sus rutas personalizadas en la relación de intercambio de tráfico a la red de VPC del plano de control. La red de VPC del plano de control ya está configurada para importar rutas personalizadas. Esto proporciona una ruta para que el plano de control envíe paquetes a recursos locales.

Actualiza la conexión de intercambio de tráfico, lo que habilita la exportación de rutas personalizadas para la conexión de intercambio de tráfico que identificaste en el paso anterior.
A fin de proporcionar una ruta para el tráfico desde la red local a la red de VPC del plano de control, realiza una de las siguientes acciones:
- Para Cloud Interconnect y Cloud VPN: Anuncia el rango de CIDR del plano de control mediante un anuncio de ruta personalizada de Cloud Router. Si el acceso global al plano de control está inhabilitado, este anuncio de ruta personalizada debe estar en una sesión de BGP de un Cloud Router en la misma región que el clúster. Si el acceso global al plano de control está habilitado, puedes colocar este anuncio de ruta personalizada en un Cloud Router en cualquier región. Consulta Anuncia rangos de IP personalizados para obtener más información.
- En un túnel VPN clásica que no usa el enrutamiento dinámico, debes configurar una ruta estática para el rango de CIDR del plano de control en las routers locales.

Consideraciones para los anuncios de rutas locales

Los CIDR que la red local anuncia a los Cloud Routers en la red de VPC del clúster deben cumplir con las siguientes condiciones:

Mientras que la VPC del clúster aceptará una ruta predeterminada, la red de VPC del plano de control siempre rechaza las rutas con el destino 0.0.0.0/0 (una ruta predeterminada) porque la red de VPC del plano de control ya tiene una ruta predeterminada local que siempre se considera primero. Si el router local anuncia una ruta predeterminada en la red de VPC, también debe anunciar destinos locales específicos para que el plano de control tenga una ruta de retorno a la red local. Estos destinos más específicos dan como resultado rutas dinámicas personalizadas más específicas en la red de VPC. La red de VPC del plano de control acepta estas rutas a través del intercambio de tráfico entre redes de VPC.
Cuando la red de VPC del plano de control acepta otras rutas amplias, rompen la conectividad a las direcciones IP públicas para los servicios y las API de Google. Como ejemplo representativo, no debes anunciar rutas con los destinos 0.0.0.0/1 y 128.0.0.0/1. Consulta el punto anterior para ver una alternativa.
Presta mucha atención a los límites de Cloud Router, en especial, a la cantidad máxima de destinos únicos para las rutas aprendidas.

Inhabilita la exportación de rutas personalizadas

Para inhabilitar la exportación de rutas personalizadas desde tu VPC, haz lo siguiente:

gcloud compute networks peerings update PEERING_NAME --network VPC_NAME --no-export-custom-routes

Reemplaza lo siguiente:

PEERING_NAME: Es el valor de privateClusterConfig.peeringName.
VPC_NAME: Es el nombre de tu VPC.

Para buscar el peeringName, consulta el primer paso de las instrucciones anteriores a fin de habilitar la exportación de rutas personalizadas.

Verifica que los nodos no tengan direcciones IP externas

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

gcloud

Ejecuta el siguiente comando:

kubectl get nodes --output wide

La columna EXTERNAL-IP del resultado 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

Ve al menú de Google Kubernetes Engine en Cloud Console.

Ir al menú Google Kubernetes Engine
En la lista de clústeres, haz clic en el nombre del clúster.
En la página Clústeres, haz clic en la pestaña Nodos.
En Grupos de nodos, haz clic en el nombre del grupo de nodos.
En la página de detalles del grupo de nodos, en Grupos de instancias, haz clic en el nombre de tu 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

Muestra todas las subredes

Ejecuta el siguiente comando para ver la lista de subredes de la red del clúster:

gcloud compute networks subnets list --network NETWORK_NAME

Reemplaza NETWORK_NAME por la red del clúster privado. Si creaste el clúster con una subred creada de forma automática, 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

Reemplaza SUBNET_NAME por 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 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 de redes de VPC en Cloud Console.

Visitar la página de 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.

Visualiza los extremos del clúster privado

Puedes ver los extremos del clúster privado con la herramienta de línea de comandos de gcloud o Cloud 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

Visita el menú de Google Kubernetes Engine en Cloud Console.

Ir al menú Google Kubernetes Engine
En la lista de clústeres, haz clic en el nombre.
En la pestaña Detalles, en Aspectos básicos del 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, pero 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

Agrega reglas de firewall para casos prácticos específicos

En esta sección, se explica cómo agregar una regla de firewall a un clúster privado. De forma predeterminada, las reglas de firewall restringen el plano de control del clúster para iniciar solo conexiones TCP a los nodos en los puertos 443 (HTTPS) y 10250 (kubelet). Para algunas características de Kubernetes, es posible que debas agregar reglas de firewall a fin de permitir el acceso a puertos adicionales.

Entre las funciones de Kubernetes que requieren reglas de firewall adicionales, se incluyen las siguientes:

Webhooks de admisión
Servidores de API agregados
Conversión de webhooks
Configuración de auditoría dinámica
Por lo general, cualquier API que tenga un campo ServiceReference requiere reglas de firewall adicionales

Agregar una regla de firewall permite el tráfico del plano de control del clúster a todos los siguientes puertos:

El puerto especificado de cada nodo (hostPort)
El puerto especificado de cada pod que se ejecuta en estos nodos.
El puerto especificado de cada servicio que se ejecuta en estos nodos

Para obtener más información, consulta Reglas de firewall en la documentación de Cloud Load Balancing.

Si deseas agregar una regla de firewall a un clúster privado, debes registrar el bloque CIDR del plano de control del clúster y el destino que se usó. Después de grabar esto, puedes crear la regla.

Paso 1. Visualiza el bloque CIDR del plano de control

El bloque CIDR del plano de control del clúster es necesario para agregar una regla de firewall.

gcloud

Ejecuta el siguiente comando:

gcloud container clusters describe CLUSTER_NAME

Reemplaza CLUSTER_NAME por el nombre de tu clúster privado.

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

Console

Ve al menú de Google Kubernetes Engine en Cloud Console.

Ir al menú Google Kubernetes Engine
En la lista de clústeres, haz clic en el nombre que desees.

En la pestaña Detalles, en Herramientas de redes, anota el valor en el campo Rango de direcciones de la instancia principal.

Paso 2. 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.

Nota: Para ver las reglas de firewall de una VPC compartida, agrega la marca --project HOST_PROJECT_ID al comando.

Para obtener más información sobre la VPC compartida, consulta Configura clústeres con una VPC compartida.

Console

Visita el menú Firewall en Cloud Console.

Visitar el menú Firewall
En Tabla de filtro (Filter table), ingresa gke-CLUSTER_NAME.

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

Paso 3. Agrega 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

Reemplaza lo siguiente:

FIREWALL_RULE_NAME: Es el nombre que elegiste para la regla de firewall.
MASTER_CIDR_BLOCK: Es el bloque CIDR del plano de control del clúster (masterIpv4CidrBlock) que obtuviste en el paso anterior.
PROTOCOL:PORT: Es el puerto deseado y su protocolo, tcp o udp.
TARGET: Es el valor de destino (Targets) que recopilaste antes.

Nota: Para agregar una regla de firewall a una VPC compartida, agrega las siguientes marcas al comando:

--project HOST_PROJECT_ID
--network NETWORK_ID

Para obtener más información sobre la VPC compartida, consulta Configura clústeres con una VPC compartida.

Console

Visita el menú Firewall en Cloud Console.

Visitar el menú Firewall
Haga clic en Crear regla de firewall.
En Nombre, ingresa el nombre que desees para la regla de firewall.
En la lista desplegable Red, selecciona la red relevante.
En Dirección del tráfico, haz clic en Ingress.
En Acción en caso de coincidencia, haz clic en Permitir.
En la lista desplegable Destinos, selecciona Etiquetas de destino especificadas.
En Etiquetas de destino, ingresa el valor de destino que anotaste antes.
En la lista desplegable Filtro de fuente, selecciona Rangos de IP.
En Rangos de IP de origen, ingresa el bloque CIDR del plano de control del clúster.
En Protocolos y puertos, haz clic en Protocolos y puertos especificados, selecciona la casilla de verificación para el protocolo relevante (tcp oudp ) y, luego, ingresa el número de puerto en el campo del protocolo.
Haga clic en Crear.

Protege un clúster privado con los Controles del servicio de VPC

Para proteger aún más tus clústeres privados de GKE, puedes usar los Controles del servicio de VPC.

Los Controles del servicio de VPC brindan seguridad adicional para tus clústeres privados de GKE a fin de mitigar el riesgo de robo de datos. Con los Controles del servicio de VPC, puedes agregar proyectos a perímetros de servicio que protejan los recursos y servicios de las solicitudes que se originan fuera del perímetro.

Para obtener más información sobre los perímetros de servicio, consulta la página de configuración del perímetro de servicio de la documentación de Controles del servicio de VPC.

Si usas Container Registry con tu clúster privado de GKE, se requieren pasos adicionales para usar ese clúster privado con los Controles del servicio de VPC. Si deseas obtener más información, consulta la página Configura Container Registry para clústeres privados de GKE.

Reutilización del intercambio de tráfico entre VPC

Todos los clústeres privados que crees después del 15 de enero de 2020 vuelven a usar las conexiones del intercambio de tráfico entre redes de VPC.

Todos los clústeres privados que creaste antes del 15 de enero de 2020 usan una única conexión de intercambio de tráfico entre redes de VPC. Cada red de VPC puede intercambiarse con hasta 25 redes de VPC, lo que significa que hay un límite máximo de 25 clústeres privados por red (si es que los intercambios de tráfico no se usan para otros fines).

Esta característica no se encuentra en versiones anteriores. Para habilitar la reutilización del intercambio de tráfico de red de VPC en clústeres privados más antiguos, puedes borrar el clúster y volver a crearlo. La actualización del clúster no hace que este vuelva a usar una conexión de intercambio de tráfico de red de VPC existente.

Cada ubicación puede admitir un máximo de 75 clústeres privados si estos tienen habilitada la reutilización del intercambio de tráfico de VPC. Las zonas y las regiones se tratan como ubicaciones separadas. Por ejemplo, puedes crear hasta 75 clústeres zonales privados en us-east1-a y otros 75 clústeres regionales privados en us-east1. Esto también se aplica si usas clústeres privados en una red de VPC compartida. La cantidad máxima de conexiones a una sola red de VPC es 25, lo que significa que solo puedes crear clústeres privados con 25 ubicaciones únicas.

Puedes comprobar si tu clúster privado vuelve a usar las conexiones de intercambio de tráfico de VPC.

gcloud

gcloud container clusters describe CLUSTER_NAME \
--zone=ZONE_NAME \
--format="value(privateClusterConfig.peeringName)"

Si tu clúster vuelve a usar conexiones de intercambio de tráfico de VPC, el resultado comenzará con gke-n. Por ejemplo, gke-n34a117b968dee3b2221-93c6-40af-peer.

Console

Verifica la fila del intercambio de tráfico de VPC en la página de detalles del clúster. Si tu clúster vuelve a usar conexiones de intercambio de tráfico de VPC, el resultado comenzará con gke-n. Por ejemplo, gke-n34a117b968dee3b2221-93c6-40af-peer.

Realiza una 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

Ve al menú de Google Kubernetes Engine en Cloud Console.

Ir al menú Google Kubernetes Engine
Selecciona cada clúster.
Haz clic en Borrar.

Borra la red

gcloud

gcloud compute networks delete net-0

Console

Visita la página de redes de VPC en Cloud Console.

Visitar la página de redes de VPC
En la lista de redes, haz clic en net-0.
En la página de detalles de la red de VCP, haz clic en Borrar red de VPC.
En el diálogo Borrar una red, haz clic en Borrar.

Requisitos, restricciones y limitaciones

Los clústeres privados tienen los siguientes requisitos:

Un clúster privado debe ser un clúster nativo de la VPC, que tenga habilitados los rangos de IP de alias. La opción nativos de la VPC está habilitada de forma predeterminada para los clústeres nuevos. Los clústeres nativos de la VPC no son compatibles con las redes heredadas.

Los clústeres privados tienen las siguientes restricciones:

No puedes convertir un clúster público existente en un clúster privado.
En los clústeres que ejecutan versiones anteriores a 1.16.9 o versiones entre 1.17.0 y 1.17.4, no se puede acceder al plano de control del clúster desde el CIDR 172.17.0.0/16.
En los clústeres que ejecutan versiones anteriores a 1.14.4, el rango de IP del plano de control del clúster, un nodo, un Pod o un servicio no puede superponerse con 172.17.0.0/16.
Cuando usas 172.17.0.0/16 para el rango de IP del plano de control, no puedes usar este rango para direcciones IP de nodos, Pods o servicios. Esta restricción se aplica a los clústeres zonales que ejecutan las versiones 1.14.4 o posteriores y a los clústeres regionales que ejecutan las versiones 1.16.9 a 1.17.0, o 1.17.4 y posteriores.
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. Para que un clúster privado vuelva a funcionar después de borrar la ruta predeterminada, debes aprovisionar el VIP restringido de manera estática.
Puedes agregar hasta 50 redes autorizadas (bloques CIDR permitidos) a un proyecto. Para obtener más información, consulta Agrega una red autorizada a un clúster existente.

Los clústeres privados tienen las siguientes limitaciones:

El tamaño del bloque RFC 1918 del plano de control de clústeres debe ser de /28.
Si bien GKE puede detectar la superposición con el bloque de direcciones del plano de control, no puede detectar la superposición dentro de una red de VPC compartida.
Todos los nodos de un clúster privado se crean sin una IP pública. Tienen acceso limitado a los servicios y a las API de Google. Para proporcionar acceso a Internet saliente a los nodos privados, puedes usar Cloud NAT o administrar tu propia puerta de enlace NAT. Para permitir que los nodos se comuniquen con los servicios y las API de Google, habilita el Acceso privado a Google en tu subred.
Todos los clústeres privados que creaste antes del 15 de enero de 2020 tienen un límite máximo de 25 clústeres privados por red (si es que el intercambio de tráfico no se usa para otros fines). Consulta Reutilización del intercambio de tráfico entre VPC para obtener más información.
Cada clúster privado requiere una ruta de intercambio de tráfico entre tu VPC y la de Google, 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 a fin de que las rutas de intercambio de tráfico de VPC ya existan en cada clúster privado posterior. Si intentas crear un clúster privado único, es posible que también se agote el tiempo de espera si hay operaciones en ejecución en la VPC.
Si expandes el rango de IP principal de una subred para admitir nodos adicionales, debes agregar el rango de direcciones IP principal de la subred expandida a la lista de redes autorizadas de instancia principal para tu clúster. Si no lo haces, las reglas de firewall de entrada permitida que son relevantes para la instancia principal no se actualizan, y los nodos nuevos creados en el espacio de direcciones IP expandido no podrán registrarse con la instancia principal. Esto puede provocar una interrupción en la que los nodos nuevos se borren y se reemplacen de forma continua. Este tipo de interrupción puede ocurrir cuando se realizan actualizaciones de grupos de nodos o cuando los nodos se reemplazan de manera automática debido a fallas de sondeo de estado en funcionamiento.

Soluciona 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: Si intentas crear un clúster privado, se muestra un error, como 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 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, 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 el plano de control del clúster.
Solución: Debes agregar redes autorizadas para que el clúster permita las conexiones al plano de control del clúster desde tu red.; Asegúrate de que esté habilitado el acceso global del extremo privado del plano de control si los clientes usan el comando de kubectl desde una región diferente del clúster. Consulta Accede al extremo privado del plano de control de forma global para obtener más información.

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 que especificaste las marcas necesarias. No puedes habilitar un extremo privado para el plano de control del clúster sin también habilitar nodos privados.

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, 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 del plano de control que se superpone con una subred existente en tu VPC.
Solución: Especifica un bloque CIDR para que --master-ipv4-cidr no se superponga con una subred existente.

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, 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 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 API de Google, incluido Container 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 Container Registry. Consulta la página sobre cómo migrar contenedores desde un registro de terceros para obtener más información.
Utiliza mirror.gcr.io, que almacena en caché copias de imágenes a las que se accede con frecuencia desde Docker Hub. Para obtener más información, consulta la sección Extrae imágenes almacenadas en caché de Docker Hub.
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.