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, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud
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.
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 pods y a los intervalos de direcciones IP secundarias de subredes en general desde redes on-premise conectadas con Cloud VPN o Cloud Interconnect mediante Cloud Routers.
Algunas funciones, como los grupos de puntos finales de red (NEG), 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.
| Versiones de GKE | Método de creación del clúster | Modo de red del clúster |
|---|---|---|
| Todas las versiones | La Google Cloud consola | VPC nativa |
| 1.21.0-gke.1500 y versiones posteriores | API de GKE o Google Cloud CLI | VPC nativa |
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. Esta página se centra en el uso de un único intervalo de direcciones IPv4 secundarias de 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 IPv434.118.224.0/20para los servicios.Google Cloud usa el intervalo de direcciones34.118.224.0/20con 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
/96intervalo 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/64No 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:
| Intervalo | Explicación | Ejemplo |
|---|---|---|
| Nodos |
Las direcciones IP de los nodos se asignan del intervalo de direcciones IP principal de la subred asociada a tu clúster. Tanto las direcciones IP de los nodos como el tamaño del intervalo de direcciones IP secundarias de la subred para los pods limitan el número de nodos que puede admitir un clúster. Consulta los intervalos de limitación de nodos para obtener más información. |
Si tienes previsto crear un clúster de 900 nodos, el intervalo de direcciones IP principal de la subred del clúster debe ser al menos Para obtener más información, consulta Intervalo de direcciones IP principales de subred e Intervalo de direcciones IP secundarias de subred para pods. |
| Pods |
Las direcciones IP de los pods se toman del intervalo de direcciones IP secundario de la subred del clúster para los pods. A menos que definas un número máximo diferente de pods por nodo, GKE asigna un |
En un clúster de 900 nodos que admite hasta 110 pods por nodo, necesitas 900 × 256 = 230.400 direcciones IP para los pods. A cada nodo se le asigna un intervalo de IPs de alias cuya máscara de red tiene un tamaño de /24. Este clúster requiere una subred cuyo intervalo de IPs secundario para pods tenga una máscara de subred no superior a /14. Este intervalo de IPs secundario proporciona 2(32-14) = 218 = 262.144 direcciones IP para los pods. Consulta más información en Intervalo de direcciones IP secundarias de subred para pods. |
| Servicios |
Las direcciones de servicio (IP de clúster) se toman del intervalo de direcciones IP secundario de la subred del clúster para los servicios. Debes asegurarte de que este intervalo sea lo suficientemente amplio para proporcionar direcciones a todos los servicios de Kubernetes que alojes en tu clúster. 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 GKE desde un intervalo gestionado por GKE: |
En un clúster que ejecute hasta 3000 servicios, necesitarás 3000 direcciones IP de clúster. Necesitas un intervalo secundario de tamaño /20 o superior. Un intervalo /20 de direcciones IP da como resultado 2(32-20) = 212 = 4096 direcciones IP. Para obtener más información, consulta Intervalo de direcciones IP secundarias de subred para 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 subred 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 y de servicios (ClusterIP) a un clúster nativo de VPC. GKE o el usuario pueden gestionar estos intervalos de direcciones IP.
Para entender los métodos de asignación de intervalos secundarios, debes conocer los siguientes términos clave.
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 de intervalo mediante 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 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 para 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 que utiliza 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 redes 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
Use 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.
- Las dos primeras y las dos últimas direcciones IP de un intervalo de direcciones IP principal están reservadas porGoogle Cloud.
- 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.
| Intervalo de direcciones IP principales de la subred | Caso 1 | Caso 2 |
|---|---|---|
| /29 Tamaño mínimo del intervalo de direcciones IP principales 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 | 1020 nodos | 1019 nodos |
| /21 | 2044 nodos | 2043 nodos |
| /20 Tamaño predeterminado del intervalo de direcciones IP principales de una subred en redes en modo automático |
4092 nodos | 4091 nodos |
| /19 | 8188 nodos | 8187 nodos |
| /8 Tamaño máximo del intervalo de direcciones IP principales de una subred |
16.777.212 nodos | 16.777.211 nodos |
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 y los nodos internos.
- 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
8y29, 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), lo que significa que se redondea al entero siguiente. El intervalo válido para el tamaño de la máscara de red, S, está comprendido entre8y29, 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
Determina el número máximo de pods por nodo (
Q):- En los clústeres de Autopilot, el valor de
Qes fijo y se establece en 32. - En los clústeres estándar, puedes configurar
Q.
- En los clústeres de Autopilot, el valor de
Define el tamaño del bloque CIDR de la subred de pods (
DS):- Determina el tamaño del bloque CIDR seleccionado para la subred de pods (por ejemplo,
/17).
- Determina el tamaño del bloque CIDR seleccionado para la subred de pods (por ejemplo,
Calcula el tamaño de la máscara de subred (
M):M = 31 - ⌈log₂(Q)⌉Sustituye
Qpor el valor de número máximo de pods por nodo. Usa la función CEILING (⌈ ⌉) para redondear al entero más cercano.Calcula los bits de host del intervalo de pods (
HM):HM = 32 - MCalcula los bits de host del bloque CIDR seleccionado (
HD):HD = 32 - DSCalcula 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.
Calcula el número máximo de pods (
MP):MP = MN * QEl resultado de este cálculo es el número máximo de pods que puede admitir el clúster.
Calcula el número de direcciones IP utilizables del intervalo principal (
N):none N = 2<sup>(32-S)</sup> - 4dondeSes 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:
M = 31 - ⌈log₂(32)⌉ = 26HM = 32 - 26 = 6HD = 32 - 17 = 15MN = 2(15 - 6) = 512MP = 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 de varios clústeres, 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-cidro la marca--services-secondary-range-name. - Si solo especificas un tamaño de intervalo mediante 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.
| Intervalo de IP secundario para servicios | Número máximo de servicios |
|---|---|
| /28 Intervalo de direcciones de servicio más pequeño posible cuando el método de asignación del intervalo secundario es gestionado por el usuario |
16 servicios |
| /27 Intervalo de direcciones de servicio más pequeño posible cuando el método de asignación de intervalos secundarios está gestionado por GKE |
32 Servicios |
| /26 | 64 servicios |
| /25 | 128 Services |
| /24 | 256 Services |
| /23 | 512 Services |
| /22 | 1024 Services |
| /21 | 2048 Services |
| /20 Tamaño predeterminado del intervalo de IPs secundario de la subred para los servicios cuando el método de asignación del intervalo secundario lo gestiona GKE |
4096 Servicios |
| /19 | 8192 servicios |
| /18 | 16.384 servicios |
| /17 | 32.768 servicios |
| /16 Intervalo de direcciones de servicio más grande posible |
65.536 servicios |
Compartir intervalos de direcciones IP entre clústeres de GKE
Puedes compartir el intervalo principal, el intervalo de direcciones IP secundarias de los pods y el intervalo de direcciones IP secundarias 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 tendrán 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, uno de los clústeres 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.
Compartir el intervalo de direcciones IP secundario de los pods
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.
Compartir el intervalo de direcciones IP secundario de los servicios
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 secundarias de subred común para los servicios, usa el mismo intervalo de direcciones IPv4 secundarias 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 únicos 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 pila dual 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 ni 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 doble pila 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 se admiten en los servicios
ClusterIP,NodePortyLoadBalancer. - 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:
Marca ipv6-access-type |
Asignación de direcciones IP | Intervalo de subredes |
|---|---|---|
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 |
De fd20::/20 (que es un subconjunto del intervalo general de ULA: fc00::/7).
|
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 a cada subred como intervalo principal.
- Un intervalo por nodo /96 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:
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 tipo
ClusterIP
o
NodePort.
Los nuevos clústeres de GKE que ejecutan la versión 1.29 o 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.