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

Cloud Load Balancing admite tráfico mediante proxy a backends externos fuera de Google Cloud. 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 de Google 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.
• Con los balanceadores de cargas globales, puedes usar Cloud CDN para almacenar en caché el contenido de tu backend externo.

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

Figura 1. Grupos de extremos de red de Internet en el balanceo de cargas (haz clic para agrandar).

Los backends de NEG de Internet son compatibles con varios balanceadores de cargas regionales y globales. Según el balanceador de cargas (global o regional), la compatibilidad con los NEG de Internet difiere en relación con el DNS, la verificación de estado, la cantidad disponible de extremos y los comportamientos de enrutamiento de tráfico.

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.

Nota: Cloud Load Balancing también admite la conexión a backends locales o en otros entornos de nube fuera de Google Cloud mediante NEGs híbridos. Sin embargo, las conexiones a los extremos de NEGs híbridos usan la conectividad híbrida. En cambio, las conexiones a los extremos de NEG de Internet usan Internet y, al mismo tiempo, mantienen tu tráfico en la red troncal de alto rendimiento de Google durante la mayor distancia posible para reducir la latencia y mejorar la capacidad de procesamiento.

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 Google Cloud y se puede acceder a él a través de Internet. El extremo en un NEG de Internet.
• origen personalizado: Igual que un backend externo. En CDN, origen es el término estándar de la industria para una instancia de backend que entrega contenido web.
• Grupo de extremos de red de Internet (NEG): el recurso de la API de Google Cloud 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 recursos de Google Cloud necesarios para configurar un balanceador de cargas con un backend externo.

Global externo

En la figura, se muestran los recursos de Google Cloud necesarios para configurar un balanceador de cargas de aplicaciones externo global con un backend externo.

Balanceador de cargas de aplicaciones externo global con backend externo (haz clic para ampliar).

Regional y externo

En la figura, se muestran los recursos de Google Cloud necesarios para configurar un balanceador de cargas de aplicaciones externo regional con un backend externo.

Un balanceador de cargas regional externo de aplicaciones con un backend externo (haz clic para ampliar).

Regional interno

En esta figura, se muestran los recursos de Google Cloud necesarios para configurar un balanceador de cargas de red de proxy interno regional con backend externo.

Un balanceador de cargas de aplicaciones regional interno con un backend externo (haz clic para ampliar).

En esta figura, se muestran los recursos de Google Cloud necesarios para configurar un balanceador de cargas de red de proxy interno regional con backend externo.

Balanceador de cargas de red de proxy interno regional con backend externo (haz clic para ampliar)

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 del balanceador de cargas correspondiente:

• 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: NEG de Internet global y NEG de Internet regional. Se diferencian en el alcance (global o regional) y el comportamiento. Se puede acceder al backend externo al que hace referencia un NEG de Internet global exclusivamente a través de Internet, no 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 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 extremo por NEG y un NEG de Internet por servicio de backend.

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

Balanceadores de cargas	Tipo de extremo	Definición de extremo	Alcance	Verificaciones de estado
Balanceador de cargas de aplicaciones externo global Balanceador de cargas de aplicaciones clásico	INTERNET_FQDN_PORT	Un nombre de dominio completamente calificado que se pueda resolver públicamente y un puerto opcional. Por ejemplo, backend.example.com:443^†. El nombre de dominio debe poder resolverse con la infraestructura de DNS público de Google. Solo se permite un extremo por NEG.	Global	No compatible
	INTERNET_IP_PORT	Una dirección IP enrutable de forma pública y un puerto opcional. Por ejemplo, 8.8.8.8:443^1. La dirección IP no puede ser RFC 1918. Solo se permite un extremo por NEG.

^† Si no especificas un puerto cuando agregas el extremo, se usa el puerto predeterminado del NEG. Si no especificaste un puerto predeterminado para la negociación, se usará el puerto conocido para tu protocolo de backend (80 para HTTP y 443 para HTTPS y HTTP/2).

Los NEG de Internet regionales se basan en proxies de Envoy administrados y puertas de enlace de Cloud NAT. Admiten varios extremos por NEG y varios NEG de Internet por servicio de backend. Las direcciones IP que se usan para el tráfico de salida a los clientes se pueden configurar con las puertas de enlace de Cloud NAT.

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 de 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^*. El proceso de resolución de nombres de dominio sigue el orden de resolución de nombres de Cloud DNS. 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 enrutable de forma pública y un puerto opcional. Por ejemplo, 8.8.8.8:443^2. La dirección IP no puede ser RFC 1918. Se permite un máximo de 256 extremos por NEG.

