Crea un clúster nativo de VPC

En esta página, se explica cómo configurar los clústeres nativos de la VPC en Google Kubernetes Engine.

Descripción general

En GKE, los clústeres se pueden distinguir de acuerdo con la forma en la que enrutan el tráfico de un pod a otro. Un clúster que usa IP de alias se conoce como un clúster nativo de la VPC. Un clúster que usa Rutas de Google Cloud Platform se conoce como un clúster basado en rutas.

Beneficios de los IP de alias

El uso de direcciones IP de alias tiene los beneficios siguientes:

  • Las direcciones IP de un pod se pueden enrutar de forma nativa dentro de la red de GCP (incluso mediante un intercambio de tráfico de la red de VPC), y ya no utilizan una cuota de ruta.
  • Las direcciones IP de un pod se reservan dentro de la red antes de la creación del clúster, lo cual evita un conflicto con otros recursos de procesamiento.
  • Los controles de firewall para pods se pueden aplicar por separado desde sus nodos.
  • La capa de herramientas de redes puede realizar verificaciones contra la falsificación de identidad a fin de asegurarse de que el tráfico de salida no se envíe con direcciones IP de origen arbitrarias.
  • Cloud Router puede anunciar las direcciones IP de alias mediante BGP.
  • Las direcciones IP de alias permiten que los pods accedan directamente a servicios alojados sin usar una puerta de enlace NAT.

Restricciones

  • No puedes migrar un clúster nativo de la VPC a un clúster basado en rutas.

  • No puedes migrar un clúster basado en rutas a un clúster nativo de la VPC.

  • No puedes usar redes heredadas con clústeres nativos de la VPC. Para crear un clúster en una red heredada, crea un clúster basado en rutas.

  • Las IP de clúster para los servicios internos solo están disponibles en el clúster. Si deseas acceder a un servicio Kubernetes desde dentro de VPC, pero desde fuera del clúster (por ejemplo, desde una instancia de Compute Engine), usa un balanceador de cargas interno.

Antes de comenzar

Sigue estos pasos a fin de prepararte para esta tarea:

  • Asegúrate de habilitar la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Asegúrate de instalar el SDK de Cloud.
  • Establece tu ID del proyecto predeterminado:
    gcloud config set project [PROJECT_ID]
  • Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada con el siguiente comando:
    gcloud config set compute/zone [COMPUTE_ZONE]
  • Si trabajas con clústeres regionales, establece tu región de procesamiento predeterminada con el siguiente comando:
    gcloud config set compute/region [COMPUTE_REGION]
  • Actualiza gcloud a la versión más reciente con el siguiente comando:
    gcloud components update

Rangos secundarios

Los clústeres nativos de la VPC usan dos rangos de direcciones IP secundarias:

  • Un rango de direcciones para pods
  • Un rango de direcciones para servicios

En un clúster nativo de la VPC, el esquema de asignación es diferente del esquema que se utiliza en un clúster basado en rutas. En un clúster basado en rutas, se asigna un rango de CIDR tanto para pods como para servicios. En un clúster nativo de la VPC, se asigna un rango de CIDR para los pods y un rango de CIDR separado para los servicios.

Administración del rango secundario

Las siguientes son dos formas de asociar rangos secundarios a tu clúster:

Administración por GKE

Puedes hacer que GKE administre los rangos secundarios. Este es el modo predeterminado que se usa cuando creas un clúster.

Cuando creas un clúster, puedes especificar los rangos de CIDR para tus pods y servicios, o puedes definir tamaños para tus rangos de pods y servicios. Por ejemplo, podrías especificar un rango de 10.0.0.0/16 o un tamaño de /16.

Administración por el usuario

Puedes crear manualmente los rangos secundarios y, luego, crear un clúster que los use. Si creas rangos secundarios de forma manual, debes administrarlos tú mismo.

Con la VPC compartida, el propietario del proyecto host crea los rangos secundarios y los pasa a las instancias para usarlos con sus clústeres en proyectos de servicio. Los usuarios que crean clústeres de GKE en proyectos de servicio no pueden crear rangos secundarios con sus credenciales de instancia.

Consideraciones para el tamaño de clústeres

