Descripción general de grupos de extremos de red de Internet

Cloud Load Balancing admite tráfico mediante proxy a backends externos fuera de Trusted Cloud by S3NS. Para definir un backend externo para un balanceador de cargas, se usa un recurso llamado grupo de extremos de red (NEG) de Internet.

Puedes usar este tipo de implementación cuando quieras entregar contenido desde un backend externo, pero quieras que tu balanceador de cargas Trusted Cloud sea el frontend. Esto te permite hacer lo siguiente:

• Usar la infraestructura de Google Edge para finalizar tus conexiones de usuario.
• Dirige las conexiones a tu backend externo.
• Enviar tráfico a tu extremo público a través de la red troncal privada de Google, lo que mejora la confiabilidad y puede reducir la latencia entre el cliente y el servidor.

En las siguientes secciones, se explica cómo se usan los backends externos con Cloud Load Balancing. Si quieres usar un backend externo con Cloud Service Mesh, consulta Cloud Service Mesh con grupos de extremos de red de Internet.

Terminología

Los siguientes términos a veces se usan indistintamente porque tienen el mismo significado o uno similar:

• Backend externo: Es un backend que reside fuera de Trusted Cloud by S3NS y se puede acceder a él a través de Internet. Es el extremo en un NEG de Internet.
• Grupo de extremos de red de Internet (NEG): El recurso de la API de Trusted Cloud by S3NS que usas para especificar un backend externo.
• extremo externo: Igual que un backend externo.

En este documento, se usa el término backend externo, excepto cuando se hace referencia al recurso de la API de NEG de Internet.

Componentes del balanceador de cargas

En esta sección, se describen la arquitectura y los recursos del balanceo de cargas necesarios para configurar un balanceador de cargas con un backend externo. El balanceador de cargas requiere una configuración especial solo para el servicio de backend. La configuración del frontend es la misma que la de cualquier otro balanceador de cargas.

En las siguientes figuras, se muestran los Trusted Cloud recursos necesarios para configurar un balanceador de cargas con un backend externo.

Solo puedes usar NEGs de Internet en el nivel de servicio de red Premium.

Configuración de frontend

No se requiere ninguna configuración especial de frontend para crear un balanceador de cargas con un backend de NEG de Internet. Las reglas de reenvío se usan para enrutar el tráfico por dirección IP, puerto y protocolo a un proxy de destino. Luego, el proxy de destino finaliza las conexiones de los clientes. Además, los balanceadores de cargas basados en Envoy requieren una subred de solo proxy.

Los balanceadores de cargas de aplicaciones también usan mapas de URL para configurar el enrutamiento basado en URL de las solicitudes a los servicios de backend correspondientes.

Para obtener más detalles sobre cada uno de estos componentes, consulta las secciones de arquitectura de los respectivos balanceador de cargas:

• Descripción general del balanceador de cargas de aplicaciones externo
• Descripción general del balanceador de cargas de aplicaciones interno
• Descripción general del balanceador de cargas de red del proxy externo
• Descripción general del balanceador de cargas de red de proxy interno

NEG de Internet

Un NEG de Internet es un recurso que se usa para definir un backend externo para el balanceador de cargas. Existen dos tipos de NEG de Internet: el NEG de Internet global y el NEG de Internet regional. Se diferencian en el alcance (global o regional) y el comportamiento. Se debe poder acceder al backend externo al que hace referencia un NEG de Internet global exclusivamente a través de Internet; no se puede acceder a él a través de Cloud VPN ni Cloud Interconnect. Si el backend externo hace referencia a una API o servicio de Google, se debe poder acceder a estos mediante el puerto TCP 80 o 443 con el protocolo HTTP, HTTPS o HTTP/2.

Existen dos maneras de configurar el extremo externo al que hace referencia el NEG: INTERNET_FQDN_PORT o INTERNET_IP_PORT. Si se elige el formato INTERNET_IP_PORT, solo se puede usar una dirección IP pública enrutable por Internet. Si se elige el formato INTERNET_FQDN_PORT, el FQDN se puede resolver en una dirección IP pública enrutable por Internet o en una dirección IP privada, según el alcance del extremo: regional o global.

Los NEG de Internet regionales se basan en proxies de Envoy administrados. Cada NEG puede tener varios extremos, y un servicio de backend puede incluir varios NEG de Internet.

Para el tráfico de salida, puedes configurar puertas de enlace de Cloud NAT para establecer las direcciones IP de origen. Como alternativa, puedes enrutar el tráfico con rutas aprendidas dentro de tu red de VPC. Si bien Cloud NAT no es necesario para este método de enrutamiento, sí se admite.

En la siguiente tabla, se describe cómo los diferentes balanceadores de cargas admiten NEG de Internet regionales.

