En esta página, se proporciona una descripción general de los clústeres nativos de la VPC en Google Kubernetes Engine (GKE).
Esta página está dirigida a arquitectos de nube y especialistas en herramientas de redes que diseñan la red para su organización. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud, consulta Tareas y roles comunes de los usuarios de GKE Enterprise.
Descripción general
En GKE, los clústeres se pueden distinguir de acuerdo con la forma en la que enrutan el tráfico de un pod a otro.
Un clúster que usa rangos de direcciones IP de alias se denomina clúster nativo de la VPC.
Un clúster que usa rutas estáticas personalizadas en una red de VPC se denomina clúster basado en rutas.
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 responsable de definir, implementar y mantener la arquitectura de red.
Beneficios de los clústeres nativos de la VPC
Los clústeres nativos de la VPC tienen varios beneficios:
Pod Las direcciones IP del Pod se pueden enrutar de forma nativa dentro de la red de VPC del clúster y otras redes de VPC conectadas mediante intercambio de tráfico de la red de VPC.
Las direcciones IP de un Pod se reservan en la red de VPC antes de que se creen los Pods en tu clúster. Esto evita conflictos con otros recursos de la red de VPC y te permite planificar mejor las asignaciones de direcciones IP.
Los rangos de direcciones IP de un Pod no dependen de rutas estáticas personalizadas. No consumen la cuota de rutas estáticas personalizadas y generadas por el sistema. En su lugar, las rutas de subred generadas automáticamente manejan el enrutamiento para los clústeres nativos de la VPC.
Puedes crear reglas de firewall que se apliquen solo a los rangos de direcciones IP de los Pods en lugar de cualquier dirección IP en los nodos del clúster.
En general, se puede acceder a los rangos de direcciones IP de los Pods y a los rangos de direcciones IP secundarios de las subredes desde redes locales conectadas con Cloud VPN o Cloud Interconnect mediante Cloud Routers.
Algunas funciones, como los grupos de extremos de red (NEG), solo funcionan con clústeres nativos de la VPC.
Modo de red de clúster predeterminado
Nativo de la VPC es el modo de red predeterminado para todos los clústeres en las versiones 1.21.0-gke.1500 y posteriores de GKE. En versiones anteriores, el modo de red de clúster predeterminado depende de cómo creas el clúster.
En la siguiente tabla, se muestra el modo de red de clúster predeterminado para las versiones de clústeres de GKE y los métodos de creación de clústeres.
| Versiones de GKE | Método de creación de clúster | Modo de red de clúster |
|---|---|---|
| Todas las versiones | La consola de Google Cloud | VPC nativa |
| 1.21.0-gke.1500 y posteriores | La API de Kubernetes Engine o Google Cloud CLI | VPC nativa |
También puedes crear un clúster basado en rutas si especificas la marca --no-enable-ip-alias cuando creas el clúster.
Rangos de direcciones IP para clústeres nativos de la VPC
Cuando creas un clúster nativo de la VPC, especificas una subred en una red de VPC. El clúster usa los siguientes rangos de direcciones IP de subred:
Asignación de direcciones IPv4
Los clústeres nativos de la VPC asignan direcciones IPv4 para nodos, Pods y servicios usando rangos distintos dentro de la subred especificada de la siguiente manera.
Direcciones IP de los nodos: El clúster utiliza el rango de direcciones IPv4 principal de la subred para asignar direcciones IP a todos los nodos.
Direcciones IP de Pod: El clúster utiliza el rango de direcciones IPv4 secundario dentro de la subred para todas las direcciones IPv4 de Pod dentro del clúster. Para obtener una mayor flexibilidad, puedes usar rangos de direcciones IPv4 secundarios adicionales de la subred si configuras un CIDR de varios Pods discontinuos.
Direcciones IP de los servicios: El clúster utiliza un rango de direcciones IP secundario independiente para todas las direcciones de los servicios (IP del clúster). Si deseas obtener información para permitir que varios clústeres compartan el mismo rango IPv4 de los servicios, consulta Comparte rangos de direcciones IP entre clústeres de GKE.
Asignación de direcciones IPv6 (redes de pila doble)
- Direcciones IPv6 de nodos y Pods: En los clústeres habilitados para las redes de pila doble, la dirección IPv6 del nodo y todas las direcciones IPv6 del Pod provienen del rango de direcciones IPv6
/96designado del nodo. La dirección IP del nodo es la primera/128(dirección IPv6 única) dentro de este rango. Para obtener más información, consulta Herramientas de redes de pila doble.
En la siguiente tabla, se proporciona un resumen de los rangos de direcciones IP para nodos, Pods y objetos Service:
| Rango | Explicación | Ejemplo |
|---|---|---|
| Nodos |
Las direcciones IP de nodo se asignan a partir del rango de direcciones IP principales de la subred asociada a tu clúster. La cantidad de nodos con los que es compatible un clúster está limitada por las direcciones IP del nodo y el tamaño del rango de direcciones IP secundario para Pods de la subred. Consulta los rangos de límite de nodo para obtener más información. |
Si planeas crear un clúster de 900 nodos, el rango de direcciones IP principal de la subred del clúster debe ser al menos un Para obtener más información, consulta las secciones Rango de direcciones IP principal de la subred y Rango de direcciones IP secundario de la subred para los pods. |
| Pods |
Las direcciones IP del pod se toman del rango de direcciones IP secundario de la subred del clúster para los pods. A menos que defina un número máximo de pods por nodo diferente, GKE asigna un rango de IP de alias de |
Para un clúster de 900 nodos compatible con hasta 110 pods por nodo, necesitas 900 × 256 = 230.400 direcciones IP para los pods. (Cada nodo tiene asignado un rango de IP de alias con un tamaño de máscara de red de /24). Este clúster requiere una subred con un rango de IP secundario para pods que tenga una máscara de subred no mayor que /14. Este rango de IP secundario proporciona 2(32-14) = 218 = 262,144 direcciones IP para los Pods. Consulta Rango de direcciones IP secundario de la subred para los pods si deseas obtener más información. |
| Servicios |
Las direcciones de servicio (IP del clúster) se toman del rango de direcciones IP secundario de la subred del clúster para los servicios. Debes asegurarte de que este rango sea lo suficientemente grande como para proporcionar direcciones a todos los servicios de Kubernetes que alojes en tu clúster. En los clústeres de GKE Autopilot que ejecutan la versión 1.27 y versiones posteriores, y en los clústeres de GKE Standard que ejecutan la versión 1.29 y versiones posteriores, GKE asigna direcciones IP para los servicios de GKE de un rango administrado por GKE: |
Para un clúster que ejecute hasta 3000 servicios, necesitarás 3000 direcciones IP del clúster. Necesitas un rango secundario de tamaño /20 o superior. Un rango de direcciones IP de /20 da como resultado 2(32-20) = 212 = 4096 direcciones IP. Consulta Rango de direcciones IP secundario de la subred para los servicios si deseas obtener más información. |
Direcciones IP internas
Las direcciones IP que usas para las subredes de tu clúster nativo de la VPC deben provenir de un rango de subred válido. En los rangos válidos, se incluyen direcciones IP privadas (RFC 1918 y otras) y direcciones IP públicas reutilizadas de forma privada. Consulta Rangos válidos y Rangos restringidos en la documentación de VPC para obtener más información sobre los rangos de subred válidos.
Consulta Usa rangos de direcciones IP privadas que no sean RFC 1918 para obtener instrucciones sobre cómo habilitar estos rangos.
Consulta Habilita rangos de direcciones IP públicas que se usan de forma privada para obtener instrucciones sobre cómo usar estos rangos.
Métodos de asignación del rango secundario
Puedes asignar rangos de direcciones IP de Pod y rangos de direcciones de servicio (ClusterIP) a un clúster nativo de la VPC. GKE puede administrar estos rangos de direcciones IP, o bien el usuario puede hacerlo.
Debes comprender los siguientes términos clave para entender los métodos de asignación de rango secundario.
Asignación: La asignación de rangos de direcciones IP hace referencia al proceso de asignar un rango de subred específico a un clúster nativo de la VPC. Esto establece un grupo de direcciones IP que los componentes pueden usar dentro del clúster, como Pods y servicios.
Administración: La administración del rango de direcciones IP se refiere a las operaciones de CRUD en curso (creación, actualización, eliminación y lectura) a nivel de clúster, grupo de nodos o Pod, relacionadas con la asignación de rangos de subredes y recursos dentro de tu clúster nativo de la VPC.
Rangos secundarios administrados por GKE (predeterminado)
En el caso de los clústeres de GKE Autopilot que ejecutan la versión 1.27 y versiones posteriores, y los clústeres de GKE Standard que ejecutan las versiones 1.29 y versiones posteriores, GKE asigna direcciones IP para los servicios de un rango administrado por GKE de forma predeterminada: 34.118.224.0/20. Esto elimina la necesidad de especificar tu propio rango de direcciones IP para los servicios. Se aplican las siguientes consideraciones:
- De manera opcional, puedes especificar rangos personalizados para los servicios con la marca
--services-ipv4-cidr. - Si solo especificas un tamaño de rango con la marca
--services-ipv4-cidr(por ejemplo,/22), GKE seguirá usando el rango administrado por GKE para obtener el subrango de direcciones. - GKE no crea un rango de direcciones IP secundario independiente para los objetos Service cuando se usa el rango administrado por GKE.
Administrada por el usuario
Para tener control total sobre la asignación de direcciones IP, puedes administrar manualmente las subredes de tu clúster nativo de la VPC.
Puedes crear los rangos de direcciones IP secundarios de la subred y, luego, crear un clúster que los use. Durante la creación del clúster, especifica el nombre del rango de subred para los Pods y los servicios. Si creas los rangos secundarios de forma manual, debes administrarlos tú mismo.
El rango de direcciones IP más pequeño que puedes crear sin usar CIDR de varios Pods discontinuos es /28, pero ese rango solo te permitiría crear 1 nodo con un máximo de 8 Pods. Debes usar un rango que sea lo suficientemente grande para la cantidad máxima de nodos que necesitas.
El rango mínimo utilizado también depende de la cantidad máxima de Pods por nodo.
Consulta la tabla en Optimiza la asignación de direcciones IP a fin de obtener el rango mínimo de CIDR que se puede usar para diferentes valores de cantidad máxima de Pods por nodo.
Si agotas el rango de direcciones IP para los Pods, debes realizar una de las siguientes acciones:
- Crea un clúster nuevo con un rango de direcciones de Pods más grande
- Vuelve a crear tus grupos de nodos después de disminuir el
--max-pods-per-nodepara los grupos de nodos. - Expande el rango de direcciones IP del Pod secundario mediante CIDR de varios Pods discontinuos.
Diferencias con los clústeres basados en rutas
El esquema de asignación para direcciones (ClusterIP) de Pods y objetos Service es diferente del esquema que usa un clúster basado en rutas. En lugar de especificar un solo CIDR para Pods y objetos Service juntos, debes elegir o crear dos rangos de direcciones IP secundarios en la subred del clúster: uno para Pods y otro para objetos Service.
Consideraciones de VPC compartida
Cuando se crea un clúster nativo de la VPC en un entorno de VPC compartida, el propietario o el editor del proyecto, o un principal de Identity and Access Management (IAM) con la función de administrador de red en el proyecto host de la VPC compartida debe crear el subred y los rangos de direcciones IP secundarios de forma manual. Un administrador del proyecto de servicio que crea un clúster debe tener al menos permisos a nivel de subred en la subred deseada del proyecto host de la red de VPC compartida.
En un entorno de VPC compartida, GKE no puede administrar los rangos de direcciones IP secundarios. Un administrador de red del proyecto host de la VPC compartida debe crear la subred y los rangos de direcciones IP secundarios antes de que puedas crear el clúster. Para ver un ejemplo sobre cómo configurar un clúster nativo de la VPC en una red de VPC compartida, consulta Configura clústeres con VPC compartida.
Planificación del rango de direcciones IP
Usa la información de las siguientes secciones para calcular los tamaños de los rangos de direcciones IP principales y secundarios de la subred que usa tu clúster.
Rango de direcciones IP principal de la subred
Ten en cuenta las siguientes condiciones cuando planifiques el rango de direcciones IP de tu nodo principal:
- Cada subred debe tener un rango de direcciones IP principal. Este es el rango de direcciones IP que GKE usa para asignar direcciones IP a los balanceadores de cargas internos y a los nodos.
- No puedes reducir ni cambiar el rango de direcciones IP principal de una subred después de crearla.
- Google Cloud se reserva las dos primeras y las dos últimas direcciones IP de un rango de direcciones IP principal.
- De forma predeterminada, los clústeres con Private Service Connect usan el rango de subred principal para aprovisionar la dirección IP interna asignada al extremo del plano de control. Sin embargo, puedes anular este aprovisionamiento de direcciones IP con la marca
private-endpoint-subnetwork. Para obtener más información, consulta Crea un clúster y selecciona el rango de direcciones IP del plano de control.
En la siguiente tabla, se muestra la cantidad máxima de nodos que puedes crear según el tamaño del rango de direcciones IP principal de la subred y la configuración del clúster:
- Situación 1: Cantidad máxima de nodos en un clúster que usa la subred predeterminada.
- Situación 2: Cantidad máxima de nodos en un clúster de Private Service Connect que no usa la marca
private-endpoint-subnetwork
| Rango de IP principal de la subred | Situación 1 | Situación 2 |
|---|---|---|
| /29 Tamaño mínimo del rango 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 | 1,020 nodos | 1019 nodos |
| /21 | 2,044 nodos | 2043 nodos |
| /20 Tamaño predeterminado del rango de IP principal de una subred en redes de modo automático |
4,092 nodos | 4091 nodos |
| /19 | 8,188 nodos | 8187 nodos |
| /8 Tamaño máximo del rango de IP principal de una subred |
16,777,212 nodos | 16,777,211 nodos |
Expande el rango de direcciones IP principal
Si te quedas sin direcciones IP en el rango de direcciones IP principal, puedes expandir el rango de direcciones IP principal en cualquier momento, incluso cuando los recursos de Google Cloud, como los balanceadores de cargas y los grupos de extremos de red, usan la subred.
Antes de expandir el rango de direcciones IP principal, considera lo siguiente:
- No debe haber rangos de direcciones IP superpuestos en la subred.
- GKE usa el rango de direcciones IP principal a fin de asignar direcciones IP para balanceadores de cargas internos y nodos.
Fórmulas útiles
Puedes usar estas fórmulas para lo siguiente:
Calcula la cantidad máxima de nodos, N, que puede admitir una máscara de red determinada en los clústeres que usan la subred predeterminada. Usa S para el tamaño de la máscara de red, cuyo rango válido se encuentra entre
8y29, inclusive.N = 2(32 – S) – 4
Calcula el tamaño de la máscara de red, S, que se requiere para admitir un máximo de N nodos:
S = 32 – ⌈log2(N + 4)⌉
⌈⌉es la función techo (mínimo entero), es decir, redondea al siguiente número entero. El rango válido para el tamaño de la máscara de red, S, se encuentra entre8y29, inclusive.
En los clústeres de Private Service Connect que no usan la marca private-endpoint-subnetwork, puedes usar las fórmulas anteriores, pero debes reducir el valor de N en 1.
Rango de direcciones IP secundario de la subred para Pods
Planifica con cuidado el rango de direcciones IP secundario para Pods.
En la siguiente tabla, se muestra la cantidad máxima de nodos y pods que puedes crear en todos los clústeres que usan la subred, dado el tamaño del rango de direcciones IP secundario de la subred que usan los pods.
En esta tabla, se supone que el número máximo de Pods por nodo es 110, que es la densidad predeterminada de Pods.
| Rango de IP secundario de la subred para pods | Cantidad máx. de direcciones IP del pod | Cant. máx. de nodos | Cantidad máx. de pods |
|---|---|---|---|
| /24 El menor rango de IP de pod posible cuando el método de asignación del rango secundario es administrado por el usuario |
256 direcciones | 1 nodo |
Autopilot: 32 Pods Estándar: 110 Pods |
| /23 Solo es posible cuando el método de asignación del rango secundario es administrado por el usuario |
512 direcciones | 2 nodos |
Autopilot: 64 Pods Estándar: 220 Pods |
| /22 Solo es posible cuando el método de asignación del rango secundario es administrado por el usuario |
1,024 direcciones | 4 nodos |
Autopilot: 128 Pods Estándar: 440 Pods |
| /21 El menor rango de IP de pod posible cuando el método de asignación del rango secundario es administrado por GKE |
2,048 direcciones | 8 nodos |
Autopilot: 256 Pods Estándar: 880 Pods |
| /20 | 4,096 direcciones | 16 nodos |
Autopilot: 512 Pods Estándar: 1,760 Pods |
| /19 | 8,192 direcciones | 32 nodos |
Autopilot: 1,024 Pods Estándar: 3,520 Pods |
| /18 | 16,384 direcciones | 64 nodos |
Autopilot: 2,048 Pods Estándar: 7,040 Pods |
| /17 | 32,768 direcciones | 128 nodos |
Autopilot: 4,096 Pods Estándar: 14,080 Pods |
| /16 | 65,536 direcciones | 256 nodos |
Autopilot: 8,192 Pods Estándar: 28,160 Pods |
| /15 | 131,072 direcciones | 512 nodos |
Autopilot: 16,384 Pods Estándar: 56,320 Pods |
| /14 Tamaño predeterminado del rango de direcciones IP secundario de la subred para los pods cuando el método de asignación del rango secundario es administrado por GKE |
262,144 direcciones | 1,024 nodos |
Autopilot: 32,768 Pods Estándar: 112,640 Pods |
| /13 | 524,288 direcciones | 2,048 nodos |
Autopilot: 65,536 Pods Estándar: 225,280 Pods |
| /12 | 1,048,576 direcciones | 4,096 nodos |
Autopilot: 131,072 Pods Estándar: 450,560 Pods |
| /11 | 2,097,152 direcciones | 8,192 nodos |
Autopilot: 262,144 Pods Estándar: 901,120 Pods |
| /10 | 4,194,304 direcciones | 16,384 nodos |
Autopilot: 524,288 Pods Estándar: 1,802,240 Pods |
| /9 El rango más grande posible de direcciones de pods |
8,388,608 direcciones | 32,768 nodos |
Autopilot: 1,048,576 Pods Estándar: 3,604,480 Pods |
Si cambiaste la cantidad máxima de Pods por nodo, puedes usar las siguientes fórmulas para calcular la cantidad máxima de nodos y Pods que puede admitir un rango de direcciones IP secundario de una subred para Pods:
Calcula el tamaño de la máscara de red del rango de Pods de cada nodo, M.
M = 31 - ⌈log2(Q)⌉, en el que se usan los siguientes valores:- Q es la cantidad de Pods por nodo.
⌈⌉es la función techo (mínimo entero), es decir, redondea al siguiente número entero.- Por ejemplo, si Q es 110, entonces
M = 24
Calcula la cantidad máxima de nodos, N, que el rango de direcciones IP secundario de la subred para los Pods puede admitir:
N = 2(M - S), en el que se usan los siguientes valores:- M es el tamaño de la máscara de red del rango de direcciones IP de alias de cada nodo para los Pods, que se calculó en el primer paso.
- S es el tamaño de la máscara de subred del rango de direcciones IP secundario de la subred.
- Por ejemplo, si M es 24 y S es 20, entonces
N = 16
Calcula la cantidad máxima de Pods, P, que el rango de direcciones IP secundario de la subred para los Pods puede admitir.
P = N × Q, en el que se usan los siguientes valores:- N es la cantidad máxima de nodos, que se calculó en el paso anterior.
- Q es la cantidad de Pods por nodo.
- Por ejemplo, si N es 16 y Q es 110, entonces
P = 1760
Puedes agregar más direcciones IP para los Pods mediante CIDR de varios pods discontinuos.
Rango de direcciones IP secundario de la subred para servicios
Planifica con cuidado el rango de direcciones IP secundario para objetos Service. Debido a que este también es un rango de direcciones IP secundario de la subred, este rango no se puede cambiar una vez que se crea el clúster.
Si usas Service de varios clústeres, el objeto ServiceImport usa direcciones IP del rango de direcciones IP secundario para servicios.
En los clústeres de Autopilot de GKE que ejecutan la versión 1.27 y versiones posteriores, y en los clústeres de GKE Standard que ejecutan las versiones 1.29 y posteriores, GKE asigna direcciones IP para los servicios de un rango administrado por GKE de forma predeterminada: 34.118.224.0/20. Esto elimina la necesidad de especificar tu propio rango de direcciones IP para los servicios. Se aplican las siguientes consideraciones:
- De manera opcional, puedes especificar rangos personalizados para los servicios con la marca
--services-ipv4-cidro la marca--services-secondary-range-name. - Si solo especificas un tamaño de rango con la marca
--services-ipv4-cidr(por ejemplo,/22), GKE seguirá usando el rango administrado por GKE para obtener el subrango de direcciones. - GKE no crea un rango de direcciones IP secundario independiente para los objetos Service cuando se usa el rango administrado por Google. El rango administrado por GKE no usa la cuota del rango de direcciones IP secundario de tu subred.
La siguiente tabla muestra la cantidad máxima de servicios que puedes crear en un solo clúster con la subred, dado el tamaño del rango de direcciones IP secundario de la subred para servicios.
| Rango de IP secundario para servicios | Cantidad máxima de servicios |
|---|---|
| /28 El menor rango de direcciones del servicio posible cuando el método de asignación del rango secundario es administrado por el usuario |
16 servicios |
| /27 El menor rango de direcciones del servicio posible cuando el método de asignación del rango secundario es administrado por GKE |
32 servicios |
| /26 | 64 servicios |
| /25 | 128 servicios |
| /24 | 256 servicios |
| /23 | 512 servicios |
| /22 | 1,024 servicios |
| /21 | 2,048 servicios |
| /20 Tamaño predeterminado del rango de IP secundario de la subred para servicios cuando el método de asignación del rango secundario es administrado por GKE |
4,096 servicios |
| /19 | 8,192 servicios |
| /18 | 16,384 servicios |
| /17 | 32,768 servicios |
| /16 El mayor rango de direcciones del servicio posible |
65,536 servicios |
Comparte rangos de direcciones IP en clústeres de GKE
Puedes compartir el rango de direcciones IP principal y secundario para los Pods y el rango de direcciones IP secundario para objetos Service entre clústeres en la misma subred.
Este comportamiento está disponible para los clústeres de Standard y Autopilot.
Se recomienda compartir rangos de direcciones IP si tienes un equipo centralizado que administra la infraestructura para los clústeres. Puedes reducir la sobrecarga si creas tres rangos para Pods, Services y nodos, y los vuelves a usar o los compartes, en especial en un modelo de VPC compartida. También puede facilitar la administración de direcciones IP a los administradores de red, ya que no es necesario que creen subredes específicas para cada clúster.
Comparte el rango de direcciones IP principal para los nodos
Si creas más de un clúster en la subred, el rango de direcciones IP principal para los nodos se comparte de forma predeterminada.
Compartir la dirección IP principal para los nodos tiene las siguientes limitaciones:
- Si compartes el rango de direcciones IP principal para nodos con dos o más clústeres nativos de la VPC, un clúster puede usar una gran parte del rango de direcciones IP compartidas, lo que deja los otros clústeres sin suficientes direcciones IP para expandir.
Comparte el rango de direcciones IP secundario para Pods
Cuando compartes el rango secundario para los Pods, cada Pod obtiene una dirección IP única.
Compartir el rango de direcciones IP secundario para Pods tiene las siguientes limitaciones:
Si compartes el rango de direcciones IP secundario para Pods con dos o más clústeres nativos de la VPC, un clúster puede usar una gran parte del rango de direcciones IP compartidas, lo que deja los otros clústeres sin suficientes direcciones IP para expandir.
Entre los diferentes tipos de rangos secundarios, tanto el rango Administrado por GKE y los Rangos de Pods adicionales no pueden compartirse entre clústeres.
Para compartir un rango de direcciones IP secundario, pásalo en la línea de comandos con
--cluster-secondary-range, no puedes usar un rango secundario compartido cuando creas clústeres en la IU.
Comparte el rango de direcciones IP secundario para objetos Service
Dos o más clústeres pueden usar simultáneamente el mismo rango de direcciones IPv4 secundario de la subred para servicios cuando usas rangos secundarios administrados por el usuario.
Si deseas configurar dos o más clústeres a fin de compartir un rango de direcciones IPv4 secundario de subred común para objetos Service, usa el mismo rango de direcciones IPv4 secundario de la subred cuando crees cada clúster. No se requiere una marca de configuración independiente para compartir un rango de direcciones IPv4 común para Services.
Cuando se comparte un rango de direcciones IPv4 común para servicios, cada clúster usa el rango de direcciones IPv4 secundario de la subred completo para los Services de forma interna. Las direcciones IP para los Services se programan dentro del nodo de cada clúster, pero no se asignan a la interfaz de red de ningún nodo. Las direcciones IP de los servicios no se pueden enrutar dentro de la red de VPC del clúster. Solo los Pods cliente pueden usar las direcciones IP de Service dentro del mismo clúster que el Service.
Cuando un Pod envía un paquete a una dirección IP de Service, la configuración de iptables o eBPF del nodo realiza la traducción de direcciones de red (NAT) de destino y cambia la dirección IP de destino del paquete desde la IP del Service. dirección a una IP de Pod de entrega. El paquete se enruta en función de la dirección IP del Pod de destino.
Compartir el rango de direcciones IP secundario para objetos Service proporciona los siguientes beneficios:
- Reduce la cantidad de rangos de direcciones IP secundarios únicos para los servicios creados en una subred
- Usa menos direcciones IP
Compartir el rango de direcciones IP secundario para objetos Service tiene las siguientes limitaciones:
- El uso compartido del rango de direcciones IP secundario para objetos Service no es compatible con el permiso de VPC de Cloud DNS para GKE.
No puedes compartir rangos que coincidan con la siguiente regex:
^gke-.*-services-[abcdef0-9]{8}Para compartir un rango de direcciones IP secundario para los servicios, pásalo en la línea de comandos con
--cluster-secondary-range, no puedes usar un rango secundario compartido para los servicios cuando creas clústeres en la IU.
Rangos de límite de nodo
La cantidad máxima de pods y servicios para un clúster de GKE determinado está limitada por el tamaño de los rangos secundarios del clúster. La cantidad máxima de nodos en el clúster está limitada por el tamaño del rango de direcciones IP principal de la subred del clúster y del rango de direcciones del pod del clúster.
El siguiente mensaje de error indica que se agotó el rango de direcciones IP principal de la subred o el rango de direcciones IP del Pod del clúster (el rango de direcciones IP secundario de la subred):
Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted
Puedes agregar más direcciones IP para los nodos si expandes la subred principal o agregas direcciones IP nuevas para los pods con CIDR de varios pods discontinuos. Si deseas obtener más información, consulta No hay suficiente espacio de direcciones IP gratuito para Pods.
Herramientas de redes de pila doble IPv4/IPv6
Con las herramientas de redes de pila doble IPv4/IPv6, puedes definir cómo GKE asigna direcciones IP (ipFamilies) a los siguientes objetos:
- Para los Pods y los nodos, GKE asigna direcciones IPv4 e IPv6.
- Para los Services, GKE asigna direcciones de pila única (solo IPv4 o solo IPv6) o de pila doble.
En la versión 1.24 de GKE o en versiones posteriores, puedes habilitar las redes de pila doble para los clústeres de GKE nuevos en redes de VPC independientes y compartidas. También puedes aplicar políticas de red con las redes de pila doble habilitadas.
Beneficios
Las herramientas de redes de pila doble proporcionan los siguientes beneficios:
- Habilitan la comunicación IPv6 de extremo a extremo.
- Habilitan un mejor rendimiento en comparación con la traducción de direcciones de red (NAT) o los túneles IP. Esto se logra porque no hay traducción de IPv6 a IPv4.
Disponibilidad
Las herramientas de redes de pila doble con GKE tienen las siguientes restricciones:
- Las herramientas de redes de pila doble solo están disponibles para los clústeres nativos de VPC con GKE Dataplane V2 habilitado.
- Las redes de doble pila solo son compatibles con subredes en VPC de modo personalizado. Para obtener más información, consulta Tipos de redes de VPC de Google Cloud.
- No se admiten direcciones IPv6 de pila única para Pods o nodos.
- Los clústeres de pila doble consumen memoria adicional por nodo para admitir IPv4 e IPv6 en comparación con los clústeres solo IPv4. Ten en cuenta esta característica cuando configures clústeres a gran escala.
- Los clústeres de pila doble no son compatibles con el Acceso privado a Google a través de IPv6.
- Las versiones de GKE 1.26.0-gke.2200 y posteriores admiten IPv6 (registros AAAA) con Cloud DNS para las operaciones internas del clúster y las consultas de DNS externo.
- Los Services de pila doble son compatibles con los Services
ClusterIP,NodePortyLoadBalancer.
- IPv6 no es compatible con nodos de Windows.
Ten en cuenta las restricciones anteriores antes de crear un clúster con herramientas de redes de pila doble. Para obtener más información, consulta cómo crear un clúster nativo de la VPC con herramientas de redes de pila doble.
Asignación de dirección IPv6 pública y privada
En la siguiente tabla, se proporciona un resumen de los clústeres IPv6 públicos y privados con el comportamiento y la configuración de red de pila doble:
Marca ipv6-access-type |
Asignación de una dirección IP | Rango de subred |
|---|---|---|
EXTERNAL |
GKE asigna direcciones IPv6 externas que se pueden enrutar a Internet. |
De 2600:1900/28
|
INTERNAL |
GKE asigna direcciones IPv6 internas que no se pueden enrutar a Internet. Los clústeres con el tipo de acceso IPv6 |
Desde fd20::/20 (que es un subconjunto del rango general de ULA: fc00::/7).
|
Si deseas obtener más información, consulta cómo usar una red de pila doble para un clúster nativo de la VPC.
Arquitectura
Un clúster con herramientas de redes de pila doble IPv4/IPv6 tiene los siguientes rangos asignados:
- Un rango /64 a cada subred como un rango principal.
- Un rango /96 por nodo del rango principal para usar como rango de direcciones IP del nodo principal.
Un rango /112 por nodo del rango de direcciones IP del nodo principal para usar como rango de direcciones IP del Pod para ese nodo. Con las redes de doble pila, los Pods obtienen sus direcciones IPv6 del rango de direcciones IP general del Pod (similar a los nodos) y no del rango secundario para Pods reservado para direcciones IPv4.
El rango de direcciones IP general del Pod consta de rangos que no se superponen del rango de IP del nodo principal. Por lo tanto, este rango de IP del Pod no es contiguo.
Un rango /112 para usar con los Services. Este rango proviene de un rango de direcciones /64 del rango de direcciones privadas de Google que se reservó para el rango de direcciones IP de los servicios secundarios de GKE.
En el siguiente diagrama, se muestra cómo Google Cloud y GKE asignan direcciones IPv6:
En el diagrama, el rango principal de la subred de VPC es 2600:1900:0:1::/64 y el rango reservado para los Services de GKE es 2600:2D00:0:4::0:0/64. Cada nodo del clúster tiene un rango /96 para el rango de direcciones IP del nodo principal y un rango /112 para el rango de direcciones IP del Pod. El clúster también tiene un rango de direcciones IP de servicios secundarios /112.
Servicios
Puedes crear un objeto Service de pila doble IPv4/IPv6 de tipo ClusterIP o NodePort.
Los clústeres de GKE nuevos que ejecutan la versión 1.29 o una posterior admiten los Services de pila doble de tipo LoadBalancer.
Puedes exponer un objeto Deployment con un objeto Service de tipo ClusterIP, NodePort o LoadBalancer. Para cada uno de estos tipos de servicios, puedes definir los campos ipFamilies y ipFamilyPolicy como IPv4, IPv6 o un objeto Service de pila doble. Para obtener más información, consulta un ejemplo de configuración de un Deployment.
¿Qué sigue?
- Obtén más información sobre el intercambio de tráfico entre redes de VPC.
- Obtén información para crear un clúster nativo de la VPC.