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

Esta página está dirigida a arquitectos de nube y especialistas en herramientas de redes que diseñan la red para su organización. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de 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.

Práctica recomendada:

Planifica y diseña la configuración de tu clúster con los arquitectos de red, los administradores de red o cualquier otro equipo de ingenieros de red de tu organización que sea responsable de definir, implementar y mantener tu arquitectura de red.

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 a ella por medio del intercambio de tráfico de la red de VPC.

  • Las direcciones IP de los Pods 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 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.

  • Algunas funciones, como los grupos de extremos de red (NEG), solo funcionan con clústeres nativos de la VPC.

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
Todas las versiones La consola de Google Cloud Nativo de la VPC
1.21.0-gke.1500 y posteriores API de GKE o Google Cloud CLI Nativo de la VPC

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 los siguientes rangos de direcciones IP de subred:

Asignación de direcciones IPv4

Los clústeres nativos de la VPC asignan direcciones IPv4 para nodos, Pods y servicios de la siguiente manera.

  • Direcciones IPv4 de nodos: El clúster utiliza el rango de direcciones IPv4 principal de la subred para asignar direcciones IP a todos los nodos.

  • Direcciones IPv4 de Pod: El clúster utiliza uno o más rangos de direcciones IPv4 secundarias de subred para todas las direcciones IPv4 de Pod. En esta página, se explica el uso de un solo rango de direcciones IPv4 secundario de la subred. Para obtener información sobre el uso de varios rangos, consulta Cómo agregar rangos de direcciones IPv4 de Pod.

  • Direcciones IPv4 de servicio: Hay dos opciones disponibles:

    • Direcciones IPv4 de servicio de 34.118.224.0/20: Los clústeres de GKE Autopilot que ejecutan la versión 1.27 y versiones posteriores, y los clústeres de GKE Standard que ejecutan la versión 1.29 y versiones posteriores usan el rango de direcciones IPv4 de 34.118.224.0/20 para los servicios.Google Cloud usa el rango de direcciones de 34.118.224.0/20 para fines privados y no publica ninguna ruta en Internet pública para este rango. No puedes usar este rango para las direcciones IPv4 externas de tus recursos.

    • Direcciones IPv4 de Service de un rango de direcciones IPv4 secundario de subred: Para todas las direcciones de Service (ClusterIP), el clúster utiliza un rango de direcciones IPv4 secundario de subred que es diferente de los rangos que usan los Pods.

Asignación de direcciones IPv6 (redes de pila doble)

  • Direcciones IPv6 de nodos y Pods: En los clústeres habilitados para redes de doble pila, la dirección IPv6 del nodo y todas las direcciones IPv6 del Pod se originan en el rango de direcciones IPv6 /96 designado del nodo. La dirección IP del nodo en sí es la primera /128 (dirección IPv6 única) dentro de este rango. Para obtener más información, consulta Herramientas de redes de pila doble.

  • Direcciones IPv6 de Service: Los clústeres de GKE usan el rango de direcciones IPv6 2600:2D00:0:4::0:0/64 para los Services. Google Cloudusa el rango de direcciones 2600:2D00:0:4::0:0/64 para fines privados y no publica ninguna ruta en Internet pública para este rango. No puedes usar este rango para las direcciones IPv6 externas de tus recursos.

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.

En los clústeres de GKE Autopilot que ejecutan la versión 1.27 y versiones posteriores, y en los clústeres de GKE Standard que ejecutan la versión 1.29 y versiones posteriores, GKE asigna direcciones IP para los servicios de GKE de un rango administrado por GKE: 34.118.224.0/20 de forma predeterminada. Esto elimina la necesidad de especificar tu propio rango de direcciones IP para los servicios. Para obtener más detalles, consulta Rango de direcciones IP secundario de la subred para los servicios.

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

Las direcciones IPv4 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 IPv4 privadas, como RFC 1918, y direcciones IP públicas utilizadas 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 IPv4 de subred válidos.

Para obtener información importante sobre el uso de direcciones privadas que no son direcciones RFC 1918, consulta Usa rangos de direcciones IPv4 privadas que no sean RFC 1918.

