Clústeres nativos de la VPC

En esta página, se proporciona una descripción general de los clústeres nativos de la VPC en Google Kubernetes Engine (GKE).

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 rangos de direcciones IP de alias se denomina clúster nativo de la VPC. Un clúster que usa rutas estáticas personalizadas en una red de VPC se denomina clúster basado en rutas.

Beneficios de los clústeres nativos de la VPC

Los clústeres nativos de la VPC tienen varios beneficios:

  • Las direcciones IP del Pod se pueden enrutar de forma nativa dentro de la red de VPC del clúster y otras redes de VPC conectadas mediante intercambio de tráfico de la red de VPC.

  • Las direcciones IP de un Pod se reservan en la red de VPC antes de que se creen los Pods en tu clúster. Esto evita conflictos con otros recursos de la red de VPC y te permite planificar mejor las asignaciones de direcciones IP.

  • Los rangos de direcciones IP de un Pod no dependen de rutas estáticas personalizadas. No consumen la cuota de rutas estáticas personalizadas y generadas por el sistema. En su lugar, las rutas de subred generadas automáticamente manejan el enrutamiento para los clústeres nativos de la VPC.

  • Puedes crear reglas de firewall que se apliquen solo a los rangos de direcciones IP de los Pods en lugar de cualquier dirección IP en los nodos del clúster.

  • En general, se puede acceder a los rangos de direcciones IP de los Pods y a los rangos de direcciones IP secundarios de las subredes desde redes locales conectadas con Cloud VPN o Cloud Interconnect mediante Cloud Routers.

Modo de red de clúster predeterminado

El modo de red de clúster predeterminado depende de cómo creas el clúster.

En la siguiente tabla, se muestra el modo de red de clúster predeterminado para cada método de creación de clústeres.

Método de creación de clúster Modo de red de clúster
Google Cloud Console Nativo de la VPC
API de REST Basado en rutas
gcloud v.256.0.0 y posteriores o v.250.0.0 y anteriores Basado en rutas
gcloud v.251.0.0 - 255.0.0 Nativo de la VPC

Rangos de direcciones IP para clústeres nativos de la VPC

Cuando creas un clúster nativo de la VPC, especificas una subred en una red de VPC. El clúster usa tres rangos de direcciones IP de subred únicos:

  • Usa el rango de direcciones IP principal de la subred para todas las direcciones IP del nodo.
  • Usa un rango de direcciones IP secundario para todas las direcciones IP del Pod.
  • Usa otro rango de direcciones IP secundario para todas las direcciones (IP del clúster) de los objetos Service.

En la siguiente tabla, se proporciona un resumen de los rangos de direcciones IP para nodos, Pods y objetos Service:

Rango Explicación Ejemplo
Nodos

Las direcciones IP de nodo se asignan a partir del rango de direcciones IP principales de la subred asociada a tu clúster.

La cantidad de nodos con los que es compatible un clúster está limitada por las direcciones IP del nodo y el tamaño del rango de direcciones IP secundario para Pods de la subred. Consulta los rangos de límite de nodo para obtener más información.

Si planeas crear un clúster de 900 nodos, el rango de direcciones IP principal de la subred del clúster debe ser al menos un /22 (2(32-22) = 210 = 1024 direcciones). De esas 1024 direcciones, se pueden utilizar 1020 porque cuatro direcciones IP están reservadas en cada rango de direcciones IP principal.

Para obtener más información, consulta las secciones Rango de direcciones IP principal de la subred y Rango de direcciones IP secundario de la subred para los pods.

Pods

Las direcciones IP del pod se toman del rango de direcciones IP secundario de la subred del clúster para los pods. A menos que defina un número máximo de pods por nodo diferente, GKE asigna un rango de IP de alias de /24 (256 direcciones) a cada nodo para los pods que se ejecutan en él. En cada nodo, esas 256 direcciones IP de alias son compatibles con hasta 110 pods.

