Clústeres nativos de VPC (original) (raw)

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

Esta página está dirigida a arquitectos de nube y especialistas en redes que diseñan y definen la arquitectura de la red de su organización. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas habituales de los usuarios de GKE.

Información general

En GKE, los clústeres se pueden distinguir según la forma en que enrutan el tráfico de un pod a otro.

Un clúster que usa intervalos de direcciones IP con alias se denomina clúster nativo de 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 se encargue de definir, implementar y mantener tu arquitectura de red.

Ventajas de los clústeres nativos de VPC

Los clústeres nativos de VPC ofrecen varias ventajas:

• Las direcciones IP de los pods se pueden enrutar de forma nativa en la red de VPC del clúster y en otras redes de VPC conectadas a ella mediante el emparejamiento entre redes de VPC.
• Las direcciones IP de los pods se reservan en la red VPC antes de que se creen los pods en tu clúster. De esta forma, se evitan conflictos con otros recursos de la red de VPC y se pueden planificar mejor las asignaciones de direcciones IP.
• Los intervalos de direcciones IP de pods no dependen de las 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 gestionan el enrutamiento de los clústeres nativos de VPC.
• Puedes crear reglas de cortafuegos que se apliquen solo a intervalos de direcciones IP de pods en lugar de a cualquier dirección IP de los nodos del clúster.
• Se puede acceder a los intervalos de direcciones IP de los pods y a los intervalos de direcciones IP secundarias de las subredes en general desde las redes on-premise conectadas con Cloud VPN o Cloud Interconnect mediante Cloud Routers.
• Algunas funciones, como los grupos de puntos finales de red (NEGs), solo funcionan con clústeres nativos de VPC.

Modo de red de clúster predeterminado

El modo de red nativo de VPC es el predeterminado para todos los clústeres de GKE 1.21.0-gke.1500 y versiones posteriores. En versiones anteriores, el modo de red de clúster predeterminado depende de cómo crees el clúster.

En la siguiente tabla se muestra el modo de red de clúster predeterminado para las versiones de clúster de GKE y los métodos de creación de clústeres.

También puedes crear un clúster basado en rutas especificando la marca --no-enable-ip-alias al crear el clúster.

Intervalos de direcciones IP de clústeres nativos de VPC

Cuando creas un clúster nativo de VPC, especificas una subred en una red de VPC. El clúster usa los siguientes intervalos de direcciones IP de subred:

Asignación de direcciones IPv4

Los clústeres nativos de VPC asignan direcciones IPv4 a los nodos, los pods y los servicios de la siguiente manera.

• Direcciones IPv4 de los nodos: el clúster utiliza el intervalo de direcciones IPv4 principal de la subred para asignar direcciones IP a todos los nodos.
• Direcciones IPv4 de los pods: el clúster utiliza uno o varios intervalos de direcciones IPv4 secundarias de subred para todas las direcciones IPv4 de los pods. En esta página se explica cómo usar un único intervalo de direcciones IPv4 secundarias de una subred. Para obtener información sobre cómo usar varios intervalos, consulta Añadir intervalos de direcciones IPv4 de pods.
• Direcciones IPv4 de servicio: hay dos opciones disponibles:
  • Direcciones IPv4 de servicio de 34.118.224.0/20: los clústeres Autopilot de GKE que ejecutan la versión 1.27 y posteriores, y los clústeres Estándar de GKE que ejecutan la versión 1.29 y posteriores usan el intervalo de direcciones IPv4 34.118.224.0/20 para los servicios.Google Cloud usa el intervalo de direcciones 34.118.224.0/20 con fines privados y no publica ninguna ruta en Internet pública para este intervalo. No puedes usar este intervalo para las direcciones IPv4 externas de tus recursos.
  • **Direcciones IPv4 de servicio de un intervalo de direcciones IPv4 secundario de una subred:**para todas las direcciones de servicio (ClusterIP), el clúster utiliza un intervalo de direcciones IPv4 secundario de una subred que es diferente de los intervalos utilizados por los pods.

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