Para obtener información importante sobre el uso de rangos de direcciones IPv4 públicas utilizadas de forma privada, consulta Habilita los rangos de direcciones IP públicas utilizadas de forma privada.

Métodos de asignación del rango de IPv4 secundario de la subred

Puedes asignar rangos de direcciones IP de Pod y rangos de direcciones de servicio (ClusterIP) a un clúster nativo de la VPC. GKE o el usuario pueden administrar estos rangos de direcciones IP.

Debes comprender los siguientes términos clave para entender los métodos de asignación de rangos secundarios.

Asignación: La asignación de rangos de direcciones IP hace referencia al proceso de asignar un rango de subred específico a un clúster nativo de la VPC. Esto establece un grupo de direcciones IP que los componentes pueden usar dentro del clúster, como los Pods y los Services.

Administración: La administración del rango de direcciones IP se refiere a las operaciones de CRUD en curso (creación, actualización, eliminación y lectura) a nivel de clúster, grupo de nodos o Pod, relacionadas con la asignación de rangos de subredes y recursos dentro de tu clúster nativo de la VPC.

Rangos secundarios administrados por GKE (predeterminado)

En el caso de los clústeres de GKE Autopilot que ejecutan la versión 1.27 y versiones posteriores, y los clústeres de GKE Standard que ejecutan las versiones 1.29 y versiones posteriores, GKE asigna direcciones IP para los Services de un rango administrado por GKE de forma predeterminada: 34.118.224.0/20. Esto elimina la necesidad de especificar tu propio rango de direcciones IP para los servicios. Se aplican las siguientes consideraciones:

  • De manera opcional, puedes especificar rangos personalizados para los servicios con la marca --services-ipv4-cidr.
  • Si solo especificas un tamaño de rango con la marca --services-ipv4-cidr (por ejemplo, /22), GKE seguirá usando el rango administrado por GKE para obtener el subrango de direcciones.
  • GKE no crea un rango de direcciones IP secundario independiente para los objetos Service cuando se usa el rango administrado por GKE.

Administrada por el usuario

Para tener control total sobre la asignación de direcciones IP, puedes administrar manualmente las subredes de tu clúster nativo de la VPC.

Puedes crear los rangos de direcciones IP secundarios de la subred y, luego, crear un clúster que los use. Durante la creación del clúster, especifica el nombre del rango de subred para los Pods y los servicios. 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 utilizable también depende de la cantidad máxima de Pods por nodo.

Consulta la tabla en Rangos de CIDR de Pod en clústeres estándar para 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 el rol de administrador de red en el proyecto host de la VPC compartida debe crear la subred del clúster 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 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 IPv4 principal de la subred

Ten en cuenta lo siguiente cuando planifiques el rango de direcciones IPv4 principal de la subred de un clúster:

  • Cada subred debe tener un rango de direcciones IP principal. Este es el rango de direcciones IP que GKE usa para asignar direcciones IP a los balanceadores de cargas internos y a los nodos.
  • No puedes reducir ni cambiar el rango de direcciones IP principal de una subred después de crearla.
  • Después de crear una subred, puedes expandir su rango de direcciones IP principal, pero no puedes reducirlo. Si expandes una subred que usa un clúster con redes autorizadas, debes agregar el rango de direcciones IP expandido a la lista de redes autorizadas del plano de control. Antes de expandir un rango, asegúrate de revisar las limitaciones y recomendaciones en Expande un rango IPv4 principal.
  • Google Cloudse reserva las dos primeras y las dos últimas direcciones IP de un rango de direcciones IP principal.
  • De forma predeterminada, los clústeres con Private Service Connect usan el rango de subred principal para aprovisionar la dirección IP interna asignada al extremo del plano de control. Sin embargo, puedes anular este aprovisionamiento de direcciones IP con la marca private-endpoint-subnetwork. Para obtener más información, consulta Crea un clúster y selecciona el rango de direcciones IP del plano de control.

En la siguiente tabla, se muestra la cantidad máxima de nodos que puedes crear según el tamaño del rango de direcciones IPv4 principal de la subred y la configuración del clúster:

  • Situación 1: Cantidad máxima de nodos en un clúster que usa la subred predeterminada.
  • Situación 2: Cantidad máxima de nodos en un clúster de Private Service Connect que no usa la marca private-endpoint-subnetwork.