Para un clúster de 900 nodos compatible con hasta 110 pods por nodo, necesitas 900 × 256 = 230.400 direcciones IP para los pods. (Cada nodo tiene asignado un rango de IP de alias con un tamaño de máscara de red de /24). Este clúster requiere una subred con un rango de IP secundario para pods que tenga una máscara de subred no mayor que /14. Este rango de IP secundario proporciona 2(32-14) = 218 = 262.144 direcciones IP para los pods.

Consulta Rango de direcciones IP secundario de la subred para los pods si deseas obtener más información.

Servicios

Las direcciones de servicio (IP del clúster) se toman del rango de direcciones IP secundario de la subred del clúster para los servicios. Debes asegurarte de que este rango sea lo suficientemente grande como para proporcionar direcciones a todos los servicios de Kubernetes que alojes en tu clúster.

Para un clúster que ejecute hasta 3000 servicios, necesitarás 3000 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 = 4096 direcciones IP.

Consulta Rango de direcciones IP secundario de la subred para los servicios si deseas obtener más información.

Direcciones IP internas

Las direcciones IP que usas para las subredes de tu clúster nativo de la VPC deben provenir de un rango de subred válido. En los rangos válidos, se incluyen direcciones IP privadas (RFC 1918 y otras) y direcciones IP públicas utilizadas de forma privada. Consulta Rangos válidos y Rangos restringidos en la documentación de la nube privada virtual para obtener más información sobre los rangos de subred válidos.

Consulta Usa rangos de direcciones IP privadas que no sean RFC 1918 para obtener instrucciones sobre cómo habilitar estos rangos.

Consulta Habilita los rangos de direcciones IP públicas utilizados de forma privada para obtener instrucciones sobre cómo usar estos rangos en clústeres privados.

Métodos de asignación del rango secundario

Puedes asignar rangos de direcciones IP del Pod y rangos de direcciones del objeto Service (ClusterIP) a un clúster nativo de la VPC mediante uno de estos dos métodos:

Administrado por GKE (predeterminado)

GKE puede crear y administrar los rangos secundarios de la subred automáticamente. Cuando creas el clúster, especificas un rango completo de CIDR o el tamaño de una máscara de red para los pods y los servicios. Por ejemplo, puedes especificar 10.1.0.0/16 para pods y 10.2.0.0/20 para servicios, o puedes especificar /16 para pods y /20 para servicios.

Si creas el clúster y la subred de forma simultánea, GKE administra los rangos de direcciones IP del Pod y del objeto Service.

Administrada por el usuario

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

El rango de direcciones IP más pequeño que puedes crear es /28. Sin embargo, debes usar un rango que sea lo suficientemente grande como para permitir que se cree al menos un nodo. El rango mínimo utilizado depende de la cantidad máxima de Pods por nodo. Consulta la tabla en Optimiza la asignación de direcciones IP a fin de obtener el rango mínimo de CIDR que se puede usar para diferentes valores de cantidad máxima de Pods por nodo.

Si agotas el rango de direcciones IP para los Pods, debes crear un nuevo clúster con un rango de direcciones de Pods más grande o volver a crear tus grupos de nodos después de disminuir --max-pods-per-node para los grupos de nodos.

.

Diferencias con los clústeres basados en rutas

El esquema de asignación para direcciones (ClusterIP) de Pods y objetos Service es diferente del esquema que usa un clúster basado en rutas. En lugar de especificar un solo CIDR para Pods y objetos Service juntos, debes elegir o crear dos rangos de direcciones IP secundarios en la subred del clúster: uno para Pods y otro para objetos Service.

Consideraciones de VPC compartida

Cuando se crea un clúster nativo de la VPC en un entorno de VPC compartida, el propietario o el editor del proyecto, o un miembro de IAM con la función de administrador de red en el proyecto host de la VPC compartida debe crear el subred y los rangos de direcciones IP secundarios de forma manual. Un administrador del proyecto de servicio que crea un clúster debe tener al menos permisos a nivel de subred en la subred deseada del proyecto host de la red de VPC compartida.