Balanceadores de cargas	Tipo de extremo	Definición del extremo	Alcance	Verificaciones de estado
Balanceador de cargas de aplicaciones externo regional Balanceador de cargas de aplicaciones interno regional Balanceador de cargas de red del proxy externo regional Balanceador de cargas de red del proxy interno regional	INTERNET_FQDN_PORT	Un nombre de dominio completamente calificado que se pueda resolver de forma pública o privada, y un puerto opcional. Por ejemplo, backend.example.com:443*. Cloud DNS debe poder resolver el nombre de dominio. Se permite un máximo de 256 extremos por NEG.	Regional	Verificaciones de estado distribuidas de Envoy
	INTERNET_IP_PORT	Solo una dirección IP que se pueda enrutar públicamente y un puerto opcional. Por ejemplo, 8.8.8.8:4432. La dirección IP no puede ser RFC 1918. Se permite un máximo de 256 extremos por NEG.

Resolución de DNS para extremos regionales de INTERNET_FQDN_PORT

Si tu dominio se puede resolver en Internet, no se necesita ninguna otra configuración para configurar DNS. Sin embargo, si usas FQDN privados, deberás configurar Cloud DNS para facilitar la resolución de DNS. El nombre debe estar alojado en Cloud DNS o debe poder resolverse con el reenvío de DNS desde Cloud DNS a un DNS local o al intercambio de tráfico de DNS si se hace referencia a una zona de DNS privada en otra red de VPC.

Primero, crea una zona de Cloud DNS para alojar los registros DNS en tu proyecto. Luego, agrégale los registros DNS. Para conocer los pasos de configuración específicos, consulta la documentación de Cloud DNS. El orden de resolución de Cloud DNS se detalla en Orden de resolución de nombres.

Si usas una VPC compartida, ten en cuenta los requisitos de red específicos. También puedes usar otras funciones de Cloud DNS, como zonas de reenvío, para recuperar registros de un servidor DNS local.

Resolución de dirección IP para extremos regionales INTERNET_FQDN_PORT

Los NEGs de Internet regionales admiten la resolución de nombres de dominio mediante Cloud DNS.

Si el servidor DNS muestra varias direcciones IP, el tráfico de balanceo de cargas de Envoy entre las direcciones IP mostradas se basa en el algoritmo de balanceo de cargas configurado (round robin, solicitud de mínimos, etcétera). La lista de extremos se actualiza periódicamente según el TTL del DNS. Puedes configurar políticas de reintentos para obligar a Envoy a intentar conectarse a otra dirección IP si falla una.

Servicio de backend

Los servicios de backend proporcionan información de configuración al balanceador de cargas. Los balanceadores de cargas usan la información en el servicio de backend para dirigir el tráfico entrante a uno o más backends conectados.

Para configurar un balanceador de cargas con un backend externo, debes configurar el servicio de backend con un backend de NEG de Internet. Cuando agregas un NEG de Internet a un servicio de backend, se aplican las siguientes consideraciones, según el alcance del NEG:

• El servicio de backend tampoco puede usar otros tipos de backend (como NEGs zonales o grupos de instancias) como backends.

• Cantidad de NEGs por servicio de backend

  • NEGs regionales. Puedes agregar hasta 50 NEGs de Internet al mismo servicio de backend.

• Cantidad de extremos por NEG

  • NEGs regionales. Puedes agregar hasta 256 extremos por NEG al mismo servicio de backend.

  Los NEGs regionales no son compatibles con los modos de balanceo de cargas, como la tasa, la conexión o el uso. Todos los extremos de todos los NEGs adjuntos a un servicio de backend se agrupan en un solo grupo. El balanceo de cargas de tráfico entre este grupo de extremos se controla con los algoritmos de balanceo de cargas de Envoy. Para obtener información sobre los algoritmos de la política de balanceo de cargas compatibles, consulta localityLbPolicy en la documentación de la API del servicio de backend regional.

• Verificaciones de estado

  • NEGs regionales. El balanceador de cargas usa verificaciones de estado distribuidas de Envoy.

• El esquema de balanceo de cargas del servicio de backend debe coincidir con el esquema que requiere el balanceador de cargas que implementas. Para obtener la lista completa, consulta Servicios de backend.

