Descripción general del balanceador de cargas de aplicaciones externo

En este documento, se presentan los conceptos que necesitas para configurar un balanceador de cargas de aplicaciones externo.

Un balanceador de cargas de aplicaciones externo es un balanceador de cargas de capa 7 basado en proxies que te permite ejecutar y escalar tus servicios detrás de una sola dirección IP externa. El balanceador de cargas de aplicaciones externo distribuye el tráfico HTTP y HTTPS a los backends alojados en una variedad de plataformas de Google Cloud (como Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage, etcétera), así como backends externos conectados a través de Internet o a través de la conectividad híbrida. Para obtener más detalles, consulta Descripción general del balanceador de cargas de aplicaciones: casos de uso.

Modos de operación

Puedes configurar un balanceador de cargas de aplicaciones externo en los siguientes modos:

  • Balanceador de cargas de aplicaciones externo global Este es un balanceador de cargas global que se implementa como un servicio administrado en Google Front End (GFE). Usa el proxy de Envoy de código abierto para admitir capacidades de administración de tráfico avanzadas, como la duplicación de tráfico, la división de tráfico basada en el peso, las transformaciones de encabezados de solicitud o respuesta y mucho más.
  • Balanceador de cargas de aplicaciones clásico Este es el balanceador de cargas de aplicaciones externo clásico que es global en el nivel Premium, pero se puede configurar para que sea regional en el nivel Standard. Este balanceador de cargas se implementa en Google Front End (GFE). Los GFEs se distribuyen globalmente y operan juntos mediante el plano de control y la red global de Google.
  • Balanceador de cargas de aplicaciones externo regional Este es un balanceador de cargas regional se implementa como un servicio administrado en el proxy de código abierto de Envoy. Incluye capacidades avanzadas de administración de tráfico, como duplicación de tráfico, división de tráfico basada en pesos, transformaciones de encabezados basados en solicitudes y respuestas, y mucho más.
Modo de balanceador de cargas Casos de uso recomendados Funciones
Balanceador de cargas de aplicaciones externo global Usa este balanceador de cargas para cargas de trabajo de HTTP(S) externas con usuarios de todo el mundo o servicios de backend en varias regiones.
Balanceador de cargas de aplicaciones clásico

Este balanceador de cargas es global en el nivel Premium. En el nivel de servicio de red Premium, este balanceador de cargas ofrece balanceo de cargas multirregión, intenta dirigir el tráfico al backend en buen estado más cercano que tenga capacidad y termina el tráfico HTTP(S) lo más cerca posible de tus usuarios. Para obtener detalles sobre el proceso de distribución de solicitudes, consulta Distribución de tráfico.

En el nivel de servicio de red estándar, este balanceador de cargas puede distribuir el tráfico a los backends solo en una sola región.
  • Compatible con GKE a través de puerta de enlace (completamente organizado), Ingress (por completo organizado) o NEGs independientes (organización manual).
  • Compatible con Google Cloud Armor
  • Menos funciones de enrutamiento de tráfico
Consulta la página Funciones del balanceo de cargas para ver la lista completa de funciones.
Balanceador de cargas de aplicaciones externo regional

Este balanceador de cargas contiene muchas de las características del balanceador de cargas de aplicaciones clásico existente, junto con capacidades de administración avanzada del tráfico.

Usa este balanceador de cargas si deseas entregar contenido desde una sola ubicación geográfica (por ejemplo, para cumplir con las reglamentaciones de cumplimiento).

Este balanceador de cargas se puede configurar en el nivel Premium o Estándar.

 Para obtener una lista completa, consulta Funciones de balanceo de cargas.

Identifica el modo

Consola de Cloud

  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.

    Ir a Balanceo de cargas

  2. En la pestaña Balanceadores de cargas, se muestran el tipo, el protocolo y la región del balanceador de cargas. Si la región está en blanco, entonces el balanceador de cargas es global. En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.

Modo de balanceador de cargas >Tipo de balanceador de cargas Tipo de acceso Región
Balanceador de cargas de aplicaciones externo global Aplicación Externo
Balanceador de cargas de aplicaciones clásico Application(Classic) Externo
Balanceador de cargas de aplicaciones externo regional Aplicación Externo Especifica una región

gcloud

  1. Para determinar el modo de un balanceador de cargas, ejecuta el siguiente comando:
   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

En el resultado del comando, verifica el esquema de balanceo de cargas, la región y el nivel de red. En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.

Modo de balanceador de cargas Esquema de balanceo de cargas Regla de reenvío Nivel de red
Balanceador de cargas de aplicaciones externo global EXTERNAL_MANAGED Global Premium
Balanceador de cargas de aplicaciones clásico EXTERNO Global Estándar o Premium
Balanceador de cargas de aplicaciones externo regional EXTERNAL_MANAGED Especifica una región Estándar o Premium

Arquitectura

Los siguientes recursos son necesarios para implementar el balanceador de cargas de aplicaciones externo:

  • Solo para balanceadores de cargas de aplicaciones regionales externos, se usa una subred de solo proxy para enviar conexiones desde el balanceador de cargas a los backends.

  • Una regla de reenvío externo especifica una dirección IP externa, un puerto y un proxy HTTP(S) de destino global. Los clientes usan la dirección IP y el puerto para conectarse al balanceador de cargas.

  • Un proxy HTTP(S) de destino regional recibe una solicitud del cliente. El proxy HTTP(S) evalúa la solicitud mediante el mapa de URL para tomar decisiones de enrutamiento de tráfico. El proxy también puede autenticar las comunicaciones a través del uso de certificados SSL.

    • En el balanceo de cargas de HTTPS, el proxy HTTPS de destino usa certificados SSL para demostrar su identidad a los clientes. Un proxy HTTPS de destino admite hasta una cantidad determinada de certificados SSL.

  • El proxy HTTP(S) usa un mapa de URL regional para realizar una determinación de enrutamiento basada en atributos HTTP (como la ruta de la solicitud, las cookies o los encabezados). Según la decisión de enrutamiento, el proxy reenvía las solicitudes del cliente a servicios de backend o buckets específicos. El mapa de URL puede especificar acciones adicionales, como el envío de redireccionamientos a los clientes.

  • Un servicio de backend distribuye solicitudes a backends en buen estado. Los balanceadores de cargas de aplicaciones externos globales también admiten buckets de backend.

    • Uno o más backends deben estar conectados al servicio o al bucket de backend.

  • Una verificación de estado global supervisa de manera periódica la preparación de los backends. Esto reduce el riesgo de que las solicitudes se envíen a backends que no pueden procesar la solicitud.

  • Reglas de firewall para que tus backends acepten sondeos de verificaciones de estado. Los balanceadores de cargas de aplicaciones regionales externos requieren una regla de firewall adicional para permitir que el tráfico de la subred de solo proxy llegue a los backends.

Global

En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de aplicaciones externo global. Esta arquitectura se aplica al balanceador de cargas de aplicaciones externo global y al balanceador de cargas de aplicaciones clásico en el nivel Premium.

Componentes del balanceador de cargas de aplicaciones externo global.
Componentes del balanceador de cargas de aplicaciones externo global (haz clic para ampliar).

Regional

En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de aplicaciones externo regional.

Componentes del balanceador de cargas de aplicaciones externo regional.
Componentes del balanceador de cargas de aplicaciones regional externo (haz clic para ampliar).

Subred de solo proxy

Las subredes de solo proxy solo son necesarias para los balanceadores de cargas de aplicaciones externos regionales.

La subred de solo proxy proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas de aplicaciones externos regionales. La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas regionales basados en Envoy en la misma región y red de VPC comparten un grupo de proxies de Envoy de la misma subred de solo proxy. Además:

  • Las subredes de solo proxy se usan solo para los proxies de Envoy, no para tus backends.
  • Las VM de backend o los extremos de todos los balanceadores de cargas de aplicaciones externos regionales en una región y una red de VPC reciben conexiones desde la subred de solo proxy.
  • La dirección IP del balanceador de cargas de aplicaciones externo regional no se encuentra en la subred de solo proxy. La dirección IP del balanceador de cargas se define según su regla de reenvío administrada externa, que se describe a continuación.

Si creaste una subred de solo proxy con --purpose=INTERNAL_HTTPS_LOAD_BALANCER, deberás migrar el propósito de la subred a REGIONAL_MANAGED_PROXY antes de poder crear otro balanceador de cargas basado en Envoy en la misma región de la red de VPC.

Reglas de reenvío y direcciones IP

Las reglas de reenvío enrutan el tráfico por dirección IP, puerto y protocolo a una configuración de balanceo de cargas que consiste de un proxy de destino, una asignación de URL y uno o más servicios de backend.

Especificación de dirección IP. Cada regla de reenvío proporciona una única dirección IP que se puede usar en registros DNS para tu aplicación. No se requiere el balanceo de cargas basado en DNS. Puedes especificar una dirección IP para usarla o permitir que Cloud Load Balancing te asigne una.

Especificación de puerto Cada regla de reenvío para un balanceador de cargas de aplicaciones puede hacer referencia a un puerto único del 1 al 65535. Para admitir varios puertos, debes configurar varias reglas de reenvío. Puedes configurar varias reglas de reenvío para usar la misma dirección IP externa (VIP) y hacer referencia al mismo proxy HTTP(S) de destino siempre que la combinación general de la dirección IP, el puerto y el protocolo son únicos para cada regla de reenvío. De esta manera, puedes usar un solo balanceador de cargas con un mapa de URL compartido como proxy para varias aplicaciones.

El tipo de regla de reenvío, la dirección IP y el esquema de balanceo de cargas que usan los balanceadores de cargas de aplicaciones externos dependen del modo del balanceador de cargas y del nivel de servicio de red en el que se encuentre el balanceador de cargas.

Modo de balanceador de cargas Nivel de servicio de red Regla de reenvío, dirección IP y esquema de balanceo de cargas Enrutamiento de Internet al frontend del balanceador de cargas
Balanceador de cargas de aplicaciones externo global Nivel Premium

Regla de reenvío externa global

Dirección IP externa global

Esquema de balanceo de cargas:
EXTERNAL_MANAGED

 Solicitudes enrutadas al GFE más cercano al cliente en Internet.
Balanceador de cargas de aplicaciones clásico Nivel Premium

Regla de reenvío externa global

Dirección IP externa global

Esquema de balanceo de cargas:
EXTERNAL

 Solicitudes enrutadas al GFE más cercano al cliente en Internet.
Nivel Estándar

Regla de reenvío regional externa

Dirección IP regional externa

Esquema de balanceo de cargas:
EXTERNAL

 Solicitudes enrutadas a un GFE en la región del balanceador de cargas.
Balanceador de cargas de aplicaciones externo regional Nivel Premium o Estándar *

Regla de reenvío regional externa

Dirección IP regional externa

Esquema de balanceo de cargas:
EXTERNAL_MANAGED

 Solicitudes enrutadas a los proxies de Envoy en la misma región que el balanceador de cargas.
* No puedes usar la consola de Google Cloud para crear un balanceador de cargas de aplicaciones regional externo en el nivel Premium. Además, solo las regiones que admiten el nivel Estándar están disponibles para estos balanceadores de cargas en la consola de Google Cloud. En su lugar, usa gcloud o la API.

Para obtener una lista completa de los protocolos que admiten las reglas de reenvío del balanceador de cargas de aplicaciones externo en cada modo, consulta Funciones del balanceador de cargas.

Reglas de reenvío y redes de VPC

En esta sección, se describe cómo se asocian las reglas de reenvío que usan los balanceadores de cargas de aplicaciones externos con las redes de VPC.

Modo de balanceador de cargas Asociación de red de VPC
Balanceador de cargas de aplicaciones externo global,

Balanceador de cargas de aplicaciones clásico

No hay ninguna red de VPC asociada.

La regla de reenvío siempre usa una dirección IP que está fuera de la red de VPC. Por lo tanto, la regla de reenvío no tiene una red de VPC asociada.
Balanceador de cargas de aplicaciones externo regional

La red de VPC de la regla de reenvío es la red en la que se creó la subred de solo proxy. Debes especificar la red cuando creas la regla de reenvío.

Proxies de destino