^* Con los NEGs de Internet regionales, debes especificar un puerto. Puedes especificar un puerto predeterminado cuando creas el NEG, o puedes especificar un puerto cada vez que agregas un extremo al NEG, o puedes hacer ambas acciones. Si no especificas un puerto cuando agregas un extremo, se usa el puerto predeterminado del NEG.

Resolución de DNS para extremos INTERNET_FQDN_PORT regionales

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 un 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 INTERNET_FQDN_PORT globales

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

• El balanceador de cargas usa un agente de resolución de DNS en una región de Google Cloud que está más cerca de su cliente en Internet. Si el registro DNS de tu extremo INTERNET_FQDN_PORT muestra direcciones IP diferentes según la ubicación del cliente, asegúrate de que el balanceador de cargas pueda acceder a cada una de esas direcciones IP.

• El balanceador de cargas intenta conectarse a la primera dirección IP en la respuesta DNS. Si no se puede acceder a esa dirección IP, el balanceador de cargas muestra una respuesta HTTP 502 (Bad Gateway). Esto es así incluso si están disponibles otras direcciones IP de la respuesta de DNS.

Para obtener más información sobre las ubicaciones y los rangos de IP que usa la infraestructura del agente de resolución de DNS de Google, consulta la documentación de DNS público de Google. Los nombres que el sistema de DNS público no puede resolver no se pueden usar como backends externos.

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

Los 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 el caso de Cloud DNS, el nombre de dominio debe ser uno de los siguientes:
  • Alojado en Cloud DNS
  • Debe poder resolverse con el reenvío de DNS desde Cloud DNS a un servidor DNS local.
  • Se puede resolver con el intercambio de tráfico de DNS si haces referencia a una zona de DNS privada en otra red de VPC.

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 de DNS. Puedes configurar políticas de reintento para forzar a Envoy a intentar conectarse a otra dirección IP si una falla.

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, configura 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 globales. Solo puedes agregar un backend de NEG de Internet a un servicio de backend.
  • NEGs regionales. Puedes agregar hasta 50 NEGs de Internet al mismo servicio de backend.

• Cantidad de extremos por NEG

  • NEGs globales. Puedes agregar solo un extremo a un NEG de Internet.

    Dado que solo se permite un extremo en cada NEG de Internet global, el balanceo de cargas no se realiza realmente. El balanceador de cargas funciona solo como frontend y actúa como proxy para el tráfico al backend externo especificado. Esto significa que no puedes usar ninguno de los modos de balanceo de cargas, como la tasa, la conexión o el uso.

  • 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 tráfico de balanceo de cargas 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 globales. El servicio de backend no puede hacer referencia a una verificación 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 esté encriptada y autenticada cuando transite 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 INTERNET_IP_PORT, no se realiza la validación del certificado del servidor SSL.

  • La extensión de indicación de nombre del servidor (SNI) de SSL solo es compatible 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 global y balanceador de cargas de aplicaciones clásico. Un servicio de backend con un NEG de Internet global no admite verificaciones de estado.

  Si tu backend externo se vuelve inaccesible o si el nombre de host configurado (FQDN) no se puede resolver, el balanceador de cargas muestra una respuesta HTTP 502 (Bad Gateway) a sus clientes.

• 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 de Google Cloud, gcloud CLI y la API que las verificaciones de estado centralizadas. 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 de Google 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 de Google Cloud muestra el estado de la verificación de estado como N/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 más problemas de conectividad de proxies de Envoy a tus extremos de NEG, también debes verificar 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 Google Cloud.

Este procedimiento depende del alcance del NEG: global o regional.

NEGs globales: incluye en la lista de anunciantes permitidos las direcciones IP de salida predeterminadas de Google

Si usas un NEG de Internet global, debes agregar los rangos de direcciones IP que Google usa para enviar solicitudes a backends externos a una lista de entidades permitidas. Para buscar las direcciones IP que se agregarán a una lista de entidades permitidas, consulta el registro TXT _cloud-eoips.googleusercontent.com de DNS con una herramienta como dig o nslookup.

Para ver un ejemplo, consulta Permite que el backend externo reciba tráfico de Google 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 el tráfico de Google Cloud debería origin.

Importante: La puerta de enlace NAT realiza una traducción uno a uno del rango de subred de solo proxy a las direcciones IP externas. Cada dirección IP externa asignada por NAT está disponible para un solo proxy de Envoy. Las direcciones IP de NAT no se comparten entre proxies. No se admite la asignación de puertos estáticos ni dinámicos.

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 dinámica si tu entorno de backend externo no requiere que incluyas direcciones IP específicas de Google Cloud en la lista de entidades permitidas que puedan enviar tráfico al backend externo.

