Descripción general del balanceador de cargas de red de proxy interno

El balanceador de cargas de red de proxy interno de Google Cloud 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 de 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 backends alojados en Google Cloud, 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

Puedes configurar un balanceador de cargas de red de proxy interno de los siguientes modos:

• Balanceador de cargas de red de proxy interno regional. Este es un balanceador de cargas regional se implementa como un servicio administrado basado en el proxy de código abierto de Envoy. El modo regional garantiza que todos los clientes y backends provengan de una región específica, lo que ayuda cuando necesitas cumplimiento regional.

• Balanceador de cargas de red de proxy interno entre regiones. Este es un balanceador de cargas multirregional se implementa como un servicio administrado basado en el proxy de código abierto de Envoy. El modo entre regiones te permite balancear las cargas del tráfico a los servicios de backend que se distribuyen globalmente, incluida la administración del tráfico que garantiza que el tráfico se dirija al backend más cercano. Este balanceador de cargas también permite la alta disponibilidad. Colocar backends en varias regiones ayuda a evitar fallas en una sola región. Si los backends de una región están inactivos, el tráfico puede conmutarse por error a otra región.

  En la siguiente tabla, se describen las diferencias importantes entre los modos regionales y entre regiones:

  Función	Balanceador de cargas de red del proxy interno regional	Balanceador de cargas de red del proxy interno entre regiones
  Dirección IP virtual (VIP) del balanceador de cargas.	Asignado desde una subred en una región específica de Google Cloud.	Asignado desde una subred en una región específica de Google Cloud. Las direcciones VIP multirregión pueden compartir el mismo servicio de backend global.
  Acceso del cliente	No se puede acceder a él de forma global de forma predeterminada. De manera opcional, puedes habilitar el acceso global.	Siempre accesible a nivel global. Los clientes de cualquier región de Google Cloud pueden enviar tráfico al balanceador de cargas.
  Backends con balanceo de cargas	Backends regionales. El balanceador de cargas solo puede enviar tráfico a los backends que se encuentren en la misma región que el proxy del balanceador de cargas.	Backends globales. El balanceador de cargas puede enviar tráfico a backends en cualquier región.
  Alta disponibilidad y conmutación por error	Conmutación por error automática a backends en buen estado en la misma región.	Conmutación por error automática a backends en buen estado en la misma región o en otras.

Identifica el modo

Arquitectura

En el siguiente diagrama, se muestran los recursos de Google Cloud necesarios para los balanceadores de cargas de red de proxy internos regionales.

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 del proxy interno basado en Envoy. En la siguiente tabla, se describen las diferencias entre las subredes de solo proxy en los modos regional y entre regiones:

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	REGIONAL_MANAGED_PROXY 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 red de VPC comparten la misma subred de solo proxy.
Balanceador de cargas de red del proxy interno entre regiones	GLOBAL_MANAGED_PROXY Los balanceadores de cargas entre regiones y regionales no pueden compartir las mismas subredes El balanceador de cargas entre regiones basado en Envoy debe tener una subred de solo proxy en cada región en la que esté configurado el balanceador de cargas. Los proxies del balanceador de cargas entre regiones en la misma región y red 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 internos 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 regional 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 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 las diferencias entre las reglas de reenvío en los modos regional y entre regiones:

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	Regional forwardingRules Dirección IP regional Esquema de balanceo de cargas: INTERNAL_MANAGED Subred de solo proxy --purpose: REGIONAL_MANAGED_PROXY Dirección IP --purpose: SHARED_LOADBALANCER_VIP	Puedes habilitar el acceso global para permitir que los clientes de cualquier región accedan al balanceador de cargas. Los backends también deben estar en la misma región que el balanceador de cargas.
Balanceador de cargas de red del proxy interno entre regiones	Global globalForwardingRules Direcciones IP regionales Esquema de balanceo de cargas: INTERNAL_MANAGED Subred de solo proxy --purpose: GLOBAL_MANAGED_PROXY Dirección IP --purpose: SHARED_LOADBALANCER_VIP	El acceso global está habilitado de forma predeterminada para permitir que los clientes de cualquier región accedan al balanceador de cargas. Los backends pueden estar en varias regiones.

Reglas de reenvío y redes de VPC

En esta sección, se describe cómo se asocian las reglas de reenvío que usan los balanceadores de cargas de aplicaciones externos con las redes de VPC.

Modo de balanceador de cargas	Asociación de red 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 creas la regla de reenvío, debes 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 en la que se creó una subred de solo proxy. 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 del proxy de destino que requieren los balanceadores de cargas de red de proxy interno en cada modo:

Proxy de destino	Balanceador de cargas de red del proxy interno regional	Balanceador de cargas de red del proxy interno entre regiones
TCP	Regional regionTargetTcpProxies	Global targetTcpProxies

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 especifica el tipo de servicio de backend que requieren los balanceadores de cargas de red de proxy interno en cada modo.

	Balanceador de cargas de red del proxy interno regional	Balanceador de cargas de red del proxy interno entre regiones
Tipo de servicio de backend	Regional regionBackendServices	Global backendServices

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	NEG de Private Service Connect	GKE
Balanceador de cargas de red del proxy interno regional		Extremos de tipo GCE_VM_IP_PORT	Solo NEG regionales			Agrega un NEG de Private Service Connect
Balanceador de cargas de red del proxy interno entre regiones		Extremos de tipo GCE_VM_IP_PORT				Agrega un NEG de Private Service Connect