• Direcciones IPv6 de nodos y pods: en los clústeres con redes de pila dual habilitadas, la dirección IPv6 del nodo y todas las direcciones IPv6 de los pods proceden del /96 intervalo de direcciones IPv6 designado del nodo. La dirección IP del nodo es la primera /128 (dirección IPv6 única) de este intervalo. Para obtener más información, consulta la red de pila dual.
• Direcciones IPv6 de servicio: los clústeres de GKE usan el 2600:2D00:0:4::0:0/64intervalo de direcciones IPv6 para los servicios Google Cloud.Este intervalo se usa con fines privados y no se publican rutas en Internet para este intervalo.2600:2D00:0:4::0:0/64 No puedes usar este intervalo para las direcciones IPv6 externas de tus recursos.

En la siguiente tabla se ofrece un resumen de los intervalos de direcciones IP de nodos, pods y servicios:

Direcciones IPv4 internas

Las direcciones IPv4 que uses para las subredes de tu clúster con VPC nativa deben proceder de un intervalo de subredes válido. Los intervalos válidos incluyen direcciones IPv4 privadas, como RFC 1918, y direcciones IP públicas de uso privado. Para obtener más información sobre los intervalos IPv4 de subred válidos, consulta las secciones Intervalos válidos e Intervalos restringidos de la documentación de VPC.

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

Para obtener información importante sobre el uso de intervalos de direcciones IPv4 públicas usadas de forma privada, consulte Habilitar intervalos de direcciones IP públicas usadas de forma privada.

Métodos de asignación de intervalos de IPv4 secundarios de subred

Puedes asignar intervalos de direcciones IP de pods e intervalos de direcciones de servicios (ClusterIP) a un clúster nativo de VPC. GKE o el usuario pueden gestionar estos intervalos de direcciones IP.

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

Asignación: asignar intervalos de direcciones IP se refiere al proceso de asignar un intervalo de subred específico a un clúster nativo de VPC. De esta forma, se crea un conjunto de direcciones IP que los componentes pueden usar en el clúster, como los pods y los servicios.

Gestión: la gestión del intervalo de direcciones IP hace referencia a las operaciones CRUD continuas (creación, actualización, eliminación y lectura) a nivel de clúster, grupo de nodos o pod, relacionadas con los intervalos de subred asignados y la asignación de recursos en tu clúster nativo de VPC.

Intervalos secundarios gestionados por GKE (opción predeterminada)

En los clústeres de Autopilot de GKE que ejecutan la versión 1.27 o posterior, y en los clústeres estándar de GKE que ejecutan la versión 1.29 o posterior, GKE asigna direcciones IP a los servicios desde un intervalo gestionado por GKE de forma predeterminada: 34.118.224.0/20. De esta forma, no tendrás que especificar tu propio intervalo de direcciones IP para los servicios. Se aplican las siguientes consideraciones:

• Si quiere, puede especificar intervalos personalizados para los servicios mediante la marca --services-ipv4-cidr.
• Si solo especificas un tamaño con la marca --services-ipv4-cidr (por ejemplo, /22), GKE seguirá usando el intervalo gestionado por GKE para obtener el subintervalo de direcciones.
• Si solo especificas el tamaño del intervalo de direcciones IP de los pods (por ejemplo, --cluster-ipv4-cidr=/17), GKE seleccionará automáticamente un intervalo de direcciones IP secundario disponible de tu red de VPC.
• GKE no crea un intervalo de direcciones IP secundarias independiente para los servicios cuando se usa el intervalo gestionado por GKE.

Gestionada por el usuario

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

Puedes crear los intervalos de direcciones IP secundarias de la subred y, a continuación, crear un clúster que utilice esos intervalos. Durante la creación del clúster, especifica el nombre del intervalo de subred de los pods y los servicios. Si creas manualmente los intervalos secundarios, debes gestionarlos tú mismo.

El intervalo de direcciones IP más pequeño que puedes crear sin usar CIDR de varios pods no contiguos es /28, pero ese intervalo solo te permitiría crear 1 nodo con un máximo de 8 pods. Debes usar un intervalo lo suficientemente grande como para incluir el número máximo de nodos que necesites.

El intervalo mínimo utilizable también depende del número máximo de pods por nodo.

Consulta la tabla de Intervalos CIDR de pods en clústeres estándar para ver el intervalo CIDR mínimo utilizable para diferentes valores de pods máximos por nodo.

Si agotas el intervalo de direcciones IP de los pods, debes hacer una de las siguientes acciones:

• Crea un clúster con un intervalo de direcciones de pods más grande.
• Vuelve a crear los grupos de nodos después de reducir el --max-pods-per-nodede los grupos de nodos.
• Amplía el intervalo de direcciones IP secundarias de los pods con CIDR de varios pods no contiguos.