Los proxies de destino finalizan las conexiones HTTP(S) de los clientes. Una o más reglas de reenvío dirigen el tráfico al proxy de destino y este consulta el mapa de URL para determinar cómo dirigir el tráfico a los backends.

No dependas del proxy para conservar las mayúsculas de los nombres de encabezado de solicitud o respuesta. Por ejemplo, es posible que un encabezado de respuesta Server: Apache/1.0 aparezca en el cliente como server: Apache/1.0.

En la siguiente tabla, se especifica el tipo de proxy de destino que requieren los balanceadores de cargas de aplicaciones externos en cada modo.

Modo de balanceador de cargas Tipos de proxy de destino Encabezados agregados por proxy Los Encabezados personalizados son compatibles Compatible con Cloud Trace
Balanceador de cargas de aplicaciones externo global HTTP global,
HTTPS global		 Los proxies configuran encabezados de solicitud o respuesta HTTP de la siguiente manera:
  • Via: 1.1 google (solicitudes y respuestas)
  • X-Forwarded-Proto: [http | https] (solo solicitudes)
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulta encabezado X-Forwarded-For) (solo solicitudes)

Los proxies también pueden establecer el encabezado X-Cloud-Trace-Context.

 Configurado en el servicio o bucket de backend

No compatible con Cloud CDN
Balanceador de cargas de aplicaciones clásico HTTP global,
HTTPS global		 Los proxies configuran encabezados de solicitud o respuesta HTTP de la siguiente manera:
  • Via: 1.1 google (solicitudes y respuestas)
  • X-Forwarded-Proto: [http | https] (solo solicitudes)
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulta encabezado X-Forwarded-For) (solo solicitudes)

Los proxies también pueden establecer el encabezado X-Cloud-Trace-Context.

 Configurado en el servicio o bucket de backend
Balanceador de cargas de aplicaciones externo regional HTTP regional,
HTTPS regional
  • X-Forwarded-Proto: [http | https] (solo solicitudes)
  • Via: 1.1 google (solicitudes y respuestas)
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulta encabezado X-Forwarded-For) (solo solicitudes)

Además de los encabezados que agrega el proxy de destino, el balanceador de cargas ajusta otros encabezados HTTP de las siguientes maneras:

  • Para el balanceador de cargas de aplicaciones externo global, los encabezados de respuesta y solicitud siempre se convierten en minúsculas. Por ejemplo, Host se convierte en host, y Keep-ALIVE se convierte en keep-alive.

    La única excepción es cuando usas backends de NEG de Internet globales con HTTP/1.1. Para obtener detalles sobre cómo se procesan los encabezados HTTP/1.1 con los NEG de Internet globales, consulta la descripción general de los NEG de Internet.

  • Para el balanceador de cargas de aplicaciones clásico, los encabezados de respuesta y solicitud se convierten en minúsculas, excepto cuando usas HTTP/1.1. Con HTTP/1.1, los encabezados están en mayúsculas y minúsculas. 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.

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

Encabezado del host

Cuando el balanceador de cargas realiza la solicitud HTTP, el balanceador de cargas conserva el encabezado del host de la solicitud original.

Encabezado X-Forwarded-For

El balanceador de cargas agrega dos direcciones IP separadas por una sola coma al encabezado X-Forwarded-For en el siguiente orden:

  • La dirección IP del cliente que se conecta al balanceador de cargas
  • La dirección IP de la regla de reenvío del balanceador de cargas

Si no hay un encabezado X-Forwarded-For en la solicitud entrante, estas dos direcciones IP son el valor completo del encabezado.

X-Forwarded-For: <client-ip>,<load-balancer-ip>

Si la solicitud incluye un encabezado X-Forwarded-For, el balanceador de cargas conserva el valor proporcionado antes de <client-ip>,<load-balancer-ip>:

X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>

Cuando ejecutas el software del proxy HTTP inverso en los backends del balanceador de cargas, el software puede adjuntar una o las siguientes dos direcciones IP al final del encabezado X-Forwarded-For:

  • La dirección IP del Google Front End (GFE) que se conectó al backend. Estas direcciones IP se encuentran en los rangos 130.211.0.0/22 y 35.191.0.0/16.

  • La dirección IP del sistema de backend en sí.

Por lo tanto, un proceso ascendente después del backend de tu balanceador de cargas podría recibir un encabezado X-Forwarded-For con el siguiente formato:

<existing-values>,<client-ip>,<load-balancer-ip><GFE-IP><backend-IP>

Mapas de URL

Las asignaciones de URL definen los patrones de coincidencia para el enrutamiento basado en URL de las solicitudes a los servicios de backend apropiados. Se define un servicio predeterminado para manejar cualquier solicitud que no coincida con una regla de coincidencia de ruta o una regla de host especificadas. En algunas situaciones, como en el ejemplo de balanceo de cargas multirregional, es posible que no definas ninguna regla de URL y solo te bases en el servicio predeterminado. Para el enrutamiento de solicitudes, el mapa de URL te permite dividir el tráfico a través del análisis de los componentes de URL para enviar solicitudes a diferentes conjuntos de backends.

Los mapas de URL que se usan con balanceadores de cargas de aplicaciones externos globales y el balanceador de cargas de aplicaciones externo regional admiten varias funciones avanzadas de administración de tráfico, como el direccionamiento de tráfico basado en encabezados, la división de tráfico según el peso y la duplicación de solicitudes. Para obtener más información, consulta lo siguiente:

En la siguiente tabla, se especifica el tipo de mapa de URL que requieren los balanceadores de cargas de aplicaciones externos en cada modo.

Modo de balanceador de cargas Tipo de mapa de URL
Balanceador de cargas de aplicaciones externo global Global
Balanceador de cargas de aplicaciones clásico Global (solo con un subconjunto de las funciones compatibles)
Balanceador de cargas de aplicaciones externo regional Regional

Certificados SSL

Los balanceadores de cargas de aplicaciones externos que usan proxies HTTPS de destino requieren claves privadas y certificados SSL como parte de la configuración del balanceador de cargas:

  • Google Cloud proporciona dos métodos de configuración para asignar claves privadas y certificados SSL a los proxies HTTPS de destino: los certificados SSL de Compute Engine y el Administrador de certificados. Para obtener una descripción de cada configuración, consulta Métodos de configuración de certificados en la descripción general de certificados SSL.

  • Google Cloud proporciona dos tipos de certificado: autoadministrados y administrados por Google. Para obtener una descripción de cada tipo, consulta Tipos de certificados en la descripción general de certificados SSL.

  • El tipo de balanceador de cargas de aplicaciones externo (global, regional o clásico) determina qué métodos de configuración y tipos de certificados son compatibles. Para obtener más información, consulta Certificados y balanceadores de cargas de Google Cloud en la descripción general de certificados SSL.

TLS mutua

Por lo general, con la comunicación HTTPS, la autenticación funciona solo de una manera: el cliente verifica la identidad del servidor. En las aplicaciones que requieren el balanceador de cargas para autenticar la identidad de los clientes que se conectan a él, tanto el balanceador de cargas de aplicaciones externo global como el balanceador de cargas de aplicaciones clásico admiten la TLS mutua (mTLS).

Con la mTLS, el balanceador de cargas solicita que el cliente envíe un certificado para autenticarse durante el protocolo de enlace de TLS con el balanceador de cargas. Puedes configurar un almacén de confianza que el balanceador de cargas use para validar la cadena de confianza del certificado de cliente.

Google Cloud usa el recurso TrustConfig en el Administrador de certificados para almacenar los certificados que el servidor usa para verificar el certificado que presenta el cliente. Si usas un balanceador de cargas de aplicaciones clásico en el nivel de servicio de red Premium o un balanceador de cargas de aplicaciones externo global, puedes usar el Administrador de certificados para aprovisionar y administrar tus certificados SSL o TrustConfig en varias instancias del balanceador de cargas a gran escala. Para obtener más información, consulta la descripción general del Administrador de certificados.

Para obtener más información sobre mTLS, consulta Autenticación TLS mutua.

Políticas de SSL

Las políticas de SSL especifican el conjunto de características de SSL que los balanceadores de cargas de Google Cloud usan cuando negocian SSL con los clientes.

De forma predeterminada, el balanceo de cargas HTTPS usa un conjunto de funciones de SSL que proporciona una buena seguridad y una amplia compatibilidad. Algunas aplicaciones requieren más control sobre los cifrados y las versiones de SSL que se usan para sus conexiones HTTPS o SSL. Puedes definir una política de SSL para especificar el conjunto de características de SSL que usará tu balanceador de cargas cuando negocies SSL con los clientes. Además, puedes aplicar esa política de SSL a tu proxy HTTPS de destino.

En la siguiente tabla, se especifica la compatibilidad de las políticas de SSL con los balanceadores de cargas en cada modo.

Modo de balanceador de cargas Políticas de SSL compatibles
Balanceador de cargas de aplicaciones externo global
Balanceador de cargas de aplicaciones clásico
Balanceador de cargas de aplicaciones externo regional

Servicios de backend y buckets 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 ver un ejemplo que muestra cómo configurar un balanceador de cargas con un servicio de backend y uno de Compute Engine, consulta Configura un balanceador de cargas de aplicaciones externo con un backend de Compute Engine.

Los buckets de backend dirigen el tráfico entrante a los buckets de Cloud Storage. Para ver un ejemplo que muestra cómo agregar un bucket a un balanceador de cargas de aplicaciones externo, consulta Configura un balanceador de cargas con buckets de backend.

En la siguiente tabla, se especifican los atributos de backend compatibles con los balanceadores de cargas de aplicaciones externos en cada modo.


Modo de balanceador de cargas 		Backends compatibles en un servicio de backend Compatible con buckets de backend Compatible con Google Cloud Armor Admite Cloud CDN# Compatible con IAP# Admite extensiones de servicio
Grupos de instancias NEG zonales NEG de Internet NEG sin servidores NEG híbridos NEGs de Private Service Connect
Balanceador de cargas de aplicaciones externo global ‡ †,‡
Balanceador de cargas de aplicaciones clásico *
Nivel premium
Balanceador de cargas de aplicaciones externo regional *

* Usa extremos de tipo GCE_VM_IP_PORT con GKE: Usa NEG zonales independientes o usa Ingress

†Usa extremos de tipo GCE_VM_IP_PORT con GKE: Usa NEG zonales independientes

‡ Solo es compatible con GKE Gateway Controller

# IAP y Cloud CDN no son compatibles entre sí. No se pueden habilitar en el mismo servicio de backend.

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

Backends y redes de VPC

Las restricciones sobre dónde se pueden ubicar los backends dependen del tipo de balanceador de cargas.

Las restricciones sobre dónde se pueden ubicar los backends dependen del tipo de balanceador de cargas.

Para el balanceador de cargas de aplicaciones externo global y el balanceador de cargas de aplicaciones clásico, todas las instancias de backend de los backends de grupos de instancias y todos los extremos de backend de los backends de NEG deben estar ubicados en el mismo proyecto. Sin embargo, un backend de grupo de instancias o un NEG pueden usar una red de VPC diferente en ese proyecto. No es necesario que las diferentes redes de VPC estén conectadas a través del intercambio de tráfico entre redes de VPC, ya que los GFEs se comunican de forma directa con los backends en sus respectivas redes de VPC.

Para el balanceador de cargas de aplicaciones externo regional, esto depende del tipo de backend.

  • Para los grupos de instancias, los NEGs zonales y los NEG de conectividad híbrida, todos los backends deben estar ubicados en el mismo proyecto y región que el servicio de backend. Sin embargo, un balanceador de cargas puede hacer referencia a un backend que usa una red de VPC diferente en el mismo proyecto que el servicio de backend (esta función está en versión preliminar). La conectividad entre la red de VPC del balanceador de cargas y la red de VPC del backend se puede configurar mediante el intercambio de tráfico entre redes de VPC, túneles de Cloud VPN, adjuntos de VLAN de Cloud Interconnect o un framework de Network Connectivity Center.

    Definición de la red de backend

    • En el caso de los NEGs zonales y los híbridos, debes especificar de forma explícita la red de VPC cuando creas el NEG.
    • Para los grupos de instancias administrados, la red de VPC se define en la plantilla de instancias.
    • En los grupos de instancias no administrados, la red de VPC del grupo de instancias se configura para que coincida con la red de VPC de la interfaz nic0 de la primera VM que se agrega al grupo de instancias.

    Requisitos de red de backend

    La red de tu backend debe cumplir con uno de los siguientes requisitos de red:

    • La red de VPC del backend debe coincidir con exactitud con la red de VPC de la regla de reenvío.

    • La red de VPC del backend debe estar conectada a la red de VPC de la regla de reenvío mediante el intercambio de tráfico entre redes de VPC. Debes configurar los intercambios de rutas de subred para permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos de backend.

    • La red de VPC del backend y la de la regla de reenvío deben ser radios de VPC en el mismo concentrador de Network Connectivity Center. Los filtros de importación y exportación deben permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos de backend.
    • Para todos los demás tipos de backend, todos los backends deben estar ubicados en la misma región y red de VPC.

