Crea un clúster privado

Autopilot Estándar

---

Version 1.28 and earlier (unsupported)

• Más reciente
• Versión 1.28 y anteriores

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. Puedes optar por no tener acceso de cliente, tener acceso limitado o tener acceso ilimitado al plano de control.

Nota: Te recomendamos que crees tu clúster en la versión 1.29 y versiones posteriores para obtener acceso personalizable y simplificado al plano de control y la red del clúster. Para obtener más información, consulta Cómo personalizar el aislamiento de red en GKE.

Restricciones y limitaciones

Los clústeres privados deben ser clústeres nativos de la VPC. Los clústeres nativos de la VPC no son compatibles con las redes heredadas.

Expande las siguientes secciones para ver las reglas sobre los rangos de direcciones IP y el tráfico cuando crees un clúster.

Plano de control

• 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.
• El tamaño del bloque RFC 1918 del plano de control de clústeres debe ser de /28.
• Puedes agregar hasta 50 redes autorizadas (bloques CIDR permitidos) a un proyecto con el master-authorized-networks que se explica en esta página.
• 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.

Redes de clústeres

• 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. Si deseas obtener más información, consulta Rangos de IP para clústeres nativos de la VPC.
• GKE admite cualquier rango de direcciones IP internas, incluidos los rangos privados (RFC 1918 y otros rangos privados) y los rangos de direcciones IP externas utilizados de forma privada. Consulta la documentación de VPC para obtener una lista de los rangos de direcciones IP internas válidos.
• 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 para tu clúster. Si no lo haces, las reglas de firewall de entrada permitida que son relevantes para el plano de control no se actualizan, y los nodos nuevos creados en el espacio de direcciones IP expandido no podrán registrarse con el plano de control. 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.
• Todos los nodos de un clúster privado se crean sin una IP externa. Tienen acceso limitado a los servicios y las APIs de Google Cloud . Si deseas proporcionar acceso saliente a Internet a tus nodos privados, puedes usar Cloud NAT.
• El Acceso privado a Google se habilita de forma automática cuando creas un clúster, a menos que uses una VPC compartida. No debes inhabilitar el Acceso privado a Google, a menos que uses NAT para acceder a Internet.

Antes de comenzar

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

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
  Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la CLI de gcloud como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

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

• Asegúrate de tener una ruta a la puerta de enlace predeterminada de Internet.

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

En esta sección, crearás los siguientes recursos:

• Un clúster privado llamado private-cluster-0 que tiene nodos privados y que no tiene acceso de clientes al extremo público.
• Una red llamada my-net-0.
• Una subred llamada my-subnet-0.

Importante: Incluso si inhabilitas el acceso al extremo público, GKE puede usar el extremo público del plano de control para la administración de los clústeres, como el mantenimiento programado y las actualizaciones automáticas.

Console

Crea una red y una subred

1. Ve a la página Redes de VPC en la consola de Google Cloud .
   

   Ir a las redes de VPC

2. Haga clic en Crear red de VPC.

3. En Nombre, ingresa my-net-0.

4. En Modo de creación de subred, selecciona Personalizado.

5. Dentro de la sección Subred nueva, en Nombre, ingresa my-subnet-0.

6. En la lista Región, selecciona la región que deseas.

7. En Rango de direcciones IP, ingresa 10.2.204.0/22.

8. Configura el Acceso privado a Google como Activado.

9. Haz clic en Listo.

10. Haz clic en Crear.

Crea un clúster privado

1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

   Ir a Google Kubernetes Engine

2. Haz clic en Crear y, luego, en la sección Standard o Autopilot, haz clic en Configurar.

3. En Nombre, especifica private-cluster-0.

4. En el panel de navegación, haga clic en Herramientas de redes.

5. En la lista Red, selecciona my-net-0.

6. En la lista Subred del nodo, selecciona my-subnet-0.

7. Selecciona el botón de selección Clúster privado.

8. Desmarca la casilla de verificación Permitir el acceso al plano de control mediante su dirección IP externa.

9. (Opcional para Autopilot): Configura el Rango de IP del plano de control como 172.16.0.32/28.

10. Haz clic en Crear.

gcloud

• Para los clústeres Autopilot, ejecuta el siguiente comando:

  gcloud container clusters create-auto private-cluster-0 \
      --create-subnetwork name=my-subnet-0 \
      --enable-master-authorized-networks \
      --enable-private-nodes \
      --enable-private-endpoint
  

