Descripción general de los grupos de puntos finales de red de Internet

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

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

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

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

Terminología

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

• Backend externo: un backend que se encuentra fuera de Trusted Cloud by S3NS y al que se puede acceder a través de Internet. El punto final de un NEG de Internet.
• Grupo de puntos finales de red de Internet (NEG): el recurso de la API Trusted Cloud by S3NS que usas para especificar un backend externo.
• Endpoint externo: es lo mismo que un backend externo.

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

Componentes del balanceador de carga

En esta sección se describe la arquitectura de balanceo de carga y los recursos necesarios para configurar un balanceador de carga con un backend externo. El balanceador de carga 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 carga.

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

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

Configuración de frontend

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

Los balanceadores de carga de aplicaciones también usan mapas de URLs para configurar el enrutamiento basado en URLs de las solicitudes a los servicios de backend adecuados.

Para obtener más información sobre cada uno de estos componentes, consulta las secciones de arquitectura de los respectivos balanceadores de carga:

• Descripción general del balanceador de carga de aplicaciones externo
• Descripción general del balanceador de carga de aplicaciones interno
• Descripción general del balanceador de carga de red de proxy externo
• Descripción general del balanceador de carga 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 carga. Hay dos tipos de NEGs de Internet: los globales y los regionales. Se diferencian en el ámbito (global o regional) y en el comportamiento. Solo se puede acceder al backend externo al que hace referencia un NEG de Internet global a través de Internet. No se puede acceder a él a través de Cloud VPN ni de Cloud Interconnect. Si el backend externo hace referencia a una API o un servicio de Google, se debe poder acceder al servicio a través del puerto TCP 80 o 443 mediante el protocolo HTTP, HTTPS o HTTP/2.

Hay dos formas de configurar el endpoint 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 enrutable de Internet pública. Si se elige el formato INTERNET_FQDN_PORT, el FQDN se puede resolver en una dirección IP enrutable de Internet pública o en una dirección IP privada, en función del ámbito del endpoint: regional o global.

Los NEGs de Internet regionales usan proxies Envoy gestionados. Cada NEG puede tener varios puntos finales y un servicio de backend puede incluir varios NEG de Internet.

En el caso del tráfico de salida, puedes configurar pasarelas Cloud NAT para definir las direcciones IP de origen. También puedes enrutar el tráfico mediante rutas aprendidas en tu red de VPC. Aunque Cloud NAT no es obligatorio para este método de enrutamiento, sí se admite.

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

Balanceadores de carga	Tipo de punto final	Definición de endpoint	Ámbito	Comprobaciones del estado
Balanceador de carga de aplicación externo regional Balanceador de carga de aplicación interno regional Balanceador de carga de red con proxy externo regional Balanceador de carga de red con proxy interno regional	INTERNET_FQDN_PORT	Un nombre de dominio completo que se pueda resolver de forma pública o privada, y un puerto opcional. Por ejemplo, backend.example.com:443*. El nombre de dominio debe poder resolverse mediante Cloud DNS. Se permite un máximo de 256 endpoints por NEG.	Regional	Comprobaciones del estado distribuidas de Envoy
	INTERNET_IP_PORT	Solo una dirección IP disponible públicamente y un puerto opcional. Por ejemplo, 8.8.8.8:4432. La dirección IP no puede ser una dirección RFC 1918. Se permite un máximo de 256 endpoints por NEG.

Resolución de DNS para los endpoints regionales de INTERNET_FQDN_PORT

Si tu dominio se puede resolver en Internet, no es necesario realizar ninguna otra configuración para configurar el DNS. Sin embargo, si vas a resolver FQDNs privados, tendrás que configurar Cloud DNS para facilitar la resolución de DNS. El nombre debe estar alojado en Cloud DNS o poder resolverse mediante el reenvío de DNS de Cloud DNS a un DNS local o a un peering de DNS si se hace referencia a una zona de DNS privado en otra red de VPC.

Empieza creando una zona de Cloud DNS para alojar los registros DNS de tu proyecto. A continuación, añade los registros DNS. Para ver 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 la sección Orden de resolución de nombres.

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

Resolución de direcciones IP para los endpoints regionales INTERNET_FQDN_PORT

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

Si el servidor DNS devuelve varias direcciones IP, Envoy balancea la carga del tráfico entre las direcciones IP devueltas en función del algoritmo de balanceo de carga configurado (round robin, solicitud mínima, etc.). La lista de endpoints se actualiza periódicamente en función del TTL del DNS. Puedes configurar políticas de reintento 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 carga. Los balanceadores de carga usan la información de un servicio de backend para dirigir el tráfico entrante a uno o varios backends conectados.