La cantidad máxima de pods y servicios para un clúster de GKE determinado se determina en función del tamaño de los rangos secundarios del clúster. No puedes cambiar los tamaños de rangos secundarios una vez que creas un clúster. Cuando crees un clúster, asegúrate de elegir rangos secundarios lo suficientemente grandes como para admitir el crecimiento anticipado del clúster.

En la tabla a continuación, se describen los tres rangos que debes considerar: nodos, pods y servicios.

Rango Orientación
Nodos

Las direcciones IP de nodos se obtienen del rango primario de la subred relacionada con el clúster. La subred de tu clúster debe ser lo suficientemente grande como para admitir la cantidad total de nodos en tu clúster.

Por ejemplo, si planeas crear un clúster de 900 nodos, la subred utilizada con el clúster debe ser de al menos /22 en tamaño. Una subred de tamaño /22 contiene 2(32-22) = 210 = 1,024 - 4 direcciones IP reservadas = 1,020 direcciones IP, lo que es suficiente en el caso de las direcciones IP de 900 nodos necesarias para el clúster.

Pods

De forma predeterminada, cada nodo asigna un bloque de /24 (2(32-24) = 28 = 256) del rango de dirección de pods.

Por ejemplo, para un clúster de 900 nodos, necesitas 900 × 256 = 230,400 direcciones IP. Las direcciones IP deben ser de bloques de tamaño /24, dado que ese es el nivel de detalle asignado a un nodo. Necesitas un rango secundario de tamaño /14 o superior. Un rango /14 de direcciones IP da como resultado 2(32-14) = 218 ≈ 262,000 direcciones IP.

Nota: Puedes configurar tus nodos para asignar un rango específico de IP a fin de que los nodos limiten la cantidad de pods que puede ejecutar cada uno de ellos. Todos los cálculos anteriores se basan en el valor predeterminado /24 (256 direcciones IP). Para obtener más información, consulta Optimiza la asignación de direcciones IP.

Servicios

Cada clúster necesita reservar un rango de direcciones IP para las direcciones IP del clúster de servicio de Kubernetes. Las direcciones IP del servicio son asignadas desde el rango secundario relacionado para los servicios. Debes asegurarte de que el bloque de direcciones IP sea suficiente para la cantidad total de servicios que anticipas ejecutar en el clúster.

Por ejemplo, en el caso de un clúster que ejecuta 3,000 servicios como máximo, necesitas 3,000 direcciones IP para usar con las direcciones IP del clúster. Necesitas un rango secundario de tamaño /20 o superior. Un rango de direcciones IP de /20 da como resultado 2(32-20) = 212 ≈ 4,000 direcciones IP.

La creación de nodos se limita a las direcciones disponibles para asignar desde el rango de dirección del pod. La creación del nodo falla cuando no hay más direcciones IP disponibles en el rango de direcciones del pod con el error Instance [instance name] creation failed: IP space of [cluster subnet] is exhausted. De forma predeterminada, los nodos recién creados asignan un bloque de /24 (256 direcciones IP) desde el rango de direcciones del pod, pero esto puede ser diferente si configuras una cantidad máxima de pods por nodo diferente.

Si utilizas rangos secundarios administrados por el usuario, consulta la tabla a continuación para asegurarte de que puedes alcanzar la cantidad máxima de nodos de un tamaño de subred de clúster determinado.

Tamaño de subred para nodos Cant. máx. de nodos Cant. máx. de dir. IP de un pod necesarias Rango de dirección de un pod recomendado
/29 4 1,024 /21
/28 12 3,072 /20
/27 28 7,168 /19
/26 60 15,360 /18
/25 124 31,744 /17
/24 252 64,512 /16
/23 508 130,048 /15
/22 1,020 261,120 /14
/21 2,044 523,264 /13
/20 4,092 1,047,552 /12
/19 8,188 2,096,128 /11 (rango de direcciones máximo del pod)

Valores predeterminados y límites de tamaños de rangos

Rango Tamaño predeterminado Tamaño mínimo Tamaño máximo
Nodos (subred del clúster)

/20 = 212 = 4,096 - 4 direcciones IP reservadas = 4,092 direcciones IP para nodos