• Para los clústeres estándar, 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
  

Donde:

• --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 VPC (no es necesario para Autopilot).

• --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 interna 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 (opcional para Autopilot). Esta configuración es permanente para este clúster y debe ser única dentro de la VPC. Se admite el uso de direcciones IP internas que no sean RFC 1918.

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.

Nota: En un clúster de Autopilot, al parámetro --master-ipv4-cidr se le asigna una subred dentro del rango 172.16.0.0/16 de forma predeterminada. Este rango permite varios tamaños de subred.

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.

Puedes usar Google Cloud CLI o la API de GKE.

gcloud

• Para los clústeres Autopilot, ejecuta el siguiente comando:

  gcloud container clusters create-auto private-cluster-1 \
      --create-subnetwork name=my-subnet-1 \
      --enable-master-authorized-networks \
      --enable-private-nodes
  

• Para los clústeres estándar, 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
  

Donde:

• --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 VPC (no es necesario para Autopilot).

• --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 (opcional para Autopilot). Esta configuración es permanente para este clúster y debe ser única dentro de la VPC. Se admite el uso de direcciones IP internas que no sean RFC 1918.

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, crearás los siguientes recursos:

• Un clúster privado llamado private-cluster-2.
• Una red llamada my-net-2.
• Una subred llamada my-subnet-2, con rango primario 192.168.0.0/20, para tus nodos de clúster. Tu subred tiene los siguientes rangos de direcciones secundarios:
  • my-pods para las direcciones IP del pod.
  • my-services para las direcciones IP de servicio.

Console

Crea una red, subred y rangos secundarios

1. Ve a la página Redes de VPC en la consola de Google Cloud .
   

   Ir a las redes de VPC

2. Haga clic en Crear red de VPC.

3. En Nombre, ingresa my-net-2.

4. En Modo de creación de subred, selecciona Personalizado.

5. Dentro de la sección Subred nueva, en Nombre, ingresa my-subnet-2.

6. En la lista Región, selecciona la región que deseas.

7. En Rango de direcciones IP, ingresa 192.168.0.0/20.

8. Haz clic en Crear rango de IP secundario. En Nombre de rango de subred, ingresa my-services y, en Rango de IP secundario , ingresa 10.0.32.0/20.

9. Haz clic en Agregar rango de IP. En Nombre de rango de subred, ingresa my-pods y, en Rango de IP secundario, ingresa 10.4.0.0/14.

10. Configura el Acceso privado a Google como Activado.

11. Haz clic en Listo.

12. Haz clic en Crear.

Cree un clúster privado

Crea un clúster privado que use tu subred:

1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

   Ir a Google Kubernetes Engine

2. Haz clic en Crear y, luego, en la sección Standard o Autopilot, haz clic en Configurar.

3. En Nombre, ingresa private-cluster-2.

4. En el panel de navegación, haz clic en Herramientas de redes.

5. Selecciona el botón de selección Clúster privado.

6. Para crear un plano de control accesible desde los rangos de IP externos autorizados, mantén seleccionada la casilla de verificación Permitir el acceso al plano con su dirección IP externa.

7. (Opcional para Autopilot): Configura el Rango de IP del plano de control como 172.16.0.16/28.

8. En la lista Red, selecciona my-net-2.

9. En la lista Subred del nodo, selecciona my-subnet-2.

10. Desmarca la casilla de verificación Crear rangos secundarios automáticamente.

11. En la lista Rango de CIDR secundario del pod, selecciona my-pods.

12. En la lista Rango de CIDR secundario de Services, selecciona my-services.

13. Selecciona la casilla de verificación Habilitar redes autorizadas del plano de control.

14. Haz clic en Crear.

gcloud

Crea una red

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

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

Crea una subred y rangos secundarios

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

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

Cree un clúster privado

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

• Para los clústeres Autopilot, ejecuta el siguiente comando:

  gcloud container clusters create-auto private-cluster-2 \
      --enable-master-authorized-networks \
      --network my-net-2 \
      --subnetwork my-subnet-2 \
      --cluster-secondary-range-name my-pods \
      --services-secondary-range-name my-services \
      --enable-private-nodes
  

• Para los clústeres estándar, ejecuta el siguiente comando:

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

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