• El protocolo de servicio de backend debe ser HTTP, HTTPS o HTTP2.

  Te recomendamos que uses HTTPS o HTTP/2 como protocolo cuando configures un servicio de backend con un NEG de Internet para que la comunicación entre el balanceador de cargas y el backend se encripte y autentique cuando se transmita por Internet pública.

  Además, cuando uses HTTPS o HTTP/2 como protocolo de backend, asegúrate de usar un extremo INTERNET_FQDN_PORT para crear tu backend externo. Esto tiene dos ventajas:

  • Garantiza que el balanceador de cargas valide el certificado del servidor SSL que presenta el backend externo y verifique que la siguiente información sea verdadera:

    • El certificado esté firmado por autoridades certificadoras (CA) conocidas.
    • El certificado no haya caducado.
    • La firma del certificado sea válida.
    • El FQDN configurado coincida con uno de los nombres alternativos de sujeto (SAN) en el certificado.

    Si creas el backend externo con un extremo de INTERNET_IP_PORT, no se realizará la validación del certificado del servidor SSL.

  • La extensión de indicación de nombre del servidor (SNI) de SSL solo se admite con extremos INTERNET_FQDN_PORT. El FQDN configurado recibe una SNI en la bienvenida del cliente durante el protocolo de enlace SSL entre el balanceador de cargas y el extremo externo. La SNI no se envía cuando usas un extremo INTERNET_IP_PORT porque los literales de dirección IP no están permitidos en el campo HostName de una carga útil de SNI.

Verificaciones de estado

La configuración de la verificación de estado varía según el tipo de balanceador de cargas:

• Balanceador de cargas de aplicaciones externo regional, balanceador de cargas de aplicaciones interno, balanceador de cargas de red del proxy externo regional y balanceador de cargas de red del proxy interno regional. Las verificaciones de estado son opcionales. Los sondeos de verificación de estado de estos balanceadores de cargas se originan en la subred de solo proxy y se traducen mediante NAT (con Cloud NAT) a direcciones IP reservadas previamente o a direcciones IP de NAT asignadas automáticamente. Para obtener más detalles, consulta NEG regionales: Usa una puerta de enlace de Cloud NAT.

  Las verificaciones de estado de Envoy distribuidas se crean con los mismos procesos de la consola, gcloud CLI y la API que las verificaciones de estado centralizadas.Trusted Cloud No se requiere ninguna otra configuración.

  Puntos para tener en cuenta:

  • No se admiten las verificaciones de estado de gRPC.
  • No se admiten las verificaciones de estado con el protocolo PROXY v1 habilitado.

  • Debido a que el plano de datos de Envoy controla las verificaciones de estado, no puedes usar la consola deTrusted Cloud , la API ni gcloud CLI para verificar el estado de estos extremos externos. En el caso de los NEG híbridos con balanceadores de cargas basados en Envoy, la consola Trusted Cloud muestra el estado de la verificación de estado comoN/A. Esta situación es esperable.

  • Cada proxy de Envoy asignado a la subred de solo proxy en la región de la red de VPC inicia las verificaciones de estado de forma independiente. Por lo tanto, es posible que veas un aumento en el tráfico de red debido a la verificación de estado. El aumento depende de la cantidad de proxies de Envoy asignados a tu red de VPC en una región, la cantidad de tráfico que reciben estos proxies y la cantidad de extremos en los que cada proxy de Envoy debe comprobar el estado. En el peor de los casos, el tráfico de red generado por las verificaciones de estado aumenta a una frecuencia cuadrática de (O(n^2)).

  • Los registros de las verificaciones de estado de Envoy distribuidas no incluyen estados detallados. Para obtener detalles sobre lo que se registra, consulta Registro de la verificación de estado. Para solucionar aún más los problemas de conectividad de los proxies de Envoy a los extremos de tu NEG, también debes consultar los registros correspondientes del balanceador de cargas.

    • Registro del balanceador de cargas de aplicaciones externo regional
    • Registro del balanceador de cargas de aplicaciones interno
    • Registro del balanceador de cargas de red del proxy

Habilita el backend externo para que reciba solicitudes

Configura tu backend externo para permitir el tráfico de Trusted Cloud.

NEG regionales: Usa una puerta de enlace de Cloud NAT

Si usas un NEG de Internet regional, primero configurarás una puerta de enlace de Cloud NAT para asignar un conjunto de rangos de direcciones IP desde el que Trusted Cloud debería originarse el tráfico.

El extremo de la puerta de enlace debe ser del tipo ENDPOINT_TYPE_MANAGED_PROXY_LB.

La puerta de enlace de Cloud NAT se puede configurar para asignar direcciones IP externas de forma dinámica a pedido o usar un conjunto de direcciones IP externas reservadas de forma manual.

• Direcciones IP asignadas de forma automática

  Usa direcciones IP asignadas de forma automática si tu entorno de backend externo no requiere que agregues direcciones IP específicas Trusted Cloud que puedan enviar tráfico al backend externo a una lista de entidades permitidas.