Interfaces de red y backends

Si usas backends de grupos de instancias, los paquetes siempre se entregan a nic0. Si quieres enviar paquetes a diferentes NICs, usa backends de NEG en su lugar.

Si usas backends de NEG zonales, los paquetes se envían a cualquier interfaz de red que represente el extremo en el NEG. Los extremos de NEG deben estar en la misma red de VPC que la red de VPC definida de forma explícita del NEG.

Protocolo para los backends

Cuando configuras un servicio de backend para el balanceador de cargas, configuras el protocolo que usa el servicio de backend a fin de comunicarse con estos. Puedes elegir entre HTTP, HTTPS o HTTP/2. El balanceador de cargas usa solo el protocolo que especifiques. El balanceador de cargas no recurre a uno de los otros protocolos si no logra negociar una conexión al backend con el protocolo especificado.

Si usas HTTP/2, debes usar TLS. No se admite HTTP/2 sin encriptación.

Para obtener una lista completa de los protocolos admitidos, consulta Características del balanceo de cargas: protocolos del balanceador de cargas a los backends.

Compatible con WebSocket

Los balanceadores de cargas basados en HTTP(S) de Google Cloud admiten el protocolo WebSocket cuando se usa HTTP o HTTPS como el protocolo para el backend. El balanceador de cargas no necesita ninguna configuración para usar un proxy en las conexiones de WebSocket.

El protocolo de WebSocket proporciona un canal de comunicación dúplex completo entre los clientes y el balanceador de cargas. Para obtener más información, consulta RFC 6455.

El protocolo WebSocket funciona de la siguiente manera:

  1. El balanceador de cargas reconoce una solicitud Upgrade de WebSocket de un cliente HTTP(S). La solicitud contiene los encabezados Connection: Upgrade y Upgrade: websocket, seguidos de otros encabezados de solicitud relevantes relacionados con el WebSocket.
  2. El backend envía una respuesta Upgrade de WebSocket. La instancia de backend envía una respuesta 101 switching protocol con encabezados Connection: Upgrade, Upgrade: websocket y otros encabezados de respuesta relacionados con WebSocket.
  3. El balanceador de cargas usa proxies para el tráfico bidireccional mientras dure la conexión actual.

Si la instancia de backend muestra una respuesta de error con el código de respuesta 426 o 502, el balanceador de cargas cierra la conexión.

Los tiempos de espera de la conexión de WebSocket dependen del tipo de balanceador de cargas (global, regional o clásico). Para obtener más información, consulta Tiempo de espera del servicio de backend.

La afinidad de sesión para WebSockets funciona de la misma manera que en cualquier otra solicitud. Para obtener más información, consulta afinidad de sesión.

Usa gRPC con tus aplicaciones de Google Cloud

gRPC es un framework de código abierto para llamadas de procedimiento remoto. Se basa en el estándar HTTP/2. Los casos prácticos para gRPC incluyen lo siguiente:

  • Sistemas distribuidos altamente escalables y de baja latencia
  • Desarrollo de clientes móviles que se comuniquen con un servidor en la nube
  • Diseño de protocolos nuevos que deben ser precisos, independientes del lenguaje y eficientes
  • Diseño en capas para habilitar extensiones, autenticación y registros

Para usar gRPC con tus aplicaciones de Google Cloud, debes usar las solicitudes del proxy de extremo a extremo en HTTP/2. Para ello, haz lo siguiente:

  1. Configura un balanceador de cargas HTTPS.
  2. Habilita HTTP/2 como protocolo desde el balanceador de cargas hasta los backends.

El balanceador de cargas negocia HTTP/2 con los clientes como parte del protocolo de enlace SSL a través de la extensión ALPN TLS.

El balanceador de cargas aún puede negociar HTTPS con algunos clientes o aceptar solicitudes HTTP no seguras en un balanceador de cargas configurado para usar HTTP/2 entre las instancias de backend y el balanceador de cargas. El balanceador de cargas transforma esas solicitudes HTTP o HTTPS para representar las solicitudes a través de HTTP/2 en las instancias de backend.

Debes habilitar TLS en tus backends. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.

Si quieres configurar un balanceador de cargas de aplicaciones externo a través de HTTP/2 con Ingress de Google Kubernetes Engine o a través de gRPC y HTTP/2 con Ingress, consulta HTTP/2 para el balanceo de cargas con Ingress.

Para obtener información sobre cómo solucionar problemas con HTTP/2, consulta Soluciona problemas de los backends con HTTP/2.

Para obtener información sobre las limitaciones de HTTP/2, consulta Limitaciones de HTTP/2.

Verificaciones de estado

Cada servicio de backend especifica una verificación de estado que supervisa de manera periódica la preparación de los backends para recibir una conexión del balanceador de cargas. Esto reduce el riesgo de que las solicitudes se envíen a backends que no pueden procesar la solicitud. Las verificaciones de estado no verifican si la aplicación en sí funciona.

Para los sondeos de verificación de estado, debes crear una regla de firewall de permiso de entrada que permita que los sondeos lleguen a tus instancias de backend. Por lo general, los sondeos de verificación de estado se originan a partir del mecanismo centralizado de verificación de estado de Google.

Los balanceadores de cargas de aplicaciones externos regionales que usan backends de NEG híbridos son una excepción a esta regla, ya que sus verificaciones de estado se originan en la subred de solo proxy. Para obtener más información, consulta la descripción general de los NEG híbridos.

Protocolo de verificación de estado

Aunque no es obligatorio y no siempre es posible, se recomienda usar una verificación de estado cuyo protocolo coincida con el protocolo del servicio de backend. Por ejemplo, una verificación de estado HTTP/2 comprueba de forma más precisa la conectividad HTTP/2 con los backends. Por el contrario, los balanceadores de cargas de aplicaciones externos regionales que usan backends de NEG híbridos no admiten verificaciones de estado de gRPC. Para obtener la lista de protocolos de verificación de estado compatibles, consulta Funciones del balanceo de cargas.

En la siguiente tabla, se especifica el alcance de las verificaciones de estado que admiten los balanceadores de cargas de aplicaciones externos en cada modo.

Modo de balanceador de cargas Tipo de verificación de estado
Balanceador de cargas de aplicaciones externo global Global
Balanceador de cargas de aplicaciones clásico Global
Balanceador de cargas de aplicaciones externo regional Regional

Para obtener más información sobre las verificaciones de estado, consulta los siguientes vínculos:

Reglas de firewall

El balanceador de cargas requiere las siguientes reglas de firewall:

  • Para los balanceadores de cargas de aplicaciones externos globales, una regla de permiso de entrada que permite que el tráfico de Google Front End (GFE) llegue a tus backends.
    Para el balanceador de cargas de externo regional, una regla de permiso de entrada que permite que el tráfico de la subred de solo proxy llegue a tus backends.
  • Una regla de permiso de entrada que permita el tráfico de los rangos de sondeo de verificación de estado Para obtener más información sobre los sondeos de verificación de estado y por qué es necesario permitir el tráfico de ellos, consulta Sondea rangos de IP y reglas de firewall.

Las reglas de firewall se implementan a nivel de la instancia de VM, no en los proxies de GFE. No puedes usar las reglas de firewall de Google Cloud para evitar que el tráfico llegue al balanceador de cargas. Para el balanceador de cargas de aplicaciones externo global y el balanceador de cargas de aplicaciones clásico, puedes usar Google Cloud Armor para lograrlo.

Los puertos de estas reglas de firewall deben configurarse de la siguiente manera:

  • Permite el tráfico al puerto de destino para cada verificación de estado del servicio de backend.

  • Para los backends de grupos de instancias: determina los puertos que se configurarán a través de la asignación entre el puerto con nombre del servicio de backend y los números de puerto asociados con ese puerto con nombre en cada grupo de instancias. Los números pueden variar entre grupos de instancias asignados al mismo servicio de backend.

  • Para los backends de NEG GCE_VM_IP_PORT: permite el tráfico a los números de puerto de los extremos.

En la siguiente tabla, se resumen los rangos de direcciones IP de origen necesarios para las reglas de firewall:

Modo de balanceador de cargas Rangos de origen de la verificación de estado Rangos de origen de solicitud
Balanceador de cargas de aplicaciones externo global
  • 35.191.0.0/16
  • 130.211.0.0/22

Para el tráfico IPv6 a los backends:

  • 2600:2d00:1:b029::/64
 La fuente de tráfico del GFE depende del tipo de backend:
  • Grupos de instancias y NEG zonales (GCE_VM_IP_PORT):
    • 130.211.0.0/22
    • 35.191.0.0/16

    Para el tráfico IPv6 a los backends:

    • 2600:2d00:1:1::/64
  • NEG de conectividad híbrida (NON_GCP_PRIVATE_IP_PORT):
    • 130.211.0.0/22
    • 35.191.0.0/16
  • NEG de Internet (INTERNET_FQDN_PORT y INTERNET_IP_PORT):
    • 34.96.0.0/20
    • 34.127.192.0/18
  • NEG SERVERLESS y buckets de backend: la red de producción de Google controla el enrutamiento de paquetes.
Balanceador de cargas de aplicaciones clásico
  • 35.191.0.0/16
  • 130.211.0.0/22
 La fuente de tráfico del GFE depende del tipo de backend:
  • Grupos de instancias, NEG zonales (GCE_VM_IP_PORT) y NEG de conectividad híbrida (NON_GCP_PRIVATE_IP_PORT):
    • 35.191.0.0/16
    • 130.211.0.0/22
  • NEG de Internet (INTERNET_FQDN_PORT y INTERNET_IP_PORT):
    • 34.96.0.0/20
    • 34.127.192.0/18
  • NEG SERVERLESS y buckets de backend: la red de producción de Google controla el enrutamiento de paquetes.
Balanceador de cargas de aplicaciones externo regional
  • 35.191.0.0/16
  • 130.211.0.0/22

Para el tráfico IPv6 a los backends:

  • 2600:2d00:1:b029::/64
No se requiere incluir en la lista de entidades permitidas los rangos de sondeo de verificación de estado de Google para los NEG híbridos. Sin embargo, si usas una combinación de NEG híbridos y zonales en un solo servicio de backend, debes incluir en la lista de anunciantes permitidos los rangos de sondeo de verificación de estado de Google para los NEG zonales. 		La subred de solo proxy que configuras.

Arquitectura de VPC compartida

Los balanceadores de cargas de aplicaciones externos admiten redes que usan VPC compartida. Con la VPC compartida, las organizaciones pueden conectar recursos de varios proyectos a una red de VPC común para que puedan comunicarse entre ellas de forma segura y eficiente a través de las IP internas de esa red. Si aún no estás familiarizado con la VPC compartida, lee la Documentación de la descripción general de la VPC compartida.

Hay muchas formas de configurar un balanceador de cargas de aplicaciones externo dentro de una red de VPC compartida. Sin importar el tipo de implementación, todos los componentes del balanceador de cargas deben estar en la misma organización.

Balanceador de cargas Componentes de frontend Componentes de backend
Balanceador de cargas de aplicaciones externo global

Si usas una red de VPC compartida para tus backends, crea la red requerida en el proyecto host de VPC compartida.