Supongamos que tienes un grupo de máquinas fuera de my-net-2, 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-2 \
    --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
• Los rangos de direcciones autorizados, por ejemplo, 203.0.113.0/29.

Usa Cloud Shell para acceder a un clúster privado

Si habilitaste un extremo privado, no podrás acceder al plano de control de GKE con Cloud Shell.

Si deseas usar Cloud Shell para acceder al clúster, debes agregar la dirección IP externa de Cloud Shell a la lista de redes autorizadas del clúster.

Para ello, sigue estos pasos:

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

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

   gcloud container clusters update CLUSTER_NAME \
       --enable-master-authorized-networks \
       --master-authorized-networks EXISTING_AUTH_NETS,SHELL_IP/32
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: El nombre de tu clúster.

   • EXISTING_AUTH_NETS: Son las direcciones IP de tu lista existente de redes autorizadas. Puedes encontrar las redes autorizadas en Console o mediante la ejecución del siguiente comando:

     gcloud container clusters describe CLUSTER_NAME --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"
     

   • SHELL_IP: Es la dirección IP externa de tu Cloud Shell.

3. Obtén credenciales de modo que puedas usar kubectl para acceder al clúster:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID \
       --internal-ip
   

   Reemplaza PROJECT_ID con el ID del proyecto.

4. Usa kubectl en Cloud Shell para acceder al clúster:

   kubectl get nodes
   

   El resultado es similar a este:

   NAME                                               STATUS   ROLES    AGE    VERSION
   gke-cluster-1-default-pool-7d914212-18jv   Ready    <none>   104m   v1.21.5-gke.1302
   gke-cluster-1-default-pool-7d914212-3d9p   Ready    <none>   104m   v1.21.5-gke.1302
   gke-cluster-1-default-pool-7d914212-wgqf   Ready    <none>   104m   v1.21.5-gke.1302
   

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.

Console

1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

   Ir a Google Kubernetes Engine

2. Haz clic en Crear y, luego, en la sección Standard o Autopilot, haz clic en Configurar.

3. En Nombre, ingresa private-cluster-3.

4. En el panel de navegación, haga clic en Herramientas de redes.

5. Selecciona la opción Clúster privado.

6. Deja seleccionada la casilla de verificación Permitir el acceso al plano de control mediante su dirección IP externa.

7. (Opcional para Autopilot): Configura el Rango de IP del plano de control como 172.16.0.32/28.

8. Deja la Red y la Subred del nodo establecidas en default. Esto hace que GKE genere una subred para el clúster.

9. Desmarca la casilla de verificación Habilitar redes autorizadas del plano de control.

10. Haz clic en Crear.

gcloud

• Para los clústeres Autopilot, ejecuta el siguiente comando:

  gcloud container clusters create-auto private-cluster-3 \
      --create-subnetwork name=my-subnet-3 \
      --no-enable-master-authorized-networks \
      --enable-private-nodes
  

• Para los clústeres estándar, ejecuta el siguiente comando:

  gcloud container clusters create private-cluster-3 \
      --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
  

Donde:

• --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 VPC (no es necesario para Autopilot).

• --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 IP internas para el plano de control (opcional para Autopilot). Esta configuración es permanente para este clúster y debe ser única dentro de la VPC. Se admite el uso de direcciones IP internas que no sean RFC 1918.

Agrega reglas de firewall para casos de uso específicos

En esta sección, se explica cómo agregar una regla de firewall a un clúster. De forma predeterminada, las reglas de firewall restringen el plano de control del clúster para iniciar solo conexiones TCP a los nodos y Pods 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. No crees reglas de firewall ni reglas de políticas de firewall jerárquicas que tengan una prioridad más alta que las reglas de firewall creadas de forma automática.

Nota: Los puertos permitidos (443 y 10250) hacen referencia a los puertos expuestos por los nodos y los Pods, no los puertos expuestos por cualquier servicio de Kubernetes. Por ejemplo, si el plano de control del clúster intenta acceder a un servicio en el puerto 443, pero un Pod lo implementa con el puerto 9443, esto estará bloqueado por el firewall, a menos que agregues una regla de firewall para permitir la entrada de forma explícita al puerto 9443.

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

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.

Console

1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

   Ir a Google Kubernetes Engine

2. En la lista de clústeres, haz clic en el nombre.