• Direcciones IP asignadas de forma manual

  Usa direcciones IP asignadas de forma manual solo si el entorno de backend externo requiere que agregues direcciones IP específicas de Trusted Cloud a una lista de entidades permitidas. Debido a que cada Envoy asignado a tu subred de proxy consume una dirección IP completa, asegúrate de que el grupo de direcciones IP reservadas sea lo suficientemente grande como para admitir todos los Envoy.

  Si tienes problemas de conectividad a gran escala, verifica si alcanzaste los límites de Cloud NAT. De forma predeterminada, tienes un límite de 50 direcciones IP de NAT asignadas manualmente por puerta de enlace.

Se admite la asignación dinámica de puertos para los NEGs de Internet regionales. Las direcciones IP pueden compartirse a través de proxies, por lo que se aprovechan al máximo.

Esta configuración de Cloud NAT se aplica a toda la subred de solo proxy. El tráfico de Internet asociado con todos los balanceadores de cargas regionales basados en Envoy en la región comparte la misma puerta de enlace NAT.

El uso de Cloud NAT genera cargos por el tráfico de los usuarios y del tráfico de la verificación de estado. Para obtener detalles sobre cómo funcionan los precios de los NEG de Internet regionales, consulta Precios de los NEG de Internet regionales.

Existen ciertas limitaciones para las puertas de enlace NAT configuradas en subredes de solo proxy:

• Solo se realiza la traducción de NAT de uno a uno. No se admite el uso compartido de direcciones IP.
• No se admiten el registro ni la supervisión. Es decir, no se admiten las marcas --enable-logging y --log-filter.

Autentica solicitudes al backend externo

Esta sección solo se aplica a los balanceadores de cargas de aplicaciones.

Para autenticar solicitudes enviadas a tu backend externo, puedes realizar una de las siguientes acciones:

• Puedes configurar un encabezado personalizado para indicar que la solicitud provino de un balanceador de cargas Trusted Cloud con un encabezado de solicitud personalizado. Por ejemplo, puedes usar 16 o más bytes criptográficos aleatorios como clave compartida.

  La implementación de transformaciones de encabezados personalizados depende del tipo de balanceador de cargas que uses:

  • Balanceador de cargas de aplicaciones externo regional y el balanceador de cargas de aplicaciones interno regional. Las transformaciones de encabezados personalizados solo se pueden configurar en el mapa de URL.

    Para estos balanceadores de cargas basados en Envoy, Host y authority son palabras clave especiales reservadas por Trusted Cloud. No puedes modificar estos encabezados para estos balanceadores de cargas. En cambio, te recomendamos que crees otros encabezados personalizados (por ejemplo, MyHost) para que no interfieras en los nombres de los encabezados reservados.

• Habilita IAP y verifica que Google haya firmado el JWT firmado en el encabezado de la solicitud, y que la reclamación de aud (público) contenga el número de proyecto en el que se define tu balanceador de cargas.

Registros

Las solicitudes enviadas mediante proxy a un backend externo se registran en Cloud Logging de la misma manera que las solicitudes de otros backends.

Para obtener más información, consulta lo siguiente:

• Registro del balanceador de cargas de aplicaciones externo regional
• Registro del balanceador de cargas de aplicaciones interno regional
• Registro del balanceador de cargas de red del proxy

Limitaciones

• Revisa la sección de servicio de backend para conocer las limitaciones asociadas con la configuración de NEGs de Internet como backends.
• Cuando modificas un balanceador de cargas para cambiar el backend de un NEG de Internet a cualquier otro tipo de backend, o cuando cambias el backend de cualquier otro tipo de backend a un NEG de Internet, la aplicación experimenta un tiempo de inactividad temporal de unos 30 a 90 segundos.

• Revisa la sección Puerta de enlace de Cloud NAT para conocer las limitaciones asociadas con las puertas de enlace NAT configuradas en subredes de solo proxy.

Cuotas y límites

Para obtener información sobre las cuotas y los límites, consulta la tabla de cuotas de backends de NEG y la tabla de cuotas de extremos por NEG.

Precios

El tráfico de salida a los extremos de NEG de Internet externos se cobra según las tarifas de salida de Internet para redes de nivel Premium. La fuente se basa en la ubicación del cliente, y el destino se basa en la ubicación de tu extremo público.

Si configuraste una puerta de enlace de Cloud NAT para asignar la subred de solo proxy del balanceador de cargas regional basado en Envoy, se generarán cargos de Cloud NAT. Las puertas de enlace Cloud NAT asignadas para balanceadores de cargas generan cargos por hora equivalentes a una red con más de 32 instancias de VM. Para obtener más información, consulta Precios de Cloud NAT.

Para obtener más información, consulta los precios de Cloud Load Balancing.

¿Qué sigue?

• Configura un balanceador de cargas de aplicaciones externo regional con un NEG de Internet
• Configura un balanceador de cargas de red de proxy externo regional con un NEG de Internet