La dirección IP externa regional, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URL asociado deben definirse en el mismo proyecto. Este proyecto puede ser un proyecto host o un proyecto de servicio.

 Puedes realizar una de las siguientes acciones:
  • Crea servicios de backend y backends (grupos de instancias, NEG sin servidores o cualquier otro tipo de backend compatible) en el mismo proyecto de servicio que los componentes del frontend.
  • Crea servicios y backends de backend (grupos de instancias, NEG sin servidores o cualquier otro tipo de backend compatible) en proyectos de servicio. Un solo mapa de URL puede hacer referencia a servicios de backend en diferentes proyectos. Este tipo de implementación se conoce como referencia de servicio entre proyectos.

Cada servicio de backend debe definirse en el mismo proyecto que los backends a los que hace referencia. Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend.

Los backends pueden ser parte de una red de VPC compartida desde el proyecto host o una red de VPC independiente, es decir, una red de VPC no compartida en el proyecto de servicio.
Balanceador de cargas de aplicaciones clásico La dirección IP externa global, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URL asociado deben definirse en el mismo proyecto de servicio o host que los backends. Se debe definir un servicio de backend global en el mismo proyecto de servicio o host que los backends (grupos de instancias o NEG). Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend.
Balanceador de cargas de aplicaciones externo regional

Crea la red y la subred de solo proxy necesarias en el proyecto host de la VPC compartida.

La dirección IP externa regional, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URL asociado deben definirse en el mismo proyecto. Este proyecto puede ser un proyecto host o un proyecto de servicio.

 Puedes realizar una de las siguientes acciones:
  • Crea servicios de backend y backends (grupos de instancias, NEG sin servidores o cualquier otro tipo de backend compatible) en el mismo proyecto de servicio que los componentes del frontend.
  • Crea servicios de backends y backends (grupos de instancias, NEG sin servidores o cualquier otro tipo de backend compatible) en tantos proyectos de servicio como sea necesario. Un solo mapa de URL puede hacer referencia a servicios de backend en diferentes proyectos. Este tipo de implementación se conoce como referencia de servicio entre proyectos.

Cada servicio de backend debe definirse en el mismo proyecto que los backends a los que hace referencia. Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend.

Si bien puedes crear todos los componentes y backends del balanceo de cargas en el proyecto host de la VPC compartida, este tipo de implementación no separa las responsabilidades de administración de red y de desarrollo de servicios.

Todos los componentes y backends del balanceador de cargas en un proyecto de servicio

En el siguiente diagrama de arquitectura, se muestra una implementación de VPC compartida estándar en la que todos los componentes y backends del balanceador de cargas se encuentran en un proyecto de servicio. Este tipo de implementación es compatible con todos los balanceadores de cargas de aplicaciones.

Los componentes del balanceador de cargas y los backends deben usar la misma red de VPC.

Balanceador de cargas de aplicaciones externo regional en la red de VPC compartida
Balanceador de cargas de aplicaciones externo regional en la red de VPC compartida

Backends sin servidores en un entorno de VPC compartida

Para un balanceador de cargas que usa un backend de NEG sin servidores, el servicio de backend de Cloud Run o funciones de Cloud Run debe estar en el mismo proyecto que el NEG sin servidores.

Además, para el balanceador de cargas de aplicaciones externo regional que admite referencias de servicio entre proyectos, el servicio de backend, el NEG sin servidores y el servicio de Cloud Run siempre deben estar en el mismo proyecto de servicio.

Referencia del servicio entre proyectos

En este modelo, el frontend y el mapa de URL del balanceador de cargas se encuentran en un proyecto host o de servicio. Los servicios de backend y los backends del balanceador de cargas se pueden distribuir en todos los proyectos del entorno de VPC compartida. Se puede hacer referencia a los servicios de backend entre proyectos en un solo mapa de URL. Esto se conoce como referencia a servicios entre proyectos.

La referencia a servicios entre proyectos permite a las organizaciones configurar un balanceador de cargas central y enrutar el tráfico a cientos de servicios distribuidos en varios proyectos diferentes. Puedes administrar de forma centralizada todas las reglas y las políticas de enrutamiento de tráfico en un mapa de URL. También puedes asociar el balanceador de cargas con un solo conjunto de nombres de host y certificados SSL. Por lo tanto, puedes optimizar la cantidad de balanceadores de cargas necesarios para implementar tu aplicación y reducir la administración, los costos operativos y los requisitos de cuota.

Si tienes proyectos diferentes para cada uno de los equipos funcionales, también puedes lograr la separación de los roles dentro de la organización. Los propietarios del servicio pueden enfocarse en compilar servicios en proyectos de servicio, mientras que los equipos de red pueden aprovisionar y mantener balanceadores de cargas en otro proyecto, y ambos se pueden conectar a través de referencias de servicios entre proyectos.

Los propietarios del servicio pueden mantener la autonomía sobre la exposición de sus servicios y controlar qué usuarios pueden acceder a sus servicios a través de el balanceador de cargas. Esto se logra a través de un rol especial de IAM llamado rol de usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser).

Si deseas obtener información sobre cómo configurar la VPC compartida para un balanceador de cargas de aplicaciones externo regional, con y sin referencias de servicios entre proyectos, consulta Configura un balanceador de cargas de aplicaciones externo regional con VPC compartida.

Limitaciones conocidas con la referencia del servicio entre proyectos

  • La referencia del servicio entre proyectos se puede usar con grupos de instancias, NEG sin servidores y la mayoría de los demás tipos de backend compatibles. Sin embargo, se aplican las siguientes limitaciones:

    • Con los balanceadores de cargas de aplicaciones externos globales, no puedes hacer referencia a un servicio de backend entre proyectos si el servicio tiene los siguientes backends:

      • Buckets de backend
      • NEG sin servidores con App Engine
    • Con los balanceadores de cargas de aplicaciones externos regionales, no puedes hacer referencia a un servicio de backend entre proyectos si el servicio de backend tiene backends de NEG de Internet regionales.
  • La referencia del servicio entre proyectos no es compatible con el balanceador de cargas clásico de aplicaciones.
  • Google Cloud no distingue entre recursos (por ejemplo, servicios de backend) que usan el mismo nombre en varios proyectos. Por lo tanto, cuando usas la referencia de servicios entre proyectos, te recomendamos que uses nombres de servicio de backend únicos en todos los proyectos de tu organización.

Ejemplo 1: frontend y backend del balanceador de cargas en diferentes proyectos de servicio

Este es un ejemplo de una implementación en la que se crean el frontend y el mapa de URL del balanceador de cargas en el proyecto de servicio A, y el mapa de URL hace referencia a un servicio de backend en el proyecto de servicio B.

En este caso, los administradores de red o del balanceador de cargas en el proyecto de servicio A requerirán acceso a los servicios de backend en el proyecto de servicio B. Los administradores del proyecto de servicio B otorgan el rol de IAM compute.loadBalancerServiceUser a los administradores del balanceador de cargas en el proyecto de servicio A que desean hacer referencia al servicio de backend en el proyecto de servicio B.

Frontend y mapa de URL del balanceador de cargas en el proyecto de servicio
Frontend y backend del balanceador de cargas en diferentes proyectos de servicio

Ejemplo 2: frontend del balanceador de cargas en el proyecto host y backends en proyectos de servicio

En este tipo de implementación, el frontend y el mapa de URL del balanceador de cargas se crean en el proyecto host y los servicios de backend (y los backends) se crean en los proyectos de servicio.

En este caso, los administradores de red o del balanceador de cargas en el proyecto host requerirán acceso a los servicios de backend en el proyecto de servicio. Los administradores de proyectos de servicio otorgan el rol compute.loadBalancerServiceUser de IAM a los administradores del balanceador de cargas en el proyecto host A que desean hacer referencia al servicio de backend en el proyecto de servicio.

Frontend del balanceador de cargas y mapa de URL en el proyecto host
Frontend del balanceador de cargas y mapa de URL en el proyecto host

Cómo funcionan las conexiones

Conexiones del balanceador de cargas de aplicaciones externo global

Varios proxies llamados Google Front End (GFE) implementan los balanceadores de cargas de aplicaciones externos globales. No hay un solo proxy. En el nivel Premium, la misma dirección IP externa global se anuncia desde varios puntos de presencia y las solicitudes de los clientes se dirigen al GFE del cliente más cercano.

Según dónde se encuentren tus clientes, varios GFE pueden iniciar conexiones HTTP(S) con tus backends. Los paquetes enviados desde GFE tienen direcciones IP de origen del mismo rango que usan los verificadores de estado: 35.191.0.0/16 y 130.211.0.0/22.

Según la configuración del servicio de backend, el protocolo que usa cada GFE para conectarse a los backends puede ser HTTP, HTTPS o HTTP/2. Para las conexiones HTTP o HTTPS, la versión HTTP que se usa es HTTP 1.1.

El keepalive de HTTP está habilitado de forma predeterminada, como se indica en la especificación HTTP 1.1. Los keepalives de HTTP intentan usar la misma sesión de TCP de forma eficiente; sin embargo, no hay garantía. GFE usa un tiempo de espera de keepalive HTTP del cliente de 610 segundos y un valor de tiempo de espera de keepalive de backend predeterminado de 600 segundos. Puedes actualizar el tiempo de espera de keepalive HTTP del cliente, pero el valor del tiempo de espera de keepalive del backend es fijo. Puedes configurar el tiempo de espera de la solicitud o la respuesta a través de la configuración del tiempo de espera del servicio de backend. Aunque están muy relacionados, un tiempo de espera de keepalive de HTTP y uno de inactividad de TCP no son lo mismo. Para obtener más información, consulta Tiempos de espera y reintentos.

Para garantizar que el tráfico tenga balanceo de cargas de manera uniforme, el balanceador de cargas podría cerrar de forma correcta una conexión TCP a través del envío de un paquete FIN ACK después de completar una respuesta que incluya un encabezado Connection: close, o puede emitir un marco HTTP/2 GOAWAY después de completar una respuesta. Este comportamiento no interfiere en ninguna solicitud o respuesta activa.

La cantidad de conexiones HTTP y sesiones TCP varía según la cantidad de conexiones de GFE, la cantidad de clientes que se conectan a GFE, el protocolo a los backends y la ubicación de implementación de backends.

Para obtener más información, consulta Cómo funcionan los balanceadores de cargas de aplicaciones externos en la guía de soluciones: Optimizaciones de la capacidad de las aplicaciones con el balanceo de cargas global.

Conexiones del balanceador de cargas de aplicaciones externo regional

El balanceador de cargas de aplicaciones externo regional es un servicio administrado que se implementa en el proxy de Envoy. El balanceador de cargas de aplicaciones externo regional usa una subred compartida llamada subred de solo proxy para aprovisionar un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas basados en Envoy en una red y una región en particular comparten esta subred.

Los clientes usan la dirección IP y el puerto del balanceador de cargas para conectarse al balanceador de cargas. Las solicitudes del cliente se dirigen a la subred de solo proxy en la misma región que el cliente. El balanceador de cargas finaliza las solicitudes de los clientes y abre conexiones nuevas de la subred de solo proxy a tus backends. Por lo tanto, los paquetes enviados desde el balanceador de cargas tienen direcciones IP de origen de la subred de solo proxy.

Según la configuración del servicio de backend, el protocolo que usan los proxies de Envoy para conectarse a los backends puede ser HTTP, HTTPS o HTTP/2. Si es HTTP o HTTPS, la versión HTTP es HTTP 1.1. El keepalive de HTTP está habilitado de forma predeterminada, como se indica en la especificación HTTP 1.1. El proxy de Envoy establece el tiempo de espera de keepalive HTTP del cliente y el tiempo de espera de keepalive del backend en un valor predeterminado de 600 segundos cada uno. Puedes actualizar el tiempo de espera de keepalive HTTP del cliente, pero el valor del tiempo de espera de keepalive del backend es fijo. Puedes configurar el tiempo de espera de la solicitud o la respuesta a través de la configuración del tiempo de espera del servicio de backend. Para obtener más información, consulta Tiempos de espera y reintentos.

Comunicaciones del cliente con el balanceador de cargas

  • Los clientes se pueden comunicar con el balanceador de cargas a través de el protocolo HTTP 1.1 o HTTP/2.
  • Cuando se usa HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla en el cliente, no en el balanceador de cargas de HTTPS.
  • No puedes inhabilitar HTTP/2 aunque realices un cambio de configuración en el balanceador de cargas. Sin embargo, puedes configurar algunos clientes para usar HTTP 1.1 en lugar de HTTP/2. Por ejemplo, con curl, usa el parámetro --http1.1.
  • Los balanceadores de cargas de aplicaciones externos admiten la respuesta HTTP/1.1 100 Continue.

