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 él mediante el emparejamiento entre redes de VPC.
Las direcciones IP de los pods se reservan en la red de VPC antes de que se creen los pods en el clúster. De esta forma, se evitan conflictos con otros recursos de la red VPC y puedes 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 de VPC nativa.
Puedes crear reglas de cortafuegos que se apliquen solo a los intervalos de direcciones IP de los 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 (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.
| 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 mediante intervalos distintos dentro de la subred especificada, tal como se indica a continuación.
Direcciones IP 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 IP de pods: el clúster utiliza el intervalo de direcciones IPv4 secundario de la subred para todas las direcciones IPv4 de los pods del clúster. Para disfrutar de una mayor flexibilidad, puedes usar intervalos de direcciones IPv4 secundarias de subred adicionales configurando CIDR de varios pods discontinuos.
Direcciones IP de servicio: el clúster utiliza un intervalo de direcciones IP secundario independiente para todas las direcciones IP de servicio (IP de clúster). Para obtener información sobre cómo habilitar varios clústeres para que compartan el mismo intervalo de IPv4 de los servicios, consulta Compartir intervalos de direcciones IP entre clústeres de GKE.
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.
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 desde el 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 IP internas
Las direcciones IP que uses para las subredes de tu clúster nativo de VPC deben proceder de un intervalo de subredes válido. Los intervalos válidos incluyen direcciones IP privadas (RFC 1918 y otras) y direcciones IP públicas de uso privado. Para obtener más información sobre los intervalos de subredes válidos, consulta los intervalos válidos y los intervalos restringidos en la documentación de VPC.
Consulta Usar intervalos de direcciones IP privadas que no sean RFC 1918 para obtener instrucciones sobre cómo habilitar el uso de estos intervalos.
Consulta Habilitar intervalos de direcciones IP públicas usadas de forma privada para obtener instrucciones sobre cómo usar estos intervalos.
Métodos de asignación de intervalos secundarios
Puedes asignar intervalos de direcciones IP de pods y de servicios (ClusterIP) a un clúster nativo de VPC. Estos intervalos de direcciones IP se pueden gestionar mediante GKE o por el usuario.
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 (creación, actualización, eliminación y lectura) continuas 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 posteriores y en los clústeres estándar de GKE que ejecutan la versión 1.29 o posteriores, 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. Ten en cuenta lo siguiente:
- Si quiere, puede especificar intervalos personalizados para los servicios mediante la marca
--services-ipv4-cidr. - Si solo especificas un tamaño de intervalo con el indicador
--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 la sección Optimizar la asignación de direcciones IP para ver el intervalo CIDR mínimo utilizable para diferentes valores del número máximo de pods 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 amplio.
- Vuelve a crear los grupos de nodos después de reducir el valor de
--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 y los intervalos de direcciones IP secundarias del clúster. Un administrador de un proyecto de servicio que cree un clúster debe tener al menos permisos a nivel de subred para la subred del proyecto del 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 antes de 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 el artículo 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 IP principales de la subred
Ten en cuenta las siguientes condiciones al planificar el intervalo de direcciones IP de tu nodo principal:
- 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.
- 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 IP 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 IP principal de la subred | Caso 1 | Caso 2 |
|---|---|---|
| /29 Tamaño mínimo del intervalo de 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 | 1020 nodos | 1019 nodos |
| /21 | 2044 nodos | 2043 nodos |
| /20 Tamaño predeterminado del intervalo de IP principal 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 IP principal 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 internos y a los nodos.
Fórmulas útiles
Puedes usar las siguientes fórmulas para:
Calcula el número máximo de nodos, N, que una máscara de red determinada puede admitir en clústeres que usan la subred predeterminada. Usa S para el tamaño de la máscara de red, cuyo intervalo válido es de
8a29, 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.
Intervalo de direcciones IP secundarias de subred para pods
Planifica cuidadosamente el intervalo de direcciones IP secundario de los pods.
En la siguiente tabla se muestra el número máximo de nodos y pods que puedes crear en todos los clústeres que usan la subred, dado el tamaño del intervalo de direcciones IP secundarias de la subred que usan los pods.
En esta tabla se presupone que el número máximo de pods por nodo es 110, que es la densidad de pods predeterminada.
| Intervalo de IP secundario de subred para pods | Número máximo de direcciones IP de Pod | Número máximo de nodos | Número máximo de pods |
|---|---|---|---|
| /24 El intervalo de IPs de pods más pequeño posible cuando el método de asignación del intervalo secundario es gestionado por el usuario |
256 direcciones | 1 nodo |
Autopilot: 32 pods Estándar: 110 pods |
| /23 Solo es posible cuando el método de asignación de intervalo secundario es gestionado por el usuario |
512 direcciones | 2 nodos |
Autopilot: 64 pods Estándar: 220 pods |
| /22 Solo es posible cuando el método de asignación de intervalo secundario es gestionado por el usuario |
1024 direcciones | 4 nodos |
Autopilot: 128 pods Estándar: 440 cápsulas |
| /21 Intervalo de IPs de pods más pequeño posible cuando el método de asignación del intervalo secundario lo gestiona GKE |
2048 direcciones | 8 nodos |
Autopilot: 256 pods Estándar: 880 pods |
| /20 | 4096 direcciones | 16 nodos |
Autopilot: 512 pods Estándar: 1760 pódcasts |
| /19 | 8192 direcciones | 32 nodos |
Autopilot: 1024 pods Estándar: 3520 pódcasts |
| /18 | 16.384 direcciones | 64 nodos |
Autopilot: 2048 pods Estándar: 7040 Pods |
| /17 | 32.768 direcciones | 128 nodos |
Autopilot: 4096 pods Estándar: 14.080 Pods |
| /16 | 65.536 direcciones | 256 nodos |
Autopilot: 8192 pods Estándar: 28.160 Pods |
| /15 | 131.072 direcciones | 512 nodos |
Autopilot: 16.384 pods Estándar: 56.320 pódcasts |
| /14 Tamaño predeterminado del intervalo de direcciones IP secundario de la subred para los pods cuando el método de asignación del intervalo secundario lo gestiona GKE |
262.144 direcciones | 1024 nodos |
Autopilot: 32.768 pods Estándar: 112.640 pods |
| /13 | 524.288 direcciones | 2048 nodos |
Autopilot: 65.536 pods Estándar: 225.280 pódcasts |
| /12 | 1.048.576 direcciones | 4096 nodos |
Autopilot: 131.072 pods Estándar: 450.560 pódcasts |
| /11 | 2.097.152 direcciones | 8192 nodos |
Autopilot: 262.144 pods Estándar: 901,120 pódcasts |
| /10 | 4.194.304 direcciones | 16.384 nodos |
Autopilot: 524.288 pods Estándar: 1.802.240 pods |
| /9 Intervalo de direcciones de pod más grande posible |
8.388.608 direcciones | 32.768 nodos |
Autopilot: 1.048.576 pods Estándar: 3.604.480 pods |
Si has cambiado el número máximo de pods por nodo, puedes usar las siguientes fórmulas para calcular el número máximo de nodos y pods que puede admitir el intervalo de direcciones IP secundarias de una subred para pods:
Calcula el tamaño de la máscara de subred del intervalo de pods de cada nodo, M.
M = 31 - ⌈log2(Q)⌉donde:- Q es el número de pods por nodo
⌈⌉es la función de techo (entero inferior), lo que significa que redondea al entero siguiente.- Por ejemplo, si Q es 110, entonces
M = 24
Calcula el número máximo de nodos, N, que puede admitir el intervalo de direcciones IP secundarias de la subred para pods:
N = 2(M - S)donde:- M es el tamaño de la máscara de red del intervalo de direcciones IP de alias de cada nodo para los pods, calculado en el primer paso.
- S es el tamaño de la máscara de subred del intervalo de direcciones IP secundarias de la subred.
- Por ejemplo, si M es 24 y S es 20, entonces
N = 16
Calcula el número máximo de pods, P, que puede admitir el intervalo de direcciones IP secundarias de la subred para pods:
P = N × Qdonde:- N es el número máximo de nodos, calculado en el paso anterior.
- Q es el número de pods por nodo
- Por ejemplo, si N es 16 y Q es 110, entonces
P = 1760
Puedes añadir más direcciones IP para los pods mediante CIDR de varios pods no contiguos.
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 ha 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 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. Ten en cuenta lo siguiente:
- 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 del intervalo secundario lo gestiona 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, uno de los clústeres 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 secundarias 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 a los nodos ampliando la subred principal o añadir nuevas direcciones IP a los pods mediante CIDR de varios pods no contiguos. Para obtener más información, consulta el artículo 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 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 muestra 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 pila dual 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 /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 pods de ese nodo. Con la red de doble pila, los pods obtienen sus direcciones IPv6 del intervalo de direcciones IP de pods general (de forma similar a los nodos) y no del intervalo secundario de pods reservado para direcciones IPv4.
El intervalo de direcciones IP de los pods se compone de intervalos que no se solapan del intervalo de IPs de los nodos principales. Por lo tanto, este intervalo de IPs de Pod 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 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 un despliegue.
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 direcciones IP de GKE.