En un entorno de VPC compartida, GKE no puede administrar los rangos de direcciones IP secundarios. Un administrador de red del proyecto host de la VPC compartida debe crear la subred y los rangos de direcciones IP secundarios antes de que puedas crear el clúster. Para ver un ejemplo sobre cómo configurar un clúster nativo de la VPC en una red de VPC compartida, consulta Configura clústeres con VPC compartida.

Planificación del rango de direcciones IP

Usa la información de las siguientes secciones para calcular los tamaños de los rangos de direcciones IP principales y secundarios de la subred que usa tu clúster.

Rango de direcciones IP principal de la subred

Cada subred debe tener un rango de direcciones IP principal. Puedes expandir el rango de direcciones IP principal en cualquier momento, incluso cuando los recursos de Google Cloud usen la subred. Sin embargo, no se puede reducir ni cambiar el esquema principal de direcciones IP de una subred después de crearla. Google Cloud se reserva las dos primeras y las dos últimas direcciones IP de un rango de direcciones IP principal.

En la siguiente tabla, se muestra la cantidad máxima de nodos que se pueden crear en todos los clústeres que usan la subred, según el tamaño del rango de direcciones IP principal de la subred.

Rango de IP principal de la subred Cant. máx. de nodos
/29
Tamaño mínimo del rango de IP principal de una subred
4 nodos
/28 12 nodos
/27 28 nodos
/26 60 nodos
/25 124 nodos
/24 252 nodos
/23 508 nodos
/22 1,020 nodos
/21 2,044 nodos
/20
Tamaño predeterminado del rango de IP principal de una subred en redes de modo automático
4,092 nodos
/19 8,188 nodos
/8
Tamaño máximo del rango de IP principal de una subred
16,777,212 nodos

Fórmulas útiles

Puedes usar estas fórmulas para lo siguiente:

  • Calcula la cantidad máxima de nodos, N, que puede admitir una máscara de red determinada. Usa S para el tamaño de la máscara de red, cuyo rango válido se encuentra entre 8 y 29, inclusive.

    N = 2(32 – S) – 4

  • Calcula el tamaño de la máscara de red, S, que se requiere para admitir un máximo de N nodos:

    S = 32 – ⌈log2(N + 4)⌉

    ⌈⌉ es la función techo (mínimo entero), es decir, redondea al siguiente número entero. El rango válido para el tamaño de la máscara de red, S, se encuentra entre 8 y 29, inclusive.

Rango de direcciones IP secundario de la subred para Pods

Planifica con cuidado el rango de direcciones IP secundario para Pods. Si bien es posible reemplazar el rango de direcciones IP secundario de una subred, no es compatible hacerlo porque tiene el potencial de colocar el clúster en un estado inestable.

Sin embargo, puedes crear rangos de direcciones IP de pod adicionales con el CIDR de varios pods contiguos.

En la siguiente tabla, se muestra la cantidad máxima de nodos y pods que puedes crear en todos los clústeres que usan la subred, dado el tamaño del rango de direcciones IP secundario de la subred que usan los pods. En esta tabla, se supone que el número máximo de pods por nodo es 110 (la densidad máxima posible y predeterminada del pod).

Rango de IP secundario de la subred para pods Cantidad máx. de direcciones IP del pod Cantidad máx. de nodos Cantidad máx. de pods
/24
El menor rango de IP de pod posible cuando el método de asignación del rango secundario es administrado por el usuario
256 direcciones 1 nodo 110 pods
/23
Solo es posible cuando el método de asignación del rango secundario es administrado por el usuario
512 direcciones 2 nodos 220 pods
/22
Solo es posible cuando el método de asignación del rango secundario es administrado por el usuario
1,024 direcciones 4 nodos 440 pods
/21
El menor rango de IP de pod posible cuando el método de asignación del rango secundario es administrado por GKE
2,048 direcciones 8 nodos 880 pods
/20 4,096 direcciones 16 nodos 1,760 pods
/19 8,192 direcciones 32 nodos 3,520 pods
/18 16,384 direcciones 64 nodos 7,040 pods
/17 32,768 direcciones 128 nodos 14,080 pods
/16 65,536 direcciones 256 nodos 28,160 pods
/15 131,072 direcciones 512 nodos 56,320 pods
/14
Tamaño predeterminado del rango de IP secundario de la subred para los pods cuando el método de asignación del rango secundario es administrado por GKE
262,144 direcciones 1,024 nodos 112,640 pods
/13 524,288 direcciones 2,048 nodos 225,280 pods
/12 1,048,576 direcciones 4,096 nodos 450,560 pods
/11
2,097,152 direcciones 8,192 nodos 901,120 pods
/10
4,194,304 direcciones 16,384 nodos 1,802,240 Pods
/9
El rango más grande posible de direcciones de pods
8,388,608 direcciones 32,768 nodos 3,604,480 Pods