Para obtener una lista completa de los protocolos que admiten las reglas de reenvío del balanceador de cargas de aplicaciones externo en cada modo, consulta Funciones del balanceador de cargas.

Direcciones IP de origen para paquetes de clientes

La dirección IP de origen de los paquetes, como la ven los backends, no es la dirección IP externa de Google Cloud del balanceador de cargas. En otras palabras, existen dos conexiones TCP.

Para los balanceadores de cargas de aplicaciones externos globales:

  • Sesión 1, que abarca desde el cliente original hasta el balanceador de cargas (GFE):

    • Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente usa NAT o un proxy de reenvío).
    • Dirección IP de destino: Es la dirección IP del balanceador de cargas.

  • Conexión 2, desde el balanceador de cargas (GFE) hasta el extremo o la VM de backend:

    • Dirección IP de origen: Es una dirección IP en uno de los rangos especificados en Reglas de firewall.

    • Dirección IP de destino: La dirección IP interna del contenedor o la VM de backend en la red de VPC.

Para los balanceadores de cargas de aplicaciones externos regionales:

  • Conexión 1, desde el cliente original hasta el balanceador de cargas (subred de solo proxy):

    • Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente usa NAT o un proxy de reenvío).
    • Dirección IP de destino: Es la dirección IP del balanceador de cargas.

  • Conexión 2, desde el balanceador de cargas (subred de solo proxy) hasta la VM o el extremo de backend:

    • Dirección IP de origen: Una dirección IP en la subred de solo proxy que se comparte entre todos los balanceadores de cargas basados en Envoy implementados en la misma región y la red como el balanceador de cargas.

    • Dirección IP de destino: La dirección IP interna del contenedor o la VM de backend en la red de VPC.

Rutas de acceso de enrutamiento especiales

Google Cloud usa rutas especiales no definidas en tu red de VPC para enrutar paquetes para los siguientes tipos de tráfico:

Google Cloud usa rutas de subred en subredes de solo proxy para enrutar paquetes para los siguientes tipos de tráfico:

  • Cuando se usan verificaciones de estado distribuidas de Envoy

Para los balanceadores de cargas de aplicaciones externos regionales, Google Cloud usa proxies de Envoy de código abierto para finalizar las solicitudes de los clientes al balanceador de cargas. El balanceador de cargas finaliza la sesión TCP y abre una nueva sesión TCP desde la subred de solo proxy de la región a tu backend. Las rutas definidas dentro de la red de VPC facilitan la comunicación de los proxies de Envoy a los backends y de los backends a los proxies de Envoy.

Puertos abiertos

Los GFE tienen varios puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Cuando ejecutas un análisis de puerto, es posible que veas otros puertos abiertos para otros servicios de Google que se ejecutan en GFE.

Los balanceadores de cargas basados en GFE, los balanceadores de cargas de aplicaciones externos globales y los balanceadores de cargas de aplicaciones clásicos, siempre muestran los puertos 80 y 443 como abiertos (junto con cualquier otro puerto que hayas configurado en las reglas de reenvío de tu balanceador de cargas). Sin embargo, si no configuraste una regla de reenvío para el puerto 80 o el puerto 443, se rechazan las conexiones enviadas a esos puertos. Por el contrario, los balanceadores de cargas de aplicaciones externos regionales se implementan mediante proxies de Envoy y no muestran puertos adicionales abiertos durante un análisis.

Ejecutar un análisis de puerto en la dirección IP de un balanceador de cargas basado en GFE no es útil desde la perspectiva de la auditoría por los siguientes motivos:

  • Por lo general, un análisis de puerto (por ejemplo, con nmap) no espera ningún paquete de respuesta o un paquete RST de TCP cuando realiza sondeos de TCP SYN. Los GFE enviarán paquetes SYN-ACK en respuesta a los sondeos de SYN solo para los puertos en los que configuraste una regla de reenvío. Los GFE solo envían paquetes a tus backends en respuesta a los paquetes enviados a la dirección IP del balanceador de cargas y al puerto de destino configurado en su regla de reenvío. Los paquetes que se envían a una dirección IP o un puerto diferentes no se envían a los backends.

    Los GFE implementan funciones de seguridad como Google Cloud Armor. Con Google Cloud Armor Standard, los GFE proporcionan protección siempre encendida contra ataques de DSD volumétricos basados en protocolos y desbordamientos SYN. Esta protección está disponible incluso si no configuraste Google Cloud Armor de forma explícita. Solo se te cobrará si configuras políticas de seguridad o si te inscribes en Managed Protection Plus.

  • Cualquier GFE en la flota de Google puede responder a los paquetes enviados a la dirección IP de tu balanceador de cargas. Sin embargo, el análisis de una combinación de direcciones IP del balanceador de cargas y del puerto de destino solo intercepta un solo GFE por conexión TCP. La dirección IP de tu balanceador de cargas no se asigna a un solo dispositivo o sistema. Por lo tanto, analizar la dirección IP de un balanceador de cargas basado en GFE no analiza todos los GFE de la flota de Google.

Con esto en mente, las siguientes son algunas formas más efectivas de auditar la seguridad de tus instancias de backend:

  • Un auditor de seguridad debe inspeccionar la configuración de reglas de reenvío para la configuración del balanceador de cargas. Las reglas de reenvío definen el puerto de destino para el que tu balanceador de cargas acepta paquetes y los reenvía a los backends. Para los balanceadores de cargas basados en GFE, cada regla de reenvío externo solo puede hacer referencia a un solo puerto TCP de destino. Para un balanceador de cargas con el puerto TCP 443, el puerto UDP 443 se usa cuando la conexión se actualiza a QUIC (HTTP/3).

  • Un auditor de seguridad debe inspeccionar la configuración de la regla de firewall aplicable a las VM de backend. Las reglas de firewall que configuras bloquean el tráfico desde los GFE hacia las VMs de backend, pero no bloquean el tráfico entrante a los GFE. Para conocer las prácticas recomendadas, consulta la sección de reglas de firewall.

finalización de TLS

En la siguiente tabla, se resume cómo los balanceadores de cargas de aplicaciones externos administran la finalización de TLS en cada modo.

Modo de balanceador de cargas finalización de TLS
Balanceador de cargas de aplicaciones externo global La TLS se finaliza en un GFE, que puede estar en cualquier parte del mundo.
Balanceador de cargas de aplicaciones clásico La TLS se finaliza en un GFE, que puede estar en cualquier parte del mundo.
Balanceador de cargas de aplicaciones externo regional TLS finaliza en proxies de Envoy ubicados en una subred de solo proxy en una región elegida por el usuario. Usa este modo de balanceador de cargas si necesitas control geográfico sobre la región en la que se finaliza TLS.

Tiempos de espera y reintentos

Los balanceadores de cargas de aplicaciones externos admiten los siguientes tipos de tiempos de espera para el tráfico HTTP/HTTPS:

Tipo de tiempo de espera y descripción Valores predeterminados Admite valores personalizados
Global Clásica Regional
Tiempo de espera del servicio de backend1

Un tiempo de espera de solicitud y respuesta Representa el tiempo máximo que puede transcurrir desde que el balanceador de cargas envía el primer byte de la solicitud HTTP hasta el backend hasta que el backend devuelve el último byte de la respuesta HTTP. Si la respuesta HTTP completa no se devuelve al balanceador de cargas en el tiempo de espera de solicitud o respuesta, se descartan los datos de respuesta restantes.
  • Para los NEGs sin servidores en un servicio de backend: 60 minutos
  • Para todos los demás tipos de backend en un servicio de backend: 30 segundos
  • Para buckets de backend: 24 horas (86,400 segundos)
Tiempo de espera de keepalive del HTTP del cliente
La cantidad máxima de tiempo en que la conexión TCP entre un cliente y el proxy del balanceador de cargas puede estar inactivo. (Podría usarse la misma conexión TCP para varias solicitudes HTTP).
  • Para los balanceadores de cargas de aplicaciones externos globales y los clásicos, el proxy del balanceador de cargas es un GFE de primera capa.
  • Para los balanceadores de cargas de aplicaciones externos regionales, el proxy del balanceador de cargas es el software de Envoy.
  • Para un balanceador de cargas de aplicaciones externo global y un balanceador de cargas de aplicaciones clásico: 610 segundos
  • Para un balanceador de cargas de aplicaciones externo regional: 600 segundos
Tiempo de espera de keepalive del HTTP de backend
La cantidad máxima de tiempo en que la conexión TCP entre el proxy del balanceador de cargas y un backend puede estar inactivo. (Podría usarse la misma conexión TCP para varias solicitudes HTTP).
  • Para los balanceadores de cargas de aplicaciones externos globales y los clásicos, el proxy del balanceador de cargas es un GFE de segunda capa.
  • Para los balanceadores de cargas de aplicaciones externos regionales, el proxy del balanceador de cargas es el software de Envoy.
  • Para servicios de backend: 10 minutos (600 segundos)
  • Para buckets de backend: 6 minutos (360 segundos)
Tiempo de espera de inactividad de la sesión de QUIC
La cantidad máxima de tiempo que una sesión de QUIC puede estar inactiva entre el cliente (en sentido descendente) y el GFE de una balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico.

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

El tiempo de espera de inactividad de la sesión de QUIC es el mínimo del tiempo de espera de inactividad del cliente o el tiempo de espera de inactividad de GFE (300 segundos).

El tiempo de espera de inactividad de GFE se fija en 300 segundos. Se puede configurar el tiempo de espera de inactividad del cliente.

1No se puede configurar para backends de NEG sin servidores. No se puede configurar para buckets de backend.

Tiempo de espera del servicio de backend

El tiempo de espera del servicio de backend configurable representa la cantidad máxima de tiempo que el balanceador de cargas espera que el backend procese una solicitud HTTP y devuelva la respuesta HTTP correspondiente. Excepto por los NEG sin servidores, el valor predeterminado para el tiempo de espera del servicio de backend es de 30 segundos.

Por ejemplo, si quieres descargar un archivo de 500 MB y el valor del tiempo de espera del servicio de backend es de 90 segundos, el balanceador de cargas espera que el backend entregue todo el archivo de 500 MB en 90 segundos. Es posible configurar el tiempo de espera del servicio de backend para que no sea suficiente para que el backend envíe su respuesta HTTP completa. En esta situación, si el balanceador de cargas al menos recibió encabezados de respuesta HTTP, el balanceador de cargas devuelve los encabezados de respuesta completos y todo el cuerpo de respuesta que pudo obtener dentro del tiempo de espera del servicio de backend.

Debes establecer el tiempo de espera del servicio de backend en el tiempo más largo que esperas que tu backend necesite para procesar una respuesta HTTP. Debes aumentar el tiempo de espera del servicio de backend si el software que se ejecuta en el backend necesita más tiempo para procesar una solicitud HTTP y mostrar su respuesta completa. Por ejemplo, debes aumentar el tiempo de espera si ves respuestas HTTP 408 con jsonPayload.statusDetail client_timed_out.

El tiempo de espera del servicio de backend acepta valores entre 1 y 2,147,483,647 segundos; sin embargo, los valores más grandes no son opciones de configuración prácticas. Google Cloud tampoco garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el valor del tiempo de espera del servicio de backend. En el caso de los balanceadores de cargas de aplicaciones globales y clásicos, los GFE imponen un tiempo de espera máximo efectivo del servicio de backend de 86,400 segundos (1 día). Los sistemas cliente deben implementar la lógica de reintento en lugar de depender de una conexión TCP para estar abierta durante períodos prolongados.

Para configurar el tiempo de espera del servicio de backend, usa uno de los siguientes métodos:

  • Consola de Google Cloud: Modifica el campo Tiempo de espera del servicio de backend del balanceador de cargas.
  • Google Cloud CLI: Usa el comando gcloud compute backend-services update para modificar el parámetro --timeout del recurso de servicio de backend.
  • API: Para un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico, modifica el parámetro timeoutSec para el recurso backendServices global.
  • API: Para un balanceador de cargas de aplicaciones externo regional, modifica el parámetro timeoutSec para el recurso regionBackendServices.