Diferencias con los clústeres basados en rutas

El esquema de asignación de direcciones de pods y servicios (ClusterIP) es diferente del esquema utilizado por un clúster basado en rutas. En lugar de especificar un único CIDR para pods y servicios, debes elegir o crear dos intervalos de direcciones IP secundarias en la subred del clúster: uno para los pods y otro para los servicios.

Consideraciones sobre la VPC compartida

Cuando se crea un clúster nativo de VPC en un entorno de VPC compartida, un propietario, editor o principal de Gestión de Identidades y Accesos (IAM) del proyecto host de la VPC compartida con el rol Administrador de redes debe crear manualmente la subred del clúster y los intervalos de direcciones IP secundarias. Un administrador de un proyecto de servicio que cree 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 gestionar los intervalos de direcciones IP secundarias. Un administrador de red del proyecto host de la VPC compartida debe crear la subred y los intervalos de direcciones IP secundarias para que puedas crear el clúster. Para ver un ejemplo de cómo configurar un clúster nativo de VPC en una red de VPC compartida, consulta Configurar clústeres con una VPC compartida.

Planificación de intervalos de direcciones IP

Utilice la información de las secciones siguientes para calcular los tamaños de los intervalos de direcciones IP principales y secundarias de la subred que usa su clúster.

Intervalo de direcciones IPv4 principales de la subred

Ten en cuenta lo siguiente al planificar el intervalo de direcciones IPv4 principal de la subred de un clúster:

• Cada subred debe tener un intervalo de direcciones IP principal. Es el intervalo de direcciones IP que usa GKE para asignar direcciones IP a los balanceadores de carga y los nodos internos.
• Una vez creada una subred, no puedes reducirla ni cambiar su intervalo de direcciones IP principal.
• Después de crear una subred, puedes ampliar su intervalo de direcciones IP principal, pero no reducirlo. Si amplías una subred que utiliza un clúster con redes autorizadas, debes añadir el intervalo de direcciones IP ampliado a la lista de redes autorizadas del plano de control. Antes de ampliar un intervalo, consulta las limitaciones y las recomendaciones en Ampliar un intervalo IPv4 principal.
• Google Cloudreserva las dos primeras y las dos últimas direcciones IP de un intervalo de direcciones IP principal.
• Los clústeres con Private Service Connect usan el intervalo de la subred principal para aprovisionar la dirección IP interna asignada al endpoint 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 Crear un clúster y seleccionar el intervalo de direcciones IP del plano de control.

En la siguiente tabla se muestra el número máximo de nodos que puede crear en función del tamaño del intervalo de direcciones IPv4 principal de la subred y de la configuración del clúster:

• Situación 1: número máximo de nodos en un clúster que usa la subred predeterminada.
• Situación 2: número máximo de nodos en un clúster de Private Service Connect que no usa la marca private-endpoint-subnetwork.

Amplía el intervalo de direcciones IP principal

Si te quedas sin direcciones IP en el intervalo de direcciones IP principal, puedes ampliar el intervalo de direcciones IP principal en cualquier momento, incluso cuando los recursos, como los balanceadores de carga y los grupos de endpoints de red, usen la subred. Google Cloud

Antes de ampliar el intervalo de direcciones IP principal, ten en cuenta lo siguiente:

• No debe haber intervalos de direcciones IP superpuestos en la subred.
• GKE usa el intervalo de direcciones IP principal para asignar direcciones IP a los balanceadores de carga internos y a los nodos.
• Si el clúster usa redes autorizadas, debes añadir el intervalo de direcciones IP principal ampliado a la lista de redes autorizadas.

Fórmulas útiles

Puedes usar las siguientes fórmulas para:

• Calcula el número máximo de nodos, N, que puede admitir una máscara de subred determinada en clústeres que usan la subred predeterminada. Usa S para el tamaño de la máscara de red, cuyo intervalo válido está comprendido entre 8 y 29, ambos incluidos.
  N = 2(32 -S) - 4
• Calcula el tamaño de la máscara de red, S, necesaria para admitir un máximo de N nodos:
  S = 32 - ⌈log2(N + 4)⌉
  ⌈⌉ es la función de redondeo hacia arriba (entero inferior), es decir, redondea hacia arriba al siguiente entero. El intervalo válido para el tamaño de la máscara de red, S, está comprendido entre 8 y 29, ambos incluidos.

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 intervalo de direcciones IP secundario de los pods

