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 Google Cloud. 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 Google 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.
• Con los balanceadores de carga globales, puedes usar Cloud CDN para almacenar en caché el contenido de tu backend externo.

En la figura 1 se muestra un balanceador de carga de aplicaciones externo con varios tipos de backend, uno de los cuales es un backend externo configurado con un NEG de Internet.

Los backends de NEG de Internet se admiten con varios balanceadores de carga globales y regionales. En función del balanceador de carga (global o regional), la compatibilidad con NEG de Internet varía en lo que respecta al DNS, la comprobación del estado, el número de endpoints disponibles y los comportamientos de enrutamiento del tráfico.

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 Google Cloud y al que se puede acceder a través de Internet. El punto final de un NEG de Internet.
• Origen personalizado: es igual que un backend externo. En las CDNs, el origen es el término estándar del sector para una instancia de backend que sirve contenido web.
• Grupo de puntos finales de red de Internet (NEG): el recurso de la API Google Cloud 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. Google 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 globales se basan en las tecnologías de Google Front End (GFE). Usan un conjunto fijo de direcciones IP fijas para el tráfico de salida a todos los clientes. Solo admiten un punto final por NEG y un NEG de Internet por servicio de backend.

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

Balanceadores de carga	Tipo de punto final	Definición de endpoint	Ámbito	Comprobaciones del estado
Balanceador de carga de aplicación externo global Balanceador de carga de aplicación clásico	INTERNET_FQDN_PORT	Un nombre de dominio completo que se pueda resolver públicamente y un puerto opcional. Por ejemplo: backend.example.com:443†. El nombre de dominio debe poder resolverse mediante la infraestructura de DNS público de Google. Solo se permite un endpoint por NEG.	Global	No compatible
	INTERNET_IP_PORT	Una dirección IP disponible públicamente y un puerto opcional. Por ejemplo, 8.8.8.8:4431. La dirección IP no puede ser una dirección RFC 1918. Solo se permite un endpoint por NEG.

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 proceso de resolución de nombres de dominio sigue el proceso de orden de resolución de nombres de 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 endpoints globales de INTERNET_FQDN_PORT

Cuando un endpoint INTERNET_FQDN_PORT apunta a un registro DNS que devuelve varias direcciones IP, la dirección IP se resuelve de la siguiente manera:

• El balanceador de carga usa un resolvedor de DNS en una región de Google Cloud que sea la más cercana a su cliente en Internet. Si el registro DNS de tu endpoint INTERNET_FQDN_PORT devuelve direcciones IP diferentes en función de la ubicación del cliente, asegúrate de que el balanceador de carga pueda acceder a cada una de esas direcciones IP.

• El balanceador de carga intenta conectarse a la primera dirección IP de la respuesta DNS. Si no se puede acceder a esa dirección IP, el balanceador de carga devuelve una respuesta HTTP 502 (Bad Gateway). Esto ocurre aunque haya otras direcciones IP disponibles en la respuesta DNS.

Para obtener más información sobre los intervalos de IP y las ubicaciones que utiliza la infraestructura de resolución de DNS de Google, consulta la documentación de Google Public DNS. Los nombres que no se pueden resolver mediante el sistema DNS público no se pueden usar como back-ends externos.

Resolución de direcciones IP para los endpoints regionales INTERNET_FQDN_PORT

Las NEGs de Internet regionales admiten la resolución de nombres de dominio mediante Cloud DNS y el DNS público de Google.

• Para la resolución de DNS público, Cloud DNS reenvía el tráfico a los servidores DNS públicos de Google.
• En Cloud DNS, el nombre de dominio debe ser uno de los siguientes:
  • Alojado en Cloud DNS
  • Se puede resolver mediante el reenvío de DNS de Cloud DNS a un servidor DNS local.
  • Se puede resolver mediante el emparejamiento de DNS si haces referencia a una zona DNS privada en otra red VPC.

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 globales. Solo puedes añadir un backend de NEG de Internet a un 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 globales. Solo puedes añadir un punto final a un NEG de Internet.

    Como solo se permite un punto de conexión en cada NEG de Internet global, no se realiza ningún balanceo de carga. El balanceador de carga solo actúa como frontend y proxy del tráfico al backend externo especificado. Esto significa que no puedes usar ninguno de los modos de balanceo de carga, como la tasa, la conexión o la utilización.

  • 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 globales. El servicio backend no puede hacer referencia a una comprobación de 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 aplicación externo global y balanceador de carga de aplicación clásico. Un servicio backend con un NEG de Internet global no admite comprobaciones de estado.

  Si no se puede acceder a tu backend externo o no se puede resolver el nombre de host configurado (FQDN), el balanceador de carga devuelve una respuesta HTTP 502 (Bad Gateway) a sus clientes.

• 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.Google 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.Google 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 Google 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 Google Cloud.

Este procedimiento depende del ámbito del NEG: global o regional.

NEGs globales: incluir en la lista de permitidas las direcciones IP de salida de Google predeterminadas