Los tiempos de espera de la conexión de WebSocket no siempre son los mismos que los tiempos de espera del servicio de backend. Los tiempos de espera de conexión de WebSocket dependen del tipo de balanceador de cargas:

Modo de balanceador de cargas Valores predeterminados Descripción del tiempo de espera para websockets
Balanceador de cargas de aplicaciones externo global tiempo de espera del servicio de backend: 30 segundos

Las conexiones de WebSocket activas no usan el tiempo de espera del servicio de backend configurado del balanceador de cargas. Las conexiones se cierran de forma automática después de 24 horas (86,400 segundos). Este límite de 24 horas es fijo y anula el tiempo de espera del servicio de backend si es superior a 24 horas.

Las conexiones de WebSockets inactivas se cierran después de que se agota el tiempo de espera del servicio de backend.

No recomendamos valores de tiempo de espera del servicio de backend superiores a 24 horas (86,400 segundos), ya que Google Cloud reinicia los GFEs de forma periódica para las actualizaciones de software y otras tareas de mantenimiento de rutina. El valor de tiempo de espera del servicio de backend no retrasa las actividades de mantenimiento. Mientras más largo sea el valor de tiempo de espera del servicio de backend, más probable es que Google Cloud finalice las conexiones TCP para el mantenimiento.
Balanceador de cargas de aplicaciones clásico tiempo de espera del servicio de backend: 30 segundos

Las conexiones de WebSocket, ya sean inactivas o activas, se cierran de forma automática después de que se agota el tiempo de espera del servicio de backend.

No recomendamos valores de tiempo de espera del servicio de backend superiores a 24 horas (86,400 segundos), ya que Google Cloud reinicia los GFEs de forma periódica para las actualizaciones de software y otras tareas de mantenimiento de rutina. El valor de tiempo de espera del servicio de backend no retrasa las actividades de mantenimiento. Mientras más largo sea el valor de tiempo de espera del servicio de backend, más probable es que Google Cloud finalice las conexiones TCP para el mantenimiento.
Balanceador de cargas de aplicaciones externo regional tiempo de espera del servicio de backend: 30 segundos

Las conexiones de WebSocket activas no usan el tiempo de espera del servicio de backend del balanceador de cargas.

Las conexiones de WebSockets inactivas se cierran después de que se agota el tiempo de espera del servicio de backend.

Google Cloud reinicia o cambia la cantidad de tareas de software de Envoy de forma periódica. Mientras más largo sea el valor de tiempo de espera del servicio de backend, más probable es que las tareas de Envoy se reinicien o finalicen las conexiones TCP.

Los balanceadores de cargas de aplicaciones externos regionales usan el parámetro routeActions.timeout configurado de los mapas de URL y, además, ignoran el tiempo de espera del servicio de backend. Cuando routeActions.timeout no está configurado, se usa el valor del tiempo de espera del servicio de backend. Cuando se proporciona routeActions.timeout, se ignora el tiempo de espera del servicio de backend, y el valor de routeActions.timeout se usa como tiempo de espera de solicitud y respuesta.

Tiempo de espera de keepalive de HTTP del cliente

El tiempo de espera de keepalive de HTTP del cliente representa la cantidad máxima de tiempo que una conexión TCP puede estar inactiva entre el cliente (downstream) y uno de los siguientes tipos de proxies:

  • Para un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico: Google Front End de primera capa
  • Para un balanceador de cargas de aplicaciones externo regional: un proxy de Envoy

Un tiempo de espera de keepalive de HTTP representa el tiempo de espera de inactividad de TCP para las conexiones TCP subyacentes. El tiempo de espera de keepalive de HTTP del cliente no se aplica a websockets.

  • Para un balanceador de cargas de aplicaciones externo global, el valor predeterminado es 610 segundos. Puedes configurar el tiempo de espera de keepalive de HTTP del cliente con un valor entre 5 y 1,200 segundos.
  • En el caso de un balanceador de cargas de aplicaciones clásico, el tiempo de espera de keepalive de HTTP del cliente se fija en 610 segundos.
  • En el caso de un balanceador de cargas de aplicaciones externo regional, el tiempo de espera de keepalive de HTTP del cliente se fija en 600 segundos.

Para configurar el parámetro de tiempo de espera de keepalive, usa uno de los siguientes métodos:

El tiempo de espera de keepalive del cliente HTTP del balanceador de cargas debe ser mayor que el tiempo de espera de keepalive de HTTP (TCP inactivo) que usan los clientes o proxies descendentes. Si un cliente descendente tiene un tiempo de espera de keepalive de HTTP (TCP inactivo) mayor que el del cliente HTTP del balanceador de cargas, es posible que se produzca una condición de carrera. Desde la perspectiva de un cliente descendente, una conexión TCP establecida puede estar inactiva durante más tiempo del que permite el balanceador de cargas. Esto significa que el cliente descendente puede enviar paquetes después de que el balanceador de cargas considera que la conexión TCP está cerrada. Cuando eso sucede, el balanceador de cargas responde con un paquete de restablecimiento de TCP (RST).

Tiempo de espera de keepalive de HTTP del backend

Los balanceadores de cargas de aplicaciones externos son proxies que usan al menos dos conexiones TCP:

  • Para un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico, existe una primera conexión TCP entre el cliente (downstream) y un GFE de primera capa. Los GFE de la primera capa se conectan a los GFE de la segunda capa y, luego, los GFE de la segunda capa abren una segunda conexión TCP a tus backends.

  • Para un balanceador de cargas de aplicaciones externo regional, existe una primera conexión TCP entre el cliente (downstream) y un proxy de Envoy. Luego, el proxy de Envoy abre una segunda conexión TCP a tus backends.

Es posible que las conexiones TCP secundarias del balanceador de cargas no se cierren después de cada solicitud; pueden permanecer abiertos para manejar varias solicitudes y respuestas HTTP. El tiempo de espera del keepalive de HTTP de backend define el tiempo de espera de inactividad de TCP entre el balanceador de cargas y los backends. El tiempo de espera de keepalive de HTTP de backend no se aplica a websockets.

El tiempo de espera de keepalive del backend se fija en 10 minutos (600 segundos) y no se puede cambiar. El tiempo de espera del keepalive del backend del balanceador de cargas debe ser menor que el que usa el software que se ejecuta en los backends. Esto evita una condición de carrera en la que el sistema operativo de los backends puede cerrar las conexiones TCP con un restablecimiento TCP (RST). Debido a que no se puede configurar el tiempo de espera de keepalive del backend para el balanceador de cargas, debes configurar el software de backend para que el valor de tiempo de espera de keepalive de HTTP (TCP inactivo) sea superior a 600 segundos.

En la siguiente tabla, se enumeran los cambios necesarios para modificar los valores de tiempo de espera de keepalive para el software del servidor web común.

Software de servidor web Parámetro Parámetro de configuración predeterminado Configuración recomendada
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Tiempo de espera de inactividad de la sesión de QUIC

El tiempo de espera de inactividad de la sesión de QUIC representa la cantidad máxima de tiempo que una sesión de QUIC puede estar inactiva entre el cliente y el GFE de un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico.

El valor de tiempo de espera de inactividad de la sesión de QUIC se define como el mínimo del tiempo de espera de inactividad del cliente o el tiempo de espera de inactividad del GFE (300 segundos). El tiempo de espera de inactividad de GFE se fija en 300 segundos. Se puede configurar el tiempo de espera de inactividad del cliente.

Reintentos

La compatibilidad con la lógica de reintento depende del modo del balanceador de cargas de aplicaciones externo.

Modo de balanceador de cargas Lógica de reintento
Balanceador de cargas de aplicaciones externo global

Se puede configurar a través de una política de reintento en el mapa de URL. La cantidad predeterminada de reintentos (numRetries) es 1. La cantidad máxima de reintentos que se pueden configurar con la política de reintentos es de 25. El perTryTimeout máximo configurable es de 24 horas.

Sin una política de reintento, las solicitudes fallidas que no tienen cuerpo HTTP (por ejemplo, solicitudes GET) que dan como resultado respuestas HTTP 502, 503 o 504 (retryConditions=["gateway-error"]) se reintentan una vez.

Las solicitudes HTTP POST no se reintentan.

Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final.
Balanceador de cargas de aplicaciones clásico

No se puede cambiar la política de reintento para los reintentos de conexión.

Las solicitudes HTTP POST no se reintentan.

Las solicitudes HTTP GET siempre se reintentan una vez, siempre y cuando el 80% o más de los backends estén en buen estado. Si hay una sola instancia de backend en un grupo y falla la conexión, el porcentaje de instancias de backend en mal estado es del 100%, por lo que GFE no vuelve a intentar la solicitud.

El balanceador de cargas vuelve a intentar una solicitud GET con errores si la primera solicitud falló antes de recibir encabezados de respuesta de la instancia de backend.

Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final. Para obtener más información, consulta Registro y supervisión del balanceador de cargas de aplicaciones externo.

Las solicitudes que no se ejecutan de forma correcta dan como resultado que el balanceador de cargas sintetiza una respuesta HTTP 502.
Balanceador de cargas de aplicaciones externo regional

Se puede configurar a través de una política de reintento en el mapa de URL. La cantidad predeterminada de reintentos (numRetries) es 1. La cantidad máxima de reintentos que se pueden configurar con la política de reintentos es de 25. El perTryTimeout máximo configurable es de 24 horas.

Sin una política de reintento, las solicitudes fallidas que no tienen cuerpo HTTP (por ejemplo,GET solicitudes) que den como resultado respuestas HTTP 502, 503 o 504 se reintentan una vez.

Las solicitudes HTTP POST no se reintentan.

Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final.

El protocolo WebSocket es compatible con GKE Ingress.

Solicitud ilegal y manejo de respuestas

El balanceador de cargas impide que las solicitudes de cliente y las respuestas de backend lleguen al backend o al cliente, respectivamente, por varios motivos. Algunas razones son solo para el cumplimiento de HTTP/1.1 y otras para evitar que se pasen datos inesperados a los backends o desde ellos. No se puede inhabilitar ninguna de las verificaciones.

El balanceador de cargas bloquea las siguientes solicitudes para el cumplimiento de HTTP/1.1:

  • No se puede analizar la primera línea de la solicitud.
  • A un encabezado le falta el delimitador de dos punto :.
  • Los encabezados o la primera línea contienen caracteres no válidos.
  • La longitud del contenido no es un número válido o hay varios encabezados de longitud del contenido.
  • Hay varias claves de codificación de transferencia o hay valores de codificación de transferencia no reconocidos.
  • Hay un cuerpo no fragmentado y no se especifica la longitud del contenido.
  • Los fragmentos del cuerpo no se pueden analizar. Este es el único caso en el que algunos datos llegan al backend. El balanceador de cargas cierra las conexiones con el cliente y el backend cuando recibe un fragmento no analizable.

Cómo administrar solicitudes

El balanceador de cargas bloquea la solicitud si se cumple alguna de las siguientes condiciones:

Control de respuestas

El balanceador de cargas bloquea la respuesta del backend si se cumple alguna de las siguientes condiciones:

  • El tamaño total de los encabezados de respuesta supera el límite del tamaño máximo del encabezado de respuesta del balanceador de cargas de aplicaciones externo.
  • La versión HTTP es desconocida.

Cuando se manejan la solicitud y la respuesta, el balanceador de cargas puede quitar o reemplazar los encabezados de salto por salto en HTTP/1.1 antes de reenviarlos al destino previsto.

Distribución del tráfico

Cuando agregas un grupo de instancias de backend o un NEG a un servicio de backend, debes especificar un modo de balanceo, que define un método que mide la carga de backend y una capacidad objetivo. Los balanceadores de cargas de aplicaciones externos admiten dos modos de balanceo:

  • RATE, para grupos de instancias o NEG, es la cantidad máxima de solicitudes (consultas) de destino por segundo (RPS, QPS). Se puede exceder la cantidad máxima de RPS/QPS si se alcanza o supera la capacidad de todos los backends.

  • UTILIZATION es el uso de backend de las VMs en un grupo de instancias.