Para configurar un balanceador de carga con un backend externo, configure el servicio de backend con un backend de NEG de Internet. Cuando añades un NEG de Internet a un servicio de backend, se aplican las siguientes consideraciones, en función del ámbito del NEG:

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

• Número de NEGs por servicio de backend

  • NEGs regionales. Puedes añadir hasta 50 NEGs de Internet al mismo servicio de backend.

• Número de puntos finales por NEG

  • NEGs regionales. Puedes añadir hasta 256 puntos finales por NEG al mismo servicio de backend.

  Los NEG regionales no admiten modos de balanceo de carga, como la frecuencia, la conexión o la utilización. Todos los puntos finales de todos los NEGs asociados a un servicio de backend se agrupan en un solo grupo. El balanceo de carga del tráfico entre este grupo de endpoints se gestiona mediante algoritmos de balanceo de carga de Envoy. Para ver los algoritmos de la política de balanceo de carga admitidos, consulta localityLbPolicy en la documentación de la API del servicio de backend regional.

• Comprobaciones del estado

  • NEGs regionales. El balanceador de carga usa comprobaciones de estado de Envoy distribuidas.

• El esquema de balanceo de carga del servicio de backend debe coincidir con el esquema que requiere el balanceador de carga que vas a implementar. Para ver la lista completa, consulta Servicios de backend.

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

  Te recomendamos que uses HTTPS o HTTP/2 como protocolo al configurar un servicio de backend con un NEG de Internet para que la comunicación entre el balanceador de carga y el backend esté cifrada y autenticada al transitar por Internet público.

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

  • De esta forma, el balanceador de carga valida el certificado de servidor SSL presentado por el backend externo y verifica que la siguiente información sea correcta:

    • El certificado está firmado por autoridades de certificación (CAs) conocidas.
    • El certificado no ha caducado.
    • La firma del certificado es válida.
    • El FQDN configurado coincide con uno de los nombres alternativos del sujeto (SANs) del certificado.

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

  • La extensión de indicador del nombre de servidor (SNI) de SSL solo se admite con los endpoints INTERNET_FQDN_PORT. El FQDN configurado se envía como SNI en el saludo del cliente durante la negociación de SSL entre el balanceador de carga y el endpoint externo. El SNI no se envía cuando se usa un endpoint INTERNET_IP_PORT porque no se permiten literales de direcciones IP en el campo HostName de una carga útil de SNI.

Comprobaciones del estado

La configuración de la comprobación de estado varía en función del tipo de balanceador de carga:

• Balanceador de carga de aplicaciones externo regional, balanceador de carga de aplicaciones interno regional, balanceador de carga de red con proxy externo regional y balanceador de carga de red con proxy interno regional. Las comprobaciones de estado son opcionales. Las exploraciones de comprobación del estado de estos balanceadores de carga proceden de la subred solo de proxy y se traducen mediante NAT (con Cloud NAT) a direcciones IP reservadas o a direcciones IP de NAT asignadas automáticamente. Para obtener más información, consulta NEGs regionales: usar una pasarela de Cloud NAT.

  Las comprobaciones de estado distribuidas de Envoy se crean mediante los mismos procesos de consola, CLI de gcloud y API que las comprobaciones de estado centralizadas.Trusted Cloud No es necesario realizar ninguna otra configuración.

  Aspectos que debe tener en cuenta:

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

  • Como el plano de datos de Envoy gestiona las comprobaciones de estado, no puedes usar la consola, la API ni la interfaz de línea de comandos de gcloud para comprobar el estado de estos endpoints externos.Trusted Cloud En el caso de los NEGs híbridos con balanceadores de carga basados en Envoy, la consola muestra el estado de la comprobación de estado como Trusted Cloud N/A. Este es el comportamiento esperado.

  • Cada proxy de Envoy asignado a la subred solo de proxy de la región de la red VPC inicia comprobaciones de estado de forma independiente. Por lo tanto, es posible que observes un aumento del tráfico de red debido a las comprobaciones de estado. El aumento depende del número de proxies de Envoy asignados a tu red de VPC en una región, la cantidad de tráfico que reciben estos proxies y el número de endpoints que cada proxy de Envoy debe comprobar. En el peor de los casos, el tráfico de red debido a las comprobaciones de estado aumenta a un ritmo cuadrático (O(n^2)).

  • Los registros de comprobación del estado de las comprobaciones del estado de Envoy distribuidas no incluyen estados de salud detallados. Para obtener más información sobre lo que se registra, consulta Registro de comprobaciones del estado. Para solucionar problemas de conectividad de los proxies de Envoy a los endpoints de tu NEG, también debes consultar los registros del balanceador de carga correspondiente.

    • Registro del balanceador de carga de aplicación externo regional
    • Registro del balanceador de carga de aplicación interno
    • Registro de balanceadores de carga de red de proxy

Habilita el backend externo para recibir solicitudes.

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