/29 = 23 = 8 - 4 direcciones IP reservadas = 4 direcciones IP para nodos

/7 = 225 = aproximadamente 33 millones de direcciones IP para nodos

Pods (rango secundario)

/14 = 218 = 262,114 direcciones IP asignadas para pods

/24 = 28 = 256 direcciones IP asignadas para pods


/21 = 211 = 2,048 direcciones IP asignadas para pods (rangos administrados por GKE)

/11 = 221 = aproximadamente 2 millones de direcciones IP

Servicios (rango secundario)

/20 = 212 = 4,096 direcciones IP asignadas para servicios

/27 = 25 = 32 direcciones IP asignadas para servicios

/16 = 216 = 65,536 direcciones IP asignadas para servicios

Crea un clúster nativo de VPC

Para crear un clúster nativo de la VPC, puedes usar Google Cloud Platform Console, la herramienta de línea de comandos de gcloud o la API de GKE.

gcloud

Para crear el clúster nativo de la VPC, ejecuta el comando siguiente, en el que [CLUSTER_NAME] es el nombre que seleccionaste para el clúster:

gcloud container clusters create [CLUSTER_NAME] --enable-ip-alias

Console

Para crear un clúster nativo de la VPC, sigue estos pasos:

  1. Ve al menú de Google Kubernetes Engine en GCP Console.

    Ir al menú de Google Kubernetes Engine

  2. Haz clic en Crear clúster.

  3. Configura tu clúster como desees. Luego, haz clic en Opciones avanzadas.

  4. En la sección VPC nativa, deja seleccionada la opción Habilitar VPC nativa (con un alias de IP).

  5. Haz clic en Crear.

API

Para crear un clúster nativo de la VPC, define un objeto IPAllocationPolicy en tu recurso de clúster:

{
  "name": [CLUSTER_NAME],
  "description": [DESCRIPTION],
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "clusterIpv4CidrBlock"      : string,
    "servicesIpv4CidrBlock"     : string,
    "clusterSecondaryRangeName" : string,
    "servicesSecondaryRangeName": string,

  },
  ...
}

en el que:

  • "clusterIpv4CidrBlock" es el tamaño o la ubicación del rango de CIDR para pods. Determina el tamaño del rango secundario para pods, que puede ser IP/tamaño en la notación CIDR (como 10.0.0.0/14) o /tamaño (como /14). Se elige un espacio vacío con el tamaño dado del espacio disponible en tu VPC. Si se deja en blanco, se encuentra un rango válido y se crea con un tamaño predeterminado.
  • "servicesIpv4CidrBlock" es el tamaño/ubicación del rango de CIDR para los servicios. Consulta la descripción de "clusterIpv4CidrBlock".
  • "clusterSecondaryRangeName" es el nombre del rango secundario para los pods. El rango secundario debe existir previamente y pertenecer a la subred asociada con el clúster (como la subred especificada con la marca --subnetwork).
  • "serviceSecondaryRangeName" es el nombre del rango secundario para los servicios. El rango secundario debe existir previamente y pertenecer a la subred asociada con el clúster (como la subred especificada con la marca --subnetwork).

Para obtener más ejemplos de clúster, consulta Ejemplos.

Verifica los rangos secundarios del clúster

Después de crear un clúster nativo de la VPC, debes verificar los rangos del clúster.

gcloud

Para verificar el clúster, ejecuta el siguiente comando:

gcloud container clusters describe [CLUSTER_NAME]

En el resultado del comando, mira debajo del campo ipAllocationPolicy:

  • clusterIpv4Cidr es el rango secundario para los pods.
  • servicesIpv4Cidr es el rango secundario para los servicios.

Console

Para verificar el clúster, realiza los siguientes pasos:

  1. Ve al menú de Google Kubernetes Engine en GCP Console.

    Ir al menú de Google Kubernetes Engine

  2. Selecciona el clúster deseado.

Los rangos secundarios se muestran en la sección Clúster en la pestaña Detalles con la información siguiente:

  • El Rango de direcciones de contenedor es el rango secundario para pods.
  • El Rango de direcciones de servicio es el rango secundario para servicios.