La manera en que se distribuye el tráfico entre backends depende del modo del balanceador de cargas.

Balanceador de cargas de aplicaciones externo global

Antes de que Google Front End (GFE) envíe solicitudes a instancias de backend, GFE estima qué instancias de backend tienen capacidad para recibir solicitudes. Esta estimación de capacidad se realiza de forma proactiva, no al mismo tiempo que cuando llegan las solicitudes. Los GFE reciben información de manera periódica sobre la capacidad disponible y distribuyen las solicitudes entrantes según corresponda.

El significado de capacidad depende en parte del modo de balanceo. Para el modo RATE, es bastante simple: un GFE determina con exactitud cuántas solicitudes puede asignar por segundo. El balanceo de cargas basado en UTILIZATION es más complejo: el balanceador de cargas verifica el uso actual de las instancias y, luego, calcula una carga de consulta que cada instancia puede controlar. Esta estimación cambia a medida que cambian el uso de la instancia y los patrones de tráfico.

Ambos factores, la estimación de capacidad y la asignación proactiva, influyen en la distribución entre las instancias. Por lo tanto, Cloud Load Balancing se comporta de manera diferente a un balanceador de cargas round robin simple que distribuye las solicitudes en 50:50 exactas entre dos instancias. En cambio, el balanceo de cargas de Google Cloud intenta optimizar la selección de la instancia de backend para cada solicitud.

Para el balanceador de cargas de aplicaciones externo global, el balanceo de cargas tiene dos niveles. El modo de balanceo determina el peso o la fracción del tráfico que se debe enviar a cada backend (grupo de instancias o NEG). Luego, la política de balanceo de cargas (LocalityLbPolicy) determina cómo se distribuye el tráfico en las instancias o extremos dentro del grupo. Para obtener más información, consulta la política de localidad del balanceo de cargas (documentación de la API del servicio de backend).

Para el balanceador de cargas de aplicaciones clásico, el modo de balanceo se usa para seleccionar el backend más favorable (grupo de instancias o NEG). Luego, el tráfico se distribuye de forma round robin entre las instancias o los extremos dentro del backend.

Cómo se distribuyen las solicitudes

Los balanceadores de cargas de aplicaciones externos basados en GFE usan el siguiente proceso para distribuir las solicitudes entrantes:

  1. Desde el cliente hasta el GFE de la primera capa. Los routers perimetrales anuncian la dirección IP externa de la regla de reenvío en los límites de la red de Google. Cada anuncio enumera un salto siguiente a un sistema de balanceo de cargas de capa 3/4 (Maglev). Los sistemas Maglev enrutan el tráfico a Google Front End (GFE) de primera capa.
    • Cuando se usa el nivel Premium, Google hace pública la dirección IP del balanceador de cargas desde todos los puntos de presencia y en todo el mundo. Cada dirección IP del balanceador de cargas es Anycast global.
    • Cuando se usa el nivel Estándar, Google anuncia la dirección IP del balanceador de cargas desde los puntos de presencia asociados con la región de la regla de reenvío. El balanceador de cargas usa una dirección IP externa regional. El uso de una regla de reenvío de nivel Estándar te limita a los backends de NEG zonales y grupos de instancias en la misma región que la regla de reenvío del balanceador de cargas.
  2. Desde el GFE de la primera capa hasta el GFE de la segunda capa El GFE de la primera capa finaliza TLS si es necesario y, luego, enruta el tráfico a los GFE de segunda capa de acuerdo con el siguiente proceso:
    • Los GFE de primera capa analizan el mapa de URL y seleccionan un servicio o un bucket de backend.
    • Para los servicios de backend con NEG de Internet, los primeros GFE de capa seleccionan una puerta de enlace de reenvío externa de segunda capa ubicada con el GFE de la primera capa. La puerta de enlace de reenvío envía solicitudes al extremo NEG de Internet. Así finaliza el proceso de solicitud de distribución para los NEG de Internet.
    • Para los servicios de backend con NEG sin servidores, NEG de Private Service Connect (PSC) y buckets de backend, el GFE de primera capa selecciona un GFE de segunda capa en la región que coincide con la región del NEG o del bucket. Para los buckets multirregionales de Cloud Storage, los GFE de la primera capa seleccionan los GFE de segunda capa en una región lo más cerca posible de los GFE de la primera capa (definidos por el tiempo de ida y vuelta de la red).
    • Para servicios de backend con grupos de instancias, NEG zonales con extremos GCE_VM_IP_PORT y NEG híbridos, el sistema de administración de capacidad de Google informa a los GFE de primera capa sobre la capacidad usada y configurada para cada backend. La capacidad configurada para un backend se define por el modo de balanceo, la capacidad de destino del modo de balanceo y el escalador de capacidad.
      • Nivel Estándar: Los GFE de primera capa seleccionan un GFE de segunda capa en la región que contiene los backends.
      • Nivel Premium: Los GFE de primera capa seleccionan los GFE de segunda capa de un conjunto de regiones aplicables. Las regiones aplicables son todas las regiones en las que se configuraron los backends, sin incluir las regiones con backends configurados que no tienen capacidad. Los GFE de primera capa seleccionan el GFE de segunda capa más cercano en una región aplicable (definida por el tiempo de ida y vuelta de la red). Si los backends están configurados en dos o más regiones, los GFE de primera capa pueden distribuir solicitudes en otras regiones aplicables si una región de primera elección está llena. La propagación a otras regiones es posible cuando todos los backends en la región de primera elección están al máximo de capacidad.
  3. Los GFE de segunda capa seleccionan backends. Los GFE de segunda capa se encuentran en zonas de una región. Usan el siguiente proceso para seleccionar un backend:
    • Para los servicios de backend con NEG sin servidores, NEG de Private Service Connect y buckets de backend, los GFE de segunda capa reenvían solicitudes a los sistemas de producción de Google. Así finaliza el proceso de distribución de solicitudes para estos backends.

    • Para los servicios de backend con grupos de instancias, NEG zonales con extremos GCE_VM_IP_PORT y NEG híbridos, los sistemas de sondeo de verificación de estado de Google informan a los GFE de segunda capa sobre la verificación de estado de las instancias o los extremos de backend.

      Solo en el nivel Premium: Si el GFE de segunda capa no tiene instancias o extremos de backend en buen estado en su región, podría enviar solicitudes a otro GFE de segunda capa en una región aplicable diferente con backends configurados. La propagación entre GFE de segunda capa en diferentes regiones no agota todas las combinaciones de región a región posibles. Si necesitas dirigir el tráfico fuera de los backends en una región en particular, en lugar de configurar backends para que fallen las verificaciones de estado, debes establecer el escalador de capacidad del backend en cero para que el GFE de primera capa excluya la región durante el paso anterior.

    Luego, la GFE de segunda capa dirige las solicitudes a extremos o instancias de backend en las zonas de su región como se explica en el siguiente paso.

  4. El GFE de segunda capa selecciona una zona. De forma predeterminada, los GFE de segunda capa usan el algoritmo WATERFALL_BY_REGION, en el que cada GFE de segunda capa prefiere seleccionar extremos o instancias de backend en la misma zona que la que contiene el GFE de segunda capa. Debido a que WATERFALL_BY_REGION minimiza el tráfico entre zonas, a tasas de solicitud bajas, cada GFE de segunda capa puede enviar solicitudes de forma exclusiva a los backends en la misma zona que el GFE de segunda capa.

    Solo para los balanceadores de cargas de aplicaciones externos globales, se pueden configurar los GFE de segunda capa para que usen uno de los siguientes algoritmos alternativos a través de un serviceLbPolicy:

    • SPRAY_TO_REGION: Los GFE de segunda capa no prefieren seleccionar extremos o instancias de backend en la misma zona que el GFE de segunda capa. Los GFE de segunda capa intentan distribuir el tráfico a todas las instancias de backend o los extremos en todas las zonas de la región. Esto puede generar una distribución más uniforme de la carga a expensas del aumento del tráfico entre zonas.
    • WATERFALL_BY_ZONE: Los GFE de segunda capa prefieren seleccionar instancias de backend o extremos en la misma zona que el GFE de segunda capa Los GFE de segunda capa solo dirigen solicitudes a backends en diferentes zonas después de que todos los backends en la zona actual hayan alcanzado sus capacidades configuradas.
  5. El GFE de segunda capa selecciona instancias o extremos dentro de la zona. De forma predeterminada, un GFE de segunda capa distribuye las solicitudes entre los backends a través de round robin. Solo para los balanceadores de cargas de aplicaciones externos globales, puedes cambiar esto a través de una política de localidad de balanceo de cargas (localityLbPolicy). La política de localidad de balanceo de cargas solo se aplica a los backends dentro de la zona seleccionada que se analizaron en el paso anterior.

Balanceador de cargas de aplicaciones externo regional

Para los balanceadores de cargas de aplicaciones externos regionales, la distribución del tráfico se basa en el modo de balanceo de cargas y la política de localidad del balanceo de cargas.

El modo de balanceo determina el peso o la fracción del tráfico que se debe enviar a cada grupo (grupo de instancias o NEG). La política de localidad del balanceo de cargas (LocalityLbPolicy) determina cómo se balancean las cargas del backend dentro del grupo.

Cuando un servicio de backend recibe tráfico, primero lo dirige a un backend (grupo de instancias o NEG) según el modo de balanceo del backend. Después de seleccionar un backend, el tráfico se distribuye entre instancias o extremos en ese grupo de backend de acuerdo con la política de localidad del balanceo de cargas.

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

Afinidad de sesión

La afinidad de sesión hace su mejor esfuerzo para enviar solicitudes de un cliente en particular al mismo backend, siempre que el backend esté en buen estado y tenga la capacidad necesaria, según el modo de balanceo configurado.

Cuando uses la afinidad de sesión, te recomendamos el modo de balanceo RATE, en lugar de UTILIZATION. La afinidad de sesión funciona mejor si configuras el modo de balanceo en solicitudes por segundo (RPS).

Los balanceadores de cargas de aplicaciones externos ofrecen los siguientes tipos de afinidad de sesión:

En la siguiente tabla, se resumen las opciones de afinidad de sesión admitidas que son compatibles con los balanceadores de cargas de aplicaciones externos en cada modo:

Modo de balanceador de cargas Opciones de afinidad de sesión
  Ninguno IP de cliente Cookie generada Campo de encabezado Cookie HTTP Cookie de sesión con estado
Balanceador de cargas de aplicaciones externo global
Balanceador de cargas de aplicaciones clásico
Balanceador de cargas de aplicaciones externo regional

Alta disponibilidad y conmutación por error

La alta disponibilidad y la conmutación por error en los balanceadores de cargas de aplicaciones externos se pueden configurar a nivel del balanceador de cargas. Esto se controla mediante la creación de balanceadores de cargas de aplicaciones externos regionales de copia de seguridad en cualquier región en la que necesites la copia de seguridad.

En la siguiente tabla, se describe el comportamiento de conmutación por error en cada modo:

Modo de balanceador de cargas Métodos de conmutación por error
Balanceador de cargas de aplicaciones externo global,

Balanceador de cargas de aplicaciones clásico

Puedes establecer una configuración de conmutación por error activa-pasiva en la que el tráfico se conmuta por error a un balanceador de cargas de aplicaciones externo regional de copia de seguridad. Usas las verificaciones de estado para detectar interrupciones y las políticas de enrutamiento de Cloud DNS para enrutar el tráfico cuando se activa la conmutación por error.
Balanceador de cargas de aplicaciones externo regional

Usa uno de los siguientes métodos para garantizar una implementación de alta disponibilidad:

Compatibilidad con HTTP/2

HTTP/2 es una revisión importante del protocolo HTTP/1. HTTP/2 es compatible con conexiones entre clientes y el balanceador de cargas de aplicaciones externo, y con conexiones entre el balanceador de cargas y sus backends.

El balanceador de cargas negocia automáticamente HTTP/2 con los clientes como parte del protocolo de enlace SSL a través de la extensión ALPN TLS. Incluso si un balanceador de cargas está configurado para usar HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla del lado del cliente, no en el balanceador de cargas.