Para calcular el número máximo de pods que puede admitir tu clúster, ten en cuenta el tamaño de la subred de pods y el número máximo de pods por nodo. El número máximo de pods depende de la máscara de subred y del número máximo de pods por nodo. Además, recuerda que algunas direcciones IP están reservadas en el intervalo principal.

Variables clave

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

Pasos para calcular el número máximo de pods

1. Determina el número máximo de pods por nodo (Q):
   • En los clústeres de Autopilot, el valor de Q es 32.
   • En los clústeres estándar, puedes configurar Q.
2. Define el tamaño del bloque CIDR de la subred de los pods (DS):
   • Determina el tamaño del bloque CIDR seleccionado para la subred de pods (por ejemplo, /17).
3. Calcula el tamaño de la máscara de subred (M):

M = 31 - ⌈log₂(Q)⌉  

Sustituye Q por el valor de máximo de pods por nodo. Usa la función CEILING (⌈ ⌉) para redondear al entero más cercano. 4. Calcula los bits de host del intervalo de pods (HM):

HM = 32 - M  

1. Calcula los bits de host del bloque CIDR seleccionado (HD):

HD = 32 - DS  

1. Calcula el número máximo de nodos (MN):

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

El resultado de este cálculo es el número máximo de nodos que puede admitir la subred de pods seleccionada. 7. Calcula el número máximo de pods (MP):

MP = MN * Q  

El resultado de este cálculo es el número máximo de pods que puede admitir el clúster. 8. Calcula el número de direcciones IP utilizables del intervalo principal (N): none N = 2<sup>(32-S)</sup> - 4donde S es la longitud del prefijo del intervalo CIDR principal de la subred.

Información importante

• Todas las direcciones IP del intervalo 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 vas a crear un clúster de Autopilot de GKE con lo siguiente:

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

Calcula el número máximo 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 añadir más direcciones IPv4 para pods añadiendo intervalos de direcciones IPv4 de pods o añadiendo subredes a clústeres.

Intervalo de direcciones IP secundarias de subred para servicios

Planifica cuidadosamente el intervalo de direcciones IP secundarias de los servicios. Como también es un intervalo de direcciones IP secundarias de subred, no se puede cambiar una vez que se haya creado el clúster.

Si usas servicios multiclúster, el objeto ServiceImport usa direcciones IP del intervalo de direcciones IP secundario para los servicios.

En los clústeres de Autopilot de GKE que ejecutan la versión 1.27 o posterior, y en los clústeres estándar de GKE que ejecutan la versión 1.29 o posterior, GKE asigna direcciones IP a los servicios de un intervalo gestionado por GKE de forma predeterminada: 34.118.224.0/20. De esta forma, no tendrás que especificar tu propio intervalo de direcciones IP para los servicios. Se aplican las siguientes consideraciones:

• Si quiere, puede especificar intervalos personalizados para los servicios mediante la marca --services-ipv4-cidr o la marca --services-secondary-range-name.
• Si solo especificas un tamaño con la marca --services-ipv4-cidr (por ejemplo, /22), GKE seguirá usando el intervalo gestionado por GKE para obtener el subintervalo de direcciones.
• GKE no crea un intervalo de direcciones IP secundarias independiente para los servicios cuando se usa el intervalo gestionado por Google. El intervalo gestionado por GKE no usa la cuota de intervalo de direcciones IP secundarias de tu subred.

En la siguiente tabla se muestra el número máximo de servicios que puedes crear en un solo clúster mediante la subred, dado el tamaño del intervalo de direcciones IP secundarias de la subred para los servicios.

Compartir intervalos de direcciones IP entre clústeres de GKE

Puedes compartir el intervalo principal, el intervalo de direcciones IP secundario de los pods y el intervalo de direcciones IP secundario de los servicios entre clústeres de la misma subred. Este comportamiento está disponible tanto para los clústeres Estándar como para los Autopilot.

Puede que quieras compartir intervalos de direcciones IP si tienes un equipo centralizado que gestiona la infraestructura de los clústeres. Puedes reducir la sobrecarga creando tres intervalos (para pods, servicios y nodos) y reutilizándolos o compartiéndolos, sobre todo en un modelo de VPC compartida. También puede facilitar a los administradores de redes la gestión de direcciones IP, ya que no tienen que crear subredes específicas para cada clúster.