Si usas un NEG de Internet global, debes añadir a una lista de permitidos los intervalos de direcciones IP que usa Google para enviar solicitudes a back-ends externos. Para buscar las direcciones IP que se deben añadir a una lista de permitidas, consulta el registro _cloud-eoips.googleusercontent.com DNS TXT con una herramienta como dig o nslookup.

Por ejemplo, consulta Permitir que el backend externo reciba tráfico de Google 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 Google 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. Google 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. Google 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 Google 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 global y balanceador de carga de aplicación clásico. Las transformaciones de encabezados personalizados se pueden configurar en el servicio backend o en el mapa de URLs.

    Por ejemplo, puedes configurar el backend externo para que espere un valor concreto en el encabezado Host de la solicitud HTTP y puedes configurar el balanceador de carga para que asigne ese valor esperado al encabezado Host. Si no configuras un encabezado de solicitud personalizado, el balanceador de carga conservará los encabezados que el cliente haya usado para conectarse al balanceador de carga e incluirá el mismo encabezado en su respuesta. Sin embargo, ten en cuenta que no se puede modificar el encabezado Host en el mapa de URLs.

    Hay otras limitaciones asociadas a la configuración del encabezado Host. Para obtener más información, consulta Crear encabezados personalizados en servicios de backend. Para ver un ejemplo específico, consulta Configurar un balanceador de carga de aplicación externo global con un backend externo.

  • 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 Google 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.

  Ten en cuenta lo siguiente:

  • IAP no es compatible con Cloud CDN.
  • IAP no es compatible con los balanceadores de carga de red de proxy (internos y externos).

• Habilita la autenticación de origen privado, que proporciona a un balanceador de carga de aplicaciones externo acceso a largo plazo a un bucket privado de Amazon Simple Storage Service (Amazon S3) u otros almacenes de objetos compatibles. Cloud CDN (y, por lo tanto, la autenticación de origen privado) no es compatible con los balanceadores de carga de aplicaciones externos regionales ni con los balanceadores de carga de aplicaciones internos regionales.

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 y monitorización del balanceador de carga de aplicación externo global y del balanceador de carga de aplicación clásico

• 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

Si habilitas Cloud CDN en un balanceador de carga de aplicaciones externo que usa un backend externo, también se registran los aciertos de caché.

Procesamiento de encabezados con backends externos

Es posible que los distintos balanceadores de carga gestionen el procesamiento de encabezados de diferentes formas cuando proxyizan solicitudes a un backend externo. Consulta la siguiente información para saber cómo puede procesar los encabezados HTTP tu tipo de balanceador de carga.

Balanceadores de carga de aplicación externos globales y clásicos

Cuando un balanceador de carga de aplicación externo global o un balanceador de carga de aplicación clásico proxyiza solicitudes a un backend externo, ajusta los encabezados HTTP de las siguientes formas:

• Algunas cabeceras se han combinado. Cuando hay varias instancias de la misma clave de encabezado (por ejemplo, Via), el balanceador de carga combina sus valores en una sola lista separada por comas para una sola clave de encabezado. Solo se combinan los encabezados cuyos valores se pueden representar como una lista separada por comas. Otros encabezados, como Set-Cookie, nunca se combinan.

• Las cabeceras se escriben con la capitalización correcta cuando el protocolo del servicio de backend es HTTP o HTTPS:

  • La primera letra de la clave del encabezado y todas las letras que siguen a un guion (-) se escriben en mayúsculas para mantener la compatibilidad con los clientes HTTP/1.1. Por ejemplo, user-agent se cambia a User-Agent y content-encoding se cambia a Content-Encoding.

  • Algunas cabeceras, como Accept-CH (client hints), se convierten para que coincidan con la representación estándar de letras mixtas.

• Se añaden algunos encabezados o se les añaden valores. Los balanceadores de carga de aplicaciones externos siempre añaden o modifican determinados encabezados, como Via y X-Forwarded-For.

Balanceadores de carga de aplicación externos regionales y balanceadores de carga de aplicación internos regionales

No se aplica ningún procesamiento especial de encabezados a los balanceadores de carga basados en Envoy que usan NEGs de Internet. Para saber cómo procesa Envoy normalmente los encabezados, consulta Manipulación de encabezados HTTP.

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. Por ejemplo, durante este tiempo de inactividad, los clientes que envíen solicitudes a balanceadores de carga de aplicaciones externos globales verán errores 502 con el código de error failed_to_connect_to_backend. Es el comportamiento esperado.

• Las siguientes funciones avanzadas de gestión del tráfico no se admiten con back-ends de NEG de Internet globales:
  • Solicitar replicación
  • Políticas de reintentos
  • Políticas de tráfico (incluidas la política de localidad de balanceo de carga, la afinidad de sesión y la detección de valores atípicos)

• 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 global con un NEG de Internet
• Configurar un balanceador de carga de aplicación clásico con un NEG de Internet
• Configurar Cloud CDN para un balanceador de carga de aplicaciones externo con un backend externo
• Información general sobre Cloud Service Mesh con grupos de puntos de conexión de red de Internet

• 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