• Direcciones IP asignadas de forma manual

  Usa direcciones IP asignadas de forma manual solo si el entorno de backend externo requiere que incluyas direcciones IP específicas de Google Cloud en la 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.

  Advertencia: Si aprovisionas menos direcciones IP de NAT que la cantidad de proxies de Envoy asignados, las solicitudes enviadas al NEG de Internet podrían generan errores HTTP 5xx. Para garantizar que se te informe cuando ocurra ese evento, configura una alerta para la métrica nat_allocation_failed. Comunícate con el equipo de asistencia si necesitas ayuda para calcular la cantidad de direcciones IP que se deben asignar a tu balanceador de cargas en una región específica.

  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.

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 de 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 uno a uno. No se admite el uso compartido de direcciones IP.
• El registro y la supervisión no son compatibles. Es decir, las marcas --enable-logging y --log-filter no son compatibles.
• No se admiten funciones relacionadas con los puertos, como la asignación de puertos estáticos y dinámicos, la configuración de puertos máximos y mínimos por VM, ni la asignación independiente de extremos. Cada proxy obtiene los 65,536 puertos.

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 de aplicaciones de Google Cloud mediante 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 global y balanceador de cargas de aplicaciones clásico. Las transformaciones de encabezados personalizados se pueden configurar en el servicio de backend o en el mapa de URL.

    Por ejemplo, puedes configurar el backend externo para que espere un valor particular para el encabezado Host de la solicitud HTTP y puedes configurar el servicio de backend para que establezca el encabezado Host en ese valor esperado. Si no configuras un encabezado de solicitud personalizado, el balanceador de backend conserva los encabezados que el cliente usó para conectarse al balanceador de cargas e incluye el mismo encabezado en su respuesta. Sin embargo, ten en cuenta que no se admite la modificación del encabezado Host en el mapa de URL.

    Existen limitaciones adicionales asociadas con la configuración del encabezado Host. Para obtener más información, consulta Crea encabezados personalizados en servicios de backend. Para ver un ejemplo específico, consulta Configura un balanceador de cargas de aplicaciones externo global con un backend externo.

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

  Ten en cuenta lo siguiente:

  • IAP no es compatible con Cloud CDN.
  • IAP no es compatible con balanceadores de cargas de aplicaciones regionales externos ni balanceadores de cargas de red de proxy (internos y externos).

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

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 y supervisión del balanceador de cargas de aplicaciones externo global y clásico

• 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

Si habilitas Cloud CDN para un balanceador de cargas de aplicaciones externo mediante un backend externo, también se registran los aciertos de caché.

Procesamiento del encabezado con backends externos

Los diferentes balanceadores de cargas pueden manejar el procesamiento de encabezados de diferentes maneras cuando envían solicitudes mediante proxy a un backend externo. Revisa la siguiente información para comprender cómo tu tipo de balanceador de cargas podría procesar encabezados HTTP.

Balanceadores de cargas de aplicaciones externos globales y balanceadores de cargas de aplicaciones clásicos

Cuando un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico envían solicitudes a un backend externo, ajusta los encabezados HTTP de las siguientes maneras:

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

• Los encabezados son correctos 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 preservar la compatibilidad con clientes HTTP/1.1. Por ejemplo, user-agent se cambia a User-Agent, y content-encoding se cambia a Content-Encoding.

  • Ciertos encabezados, como Accept-CH (sugerencias de cliente), se convierten para coincidir con la representación estándar de letras mixtas.

• Algunos encabezados se agregan o se les agregan valores. Los balanceadores de cargas de aplicaciones externos siempre agregan o modifican determinados encabezados como Via y X-Forwarded-For.

Balanceadores de cargas de aplicaciones externos regionales y balanceadores de cargas de aplicaciones internos regionales

No hay procesamiento especial de encabezados para balanceadores de cargas basados en Envoy mediante NEG de Internet. Para obtener información sobre cómo Envoy suele procesar los encabezados, consulta Manipulación de encabezados HTTP.

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. Por ejemplo, durante este tiempo de inactividad, los clientes que envían solicitudes a los balanceadores de cargas de aplicaciones externos globales ven errores 502 con el código de error failed_to_connect_to_backend. Se prevé que esto suceda.

• Las siguientes funciones avanzadas de administración de tráfico no son compatibles con los backends de NEG de Internet globales:
  • Solicita la duplicación
  • Políticas de reintento
  • Políticas de tráfico (incluida la política de localidad del balanceo de cargas, la afinidad de sesión y la detección de valores atípicos)

• 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 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 global con un NEG de Internet
• Configura un balanceador de cargas de aplicaciones clásico con un NEG de Internet
• Configura Cloud CDN para un balanceador de cargas de aplicaciones externo con un backend externo
• Descripción general de Cloud Service Mesh con grupos de extremos de red de Internet

• 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