NEGs regionales: usa una pasarela de Cloud NAT

Si usas un NEG de Internet regional, primero debes configurar una pasarela de Cloud NAT para asignar un conjunto de intervalos de direcciones IP desde los que se debe originar el tráfico Trusted Cloud .

El endpoint de la pasarela debe ser de tipo ENDPOINT_TYPE_MANAGED_PROXY_LB.

La pasarela Cloud NAT se puede configurar para asignar automáticamente direcciones IP externas en función de la demanda o para usar un conjunto de direcciones IP externas reservadas manualmente.

• Direcciones IP asignadas automáticamente

  Usa direcciones IP asignadas automáticamente si tu entorno de backend externo no requiere que añadas a una lista de permitidos direcciones IP específicas que puedan enviar tráfico al backend externo. Trusted Cloud

• Direcciones IP asignadas manualmente

  Utiliza direcciones IP asignadas manualmente solo si tu entorno de backend externo requiere que añadas direcciones IP específicas a una lista de permitidos. Trusted Cloud Como cada Envoy asignado a tu subred proxy consume una dirección IP completa, asegúrate de que el conjunto de direcciones IP reservadas sea lo suficientemente grande como para alojar a todos los Envoys.

  Si tienes problemas de conectividad a gran escala, comprueba si has alcanzado los límites de Cloud NAT. De forma predeterminada, puedes asignar manualmente hasta 50 direcciones IP de NAT por pasarela.

La asignación dinámica de puertos se admite en los NEGs de Internet regionales. Las direcciones IP pueden compartirse mediante proxies, por lo que se aprovechan al máximo.

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

El uso de Cloud NAT genera cargos tanto por el tráfico de los usuarios como por el tráfico de comprobación de estado. Para obtener información sobre cómo funcionan los precios de los NEGs de Internet regionales, consulta la página Precios de los NEGs de Internet regionales.

Las pasarelas NAT configuradas en subredes solo proxy tienen ciertas limitaciones:

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

Autenticar solicitudes al backend externo

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

Para autenticar las solicitudes enviadas a tu backend externo, puedes hacer lo siguiente:

• Define un encabezado personalizado para indicar que la solicitud procede de un balanceador de carga Trusted Cloud mediante un encabezado de solicitud personalizado. Por ejemplo, puedes usar 16 o más bytes criptográficamente aleatorios como clave compartida.

  La implementación de transformaciones de encabezados personalizados depende del tipo de balanceador de carga que utilices:

  • Balanceador de carga de aplicación externo regional y balanceador de carga de aplicación interno regional. Las transformaciones de encabezados personalizados solo se pueden configurar en el mapa de URLs.

    En estos balanceadores de carga basados en Envoy, Host y authority son palabras clave especiales reservadas por Trusted Cloud. No puedes modificar estos encabezados en estos balanceadores de carga. En su lugar, le recomendamos que cree otros encabezados personalizados (por ejemplo, MyHost) para no interferir con los nombres de encabezado reservados.

• Habilita las compras en la aplicación y verifica que el JWT firmado en el encabezado de la solicitud esté firmado por Google y que la reclamación aud (audiencia) contenga el número de proyecto en el que se define tu balanceador de carga.

Registros

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

Para obtener más información, consulta las siguientes secciones:

• Registro del balanceador de carga de aplicación externo regional
• Registro del balanceador de carga de aplicación interno regional
• Registro de balanceadores de carga de red de proxy

Limitaciones

• Consulta la sección de servicios de backend para ver las limitaciones asociadas a la configuración de NEGs de Internet como backends.
• Cuando modificas un balanceador de carga para cambiar el backend de un NEG de Internet a cualquier otro tipo de backend, o bien para cambiar el backend de cualquier otro tipo de backend a un NEG de Internet, tu aplicación experimenta un tiempo de inactividad temporal de entre 30 y 90 segundos.

• Consulta la sección Pasarela de Cloud NAT para ver las limitaciones asociadas a las pasarelas NAT configuradas en subredes solo proxy.

Cuotas y límites

Para obtener información sobre las cuotas y los límites, consulta la tabla de cuotas de back-ends de NEG y la tabla de cuotas de endpoints por NEG.

Precios

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

Si has configurado una pasarela de Cloud NAT para asignar la subred de solo proxy de tu balanceador de carga regional basado en Envoy, se te cobrarán cargos de Cloud NAT. Las pasarelas de Cloud NAT asignadas para balanceadores de carga conllevan cargos por hora equivalentes a los de una red con más de 32 instancias de máquina virtual. Consulta más información en la página de precios de Cloud NAT.

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

Siguientes pasos

• Configurar un balanceador de carga de aplicación externo regional con un NEG de Internet
• Configurar un balanceador de carga de red de proxy externo regional con un NEG de Internet