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 especificada, lo que es útil cuando necesitas el 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 dirigido a los servicios de backend que se distribuyen globalmente, lo que incluye la administración de tráfico que garantiza que este último se dirija al backend más cercano. Este balanceador de cargas también habilita 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. Se asignan desde una subred en una región específica de Google Cloud. Se asignan 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 ellos de forma global de forma predeterminada.
De manera opcional, puedes habilitar el acceso global.Siempre se puede acceder a ellos 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 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
Consola de Cloud
En la consola de Google Cloud, ve a la página Balanceo de cargas.
En la pestaña Balanceadores de cargas, puedes ver el tipo, el protocolo y la región del balanceador de cargas. Si la región está en blanco, entonces el balanceador de cargas está en modo entre regiones. En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.
Modo de balanceador de cargas Tipo de balanceador de cargas Tipo de acceso Región Balanceador de cargas de red del proxy interno regional Red (proxy) Interno Especifica una región Balanceador de cargas de red del proxy interno entre regiones Red (proxy) Interno
gcloud
Para determinar el modo de un balanceador de cargas, ejecuta el siguiente comando:
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
En el resultado del comando, verifica el esquema de balanceo de cargas, la región y el nivel de red. En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.
Modo de balanceador de cargas Esquema de balanceo de cargas Regla de reenvío Balanceador de cargas de red del proxy interno regional INTERNAL_MANAGED Regional Balanceador de cargas de red del proxy interno entre regiones INTERNAL_MANAGED Global
Arquitectura
En el siguiente diagrama, se muestran los recursos de Google Cloud necesarios para los balanceadores de cargas de red de proxy internos regionales.
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.
Interregión
En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de red de proxy interno entre regiones en el nivel Premium dentro de la misma red de VPC. Cada regla de reenvío global usa una dirección IP regional que los clientes usan para conectarse.
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 red de VPC comparten la misma subred de solo proxy. |
| Balanceador de cargas de red del proxy interno entre regiones |
Los balanceadores de cargas entre regiones y regionales no pueden compartir las mismas subredes El balanceador de cargas HTTP(S) basado en Envoy entre regiones debe tener una subred de solo proxy en cada región en la que esté configurado. 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 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
|
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 |
Esquema de balanceo de cargas:
Subred de solo proxy
Dirección IP
|
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 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 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 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 |
| Balanceador de cargas de red del proxy interno entre regiones | Global targetTcpProxies |
Servicio de backend
Un servicio de backend dirige el tráfico entrante a uno o más backends adjuntos. 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 |
| Balanceador de cargas de red del proxy interno entre regiones | 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, de forma simultánea, 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 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
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 de 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.
- 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.
- Tanto la red de VPC del backend como la red de VPC 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 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 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 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 son compatibles 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 con 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 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 |
| 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:
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/16130.211.0.0/22
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 se requiere incluir en la lista de entidades permitidas 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 incluir en la lista de anunciantes permitidos 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 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 de los clientes a los balanceadores de cargas de red de proxy interno regional:
| 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 se debe definir 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 la configuración de
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.
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 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 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 de todas las zonas están en mal estado, el balanceador de cargas finaliza inmediatamente 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 |
| 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. 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:
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 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