Ejemplos

En las secciones siguientes, se proporcionan ejemplos para usar clústeres nativos de la VPC.

Crea un clúster con rangos de IP específicos

gcloud

Este comando crea my-cluster con los rangos de servicios y pods dados. Los rangos secundarios se crean automáticamente, se adjuntan a la subred predeterminada y GKE los administra de la siguiente manera:

gcloud container clusters create my-cluster \
  --enable-ip-alias --cluster-ipv4-cidr=10.0.0.0/14 \
  --services-ipv4-cidr=10.4.0.0/19

Console

Esto crea my-cluster con los rangos de pods y servicios dados. Los rangos secundarios se crean automáticamente, se adjuntan a la subred predeterminada y GKE los administra de la siguiente manera:

  1. Ve al menú de Google Kubernetes Engine en GCP Console.

    Ir al menú de Google Kubernetes Engine

  2. Haz clic en Crear clúster.

  3. Configura tu clúster como desees. Luego, haz clic en Opciones avanzadas.

  4. En la sección VPC nativa, deja seleccionada la opción Habilitar VPC nativa (con un alias de IP).

  5. Completa el campo Rango de direcciones de pods con el rango de pods (ejemplo: 10.0.0.0/14).

  6. Completa el campo Rango de direcciones de servicios con el rango de servicios (ejemplo: 10.4.0.0/19).

Crea un clúster con tamaños específicos en una subred diferente

Este comando crea my-cluster con los tamaños de rangos de pods y servicios dados. La ubicación del rango de CIDR se determina a partir del espacio libre en la VPC. Los rangos secundarios se crean y adjuntan a la subred my-subnet. GKE administra los rangos secundarios de la siguiente manera:

gcloud container clusters create my-cluster \
  --enable-ip-alias\
  --subnetwork my-subnet \
  --cluster-ipv4-cidr=/16 \
  --services-ipv4-cidr=/22

Crea un clúster con rangos secundarios existentes

Para obtener detalles sobre cómo crear rangos secundarios, consulta Descripción general de los rangos de IP de alias.

Debes crear dos rangos secundarios en la subred, uno llamado my-pods para los pods y otro llamado my-services para los servicios:

gcloud compute networks subnets update my-subnet \
    --add-secondary-ranges my-pods=10.0.0.0/16,my-services=10.1.0.0/16 \
    --region us-central1

Luego, para crear tu clúster, haz lo siguiente:

gcloud

Ejecuta el comando siguiente:

gcloud container clusters create my-cluster \
--enable-ip-alias \
--cluster-secondary-range-name=my-pods \
--services-secondary-range-name=my-services

Console

Completa los pasos siguientes:

  1. Ve al menú de Google Kubernetes Engine en GCP Console.

    Ir al menú de Google Kubernetes Engine

  2. Haz clic en Crear clúster.

  3. Configura tu clúster como desees. Luego, haz clic en Opciones avanzadas.

  4. En la sección VPC nativa, deja seleccionada la opción Habilitar VPC nativa (con un alias de IP).

  5. Establece Crear rangos secundarios automáticamente en falso.

  6. Selecciona la red y subred de nodo que deseas usar con tu clúster.

  7. Selecciona el rango secundario del pod y el rango secundario de servicios para usar con tu clúster.

Crea una subred automáticamente

Los procedimientos siguientes crean un clúster nativo de la VPC nuevo con una subred generada automáticamente.

gcloud

Para crear un nuevo clúster que usa direcciones IP de alias, ejecuta el siguiente comando:

gcloud container clusters create --enable-ip-alias --create-subnetwork name=my-cluster-subnet

En este comando, el nuevo clúster se configura automáticamente con rangos de direcciones IP y una subred. Puedes proporcionar un nombre para la subred (en este ejemplo, name=my-cluster-subnet) o ingresar una string vacía ("") a fin de generar un nombre automáticamente.

Para configurar el clúster tú mismo, ejecuta el comando siguiente:

gcloud container clusters create [CLUSTER_NAME] --enable-ip-alias \
--create-subnetwork="" --cluster-ipv4-cidr [RANGE] --services-ipv4-cidr [RANGE] ]