Rango de direcciones IP principal de la subred Situación 1 Situación 2
/29
Tamaño mínimo del rango de direcciones IP principal de una subred		 4 nodos 3 nodos
/28 12 nodos 11 nodos
/27 28 nodos 27 nodos
/26 60 nodos 59 nodos
/25 124 nodos 123 nodos
/24 252 nodos 251 nodos
/23 508 nodos 507 nodos
/22 1,020 nodos 1019 nodos
/21 2,044 nodos 2043 nodos
/20
Tamaño predeterminado del rango de direcciones IP principal de una subred en redes de modo automático		 4,092 nodos 4091 nodos
/19 8,188 nodos 8187 nodos
/8
Tamaño máximo del rango de direcciones IP principal de una subred		 16,777,212 nodos 16,777,211 nodos

Expande el rango de direcciones IP principal

Si te quedas sin direcciones IP en el rango de direcciones IP principal, puedes expandir el rango de direcciones IP principal en cualquier momento, incluso cuando los recursos de Google Cloud , como los balanceadores de cargas y los grupos de extremos de red, usan la subred.

Antes de expandir el rango de direcciones IP principal, considera lo siguiente:

  • No debe haber rangos de direcciones IP superpuestos en la subred.
  • GKE usa el rango de direcciones IP principal para asignar direcciones IP a los balanceadores de cargas internos y a los nodos.
  • Si el clúster usa redes autorizadas, debes agregar el rango de direcciones IP principal expandido a la lista de redes autorizadas.

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 en los clústeres que usan la subred predeterminada. Usa S para el tamaño de la máscara de red, cuyo rango válido está 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.

En los clústeres de Private Service Connect que no usan la marca private-endpoint-subnetwork, puedes usar las fórmulas anteriores, pero reduce el valor de N en 1.

Consideraciones sobre el tamaño del clúster para el rango de direcciones IP secundario para Pods

Para calcular la cantidad máxima de Pods que admite tu clúster, considera el tamaño de la subred de Pods y la cantidad máxima de Pods por nodo. La cantidad máxima de Pods depende de la máscara de subred y la cantidad máxima de Pods por nodo. Además, recuerda que algunas direcciones IP están reservadas en el rango principal.

Variables clave

  • Q: Es la cantidad máxima de Pods por nodo.
  • DS: Es el tamaño del bloque CIDR seleccionado para la subred de Pod (por ejemplo, /17).
  • M: Es el tamaño de la máscara de red para el rango de Pods de cada nodo.
  • HM: Es la cantidad de bits de host para la máscara de red del rango de Pods del nodo.
  • HD: Es la cantidad de bits de host para el bloque CIDR de la subred de Pods.
  • MN: Es la cantidad máxima de nodos que se pueden admitir.
  • MP: Es la cantidad máxima de Pods que se pueden admitir.
  • S: Es la longitud del prefijo del rango de direcciones IP principal de la subred.
  • N: Es la cantidad de direcciones IP utilizables en el rango de direcciones IP principal de la subred.

Pasos para calcular la cantidad máxima de Pods

  1. Determina la cantidad máxima de Pods por nodo (Q):

    • En el caso de los clústeres de Autopilot, el valor de Q se fija en 32.
    • En los clústeres estándar, puedes configurar Q.

  2. Define el tamaño del bloque CIDR para la subred de Pods (DS):

    • Determina el tamaño del bloque de CIDR seleccionado para la subred de Pod (por ejemplo, /17).

  3. Calcula el tamaño de la máscara de red (M):

    M = 31 - ⌈log₂(Q)⌉

    Reemplaza Q por el valor de la cantidad máxima de Pods por nodo. Usa la función techo (⌈ ⌉) para redondear hacia arriba al número entero más cercano.

  4. Calcula los bits de host para el rango de Pods (HM):

    HM = 32 - M

  5. Calcula los bits de host para el bloque CIDR seleccionado (HD):

    HD = 32 - DS

  6. Calcula la cantidad máxima de nodos (MN):

    MN = 2<sup>(HD - HM)</sup>

    El resultado de este cálculo es la cantidad máxima de nodos que puede admitir la subred de Pods seleccionada.

  7. Calcula la cantidad máxima de Pods (MP):

    MP = MN * Q

    El resultado de este cálculo es la cantidad máxima de Pods que puede admitir el clúster.

  8. Calcula la cantidad de direcciones IP utilizables en el rango principal (N): none N = 2<sup>(32-S)</sup> - 4 Donde S es la longitud del prefijo del rango CIDR principal de la subred.