Todos los backends deben ser del mismo tipo (grupos de instancias o NEG). Puedes usar diferentes tipos de backends de grupos de instancias de forma simultánea o usar diferentes tipos de backends de NEG de forma simultánea, pero no puedes usar grupos de instancias y backends de NEG juntos en el mismo servicio de backend.

Puedes combinar NEG zonales y NEG híbridos dentro del mismo servicio de backend.

Para garantizar interrupciones mínimas a tus usuarios, puedes habilitar 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

Las restricciones sobre dónde se pueden ubicar los backends dependen del tipo de balanceador de cargas.

• 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 (esta función está en versión preliminar). 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, adjuntos de VLAN de Cloud Interconnect o un framework de Network Connectivity Center.

  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.
  • Para 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 nic0 de la primera VM que se agrega al grupo de instancias.

  Requisitos de red de backend

  La red de tu backend debe cumplir con uno de los siguientes requisitos de red:

  • La red de VPC del backend debe coincidir con exactitud 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 los 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.

  • La red de VPC del backend y la de la regla de reenvío deben ser radios de VPC en el mismo concentrador de Network Connectivity Center. Los filtros de importación y exportación deben 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 backend, todos los backends deben estar ubicados en la misma región y red de VPC.

Interfaces de red y backends

Si usas backends de grupos de instancias, los paquetes siempre se entregan a nic0. Si quieres enviar paquetes a diferentes NICs, 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 de NEG deben estar en la misma red de VPC que la red de VPC definida de forma explícita del 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. El balanceador de cargas de red del proxy interno regional o el balanceador de cargas de red del proxy interno entre regiones solo es compatible con 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 TCP a los backends. Para obtener la lista de protocolos de verificación de estado compatibles, consulta Funciones del balanceo 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 internos 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
Balanceador de cargas de red del proxy interno entre regiones	Global healthChecks

Para obtener más información sobre las verificaciones de estado, consulta los siguientes vínculos:

• Descripción general de las verificaciones de estado
• Crea verificaciones de estado

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.
  • 35.191.0.0/16
  • 130.211.0.0/22
  Para el tráfico IPv6 a los backends:
  • 2600:2d00:1:b029::/64
• 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 es necesario agregar los rangos de sondeo de verificación de estado de Google a una lista de entidades permitidas para NEG híbridos. Sin embargo, si usas una combinación de NEG híbridos y zonales en un solo servicio de backend, debes agregar los rangos de sondeo de verificación de estado de Google a una lista de entidades permitidas 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 NEG de Internet regionales se origina desde la subred de solo proxy y, luego, se traduce con NAT (a través de Cloud NAT) a cualquiera de las direcciones IP de NAT asignadas de forma 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 Cloud NAT para la salida.

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 interno regional, los clientes deben estar en la misma región que el balanceador de cargas de forma predeterminada. Puedes habilitar el acceso global para permitir que los clientes de cualquier región accedan al balanceador de cargas.

Para los balanceadores de cargas de red de proxy internos entre regiones, el acceso global está habilitado de forma predeterminada. Los clientes de cualquier región pueden acceder al balanceador de cargas.

En la siguiente tabla, se resume el acceso del cliente para los balanceadores de cargas de red del proxy internos regionales:

Acceso global inhabilitado	Acceso global habilitado
Los clientes deben estar en la misma región que el balanceador de cargas. También deben estar en la misma red de VPC que el balanceador de cargas o 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 pueden estar en cualquier región. Aún deben estar en la misma red de VPC que el balanceador de cargas o 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.	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 pueden estar en cualquier región.

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 de proxy interno distribuye el tráfico a sus backends de la siguiente manera:

1. 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) o UTILIZATION (solo backends de grupos de instancias).
2. Las conexiones de un cliente se envían al mismo backend si configuraste la afinidad de sesión.
3. 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 la configuración de localityLbPolicy en 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.

El balanceador de cargas de red de proxy interno ofrece afinidad de IP de cliente, que 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.

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 en cada modo:

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 suave 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 se encuentra por debajo de un umbral determinado (70%; este umbral no es configurable) Si todos los backends en todas las zonas están en mal estado, el balanceador de cargas finaliza la conexión del cliente de inmediato. 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
Balanceador de cargas de red del proxy interno entre regiones	Conmutación por error automática a backends en buen estado en la misma región o en otras regiones. El tráfico se distribuye entre backends en buen estado que abarcan varias regiones según la distribución del tráfico configurada.	Finaliza la conexión

Balanceo de cargas para aplicaciones de GKE

Si compilas aplicaciones en Google Kubernetes Engine, puedes usar NEG independientes zonales 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 se conectan a los Pods.

Documentación de GKE relacionada:

• Balanceo de cargas nativo del contenedor mediante NEG independientes

Cuotas y límites

Para obtener información sobre las cuotas y los límites, consulta Cuotas de recursos del balanceo de cargas.

Limitaciones

• El balanceador de cargas de red de proxy interno no es compatible con el 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 interno del proxy regional con un backend de grupo de instancias
• 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
• Configura un balanceador de cargas de red de proxy interno regional con un backend de NEG de Internet
• Visualiza métricas con Cloud Monitoring