Si cambiaste la cantidad máxima de Pods por nodo, puedes usar las siguientes fórmulas para calcular la cantidad máxima de nodos y Pods que puede admitir un rango de direcciones IP secundario de una subred para Pods:

  1. Calcula el tamaño de la máscara de red del rango de Pods de cada nodo, M.
    M = 31 - ⌈log2(Q)⌉ , en el que se usan los siguientes valores:

    • Q es la cantidad de Pods por nodo.
    • ⌈⌉ es la función techo (mínimo entero), es decir, redondea al siguiente número entero.
  2. Calcula la cantidad máxima de nodos, N, que el rango de IP secundario de la subred para los Pods puede admitir:
    N = 2(M - S) , en el que se usan los siguientes valores:

    • M es el tamaño de la máscara de red del rango de direcciones IP de alias de cada nodo para los Pods, que se calculó en el primer paso.
    • S es el tamaño de la máscara de subred del rango de direcciones IP secundario de la subred.
  3. Calcula la cantidad máxima de Pods, P, que el rango de direcciones IP secundario de la subred para los Pods puede admitir.
    P = N × Q , en el que se usan los siguientes valores:

    • N es la cantidad máxima de nodos, que se calculó en el paso anterior.
    • Q es la cantidad de Pods por nodo.

Rango de direcciones IP secundario de la subred para servicios

Planifica con cuidado el rango de direcciones IP secundario para objetos Service. Debido a que este también es un rango de direcciones IP secundario de la subred, solo puedes reemplazarlo cuando ningún recurso de Google Cloud lo use. Este rango no se puede cambiar, mientras un clúster lo use para objetos Service (direcciones IP del clúster).

A diferencia de los rangos de direcciones IP de nodos y Pods, cada clúster debe tener un rango de direcciones IP secundario de subred único para objetos Service y no puede provenir de un rango de IP primario o secundario compartido.

En la siguiente tabla, se muestra la cantidad máxima de objetos Service que puedes crear en un solo clúster mediante la subred, dado el tamaño del rango de direcciones IP secundario de la subred para los objetos Service.

Rango de IP secundario para servicios Cantidad máxima de servicios
/27
El menor rango de direcciones del servicio posible
32 servicios
/26 64 servicios
/25 128 servicios
/24 256 servicios
/23 512 servicios
/22 1,024 servicios
/21 2,048 servicios
/20
Tamaño predeterminado del rango de IP secundario de la subred para servicios cuando el método de asignación del rango secundario es administrado por GKE
4,096 servicios
/19 8,192 servicios
/18 16,384 servicios
/17 32,768 servicios
/16
El mayor rango de direcciones del servicio posible
65,536 servicios

Rangos de límite de nodo

La cantidad máxima de pods y servicios para un clúster de GKE determinado está limitada por el tamaño de los rangos secundarios del clúster. La cantidad máxima de nodos en el clúster está limitada por el tamaño del rango de direcciones IP principal de la subred del clúster y del rango de direcciones del pod del clúster.

Cloud Console muestra mensajes de error como los siguientes para indicar que se agotó el rango de direcciones IP principal de la subred o el rango de direcciones IP del Pod del clúster (el rango de direcciones IP secundario de la subred):

Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted

¿Qué sigue?