Clústeres nativos de la VPC

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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

Nativo de la VPC es el modo de red predeterminado para todos los clústeres en las versiones 1.21.0-gke.1500 y posteriores de GKE. En versiones anteriores, 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 las versiones de clústeres de GKE y los métodos de creación de clústeres.

Versiones de GKE Método de creación de clúster Modo de red de clúster
All versions La consola de Google Cloud Nativo de la VPC
1.21.0-gke.1500 y posteriores La API de Kubernetes Engine o Google Cloud CLI VPC nativa
Anterior a 1.21.0-gke.1500 La API de Kubernetes Engine o Google Cloud CLI Basado en rutas

También puedes crear un clúster basado en rutas si especificas la marca --no-enable-ip-alias cuando creas el clúster.

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 reutilizadas de forma privada. Consulta Rangos válidos y Rangos restringidos en la documentación de VPC 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 sin usar CIDR de varios Pods discontinuos es /28, pero ese rango solo te permitiría crear 1 nodo con un máximo de 8 Pods. Debes usar un rango que sea lo suficientemente grande para la cantidad máxima de nodos que necesitas. El rango mínimo utilizado también 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 realizar una de las siguientes acciones:

  • Crea un clúster nuevo con un rango de direcciones de Pods más grande
  • Vuelve a crear tus grupos de nodos después de disminuir el --max-pods-per-node para los grupos de nodos
  • Expande el rango de direcciones IP del Pod secundario mediante CIDR de varios Pods discontinuos

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 principal de Identity and Access Management (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 del Pod adicionales mediante CIDR de varios Pods discontinuos.

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, que es la densidad predeterminada de Pods.

Rango de IP secundario de la subred para pods Cantidad máx. de direcciones IP del pod Cant. 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, este rango no se puede cambiar una vez que se crea el clúster.

Si usas Service de varios clústeres, el objeto ServiceImport usa direcciones IP del rango de IP secundario para servicios.

La siguiente tabla muestra la cantidad máxima de servicios que puedes crear en un solo clúster con la subred, dado el tamaño del rango de direcciones IP secundario de la subred para servicios.

Rango de IP secundario para servicios Cantidad máxima de servicios
/28
El menor rango de direcciones del servicio posible cuando el método de asignación del rango secundario es administrado por el usuario
16 servicios
/27
El menor rango de direcciones del servicio posible cuando el método de asignación del rango secundario es administrado por GKE
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

Comparte rangos de direcciones IP en clústeres de GKE

Puedes compartir el rango de direcciones IP principal y secundario para los Pods y el rango de direcciones IP secundario para objetos Service entre clústeres en la misma subred. Este comportamiento está disponible para los clústeres de Standard y Autopilot.

Se recomienda compartir rangos de direcciones IP si tienes un equipo centralizado que administra la infraestructura para los clústeres. Puedes reducir la sobrecarga si creas tres rangos para Pods, Services y nodos, y los vuelves a usar o los compartes, en especial en un modelo de VPC compartida. También puede facilitar la administración de direcciones IP a los administradores de red, ya que no es necesario que creen subredes específicas para cada clúster.

Comparte el rango de direcciones IP principal para los nodos

Si creas más de un clúster en la subred, el rango de direcciones IP principal para los nodos se comparte de forma predeterminada.

Compartir la dirección IP principal para los nodos tiene las siguientes limitaciones:

  • Si compartes el rango de direcciones IP principal para nodos con dos o más clústeres nativos de la VPC, un clúster puede usar una gran parte del rango de direcciones IP compartidas, lo que deja los otros clústeres sin suficientes direcciones IP para expandir.

Comparte el rango de direcciones IP secundario para Pods

Cuando compartes el rango secundario para los Pods, cada Pod obtiene una dirección IP única. Compartir el rango de direcciones IP secundario para Pods tiene las siguientes limitaciones:

  • Si compartes el rango de direcciones IP secundario para Pods con dos o más clústeres nativos de la VPC, un clúster puede usar una gran parte del rango de direcciones IP compartidas, lo que deja los otros clústeres sin suficientes direcciones IP para expandir.

Comparte el rango de direcciones IP secundario para objetos Service

Puedes compartir el rango de direcciones IP secundario para objetos Service en clústeres en la misma subred cuando uses rangos secundarios administrados por el usuario.

Si enrutas a una dirección IP de un objeto Service de este rango, GKE resuelve la dirección IP a la dirección IP del Pod del backend en el nodo host o de origen. Esto significa que la dirección IP del objeto Service nunca se enruta y se puede usar en diferentes clústeres.

Compartir el rango de direcciones IP secundario para objetos Service ofrece los siguientes beneficios:

  • Reduce la cantidad de rangos de direcciones IP secundarios únicos para los servicios creados en una subred
  • Usa menos direcciones IP

Compartir el rango de direcciones IP secundario para objetos Service tiene las siguientes limitaciones:

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.

La consola de Google Cloud 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

Puedes agregar más direcciones IP para los nodos si expandes la subred principal o agregas direcciones IP nuevas para los pods con CIDR de varios pods discontinuos. Si deseas obtener más información, consulta No hay suficiente espacio IP gratuito para pods.

Herramientas de redes de pila doble

Con las herramientas de redes de pila doble, puedes definir cómo GKE asigna direcciones IP (ipFamilies) a los siguientes objetos:

  • Para los Pods y los nodos, GKE asigna direcciones IPv4 e IPv6.
  • Para los Services, GKE asigna direcciones de pila única (solo IPv4 o solo IPv6) o de pila doble.

En la versión más reciente de GKE 1.24, puedes habilitar las redes de pila doble para clústeres de GKE en redes de VPC independientes y compartidas. También puedes aplicar políticas de red con las redes de pila doble habilitadas.

Ventajas

Las herramientas de redes de pila doble proporcionan los siguientes beneficios:

  • Habilitan la comunicación IPv6 de extremo a extremo.
  • Habilitan un mejor rendimiento en comparación con los túneles IP o NAT. Esto se logra porque no hay traducción de IPv6 a IPv4.

Restricciones y limitaciones

Las herramientas de redes de pila doble con GKE tienen las siguientes restricciones y limitaciones:

  • Las herramientas de redes de pila doble solo están disponibles para los clústeres nativos de VPC con GKE Dataplane V2 habilitado.
  • Las redes de doble pila solo son compatibles con subredes en VPC de modo personalizado. Para obtener más información, consulta Tipos de redes de VPC de Google Cloud.
  • No se admiten direcciones IPv6 de pila única para Pods o nodos.
  • No se admite IPv6 para Services de LoadBalancer.
  • IPv6 no es compatible con nodos de Windows.
  • IPv6 no es compatible con clústeres existentes.

Ten en cuenta las restricciones y limitaciones anteriores antes de crear un clúster de IPv6 público o privado. Para obtener más información, consulta cómo crear un clúster nativo de la VPC con herramientas de redes de pila doble.

Clústeres IPv6 públicos y privados

En la siguiente tabla, se proporciona un resumen de los clústeres IPv6 públicos y privados con el comportamiento y la configuración de red de pila doble:

Tipo de clúster Asignación de una dirección IP Rango de subred Configuración
Public

GKE asigna lo siguiente:

  • Direcciones IPv6 externas que se pueden enrutar a Internet.
  • Direcciones IPv4 privadas y públicas para los nodos.
De 2600:1900/28 Crea una subred con la marca --ipv6-access-type configurada como EXTERNAL.
Private

GKE asigna lo siguiente:

  • Direcciones IPv6 internas que no se pueden enrutar a Internet.
  • Solo direcciones IPv4 privadas a los nodos.

Los clústeres privados pueden usar Cloud NAT para acceder a la Internet pública. Sin embargo, Cloud NAT no es compatible con las direcciones IPv6.

Desde fd20::/20 (que es un subconjunto del rango general de ULA: fc00::/7).

Crea una subred con la marca --ipv6-access-type configurada como INTERNAL.

El tipo de acceso de subred IPv6 privado solo se puede crear en redes de VPC de modo personalizado que usen direcciones IPv6 de unidifusión (ULA) únicas. Para obtener más información, consulta cómo usar redes de VPC.

Arquitectura

Cuando creas un clúster con herramientas de redes de pila doble, Google Cloud y GKE asignan los siguientes rangos:

  • Google Cloud reserva un rango /64 a cada subred como un rango principal.
  • Google Cloud reserva un rango /96 por nodo del rango principal para usar como rango de direcciones IP del nodo principal.
  • GKE reserva un rango /112 por nodo del rango de direcciones IP del nodo principal para usar como rango de direcciones IP del Pod para ese nodo. Con las redes de doble pila, los Pods obtienen sus direcciones IPv6 del rango de direcciones IP general del Pod (similar a los nodos) y no del rango secundario para Pods reservado para direcciones IPv4.

    El rango de direcciones IP general del Pod consta de rangos que no se superponen del rango de IP del nodo principal. Por lo tanto, este rango de IP del Pod no es contiguo.

  • A cada clúster se le asigna un rango /112 para usar en los servicios. Este rango proviene de un rango de direcciones /64 del rango de direcciones privadas de Google que se reservó para el rango de direcciones IP de los servicios secundarios de GKE.

En el siguiente diagrama, se muestra cómo Google Cloud y GKE asignan direcciones IPv6:

En el diagrama, el rango principal de la subred de VPC es 2600:1900:0:1::/64 y el rango reservado para los Services de GKE es 2600:2D00:0:4::0:0/64. Cada nodo del clúster tiene un rango /96 para el rango de direcciones IP del nodo principal y un rango /112 para el rango de direcciones IP del Pod. El clúster también tiene un rango de direcciones IP de servicios secundarios /112.

Servicios

Puedes crear un Service IPv6 de tipo ClusterIP o NodePort.

Puedes exponer un Deployment con un Service de tipo ClusterIP o NodePort. Para cada implementación, puedes definir los campos ipFamilies y ipFamilyPolicy como IPv4, IPv6 o un Service de pila doble. Para obtener más información, consulta un ejemplo de configuración de un Deployment.

¿Qué sigue?