El Trusted Cloud by S3NS balanceador de cargas de red del proxy interno es un balanceador de cargas basado en proxy con la tecnología del software de proxy Envoy de código abierto y la pila de virtualización de red de Andromeda.
El balanceador de cargas de red del proxy interno es un balanceador de cargas de capa 4 que te permite ejecutar y escalar el tráfico de servicio TCP detrás de una dirección IP interna regional a la que solo pueden acceder los clientes de la misma red de VPC o los clientes conectados a tu red de VPC. El balanceador de cargas primero finaliza la conexión TCP entre el cliente y el balanceador de cargas en un proxy de Envoy. El proxy abre una segunda conexión de TCP a los backends alojados en Trusted Cloud by S3NS, en entornos locales o en otros entornos de nube. Para obtener más casos de uso, consulta Descripción general del balanceador de cargas de red del proxy.
Modos de operación
Este balanceador de cargas está disponible en el modo regional y, a partir de ahora, se denominará balanceador de cargas de red de proxy interno regional. El balanceador de cargas se implementa como un servicio administrado basado en el proxy de Envoy con código abierto. En el modo regional, todos los clientes y backends se encuentran en una región especificada. Usa este balanceador de cargas si deseas entregar contenido desde una sola ubicación geográfica (por ejemplo, para cumplir con las reglamentaciones de cumplimiento).
Arquitectura
En el siguiente diagrama, se muestran los recursos de Trusted Cloud necesarios para los balanceadores de cargas de red de proxy internos.
Regional
En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de red de proxy interno regional en el nivel Premium.
Subred de solo proxy
En el diagrama anterior, la subred de solo proxy proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses un balanceador de cargas de red de proxy interno basado en Envoy.
En la siguiente tabla, se describen los requisitos de subredes de solo proxy para los balanceadores de cargas de red de proxy internos:
| Modo de balanceador de cargas | Valor de la marca --purpose de la subred de solo proxy |
|---|---|
| Balanceador de cargas de red del proxy interno regional |
Los balanceadores de cargas entre regiones y regionales no pueden compartir las mismas subredes Todos los balanceadores de cargas regionales basados en Envoy en una región y una red de VPC comparten la misma subred de solo proxy. |
Además:
- Las subredes de solo proxy se usan solo para los proxies de Envoy, no para tus backends.
- Las instancias de máquina virtual (VM) de backend o los extremos de todos los balanceadores de cargas de red de proxy interno en una región y una red de VPC reciben conexiones desde la subred de solo proxy.
- La dirección IP de un balanceador de cargas de red de proxy interno no se encuentra en la subred de solo proxy. La dirección IP del balanceador de cargas se define según su regla de reenvío administrada interna.
Reglas de reenvío y direcciones IP
Las reglas de reenvío enrutan el tráfico por dirección IP, puerto y protocolo a una configuración de balanceo de cargas que consiste de un proxy de destino y un servicio de backend.
Especificación de la dirección IP Cada regla de reenvío proporciona una sola dirección IP regional que puedes usar en los registros DNS de tu aplicación. Puedes reservar una dirección IP estática para usarla o permitir que Cloud Load Balancing te asigne una. Te recomendamos reservar una dirección IP estática; de lo contrario, deberás actualizar tu registro DNS con la dirección IP efímera recién asignada cada vez que borres una regla de reenvío y crees una nueva.
Los clientes usan la dirección IP y el puerto para conectarse a los proxies de Envoy del balanceador de cargas; la dirección IP de la regla de reenvío es la dirección IP del balanceador de cargas (a veces denominada dirección IP virtual o VIP). Los clientes que se conectan a un balanceador de cargas deben usar TCP. Para obtener una lista completa de los protocolos compatibles, consulta Comparación de funciones del balanceador de cargas.
La dirección IP interna asociada con la regla de reenvío puede provenir de una subred en la misma red y región que los backends.
Especificación de puerto Cada regla de reenvío que usas en un balanceador de cargas de red de proxy interno puede hacer referencia a un puerto único del 1 al 65535. Para admitir varios puertos, debes configurar varias reglas de reenvío.
En la siguiente tabla, se muestran los requisitos de las reglas de reenvío para los balanceadores de cargas de red de proxy internos:
| Modo de balanceador de cargas | Regla de reenvío, dirección IP y subred de solo proxy --purpose |
Enrutamiento del cliente al frontend del balanceador de cargas |
|---|---|---|
| Balanceador de cargas de red del proxy interno regional |
Esquema de balanceo de cargas:
Subred de solo proxy
Dirección IP
|
Los backends también deben estar en la misma región que el balanceador de cargas. |
Reglas de reenvío y redes de VPC
En esta sección, se describe cómo las reglas de reenvío que usan los balanceadores de cargas de aplicaciones externos se asocian con las redes de VPC.
| Modo de balanceador de cargas | Asociación de redes de VPC |
|---|---|
| Balanceador de cargas de red del proxy interno entre regiones Balanceador de cargas de red del proxy interno regional |
Las direcciones IPv4 internas regionales siempre existen dentro de las redes de VPC. Cuando crees la regla de reenvío, deberás especificar la subred de la que se toma la dirección IP interna. Esta subred debe estar en la misma región y red de VPC que una subred de solo proxy. de crear. Por lo tanto, hay una asociación de red implícita. |
Proxies de destino
El balanceador de cargas de red de proxy interno regional finaliza las conexiones TCP del cliente y crea conexiones nuevas con los backends. De forma predeterminada, la dirección IP de cliente original y la información del puerto no se conservan. Puedes conservar esta información mediante el protocolo PROXY. El proxy de destino enruta las solicitudes entrantes directamente al servicio de backend del balanceador de cargas.
En la siguiente tabla, se muestran las APIs de proxy de destino que requieren los balanceadores de cargas de red de proxy internos:
| Modo de balanceador de cargas | Proxy de destino |
|---|---|
| Balanceador de cargas de red del proxy interno regional | Regional regionTargetTcpProxies |
Servicio de backend
Un servicio de backend dirige el tráfico entrante a uno o más backends conectados. Un backend es un grupo de instancias o un grupo de extremos de red. El backend contiene información del modo de balanceo para definir la integridad en función de las conexiones (o, solo en el caso de los backends de grupos de instancias, la utilización).
Cada balanceador de cargas de red de proxy interno regional tiene un solo recurso de servicio de backend.
En la siguiente tabla, se especifican los requisitos de los servicios de backend para los balanceadores de cargas de red de proxy internos:
| Modo de balanceador de cargas | Tipo de servicio de backend |
|---|---|
| Balanceador de cargas de red del proxy interno regional | Regional regionBackendServices |
Backends compatibles
El servicio de backend admite los siguientes tipos de backends:
| Modo de balanceador de cargas | Backends compatibles en un servicio de backend | ||||||
|---|---|---|---|---|---|---|---|
| Grupos de instancias | NEG zonales | NEG de Internet | NEG sin servidores | NEG híbridos | GKE | ||
| Balanceador de cargas de red del proxy interno regional |
Extremos de tipo GCE_VM_IP_PORT |
Solo NEG regionales | |||||
Todos los backends deben ser del mismo tipo (grupos de instancias o NEG). Puedes usar simultáneamente diferentes tipos de backends de grupos de instancias o diferentes tipos de backends de NEG, pero no puedes usar backends de grupos de instancias y de NEG juntos en el mismo servicio de backend.
Puedes mezclar NEG zonales y NEG híbridos en el mismo servicio de backend.
Para minimizar las interrupciones del servicio a tus usuarios, habilita el vaciado de conexiones en los servicios de backend. Estas interrupciones pueden ocurrir cuando un backend se finaliza, se quita de forma manual o lo quita un escalador automático. Si quieres obtener más información sobre el uso del vaciado de conexiones para minimizar las interrupciones del servicio, consulta Habilita el vaciado de conexiones.
Backends y redes de VPC
Para los grupos de instancias, los NEGs zonales y los NEG de conectividad híbrida, todos los backends deben estar ubicados en el mismo proyecto y región que el servicio de backend. Sin embargo, un balanceador de cargas puede hacer referencia a un backend que usa una red de VPC diferente en el mismo proyecto que el servicio de backend. La conectividad entre la red de VPC del balanceador de cargas y la red de VPC del backend se puede configurar mediante el intercambio de tráfico entre redes de VPC, túneles de Cloud VPN o adjuntos de VLAN de Cloud Interconnect.
Definición de la red de backend
- En el caso de los NEGs zonales y los híbridos, debes especificar de forma explícita la red de VPC cuando creas el NEG.
- En los grupos de instancias administrados, la red de VPC se define en la plantilla de instancias.
- En los grupos de instancias no administrados, la red de VPC del grupo de instancias se configura para que coincida con la red de VPC de la interfaz
nic0de la primera VM que se agrega al grupo de instancias.
Requisitos de red del backend
La red de tu backend debe satisfacer uno de los siguientes requisitos de red:
La red de VPC del backend debe coincidir exactamente con la red de VPC de la regla de reenvío.
La red de VPC del backend debe estar conectada a la red de VPC de la regla de reenvío mediante el intercambio de tráfico entre redes de VPC. Debes configurar intercambios de rutas de subred para permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos de backend.
Para todos los demás tipos de backends, todos deben estar ubicados en la misma red de VPC y región.
Interfaces de red y backends
Si usas backends de grupos de instancias, los paquetes siempre se entregan a nic0. Si quieres enviar paquetes a interfaces que no son de nic0 (ya sean vNICs o interfaces de red dinámicas), usa backends de NEG en su lugar.
Si usas backends de NEG zonales, los paquetes se envían a cualquier interfaz de red que represente el extremo en el NEG. Los extremos del NEG deben estar en la misma red de VPC que la red de VPC definida explícitamente en el NEG.
Protocolo para comunicarse con los backends
Cuando configuras un servicio de backend para un balanceador de cargas de red de proxy interno regional, debes establecer el protocolo que usa el servicio de backend a fin de comunicarse con estos. El balanceador de cargas solo usa el protocolo que especifiques y no intenta negociar una conexión con el otro protocolo. Los balanceadores de cargas de red de proxy internos solo admiten TCP para comunicarse con los backends.
Verificación de estado
Cada servicio de backend especifica una verificación de estado que supervisa de manera periódica la preparación de los backends para recibir una conexión del balanceador de cargas. Esto reduce el riesgo de que las solicitudes se envíen a backends que no pueden procesar la solicitud. Las verificaciones de estado no verifican si la aplicación en sí funciona.
Protocolo de verificación de estado
Aunque no es obligatorio y no siempre es posible, se recomienda usar una verificación de estado cuyo protocolo coincida con el protocolo del servicio de backend. Por ejemplo, una verificación de estado de TCP comprueba de forma más precisa la conectividad de TCP con los backends. Para obtener la lista de protocolos de verificación de estado compatibles, consulta la sección Verificaciones de estado de la página Comparación de funciones del balanceador de cargas.
En la siguiente tabla, se especifica el alcance de las verificaciones de estado que admiten los balanceadores de cargas de red de proxy interno en cada modo:
| Modo de balanceador de cargas | Tipo de verificación de estado |
|---|---|
| Balanceador de cargas de red de proxy interno regional | Regional regionHealthChecks |
Para obtener más información sobre las verificaciones de estado, consulta los siguientes vínculos:
Reglas de firewall
Los balanceadores de cargas de red de proxy internos regionales requieren las siguientes reglas de firewall:
- Una regla de permiso de entrada que permita el tráfico de las sondas de verificación de estado de Google. Para obtener más información sobre los rangos de direcciones IP específicos de los sondeos de verificación de estado y por qué es necesario permitir el tráfico de ellos, consulta Rangos de IP del sondeo y reglas de firewall.
- Una regla de permiso de entrada que permita el tráfico de la subred de solo proxy.
Los puertos de estas reglas de firewall deben configurarse de la siguiente manera:
Permite el tráfico al puerto de destino para cada verificación de estado del servicio de backend.
Para los backends de grupos de instancias: determina los puertos que se configurarán a través de la asignación entre el puerto con nombre del servicio de backend y los números de puerto asociados con ese puerto con nombre en cada grupo de instancias. Los números pueden variar entre grupos de instancias asignados al mismo servicio de backend.
Para los backends de NEG
GCE_VM_IP_PORT, permite el tráfico a los números de puerto de los extremos.
Existen algunas excepciones a los requisitos de las reglas de firewall para estos balanceadores de cargas:
- No se requiere permitir el tráfico de los rangos de sondeo de verificación de estado de Google para los NEG híbridos. Sin embargo, si usas una combinación de NEG híbridos y zonales en un solo servicio de backend, debes permitir el tráfico de los rangos de sondeo de verificación de estado de Google para los NEG zonales.
- Para los NEG de Internet regionales, las verificaciones de estado son opcionales. El tráfico de los balanceadores de cargas que usan NEGs de Internet regionales se origina desde la subred de solo proxy y, luego, se traduce con NAT (mediante Cloud NAT) a cualquiera de las direcciones IP de NAT asignadas manual o automáticamente. Este tráfico incluye sondeos de verificación de estado y solicitudes de usuario del balanceador de cargas a los backends. Para obtener más detalles, consulta NEG regionales: Usa una puerta de enlace de Cloud NAT.
Acceso del cliente
Los clientes pueden estar en la misma red o en una red de VPC conectada mediante el intercambio de tráfico entre redes de VPC.
Para los balanceadores de cargas de red de proxy internos regionales, los clientes deben estar en la misma región que el balanceador de cargas de forma predeterminada. También deben estar en la misma red de VPC que el balanceador de cargas, o bien en una red de VPC que esté conectada a la red de VPC del balanceador de cargas mediante el intercambio de tráfico entre redes de VPC.
Los clientes locales pueden acceder al balanceador de cargas a través de túneles de Cloud VPN o adjuntos de VLAN. Estos túneles o adjuntos deben estar en la misma región que el balanceador de cargas.
Arquitectura de VPC compartida
El balanceador de cargas de red de proxy interno admite redes que usan VPC compartida. La VPC compartida te permite mantener una separación clara de las responsabilidades entre los administradores de red y los desarrolladores de servicios. Tus equipos de desarrollo pueden enfocarse en compilar servicios en proyectos de servicio, y los equipos de infraestructura de red pueden aprovisionar y administrar el balanceo de cargas. Si aún no estás familiarizado con la VPC compartida, lee la Documentación de la descripción general de la VPC compartida.
| Dirección IP | Regla de reenvío | Proxy de destino | Componentes de backend |
|---|---|---|---|
Se debe definir una dirección IP interna en el mismo proyecto que los backends. Para que el balanceador de cargas esté disponible en una red de VPC compartida, la dirección IP interna de Google Cloud debe definirse en el mismo proyecto de servicio en el que se encuentran las VMs de backend y debe hacer referencia a una subred en la red de VPC compartida deseada en el proyecto host. La dirección en sí proviene del rango de IP principal de la subred a la que se hace referencia. |
Se debe definir una regla de reenvío interna en el mismo proyecto que los backends. Para que el balanceador de cargas esté disponible en una red de VPC compartida, la regla de reenvío interno debe definirse en el mismo proyecto de servicio en el que se encuentran las VMs de backend y debe hacer referencia a la misma subred (en la red de VPC compartida) a la que hace referencia la dirección IP interna asociada. |
El proxy de destino debe definirse en el mismo proyecto que los backends. | En una situación de VPC compartida, las VMs de backend se suelen ubicar en un proyecto de servicio. En ese proyecto de servicio, debe definirse un servicio de backend interno regional y una verificación de estado. |
Distribución del tráfico
Un balanceador de cargas de red del proxy interno distribuye el tráfico a sus backends de la siguiente manera:
- Las conexiones que se originan en un solo cliente se envían a la misma zona, siempre que los backends en buen estado (grupos de instancias o NEG) dentro de esa zona estén disponibles y tengan capacidad, según lo determinado por el modo de balanceo.
Para los balanceadores de cargas de red de proxy internos regionales, el modo de balanceo puede ser
CONNECTION(grupo de instancias o backends de NEG) oUTILIZATION(solo backends de grupos de instancias). - Las conexiones de un cliente se envían al mismo backend si configuraste la afinidad de sesión.
- Después de seleccionar un backend, el tráfico se distribuye entre instancias (en un grupo de instancias) o extremos (en un NEG) de acuerdo con una política de balanceo de cargas. Para obtener información sobre los algoritmos de la política de balanceo de cargas compatibles, consulta el parámetro de configuración
localityLbPolicyen la documentación de la API del servicio de backend regional.
Afinidad de sesión
La afinidad de sesión te permite configurar el servicio de backend del balanceador de cargas para enviar todas las solicitudes del mismo cliente al mismo backend, siempre que el backend esté en buen estado y tenga capacidad.
Los balanceadores de cargas de red del proxy interno ofrecen los siguientes tipos de afinidad de sesión:Ninguno
Un parámetro de configuración de afinidad de sesión de
NONEno significa que no haya afinidad de sesión. Esto significa que no se configuró explícitamente ninguna opción de afinidad de sesión.El hashing siempre se realiza para seleccionar un backend. Además, un parámetro de configuración de afinidad de sesión de
NONEsignifica que el balanceador de cargas usa un hash de 5 tuplas para seleccionar un backend. El hash de 5 tuplas consta de la dirección IP de origen, el puerto de origen, el protocolo, la dirección IP de destino y el puerto de destino.El valor predeterminado de la afinidad de sesión es
NONE.Afinidad de IP de cliente
La afinidad de sesión de IP de cliente (
CLIENT_IP) es un hash de 2 tuplas creado a partir de las direcciones IP de origen y destino del paquete. La afinidad de IP de cliente reenvía todas las solicitudes de la misma dirección IP de cliente al mismo backend, siempre que ese backend tenga capacidad y se mantenga en buen estado.Cuando uses la afinidad de IP de cliente, ten en cuenta lo siguiente:
- La dirección IP de destino del paquete solo es la misma que la dirección IP de la regla de reenvío del balanceador de cargas si el paquete se envía directamente al balanceador de cargas.
- Es posible que la dirección IP de origen del paquete no coincida con una dirección IP asociada al cliente original si un sistema intermedio de NAT o proxy procesa el paquete antes de que se entregue a un balanceador de cargas de Trusted Cloud . En situaciones en las que muchos clientes comparten la misma dirección IP de origen efectiva, algunas VMs de backend pueden recibir más conexiones o solicitudes que otras.
Ten en cuenta lo siguiente cuando configures la afinidad de sesión:
No uses la afinidad de sesión para fines de autenticación o seguridad. La afinidad de sesión puede interrumpirse cada vez que cambia la cantidad de backends activos y en buen estado. Para obtener más información, consulta Pérdida de afinidad de sesión.
Los valores predeterminados de las marcas
--session-affinityy--subsetting-policysonNONE, y solo uno de ellos a la vez se puede establecer en un valor diferente.
Pérdida de la afinidad de sesión
Todas las opciones de afinidad de sesión requieren lo siguiente:
- La instancia o el extremo de backend seleccionados deben permanecer configurados como backend. La afinidad de sesión se puede interrumpir cuando ocurre uno de los siguientes eventos:
- Quitas la instancia seleccionada de su grupo de instancias.
- El ajuste de escala automático o la recuperación automática del grupo de instancias administrado quitan la instancia seleccionada de su grupo de instancias administrado.
- Quitas el extremo seleccionado de su NEG.
- Quitas del servicio de backend el grupo de instancias o el NEG que contiene la instancia o el extremo seleccionados.
- La instancia o el extremo de backend seleccionados deben permanecer en buen estado. La afinidad de sesión se puede interrumpir cuando la instancia o el extremo seleccionados fallan en las verificaciones de estado.
El grupo de instancias o el NEG que contiene la instancia o el extremo seleccionados no deben estar completos según su capacidad objetivo. (En el caso de los grupos de instancias administrados regionales, el componente zonal del grupo de instancias que contiene la instancia seleccionada no debe estar completo). La afinidad de sesión puede interrumpirse cuando el grupo de instancias o el NEG están llenos y otros grupos de instancias o NEG no lo están. Dado que la plenitud puede cambiar de formas impredecibles cuando se usa el modo de balanceo
UTILIZATION, debes usar el modo de balanceoRATEoCONNECTIONpara minimizar las situaciones en las que se puede interrumpir la afinidad de sesión.La cantidad total de instancias o extremos de backend configurados debe permanecer constante. Cuando se produce al menos uno de los siguientes eventos, cambia la cantidad de instancias o extremos de backend configurados, y se puede interrumpir la afinidad de sesión:
Agregar instancias o extremos nuevos:
- Agrega instancias a un grupo de instancias existente en el servicio de backend.
- El ajuste de escala automático del grupo de instancias administrado agrega instancias a un grupo de instancias administrado en el servicio de backend.
- Agrega extremos a un NEG existente en el servicio de backend.
- Agregas grupos de instancias o NEG no vacíos al servicio de backend.
Quitar cualquier instancia o extremo, no solo la instancia o el extremo seleccionados:
- Quitas cualquier instancia de un backend de grupo de instancias.
- El ajuste de escala automático o la recuperación automática de un grupo de instancias administrado quitan cualquier instancia de un backend de grupo de instancias administrado.
- Quitas cualquier extremo de un backend de NEG.
- Quita cualquier grupo de instancias de backend o NEG existente y no vacío del servicio de backend.
La cantidad total de instancias o extremos de backend en buen estado debe permanecer constante. Cuando ocurre al menos uno de los siguientes eventos, cambia la cantidad de instancias o extremos de backend en buen estado, y se puede interrumpir la afinidad de sesión:
- Cualquier instancia o extremo pasa su verificación de estado y pasa de estar en mal estado a estar en buen estado.
- Cualquier instancia o extremo falla su verificación de estado y pasa de estar en buen estado a estar en mal estado o con tiempo de espera agotado.
Conmutación por error
Si un backend se encuentra en mal estado, el tráfico se redireccionará de forma automática a los backends en buen estado.
En la siguiente tabla, se describe el comportamiento de la conmutación por error de los balanceadores de cargas de red de proxy internos:
| Modo de balanceador de cargas | Comportamiento de la conmutación por error | Comportamiento cuando todos los backends están en mal estado |
|---|---|---|
| Balanceador de cargas de red de proxy interno regional | El balanceador de cargas implementa un algoritmo de conmutación por error gradual por zona. En lugar de esperar a que todos los backends en una zona se encuentren en mal estado, el balanceador de cargas comienza a redireccionar el tráfico a una zona diferente cuando la proporción de backends en buen estado y en mal estado en cualquier zona es inferior a un umbral de porcentaje determinado (70%; este umbral no se puede configurar). Si todos los backends de todas las zonas están en mal estado, el balanceador de cargas finaliza de inmediato la conexión del cliente. El proxy de Envoy envía tráfico a backends en buen estado en una región según la distribución de tráfico configurada. |
Finaliza la conexión |
Balanceo de cargas para aplicaciones de GKE
Si compilas aplicaciones en Google Kubernetes Engine (GKE), puedes usar NEG zonales independientes para balancear las cargas del tráfico directamente a los contenedores. Con los NEG independientes, eres responsable de crear el objeto Service que crea el NEG zonal y, luego, asociar el NEG con el servicio de backend para que el balanceador de cargas pueda conectarse a los Pods.
Documentación de GKE relacionada:
Cuotas y límites
Para obtener información sobre las cuotas y los límites, consulta Cuotas y límites.
Limitaciones
- El balanceador de cargas de red de proxy interno no admite tráfico IPv6.
- El balanceador de cargas de red de proxy interno no admite implementaciones de VPC compartida, en las que el frontend del balanceador de cargas está en un proyecto host o de servicio, y el servicio de backend y los backends están en otro proyecto de servicio (también conocido como referencia de servicios entre proyectos).
¿Qué sigue?
Configura un balanceador de cargas de red de proxy interno regional con un backend de NEG zonal
Configura un balanceador de cargas de red interno del proxy regional con un backend de NEG híbrido