Compartir el intervalo de subred personalizado del plano de control

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

Compartir el intervalo de direcciones IP principal de los nodos

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

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

• Si compartes el intervalo de direcciones IP principal de los nodos con dos o más clústeres nativos de VPC, un clúster puede usar una gran parte del intervalo de direcciones IP compartido, lo que dejará a los demás clústeres sin suficientes direcciones IP para ampliarse.

Cuando compartes el intervalo secundario de los Pods, cada Pod sigue teniendo una dirección IP única.

Compartir el intervalo de direcciones IP secundario de los pods tiene las siguientes limitaciones:

• Si compartes el intervalo de direcciones IP secundarias de los pods con dos o más clústeres nativos de VPC, un clúster puede usar una gran parte del intervalo de direcciones IP compartidas, lo que dejará a los demás clústeres sin suficientes direcciones IP para ampliarse.
• De los diferentes tipos de intervalos secundarios, ni los gestionados por GKE ni los intervalos de pods adicionales se pueden compartir entre clústeres.
• Para compartir un intervalo de direcciones IP secundarias, pásalo por la línea de comandos con--cluster-secondary-range. No puedes usar un intervalo secundario compartido al crear clústeres en la interfaz de usuario.

Dos o más clústeres pueden usar simultáneamente el mismo intervalo de direcciones IPv4 secundarias de subred para los servicios cuando se usan intervalos secundarios gestionados por el usuario.

Para configurar dos o más clústeres de forma que compartan un intervalo de direcciones IPv4 secundario de subred común para los servicios, usa el mismo intervalo de direcciones IPv4 secundario de subred al crear cada clúster. No se necesita ninguna marca de configuración independiente para compartir un intervalo de direcciones IPv4 común para los servicios.

Cuando se comparte un intervalo de direcciones IPv4 común para los servicios, cada clúster utiliza internamente todo el intervalo de direcciones IPv4 secundario de la subred para los servicios. Las direcciones IP de los servicios se programan en el nodo de cada clúster, pero no se asignan a la interfaz de red de ningún nodo. Las direcciones IP de servicio no se pueden enrutar en la red de VPC del clúster. Las direcciones IP de servicio solo pueden usarlas los pods de cliente que estén en el mismo clúster que el servicio.

Cuando un pod envía un paquete a una dirección IP de servicio, la configuración de iptables o eBPF del nodo realiza la traducción de direcciones de red (NAT) de destino, cambiando la dirección IP de destino del paquete de la dirección IP de servicio a la dirección IP de un pod de servicio. El paquete se enruta en función de la dirección IP del pod de destino.

Compartir el intervalo de direcciones IP secundario de los servicios ofrece las siguientes ventajas:

• Reduce el número de intervalos de direcciones IP secundarias únicas de los servicios creados en una subred
• Usar menos direcciones IP

Compartir el intervalo de direcciones IP secundario de los servicios tiene las siguientes limitaciones:

• No se puede compartir el intervalo de direcciones IP secundarias de los servicios con Cloud DNS con ámbito de VPC para GKE.
• No puedes compartir intervalos que coincidan con la siguiente expresión regular:

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

• Para compartir un intervalo de direcciones IP secundario para los servicios, pásalo en la línea de comandos con --cluster-secondary-range. No puedes usar un intervalo secundario compartido para los servicios al crear clústeres en la interfaz de usuario.

Intervalos de limitación de nodos

El número máximo de pods y servicios de un clúster de GKE determinado está limitado por el tamaño de los intervalos secundarios del clúster. El número máximo de nodos del clúster está limitado por el tamaño del intervalo de direcciones IP principal de la subred del clúster y por el intervalo de direcciones de los pods del clúster.

El siguiente mensaje de error indica que se ha agotado el intervalo de direcciones IP principal de la subred o el intervalo de direcciones IP de los pods del clúster (el intervalo de direcciones IP secundario de la subred para los pods):

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

Puedes añadir más direcciones IP para los nodos ampliando la subred principal o añadir nuevas direcciones IP para los pods mediante CIDR de varios pods no contiguos. Para obtener más información, consulta No hay suficiente espacio de direcciones IP libres para los pods.

Redes de doble pila IPv4/IPv6