En la pestaña Detalles, en Herramientas de redes, anota el valor en el campo Rango de direcciones del plano de control.

gcloud

Ejecuta el siguiente comando:

gcloud container clusters describe CLUSTER_NAME

Reemplaza CLUSTER_NAME por el nombre de tu clúster.

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

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

Console

1. Ve a la página Políticas de firewall en la consola de Google Cloud .

   Ir a Políticas de firewall

2. En Tabla de filtro, en Reglas de firewall de VPC, ingresa gke-CLUSTER_NAME.

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

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.

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

Agrega una regla de firewall

Console

1. Ve a la página Políticas de firewall en la consola de Google Cloud .

   Ir a Políticas de firewall

2. Haga clic en Crear regla de firewall.

3. En Nombre, ingresa el nombre de la regla de firewall.

4. En la lista Red, selecciona la red que corresponda.

5. En Dirección del tráfico, haz clic en Ingress.

6. En Acción en caso de coincidencia, haz clic en Permitir.

7. En la lista Destinos, selecciona Etiquetas de destino especificadas.

8. En Etiquetas de destino, ingresa el valor de destino que anotaste antes.

9. En la lista Filtro de fuente, selecciona Rangos de IPv4.

10. En Rangos de IPv4 de origen, ingresa el bloque CIDR del plano de control del clúster.

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

12. Haz clic en Crear.

gcloud

Ejecuta el comando siguiente:

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

Reemplaza lo siguiente:

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

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

--project HOST_PROJECT_ID
--network NETWORK_ID

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.

Console

1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

   Ir a Google Kubernetes Engine

2. En la lista de clústeres, haz clic en el nombre del clúster.

3. Para los clústeres de Autopilot, en la sección Conceptos básicos del clúster, marca el campo Extremo externo. El valor es Inhabilitado.

Para los clústeres de Standard, haz lo siguiente:

1. En la página Clústeres, haz clic en la pestaña Nodos.
2. En Grupos de nodos, haz clic en el nombre del grupo de nodos.
3. 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`.
4. En la lista de instancias, verifica que las instancias 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
Ready      v1.8.7-gke.1                Container-Optimized OS
Ready      v1.8.7-gke.1                Container-Optimized OS

Verifica la reutilización del intercambio de tráfico de VPC en el clúster

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.

Puedes comprobar si tu clúster privado vuelve a usar las conexiones de intercambio de tráfico de red de VPC mediante gcloud CLI o la consola de Google Cloud .

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.

gcloud

gcloud container clusters describe CLUSTER_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

Configuraciones avanzadas del clúster

En esta sección, se describen algunas configuraciones avanzadas que puedes usar cuando creas un clúster privado.

Otorga acceso a Internet saliente a los nodos privados

Si deseas proporcionar acceso a Internet saliente a los nodos privados, como para extraer imágenes de un registro externo, usa Cloud NAT para crear y configurar un Cloud Router. Cloud NAT permite que los nodos privados establezcan conexiones salientes a través de Internet para enviar y recibir paquetes.

El Cloud Router permite que todos los nodos de la región usen Cloud NAT para todos los rangos de IP de alias y principales. También asigna de forma automática las direcciones IP externas de la puerta de enlace NAT.

Para obtener instrucciones sobre cómo crear y configurar un Cloud Router, consulta Crea una configuración de Cloud NAT con Cloud Router en la documentación de Cloud NAT.

Nota: A fin de proporcionar acceso a Internet saliente a tus pods y servicios, configura Cloud NAT para especificar rangos de subredes para NAT

Crea un clúster privado en una red de VPC compartida

Para aprender a crear un clúster privado en una red de VPC compartida, consulta Crea un clúster privado en una VPC compartida.

Implementa una aplicación de contenedor de Windows Server

Para obtener información sobre cómo implementar una aplicación de contenedor de Windows Server en un clúster con nodos privados, 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 red de transferencia 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 red de transferencia 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 red de transferencia 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 de red de transferencia internos y el acceso global, consulta Balanceadores de cargas internos y redes conectadas.

Nota: Se aplican cargos de salida al tráfico entre regiones en la red de Google Cloud, por lo que acceder al extremo privado del plano de control desde otra región genera cargos de salida interregionales estándar.

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 las siguientes herramientas según el modo del clúster:

• Para los clústeres Standard, puedes usar Google Cloud CLI o la consola de Google Cloud .

• Para los clústeres de Autopilot, puedes usar el recurso google_container_cluster de Terraform.

Console

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

1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

   Ir a Google Kubernetes Engine

2. Haz clic en Crear y, luego, en la sección Standard o Autopilot, haz clic en Configurar.

3. Escribe un Nombre.

4. En el panel de navegación, haga clic en Herramientas de redes.

5. Selecciona Clúster privado.

6. Selecciona la casilla de verificación Habilitar el acceso global al plano de control.

7. Configura otros campos como desees.

8. Haz clic en Crear.

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

1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

   Ir a Google Kubernetes Engine

2. Junto al clúster que deseas editar, haz clic en  Acciones y, luego, en  Editar.

3. En la sección Herramientas de redes, junto a Acceso global al plano de control, haz clic en Editar.

4. En el cuadro de diálogo Editar el acceso global al plano de control, selecciona la casilla de verificación Habilitar el acceso global al plano de control.

5. Haz clic en Guardar cambios.

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

Nota: Para inhabilitar el acceso global al extremo privado del plano de control, usa la marca --no-enable-master-global-access.

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

Accede al extremo privado del plano de control desde otras redes

Cuando creas un clúster privado de GKE e inhabilitas el extremo público del plano de control, debes administrar el clúster con herramientas como kubectl mediante el extremo privado del plano de control. Puedes acceder al extremo privado del plano de control del clúster desde otra red, incluidas las siguientes opciones:

• Una red local que está conectada a la red de VPC del clúster mediante túneles de Cloud VPN o adjuntos de VLAN de Cloud Interconnect
• Otra red de VPC que esté conectada a la red de VPC del clúster mediante túneles de Cloud VPN

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

Para permitir que los sistemas de otra red se conecten al extremo privado del plano de control de un clúster, completa los siguientes requisitos:

1. Identifica y registra la información de red relevante para el clúster y el extremo privado de su plano de control.

   gcloud container clusters describe CLUSTER_NAME \
      --location=COMPUTE_LOCATION \
      --format="yaml(network, privateClusterConfig)"
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: el nombre del clúster.
   • COMPUTE_LOCATION: la ubicación de Compute Engine del clúster

   En el resultado del comando, identifica y registra la siguiente información para usarla en los siguientes pasos:

   • network: es el nombre o URI de la red de VPC del clúster
   • privateEndpoint: es la dirección IPv4 del extremo privado del plano de control o el rango de CIDR de IPv4 adjunto (masterIpv4CidrBlock).
   • peeringName: es el nombre de la conexión de intercambio de tráfico entre redes de VPC que se usa para conectar la red de VPC del clúster a la red de VPC del plano de control.

   El resultado es similar a este:

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

2. Considera habilitar el acceso global al extremo privado del plano de control para permitir que los paquetes ingresen desde cualquier región en la red de VPC del clúster. Habilitar el acceso global al extremo del plano de control te permite conectarte al extremo privado mediante túneles de Cloud VPN o adjuntos de VLAN de Cloud Interconnect ubicados en cualquier región, no solo en la región del clúster.

3. Crea una ruta para la dirección IP privateEndpoint o el rango de direcciones IP masterIpv4CidrBlock en la otra red. Debido a que la dirección IP del extremo privado del plano de control siempre se ajusta al rango de direcciones IPv4 masterIpv4CidrBlock, lo que crea una ruta para la dirección IP privateEndpoint o su rango delimitador proporciona una ruta para los paquetes desde la otra red al extremo privado del plano de control si se cumplen las siguientes condiciones:

   • La otra red se conecta a la red de VPC del clúster mediante los adjuntos de VLAN de Cloud Interconnect o los túneles de Cloud VPN que usan rutas dinámicas (BGP): Usa una ruta anunciada personalizada de Cloud Router. Para obtener más información, consulta Anuncia rangos de direcciones personalizados en la documentación de Cloud Router.

   • La otra red se conecta a la red de VPC del clúster mediante túneles de VPN clásica que no usan rutas dinámicas: debes configurar una ruta estática en la otra red.

   Importante: Si se inhabilita el acceso global al plano de control, los túneles de Cloud VPN o los adjuntos de VLAN de Cloud Interconnect que conectan la red de VPC del clúster a la otra red deben estar ubicados en la misma región que el clúster.

4. Configura la red de VPC del clúster para exportar sus rutas personalizadas en la relación de intercambio de tráfico a la red de VPC del plano de control. Google Cloud siempre configura la red de VPC del plano de control para importar rutas personalizadas desde la red de VPC del clúster. En este paso, se proporciona una ruta para los paquetes desde el extremo privado del plano de control a la otra red.

   Para habilitar la exportación de rutas personalizadas desde la red de VPC del clúster, usa el siguiente comando:

   gcloud compute networks peerings update PEERING_NAME \
       --network=CLUSTER_VPC_NETWORK \
       --export-custom-routes
   

   Reemplaza lo siguiente:

   • PEERING_NAME: es el nombre del intercambio de tráfico que conecta la red de VPC del clúster a la red de VPC del plano de control
   • CLUSTER_VPC_NETWORK: es el nombre o URI de la red de VPC del clúster

   Cuando se habilita la exportación de rutas personalizadas para la VPC, la creación de rutas que se superpongan con los rangos de IP deGoogle Cloud podría interrumpir el clúster.

   Si deseas obtener más detalles para actualizar el intercambio de rutas para las conexiones de intercambio de tráfico entre redes de VPC existentes, consulta Actualiza la conexión de intercambio de tráfico.

   Las rutas personalizadas en la red de VPC del clúster incluyen rutas cuyos destinos son rangos de direcciones IP en otras redes, por ejemplo, una red local. Para asegurarte de que estas rutas sean efectivas como rutas personalizadas de intercambio de tráfico en la red de VPC del plano de control, consulta Destinos admitidos desde la otra red.

Destinos admitidos desde la otra red

Los rangos de direcciones que la otra red envía a los Cloud Routers en la red de VPC del clúster deben cumplir con las siguientes condiciones:

• Si bien la VPC de tu clúster puede aceptar una ruta predeterminada (0.0.0.0/0), la red de VPC del plano de control siempre rechaza las rutas predeterminadas porque ya tiene una ruta predeterminada local. Si la otra red envía una ruta predeterminada a tu red de VPC, la otra red también debe enviar los destinos específicos de los sistemas que necesitan conectarse al extremo privado del plano de control. Para obtener más detalles, consulta Orden de enrutamiento.

• Si la red de VPC del plano de control acepta rutas que reemplazan de manera eficaz una ruta predeterminada, esas rutas interrumpen la conectividad a las APIs y los servicios deGoogle Cloud , lo que interrumpe el plano de control del clúster. Como ejemplo representativo, la otra red no debe anunciar rutas con los destinos 0.0.0.0/1 y 128.0.0.0/1. Consulta el punto anterior para ver una alternativa.

Supervisa los límites de Cloud Router, en especial, la cantidad máxima de destinos únicos para las rutas aprendidas.

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 Configuración y detalles del perímetro de servicio.

Si usas Artifact Registry con tu clúster privado de GKE en un perímetro de servicio de los Controles del servicio de VPC, debes configurar el enrutamiento a la IP virtual restringida para evitar el robo de datos.

Realice una limpieza

Nota: Si borras una conexión de intercambio de tráfico entre redes de VPC mientras hay recursos adjuntos en el clúster de GKE, el clúster entra en un estado de reparación que genera una pérdida permanente de los recursos adjuntos. No puedes recuperar los recursos borrados. Para obtener información sobre la solución alternativa, consulta Solución de problemas: La conexión de intercambio de tráfico entre redes de VPC en un clúster privado se borra por accidente.

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:

Borra los clústeres

Console

1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

   Ir a Google Kubernetes Engine

2. Selecciona cada clúster.

3. Haz clic en Borrar.

gcloud

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

Borra la red

Console

1. Ve a la página Redes de VPC en la consola de Google Cloud .

   Ir a las redes de VPC

2. En la lista de redes, haz clic en my-net-0.

3. En la página de detalles de la red de VCP, haz clic en Borrar red de VPC.

4. En el diálogo Borrar una red, haz clic en Borrar.

gcloud

gcloud compute networks delete my-net-0

¿Qué sigue?

• Obtén información acerca de los parámetros de configuración avanzada con clústeres privados.
• Obtén información para crear clústeres nativos de VPC.
• Obtén más información sobre el intercambio de tráfico entre redes de VPC.

• Sigue el instructivo para acceder a clústeres de GKE privados con grupos privados de Cloud Build.