en el que:

  • [CLUSTER_NAME] es el nombre que eliges para el clúster.
  • La marca --create-subnetwork hace que se cree automáticamente una subred para el clúster.
  • La marca --cluster-ipv4-cidr indica el tamaño y la ubicación del

    rango de CIDR del clúster. [RANGE] puede tener el formato [IP address]/[SIZE], como 10.0.0.0/18, o simplemente /[SIZE], lo que hace que la dirección IP se asigne automáticamente. Si se omite esta marca, se asigna automáticamente un rango de CIDR con un tamaño predeterminado.

  • La marca --services-ipv4-cidr indica el tamaño y la ubicación del rango de CIDR del servicio. Las especificaciones [RANGE] son idénticas a --cluster-ipv4-cidr. El rango no se puede superponer con --cluster-ip4-cidr, y viceversa. Si se omite esta marca, se asigna automáticamente un rango de CIDR con un tamaño predeterminado.

API

Para crear un clúster nativo de la VPC, define un objeto IPAllocationPolicy en tu recurso de clúster:

{
  "name": [CLUSTER_NAME],
  "description": [DESCRIPTION],
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
    "subnetworkName": [SUBNET_NAME]
  },
  ...
}

createSubnetwork crea y aprovisiona automáticamente una subred para el clúster. subnetworkName es opcional; si se deja vacío, se elige un nombre de la subred de forma automática.

Solución de problemas

Esta sección proporciona orientación para resolver problemas relacionados con los clústeres nativos de la VPC.

Los alias de IP no se pueden usar con una red heredada

La VPC nativa es el valor predeterminado para los clústeres nuevos creados con Google Cloud Platform Console. Sin embargo, no puedes crear un clúster nativo de la VPC en una red heredada.

Para crear un clúster en una red heredada, crea un clúster basado en rutas.

El recurso 'projects/[PROJECT_NAME]/regiones/XXX/subnetworks/default' no está listo

Causas posibles
Hay operaciones paralelas en la misma subred. Por ejemplo, se crea otro clúster nativo de la VPC o se agrega o borra un rango secundario en la subred.
Solución
Vuelve a intentar el comando.

Valor no válido para el campo 'resource.secondaryIpRanges [1].ipCidrRange': 'XXX'. IPCidrRange no válido: XXX entra en conflicto con el valor 'default' de la subred existente en la región 'XXX'.

Causas posibles

Al mismo tiempo, se crea otro clúster nativo de la VPC que intenta asignar los mismos rangos.

Se agrega el mismo rango secundario a la subred.

Solución

Si se muestra este error en la creación del clúster cuando no se especificaron rangos secundarios, vuelve a ejecutar el comando de creación del clúster.

No hay espacio suficiente de IP para pod

Síntomas

El clúster está atascado en un estado de aprovisionamiento durante un período prolongado.

La creación de clústeres muestra un error de grupo de instancias administrado (MIG).

No se pueden agregar nodos nuevos a un clúster existente.

Causas posibles

El espacio no asignado en el rango secundario del pod no es lo suficientemente grande para los nodos solicitados en el clúster. Por ejemplo, si un usuario especifica un rango secundario /23 para pods y solicita más de dos nodos, entonces el clúster puede detenerse en el estado de aprovisionamiento. Consulta Consideraciones para el tamaño de clústeres a fin de obtener ayuda acerca de cómo crear tamaños de rangos de direcciones IP correctamente.

Si este problema ocurre durante la creación de un clúster, borra el clúster detenido en el estado de aprovisionamiento y crea otro con un rango secundario que tenga espacio suficiente para el clúster. Por ejemplo, si un usuario especifica un rango de CIDR secundario menor que /24 y lo asigna a un clúster, este último puede quedar atascado en el estado de aprovisionamiento.

Ten en cuenta que una subred puede tener un máximo de 30 rangos secundarios. Asimismo, cada clúster de VPC nativa requiere al menos dos rangos secundarios: uno para pods y otro para servicios.

Si este problema ocurre durante la determinación de tamaño del grupo de nodos, debes quitar los nodos existentes a fin de hacer lugar para los nuevos nodos.

Qué sigue

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Kubernetes Engine