Con la red de doble pila IPv4/IPv6, puede definir cómo asigna GKE direcciones IP (ipFamilies) a los siguientes objetos:

• En el caso de los pods y los nodos, GKE asigna direcciones IPv4 e IPv6.
• En el caso de los servicios, GKE asigna direcciones de pila única (solo IPv4 o solo IPv6) o de doble pila.

En la versión 1.24 de GKE o en una posterior, puedes habilitar la red de doble pila para los nuevos clústeres de GKE en redes de VPC independientes y compartidas. También puedes aplicar políticas de red con la red de pila dual habilitada. Si ves errores de validación al habilitar la red de pila dual en clústeres de GKE que se han actualizado de las versiones 1.24 a las 1.25 o 1.26, ponte en contacto con el Google Cloud equipo de Asistencia.

Ventajas

Las redes de pila dual ofrecen las siguientes ventajas:

• Habilita la comunicación IPv6 de extremo a extremo.
• Permite obtener un mejor rendimiento en comparación con la traducción de direcciones de red (NAT) o el túnel IP. Esto se debe a que no hay traducción de IPv6 a IPv4.

Disponibilidad

La red de doble pila con GKE tiene las siguientes restricciones:

• La red de doble pila solo está disponible en clústeres nativos de VPC con GKE Dataplane V2 habilitado.
• Las redes de pila dual solo se admiten en subredes de VPCs en modo personalizado. Para obtener más información, consulta los Google Cloud tipos de redes de VPC.
• No se admiten direcciones IPv6 de pila única para pods o nodos.
• Los clústeres de doble pila consumen más memoria por nodo para admitir tanto IPv4 como IPv6 en comparación con los clústeres solo IPv4. Ten en cuenta esta característica al configurar clústeres a gran escala.
• Los clústeres de pila dual no admiten el acceso privado a Google a través de IPv6.
• Las versiones 1.26.0-gke.2200 y posteriores de GKE admiten IPv6 (registros AAAA) con Cloud DNS para operaciones internas del clúster y consultas de DNS externas.
• Los servicios de pila dual son compatibles con los servicios ClusterIP, NodePort y LoadBalancer.
• IPv6 no es compatible con los nodos de Windows.

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

Asignación de direcciones IPv6 públicas y privadas

En la siguiente tabla se ofrece un resumen de las direcciones IPv6 públicas y privadas con el comportamiento y las configuraciones de redes de pila dual:

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

Arquitectura

Un clúster con una red de doble pila IPv4/IPv6 tiene asignados los siguientes intervalos:

• Un intervalo /64 para cada subred como intervalo principal.
• Un intervalo /96 por nodo del intervalo principal que se usará como intervalo de direcciones IP de nodo principal.
• Un intervalo por nodo /112 del intervalo de direcciones IP del nodo principal que se usará como intervalo de direcciones IP de Pod para ese nodo. Con las redes de doble pila, los pods obtienen sus direcciones IPv6 del intervalo de direcciones IP de pods general (similar a los nodos) y no de un intervalo secundario de pods reservado para direcciones IPv4.
  El intervalo de direcciones IP de pods general se compone de intervalos que no se solapan del intervalo de IP del nodo principal. Por lo tanto, este intervalo de IPs de pods no es contiguo.
• Un intervalo /112 para usarlo en los servicios. Este intervalo procede de un intervalo /64 del intervalo de direcciones privadas de Google, que se ha reservado para el intervalo de direcciones IP de los servicios secundarios de GKE.

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

Asignación de direcciones IPv6 en GKE.

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

Servicios

Puedes crear un servicio de pila dual IPv4/IPv6 de tipoClusterIPoNodePort. Los nuevos clústeres de GKE que ejecutan la versión 1.29 o una posterior admiten servicios de tipo LoadBalancer de doble pila.

Puedes exponer un Deployment con un Service de tipo ClusterIP, NodePort o LoadBalancer. En cada uno de estos tipos de servicio, puedes definir los campos ipFamilies y ipFamilyPolicy como IPv4, IPv6 o un servicio de pila dual. Para obtener más información, consulta un ejemplo de cómo configurar una implementación.

Siguientes pasos

• Más información sobre el emparejamiento entre redes de VPC
• Consulta cómo crear un clúster nativo de VPC.
• Consulta información valiosa sobre la utilización de las direcciones IP de GKE.