Notas importantes

  • Todas las direcciones IP del rango secundario se pueden usar para los Pods.
  • Estos cálculos proporcionan los máximos teóricos. El rendimiento en el mundo real puede verse afectado por otros factores.

Ejemplo

Supongamos que creas un clúster de GKE Autopilot con los siguientes parámetros:

  • Un bloque CIDR de subred de Pod de /17 (DS = 17).
  • Un máximo de 32 Pods por nodo (Q = 32)

Calcula la cantidad máxima de Pods:

  1. M = 31 - ⌈log₂(32)⌉ = 26
  2. HM = 32 - 26 = 6
  3. HD = 32 - 17 = 15
  4. MN = 2(15 - 6) = 512
  5. MP = 512 * 32 = 16,384

Este clúster puede admitir un máximo de 512 nodos y 16,384 Pods.

Puedes agregar más direcciones IPv4 para los Pods agregando rangos de direcciones IPv4 de Pod o agregando subredes a los clústeres.

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 servicios de varios clústeres, el objeto ServiceImport usa direcciones IP del rango de direcciones IP secundario para los servicios.

En los clústeres de GKE Autopilot que ejecutan la versión 1.27 y versiones posteriores, y en los clústeres de GKE Standard que ejecutan las versiones 1.29 y versiones posteriores, GKE asigna direcciones IP para los Services de un rango administrado por GKE de forma predeterminada: 34.118.224.0/20. Esto reduce la necesidad de especificar tu propio rango de direcciones IP para los servicios. Se aplican las siguientes consideraciones:

  • De manera opcional, puedes especificar rangos personalizados para los servicios con la marca --services-ipv4-cidr o la marca --services-secondary-range-name.
  • Si solo especificas un tamaño de rango con la marca --services-ipv4-cidr (por ejemplo, /22), GKE seguirá usando el rango administrado por GKE para obtener el subrango de direcciones.
  • GKE no crea un rango de direcciones IP secundario independiente para los objetos Service cuando se usa el rango administrado por Google. El rango administrado por GKE no usa la cuota de rango de direcciones IP secundarias de tu subred.

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 subred personalizado para el plano de control

De forma predeterminada, GKE usa el rango de subred principal para aprovisionar el extremo interno del plano de control. Sin embargo, en los clústeres con Private Service Connect, puedes configurar GKE para que aprovisione el extremo interno desde una subred diferente que hayas creado. Puedes compartir esta subred entre otros clústeres o en todos los proyectos si usas una VPC compartida.

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.

  • Entre los diferentes tipos de rangos secundarios, tanto el rango Administrado por GKE y los Rangos de Pods adicionales no pueden compartirse entre clústeres.

  • Para compartir un rango de direcciones IP secundario, pásalo en la línea de comandos con --cluster-secondary-range. No puedes usar un rango secundario compartido cuando creas clústeres en la IU.

Comparte el rango de direcciones IP secundario para objetos Service

Dos o más clústeres pueden usar simultáneamente el mismo rango de direcciones IPv4 secundario de la subred para servicios cuando usas rangos secundarios administrados por el usuario.

Si deseas configurar dos o más clústeres a fin de compartir un rango de direcciones IPv4 secundario de subred común para objetos Service, usa el mismo rango de direcciones IPv4 secundario de la subred cuando crees cada clúster. No se requiere una marca de configuración independiente para compartir un rango de direcciones IPv4 común para Services.

Cuando se comparte un rango de direcciones IPv4 común para servicios, cada clúster usa el rango de direcciones IPv4 secundario de la subred completo para los Services de forma interna. Las direcciones IP para los Services se programan dentro del nodo de cada clúster, pero no se asignan a la interfaz de red de ningún nodo. Las direcciones IP de los servicios no se pueden enrutar dentro de la red de VPC del clúster. Solo los Pods cliente pueden usar las direcciones IP de Service dentro del mismo clúster que el Service.