Si un cliente no admite HTTP/2 y el balanceador de cargas está configurado para usar HTTP/2 entre el balanceador de cargas y las instancias de backend, el balanceador de cargas aún podría negociar una conexión HTTPS o aceptar solicitudes HTTP no seguras. Luego, el balanceador de cargas transforma esas solicitudes HTTPS o HTTP para representar las solicitudes a través de HTTP/2 en las instancias de backend.

Para usar HTTP/2, debes habilitar TLS en tus backends. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.

Transmisiones simultáneas máximas de HTTP/2

La configuración de HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS describe el número máximo de transmisiones que acepta un extremo, que inicia el par. El valor que anuncia un cliente HTTP/2 a un balanceador de cargas de Google Cloud no tiene sentido, porque el balanceador de cargas no inicia transmisiones al cliente.

En los casos en que el balanceador de cargas usa HTTP/2 para comunicarse con un servidor que se ejecuta en una VM, el balanceador de cargas respeta el valor SETTINGS_MAX_CONCURRENT_STREAMS que anuncia el servidor. Si se anuncia un valor de cero, el balanceador de cargas no puede reenviar solicitudes al servidor y puede generar errores.

Limitaciones de HTTP/2

  • En comparación con el protocolo HTTP(S), el uso de HTTP/2 entre el balanceador de cargas y la instancia puede requerir una cantidad significativamente mayor de conexiones TCP a la instancia. La agrupación de conexiones, una optimización que reduce la cantidad de conexiones con HTTP(S), no está disponible con HTTP/2 en este momento. Como resultado, es posible que veas latencias de backend altas porque las conexiones de backend se realizan con más frecuencia.
  • El uso de HTTP/2 entre el balanceador de cargas y el backend no admite la ejecución del protocolo WebSocket a través de una sola transmisión de conexión HTTP/2 (RFC 8441).
  • El uso de HTTP/2 entre el balanceador de cargas y el backend no admite la extracción de servidor.
  • La tasa de errores de gRPC y el volumen de solicitudes no son visibles en la API de Google Cloud ni en la consola de Google Cloud. Si el extremo de gRPC devuelve un error, los registros del balanceador de cargas y los datos de supervisión informan el código de respuesta HTTP OK 200.

Compatibilidad con HTTP/3

HTTP/3 es un protocolo de Internet de nueva generación. Se basa en IETF QUIC, un protocolo desarrollado a partir del protocolo Google QUIC original. HTTP/3 es compatible entre el balanceador de cargas de aplicaciones externo, Cloud CDN y los clientes.

Específicamente:

  • IETF QUIC es un protocolo de capa de transporte que proporciona control de congestión y confiabilidad similar a TCP. Usa TLS 1.3 para la seguridad y un rendimiento mejorado.
  • HTTP/3 es una capa de aplicación basada en IETF QUIC, y se utiliza QUIC para manejar la multiplexación, el control de congestión, la detección de pérdida y la retransmisión.
  • HTTP/3 permite un inicio más rápido de la conexión del cliente, resuelve el bloqueo de línea en las transmisiones multiplexadas y admite la migración de conexión cuando cambia la dirección IP de un cliente.
  • HTTP/3 es compatible con conexiones entre clientes y el balanceador de cargas, no conexiones entre el balanceador de cargas y sus backends.
  • Las conexiones HTTP/3 usan el algoritmo de control de congestión BBR.

Habilitar HTTP/3 en el balanceador de cargas puede mejorar los tiempos de carga de las páginas web, reducir el realmacenamiento en búfer de video y mejorar la capacidad de procesamiento en las conexiones de latencia más alta.

En la siguiente tabla, se especifica la compatibilidad de HTTP/3 con balanceadores de cargas de aplicaciones externos en cada modo.

Modo de balanceador de cargas Compatibilidad con HTTP/3
Balanceador de cargas de aplicaciones externo global (siempre nivel Premium)
Balanceador de cargas de aplicaciones clásico en el nivel Premium
Balanceador de cargas de aplicaciones clásico en el nivel Estándar
Balanceador de cargas de aplicaciones regional externo (nivel Premium o Estándar)

Cómo se negocia HTTP/3

Cuando HTTP/3 está habilitado, el balanceador de cargas anuncia esta compatibilidad a los clientes, de manera que los clientes que admiten HTTP/3 intenten establecer conexiones HTTP/3 con el balanceador de cargas HTTPS.

  • Los clientes implementados de forma correcta siempre recurren a HTTPS o HTTP/2 cuando no pueden establecer una conexión HTTP/3.
  • Los clientes que admiten HTTP/3 usan su conocimiento previo almacenado en caché de la compatibilidad con HTTP/3 para ahorrar idas y vueltas innecesarias en el futuro.
  • Debido a esta solución alternativa, habilitar o inhabilitar HTTP/3 en el balanceador de cargas no interrumpe la capacidad de este para conectarse con los clientes.

La compatibilidad se anuncia en el encabezado de respuesta HTTP Alt-Svc. Cuando HTTP/3 está habilitado, las respuestas del balanceador de cargas incluyen el siguiente valor del encabezado alt-svc:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

Si HTTP/3 se configuró de forma explícita como DISABLE, las respuestas no incluyen un encabezado de respuesta alt-svc.

Cuando tienes HTTP/3 habilitado en el balanceador de cargas de HTTPS, algunas circunstancias pueden hacer que tu cliente recurra a HTTPS o HTTP/2 en lugar de negociar HTTP/3. Se incluyen las siguientes:

  • Cuando un cliente admite versiones de HTTP/3 que no son compatibles con las versiones de HTTP/3 compatibles con el balanceador de cargas HTTPS
  • Cuando el balanceador de cargas detecta que el tráfico de UDP está bloqueado o sometido a un límite de frecuencia tal que impediría el funcionamiento de HTTP/3.
  • Si el cliente no admite HTTP/3 en absoluto y, por lo tanto, no intenta negociar una conexión HTTP/3

Cuando una conexión recurre a HTTPS o HTTP/2, no consideramos esto como una falla del balanceador de cargas.

Antes de habilitar HTTP/3, asegúrate de que los comportamientos descritos con anterioridad sean aceptables para tus cargas de trabajo.

Configura HTTP/3

NONE (la opción predeterminada) y ENABLE habilitan la compatibilidad con HTTP/3 para tu balanceador de cargas.

Cuando el HTTP/3 está habilitado, el balanceador de cargas lo anuncia a los clientes, lo que permite que los clientes que lo admiten negocien una versión HTTP/3 con el balanceador de cargas. Los clientes que no admiten HTTP/3 no negocian una conexión HTTP/3. No es necesario que inhabilites HTTP/3 de forma explícita, a menos que hayas identificado implementaciones de cliente dañadas.

Los balanceadores de cargas de aplicaciones externos proporcionan tres formas de configurar HTTP/3, como se muestra en la siguiente tabla.

Valor quicOverride Comportamiento
NONE

La compatibilidad con HTTP/3 se anuncia a los clientes.

ENABLE

La compatibilidad con HTTP/3 se anuncia a los clientes.

Nota: TLS 0-RTT (también conocido como datos anticipados de TLS) aún no es compatible con HTTP/3.

DISABLE Inhabilita de manera explícita publicidad de HTTP/3 y Google QUIC para los clientes.

Si deseas habilitar (o inhabilitar) HTTP/3 explícitamente, sigue estos pasos.

Console: HTTPS

  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.

Ir a Balanceo de cargas

  1. Selecciona el balanceador de cargas que deseas editar.
  2. Haga clic en Configuración de frontend.
  3. Selecciona la dirección IP y el puerto de frontend que deseas editar. Para editar una configuración HTTP/3, el protocolo debe ser HTTPS.

Habilita HTTP/3

  1. Selecciona el menú Negociación de QUIC.
  2. Si quieres habilitar HTTP/3 para este frontend de forma explícita, selecciona Habilitado.
  3. Si tienes varias reglas de frontend que representan IPv4 y, también, IPv6, asegúrate de habilitar HTTP/3 en cada regla.

Inhabilita HTTP/3.

  1. Selecciona el menú Negociación de QUIC.
  2. Si quieres inhabilitar HTTP/3 para este frontend de forma explícita, selecciona Inhabilitado.
  3. Si tienes varias reglas de frontend que representan IPv4 y, también, IPv6, asegúrate de inhabilitar HTTP/3 para cada regla.

gcloud: HTTPS

Antes de que ejecutes este comando, debes crear un recurso de certificado SSL para cada certificado.

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

Reemplaza QUIC_SETTING por uno de los siguientes valores:

  • NONE (predeterminado): Permite que Google controle cuándo se anuncia HTTP/3.

    Cuando seleccionas NONE, HTTP/3 se anuncia a los clientes, pero Google QUIC no se anuncia. En la consola de Google Cloud, esta opción se llama Automática (predeterminado).

  • ENABLE: Anuncia HTTP/3 a los clientes.

  • DISABLE: No anuncia HTTP/3 a los clientes.

API: HTTPS

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

Reemplaza QUIC_SETTING por uno de los siguientes valores:

  • NONE (predeterminado): Permite que Google controle cuándo se anuncia HTTP/3.

    Cuando seleccionas NONE, HTTP/3 se anuncia a los clientes, pero Google QUIC no se anuncia. En la consola de Google Cloud, esta opción se llama Automática (predeterminado).

  • ENABLE: Anuncia HTTP/3 y Google QUIC a los clientes

  • DISABLE: No anuncia HTTP/3 ni Google QUIC a los clientes.

Limitaciones

  • Los balanceadores de cargas HTTPS no envían una alerta de cierre close_notify cuando finalizan conexiones SSL. Es decir, el balanceador de cargas cierra la conexión TCP en lugar de realizar un cierre SSL.
  • Los balanceadores de cargas de HTTPS solo admiten caracteres en minúsculas en dominios en un atributo de nombre común (CN) o un nombre de entidad alternativo (SAN) del certificado. Los certificados con caracteres en mayúscula en los dominios solo se devuelven cuando se configuran como el certificado principal en el proxy de destino.
  • Los balanceadores de cargas HTTPS no usan la extensión de indicación del nombre del servidor (SNI) cuando se conectan al backend, excepto los balanceadores de cargas con backends de NEG de Internet. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.
  • Cuando se usan balanceadores de cargas de aplicaciones externos regionales con Cloud Run en un entorno de VPC compartida, las redes de VPC independientes en los proyectos de servicio pueden enviar tráfico a cualquier otro servicio de Cloud Run implementado en cualquier otro proyecto de servicio dentro del mismo entorno de VPC compartida. Este es un problema conocido, y esta forma de acceso se bloqueará en el futuro.
  • Google Cloud no garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el valor del tiempo de espera del servicio de backend. Los sistemas cliente deben implementar la lógica de reintento en lugar de depender de una conexión TCP para estar abierta durante períodos prolongados.
  • No puedes crear un balanceador de cargas de aplicaciones externo regional en el nivel Premium con la consola de Google Cloud. Además, solo las regiones compatibles con el nivel Estándar están disponibles para estos balanceadores de cargas en la consola de Google Cloud. En su lugar, usa gcloud CLI o la API. En su lugar, usa gcloud CLI o la API.
  • Cloud CDN te permite forzar que un objeto o un conjunto de objetos sean ignorados por la caché mediante la solicitud de una invalidación de caché. De forma predeterminada, cuando usas un balanceador de cargas de aplicaciones externo global con referencia del servicio entre proyectos de VPC compartida, los administradores del proyecto de servicio no tendrán los permisos necesarios para lo siguiente: invalidaciones de caché de solicitudes. Esto se debe a que la invalidación de caché se configura en el proyecto de frontend (es decir, el proyecto que tiene la regla de reenvío, el proxy de destino y el mapa de URL del balanceador de cargas). Por lo tanto, las invalidaciones de caché solo pueden emitirse las principales que tienen los roles de IAM para configurar los recursos relacionados con el balanceador de cargas en los proyectos de frontend (por ejemplo, el rol de administrador de red de Compute). Los administradores de servicios, que controlan el aprovisionamiento de los servicios de backend en un proyecto separado, deberán trabajar con el administrador del balanceador de cargas del proyecto de frontend para emitir la invalidación de caché para sus servicios entre proyectos.

¿Qué sigue?