Cuando un Pod envía un paquete a una dirección IP de Service, la configuración de iptables o eBPF del nodo realiza la traducción de direcciones de red (NAT) de destino y cambia la dirección IP de destino del paquete desde la IP del Service. dirección a una IP de Pod de entrega. El paquete se enruta en función de la dirección IP del Pod de destino.

Compartir el rango de direcciones IP secundario para objetos Service proporciona 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:

  • El uso compartido del rango de direcciones IP secundario para objetos Service no es compatible con el permiso de VPC de Cloud DNS para GKE.

  • No puedes compartir rangos que coincidan con la siguiente expresión regular:

    ^gke-.*-services-[abcdef0-9]{8}

  • Para compartir un rango de direcciones IP secundario para los servicios, pásalo en la línea de comandos con --cluster-secondary-range. No puedes usar un rango secundario compartido para los servicios cuando creas clústeres en la IU.

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.

El siguiente mensaje de error indica 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 para Pods):

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 de direcciones IP gratuito para Pods.

Herramientas de redes de pila doble IPv4/IPv6

Con las herramientas de redes de pila doble IPv4/IPv6, 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 1.24 de GKE o en versiones posteriores, puedes habilitar las redes de pila doble para los clústeres de GKE nuevos en redes de VPC independientes y compartidas. También puedes aplicar políticas de red con las redes de pila doble habilitadas. Si ves errores de validación cuando habilitas las redes de pila doble en clústeres de GKE que se actualizaron de la versión 1.24 a la 1.25 o 1.26, comunícate con el Google Cloud equipo de asistencia al cliente.

Beneficios

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 la traducción de direcciones de red (NAT) o los túneles IP. Esto se logra porque no hay traducción de IPv6 a IPv4.

Disponibilidad

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

  • 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 Google Cloud tipos de redes de VPC.
  • No se admiten direcciones IPv6 de pila única para Pods o nodos.
  • Los clústeres de pila doble consumen memoria adicional por nodo para admitir IPv4 e IPv6 en comparación con los clústeres solo IPv4. Ten en cuenta esta característica cuando configures clústeres a gran escala.
  • Los clústeres de pila doble no son compatibles con el Acceso privado a Google a través de IPv6.
  • Las versiones de GKE 1.26.0-gke.2200 y posteriores admiten IPv6 (registros AAAA) con Cloud DNS para las operaciones internas del clúster y las consultas de DNS externo.
  • Los Services de pila doble son compatibles con los Services ClusterIP, NodePort y LoadBalancer.
  • IPv6 no es compatible con nodos de Windows.

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

Asignación de dirección IPv6 pública y privada

En la siguiente tabla, se proporciona un resumen de las direcciones IPv6 públicas y privadas con el comportamiento y la configuración de red de pila doble:

Marca ipv6-access-type Asignación de una dirección IP Rango de subred
EXTERNAL

GKE asigna direcciones IPv6 externas que se pueden enrutar a Internet.

 De 2600:1900/28
INTERNAL

GKE asigna direcciones IPv6 internas que no se pueden enrutar a Internet.

Los clústeres con el tipo de acceso IPv6 INTERNAL no pueden acceder a Internet a través de direcciones IPv6. 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).

Si deseas obtener más información, consulta cómo usar una red de pila doble para un clúster nativo de la VPC.

Arquitectura

Un clúster con redes IPv4/IPv6 de pila doble tiene los siguientes rangos asignados:

  • Un rango /64 a cada subred como un rango principal.
  • Un rango /96 por nodo del rango principal para usar como rango de direcciones IP del nodo principal.

  • 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 de un 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.

  • Un rango /112 para usar con los Services. 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:

Asignación de direcciones IPv6 en GKE. Diagrama que 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 objeto Service de pila doble IPv4/IPv6 de tipo ClusterIP o NodePort. Los clústeres de GKE nuevos que ejecutan la versión 1.29 o una posterior admiten los Services de pila doble de tipo LoadBalancer.

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

¿Qué sigue?