Descripción general del balanceo de cargas de HTTP(S) externo

En este documento, se presentan los conceptos que debes comprender para configurar el balanceo de cargas de HTTP(S) externo de Google Cloud.

El balanceo de cargas HTTP(S) de Google Cloud es un balanceador de cargas de capa 7 global basado en proxy que te permite ejecutar y escalar tus servicios en todo el mundo detrás de una sola dirección IP externa. El balanceo de cargas HTTP(S) externo distribuye el tráfico HTTP y HTTPS a los backends alojados en Compute Engine y Google Kubernetes Engine (GKE).

El balanceo de cargas HTTP(S) externo se implementa en Google Front End (GFE). Los GFE se distribuyen globalmente y operan juntos mediante el plano de control y la red global de Google. En el nivel Premium, los GFE ofrecen balanceo de cargas multirregional, lo que dirige el tráfico al backend en buen estado más cercano y termina el tráfico HTTP(S) lo más cerca posible de tus usuarios. En el nivel Estándar, el balanceo de cargas se maneja a nivel regional.

Para obtener información sobre la diferencia entre los balanceadores de cargas de Google Cloud, consulta los siguientes documentos:

Casos prácticos

Los balanceadores de cargas de HTTP(S) externos abordan muchos casos prácticos. En esta sección, se proporcionan algunos ejemplos de alto nivel.

Servicios web de tres niveles

Puedes usar el balanceo de cargas de HTTP(S) externo para servicios web tradicionales de tres niveles. En el siguiente ejemplo, se muestra cómo puedes usar tres tipos de balanceadores de cargas de Google Cloud para escalar en los tres niveles. En cada nivel el tipo de balanceador de cargas depende del tipo de tráfico:

En el diagrama, se muestra cómo se mueve el tráfico por los niveles:

  1. Un balanceador de cargas de HTTP(S) externo (el asunto de esta descripción general) distribuye el tráfico desde Internet hasta un conjunto de grupos de instancias de frontend web en varias regiones.
  2. Estos frontends envían el tráfico de HTTP(S) a un conjunto de balanceadores de cargas de HTTP(S) internos y regionales. Para que el balanceador de cargas HTTP(S) externo reenvíe el tráfico a un balanceador de cargas HTTP(S) interno, el balanceador de cargas HTTP(S) externo debe tener instancias de backend con software de servidor web (como Netscaler o NGNIX) configurado para reenviar el tráfico al frontend del balanceador de cargas HTTP(S) interno.
  3. Los balanceadores de cargas de HTTP(S) internos distribuyen el tráfico a grupos de instancias de middleware.
  4. Estos grupos de instancias de middleware envían el tráfico a balanceadores de cargas de TCP/UDP internos, que balancean la carga del tráfico a los clústeres de almacenamiento de datos.
Enrutamiento basado en la capa 7 para niveles internos en una app de varios niveles.
Enrutamiento basado en la capa 7 para niveles internos en una app de varios niveles

Balanceo de cargas multirregión

Representación del balanceo de cargas multirregión.

Cuando configuras un balanceador de cargas de HTTP(S) externo en el nivel Premium, se usa una dirección IP externa global y se pueden enrutar de forma inteligente las solicitudes de los usuarios al grupo de instancias de backend o NEG más cercano, según la proximidad. Por ejemplo, si configuras grupos de instancias en Norteamérica, Europa y Asia, y los conectas al servicio de backend de un balanceador de cargas, las solicitudes de usuarios de todo el mundo se envían de manera automática a las VM más cercanas a los usuarios, en caso de que las VM pasen las verificaciones de estado y tengan capacidad suficiente (definida por el modo de balanceo). Si las VM más cercanas están en mal estado, o si el grupo de instancias más cercano está al máximo de capacidad y otro grupo no, el balanceador de cargas envía solicitudes de manera automática a la siguiente región más cercana con capacidad.


Balanceo de cargas con enrutamiento de solicitudes

Representación del balanceo de cargas basado en contenido

El balanceo de cargas HTTP(S) admite el enrutamiento de solicitudes mediante mapas de URL para seleccionar un servicio de backend según el nombre de host solicitado, la ruta de solicitud o ambos. Por ejemplo, puedes usar un conjunto de grupos de instancias o NEG para manejar el contenido de video y otro conjunto a fin de manejar todo lo demás.

También puedes usar el balanceo de cargas de HTTP(S) en depósitos de Cloud Storage. Una vez que configures el balanceador de cargas, podrás agregarle depósitos de Cloud Storage.


Balanceo de cargas con varios tipos de backend

El balanceo de cargas de HTTP(S) externo admite los siguientes tipos de backend:

Un caso práctico común es el tráfico de balanceo de cargas entre los servicios. En el siguiente ejemplo, los clientes IPv4 y IPv6 externos pueden solicitar contenido de imágenes, API y video mediante la misma URL base, con las rutas de acceso /api, /video y /images.

El mapa de URL del balanceador de cargas HTTP(S) externo especifica lo siguiente:

  • Las solicitudes a la ruta de acceso /api van a un servicio de backend con un grupo de instancias de VM o un backend de NEG zonal.
  • Las solicitudes a la ruta de acceso /images van a un bucket de backend con un backend de Cloud Storage.
  • Las solicitudes a la ruta de acceso /video van a un servicio de backend que apunta a un NEG de Internet que contiene un extremo externo ubicado de manera local, fuera de Google Cloud.

Cuando un cliente envía una solicitud a la dirección IPv4 o IPv6 externa del balanceador de cargas, este evalúa la solicitud según el mapa de URL y la envía al servicio correspondiente.

En el siguiente diagrama, se ilustra este caso práctico.

Diagrama del balanceo de cargas con un backend externo.
Diagrama del balanceo de cargas con un backend externo (haz clic para ampliar)

En cada servicio de backend, puedes habilitar de manera opcional Cloud CDN y Google Cloud Armor. Si usas Google Cloud Armor con Cloud CDN, las políticas de seguridad solo se aplican a las solicitudes de contenido dinámico, errores de caché y otras solicitudes que están destinadas al servidor de origen de CDN. Los aciertos de caché se entregan incluso si la política de seguridad posterior de Google Cloud Armor evitará que la solicitud llegue al servidor de origen de CDN.

En los depósitos de backend, se admite Cloud CDN, pero no Google Cloud Armor.

Crea un balanceador de cargas combinado

Puedes configurar un balanceador de cargas HTTP(S) externo en el nivel Premium para proporcionar balanceo de cargas multirregional, con varios servicios de backend, cada uno con grupos de instancias de backend o NEG en varias regiones. Puedes combinar y extender los casos prácticos para configurar un balanceador de cargas de HTTP(S) externo que satisfaga tus necesidades.

Representación del balanceo de cargas multirregión.
Representación del balanceo de cargas multirregión

Arquitectura

En el siguiente diagrama, se muestran los recursos de Google Cloud necesarios para un balanceador de cargas de HTTP(S) externo.

Componentes del balanceo de cargas de HTTP(S).
Componentes del balanceo de cargas de HTTP(S)

Los siguientes recursos definen un balanceador de cargas de HTTP(S) externo:

  • 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 global 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 mediante el uso de certificados SSL.

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

  • El proxy HTTP(S) usa un mapa de URL global para determinar el enrutamiento según los atributos HTTP (como la ruta de acceso 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 depósitos específicos. El mapa de URL puede especificar acciones adicionales, como el envío de redireccionamientos a los clientes.

  • Un servicio de backend o un bucket de backend distribuye solicitudes a backends en buen estado.

  • Uno o más backends deben estar conectados al servicio o al bucket de backend. Los backends pueden ser grupos de instancias, NEG o depósitos en cualquiera de las siguientes opciones de configuración:

    • Grupos de instancias administrados (zonales o regionales)
    • Grupos de instancias no administrados (zonales)
    • Grupos de extremos de red (zonales)
    • Grupos de extremos de red (Internet)
    • Depósitos de Cloud Storage

    No puedes tener grupos de instancias y NEG en el mismo servicio 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 puedan procesar la solicitud.

  • Un firewall para que los backends acepten sondeos de verificaciones de estado.

Direcciones y reglas de reenvío

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.

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.

  • La regla de reenvío para un balanceador de cargas de HTTP solo puede hacer referencia a los puertos TCP 80 y 8080.
  • La regla de reenvío de un balanceador de cargas HTTPS solo puede hacer referencia al puerto TCP 443.

El tipo de regla de reenvío que se necesita para los balanceadores de cargas de HTTP(S) externos depende del nivel de servicio de red en el que se encuentra el balanceador de cargas.

  • Los balanceadores de cargas de HTTP(S) externos en el nivel Premium usan reglas de reenvío externas globales.
  • Los balanceadores de cargas de HTTP(S) externos en el nivel Estándar usan reglas de reenvío externas regionales.

Para obtener una lista completa de los protocolos compatibles con las reglas de reenvío del balanceo de cargas HTTP(S), consulta Funciones del balanceador de cargas.

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.

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-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (solo solicitudes)
    Contiene parámetros de Cloud Trace.

Puedes crear encabezados personalizados de solicitud y respuesta si los encabezados predeterminados no satisfacen tus necesidades. Para obtener más información sobre esta función, consulta Crea encabezados personalizados.

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.

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 mediante el análisis de los componentes de URL a fin de enviar solicitudes a diferentes conjuntos de backends.

Certificado SSL

Si usas el balanceo de cargas basado en HTTPS, debes instalar uno o más certificados SSL en el proxy HTTPS de destino.

Los proxies HTTPS de destino usan estos certificados para proteger las comunicaciones entre el balanceador de cargas y el cliente.

A fin de obtener más información sobre los límites y las cuotas de los certificados SSL, consulta Certificados SSL en la página de cuotas del balanceo de cargas.

Para obtener la mejor seguridad, usa la encriptación de extremo a extremo en la implementación del balanceador de cargas de HTTPS. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.

Para obtener información sobre cómo Google encripta el tráfico de los usuarios, consulta el informe Encriptación en tránsito en Google Cloud.

Políticas de SSL

Las políticas de SSL te permiten controlar las funciones de SSL que el balanceador de cargas HTTPS negocia con clientes HTTPS.

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 políticas de SSL para controlar las características de SSL que tu balanceador de cargas negocia y asocia una política de SSL con tu proxy HTTPS de destino.

Servicios y buckets de backend

Un balanceador de cargas de HTTP(S) externo puede tener servicios de backend o buckets de backend.

Servicios 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 HTTP(S) externo con un backend de Compute Engine.

Buckets de backend

Los depósitos de backend dirigen el tráfico entrante a los depósitos de Cloud Storage.

Para ver un ejemplo que muestra cómo agregar un bucket a un balanceador de cargas existente, consulta Configura un balanceador de cargas con bucket s de backend.

Verificaciones de estado

Cada servicio de backend también especifica qué verificación de estado se realiza en cada instancia disponible. Para que los sondeos de verificación de estado funcionen de manera correcta, debes crear una regla de firewall que permita que el tráfico de 130.211.0.0/2235.191.0.0/16 llegue a las instancias.

Para obtener más información sobre las verificaciones de estado, consulta Crea verificaciones de estado.

Protocolo para los backends

Cuando configuras un servicio de backend para el balanceador de cargas de HTTP(S) externo, debes configurar el protocolo que usa el servicio de backend a fin de comunicarse con otros. 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.

Aunque no es obligatorio, 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.

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 hacerlo con un balanceador de cargas de HTTP(S) externo, sigue estos pasos:

  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 mediante la extensión ALPN TLS.

Es posible que el balanceador de cargas aún negocie HTTPS con algunos clientes o acepte solicitudes HTTP no seguras en un balanceador de cargas de HTTP(S) externo configurado para usar HTTP/2 entre las instancias del 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 HTTP(S) externo mediante HTTP/2 con Ingress de Google Kubernetes Engine o mediante 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.

Reglas de firewall

Las instancias de backend deben permitir conexiones desde los rangos de verificación de estado o GFE del balanceador de cargas. Esto significa que debes crear una regla de firewall de permiso de entrada para el tráfico de 130.211.0.0/22 y 35.191.0.0/16 a tus instancias o extremos de backend. Estos rangos de direcciones IP se usan como orígenes para los paquetes de verificación de estado y para todos los paquetes con balanceo de cargas que se envían a tus backends.

Los puertos que configures para esta regla de firewall deben cumplir con estos requisitos:

  • Permitir el tráfico hacia el puerto de destino necesario para la verificación de estado configurada de cada servicio de backend.

  • Para los backends de grupos de instancias: permite el tráfico al puerto de destino que coincide con los números de puerto a los que se suscribe el puerto con nombre del servicio de backend.

  • Para los backends de NEG GCE_VM_IP_PORT: permite el tráfico a los puertos de los extremos en los NEG.

Las reglas de firewall se implementan a nivel de la instancia de VM, no en los proxies de Google Front End (GFE). No puedes usar las reglas de firewall de Google Cloud para evitar que el tráfico llegue al balanceador de cargas.

Para obtener más información sobre los sondeos de verificación de estado y por qué es necesario permitir el tráfico de 130.211.0.0/2235.191.0.0/16, consulta Rangos de IP del sondeo y reglas de firewall.

Ruta de acceso de retorno

Google Cloud usa rutas especiales no definidas en tu red de VPC para las verificaciones de estado. Para obtener más información, consulta Rutas de acceso de retorno del balanceador de cargas.

Cómo funcionan las conexiones en el balanceo de cargas de HTTP(S)

El balanceo de cargas de HTTP(S) externo es un servicio implementado por muchos proxies llamados Google Front End (GFE). No hay un solo proxy. En el nivel Premium, la misma dirección IP externa global se anuncia desde varios puntos de presencia y el tráfico se dirige 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/16130.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. 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. GFE usa un tiempo de espera de 600 segundos para el keepalive, y no puedes configurarlo. Sin embargo, puedes configurar el tiempo de espera de la solicitud o la respuesta mediante la configuración del tiempo de espera del servicio de backend. Para obtener más información, consulta Tiempos de espera y reintentos.

Los keepalives de HTTP intentan usar la misma sesión de TCP de forma eficiente; sin embargo, no hay garantía. Aunque están muy relacionados, un tiempo de espera de keepalive de HTTP y uno de inactividad de TCP no son lo mismo.

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 funciona el balanceo de cargas de HTTP(S) en la guía de soluciones: Optimizaciones de la capacidad de las aplicaciones con el balanceo de cargas global.

Comunicaciones del cliente con el balanceador de cargas

  • Los clientes se pueden comunicar con el balanceador de cargas mediante 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.
  • El balanceo de cargas HTTP(S) admite la respuesta HTTP/1.1 100 Continue.

Para obtener una lista completa de los protocolos compatibles con las reglas de reenvío del balanceo de cargas HTTP(S), consulta Funciones del balanceador de cargas.

Direcciones IP de origen para paquetes de clientes

Las direcciones IP de origen de los paquetes, vistas por los contenedores o instancias de máquina virtual (VM) de backend, son una dirección IP de estos rangos:

  • 35.191.0.0/16
  • 130.211.0.0/22

La dirección IP de origen para el tráfico real del balanceo de cargas es la misma que la de los rangos de IP del sondeo de verificación de estado.

Las direcciones IP de origen del tráfico, vistas por los backends, no son la dirección IP externa de Google Cloud del balanceador de cargas. En otras palabras, existen dos sesiones HTTP, SSL o TCP:

  • 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).
    • Dirección IP de destino: Es la dirección IP del balanceador de cargas.
  • Sesión 2, que abarca desde el balanceador de cargas (GFE) hasta el contenedor o la VM de backend:

    • Dirección IP de origen: Es una dirección IP en uno de estos rangos: 35.191.0.0/16130.211.0.0/22.

      No puedes predecir la dirección real de origen.

    • Dirección IP de destino: Es la dirección IP interna del contenedor o la VM de backend en la red de nube privada virtual (VPC).

Puertos abiertos

Los balanceadores de cargas de HTTP(S) externos son balanceadores de cargas de proxy inverso. El balanceador de cargas finaliza las conexiones entrantes y abre conexiones nuevas del balanceador de cargas a los backends. Estos balanceadores de cargas se implementan mediante proxies de Google Front End (GFE) en todo el mundo.

Los GFE tienen varios puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Para ver una lista de algunos de los puertos que probablemente estén abiertos en los GFE, consulta Regla de reenvío: especificaciones de puertos. Es posible que haya otros puertos abiertos para otros servicios de Google que se ejecutan en GFE.

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 una 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 de una variedad de puertos si el balanceador de cargas usa una dirección IP del nivel Premium. Sin embargo, 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 enviados a direcciones IP de balanceador de cargas diferentes o la dirección IP del balanceador de cargas en un puerto que no se configuró en la regla de reenvío no tienen como resultado que los paquetes se envíen a los backends del balanceador de cargas. Los GFE implementan funciones de seguridad como Google Cloud Armor. Incluso sin una configuración de Google Cloud Armor, la infraestructura de Google y los GFE proporcionan una defensa en profundidad para los ataques de DSD y desbordamientos SYN.

  • 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 del 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 las 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 los balanceadores de cargas de HTTP(S) externos que usan el puerto TCP 443, se usa el puerto UDP 443 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 VM de backend, pero no bloquean el tráfico entrante a los GFE. Si deseas conocer prácticas recomendadas, consulta la sección de reglas de firewall.

finalización de TLS

El balanceador de cargas HTTPS finaliza TLS en ubicaciones distribuidas de manera global a fin de minimizar la latencia entre los clientes y el balanceador de cargas. Si necesitas un control geográfico sobre la ubicación donde se finaliza TLS, usa el balanceo de cargas de red de Google Cloud y finaliza TLS en backends ubicados en regiones adecuadas para tus necesidades.

Tiempos de espera y reintentos

El balanceo de cargas de HTTP(S) tiene dos tipos distintos de tiempos de espera:
  • Un tiempo de espera del servicio de backend HTTP configurable, que representa la cantidad de tiempo que el balanceador de cargas espera para que el backend muestre una respuesta HTTP completa. El valor predeterminado para el tiempo de espera del servicio de backend es de 30 segundos. El rango completo de valores de tiempo de espera permitidos es de 1 a 2,147,483,647 segundos.

    Considera aumentar este tiempo de espera en cualquiera de estas circunstancias:

    • Si esperas que un backend tarde más en mostrar respuestas HTTP
    • Si ves una respuesta HTTP 408 con jsonPayload.statusDetail client_timed_out.
    • La conexión se actualiza a un WebSocket.

Por ejemplo, un valor de tiempo de espera práctico para los balanceadores de cargas HTTP(S) externos es de 1 día (86,400 segundos). Ten en cuenta que los eventos como los reinicios de GFE pueden hacer que las sesiones finalicen antes que este tiempo de espera.

Para el tráfico WebSocket enviado mediante un balanceador de cargas, el tiempo de espera del servicio de backend se interpreta como la cantidad máxima de tiempo que una conexión WebSocket puede permanecer abierta, ya sea que esté activa o no. Para obtener más información, consulta Configuración del servicio de backend.

  • Un tiempo de espera de sesión TCP, cuyo valor se fija en 10 minutos (600 segundos). Este tiempo de espera de la sesión a veces se denomina tiempo de espera keepalive o inactivo, y su valor no se puede configurar mediante la modificación del servicio de backend. Debes configurar el software del servidor web que usan tus backends para que su tiempo de espera keepalive sea superior a 600 segundos a fin de evitar que el backend cierre de forma prematura las conexiones. Este tiempo de espera no se aplica a WebSockets.

En esta tabla, se ilustran los cambios necesarios a fin de modificar los tiempos de espera de keepalive para el software del servidor web común:

Software del 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;

El balanceador de cargas reintenta las solicitudes GET que fallaron en ciertas circunstancias, como cuando se agota el tiempo de espera del servicio de backend. No se reintentan las solicitudes POST que fallaron. Solo se puede reintentar dos veces. Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final.

Un GFE no vuelve a intentarlo si más del 80% de las instancias de backend están en mal 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. Para obtener más información, consulta Registro y supervisión del balanceo de cargas de HTTP(S).

El protocolo WebSocket es compatible con Ingress.

Solicitud ilegal y manejo de respuestas

El balanceador de cargas de HTTP(S) externo impide que las solicitudes de clientes 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 lo siguiente 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 :.
  • 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.

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

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 balanceo de cargas de HTTP(S) externo.
  • La versión HTTP es desconocida.

Distribución de 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. El balanceo de cargas de HTTP(S) externo admite 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 VM en un grupo de instancias.

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 obtener más información, consulta Distribución de tráfico.

Para obtener más información sobre los modos de balanceo, consulta Modos de balanceo.

Comportamiento en diferentes niveles de servicio de red

La distribución del tráfico a nivel regional o global depende de qué nivel de servicio de red se esté utilizando.

Nivel Premium

Cuando se usa el nivel Premium, las solicitudes enviadas al balanceador de cargas HTTP(S) externo se entregan a grupos de instancias de backend o NEG en la región más cercana al usuario, si es que un backend en esa región tiene capacidad disponible. La capacidad disponible se configura mediante el modo de balanceo del balanceador de cargas.

Puedes tener más de un servicio de backend en una región y puedes crear servicios de backend en más de una región, todos atendidos por el mismo balanceador de cargas global. El tráfico se asigna a los servicios de backend de la manera siguiente:

  1. Cuando llega una solicitud de usuario, el servicio de balanceo de cargas determina el origen aproximado de la solicitud a partir de la dirección IP de origen.
  2. El servicio de balanceo de cargas conoce las ubicaciones de las instancias que posee el servicio de backend, su capacidad general y su uso actual general.
  3. Si las instancias más cercanas al usuario tienen capacidad disponible, la solicitud se reenviará a ese conjunto de instancias.
  4. Las solicitudes entrantes a la región determinada se distribuyen de manera uniforme entre todos los servicios de backend y las instancias disponibles en esa región. Sin embargo, con cargas muy pequeñas, la distribución puede parecer desigual.
  5. Si no hay instancias en buen estado con capacidad disponible en una región determinada, el balanceador de cargas envía la solicitud a la siguiente región más cercana con capacidad disponible.

Nivel Estándar

Cuando se usa el nivel Estándar, el balanceador de cargas HTTP(S) externo es un servicio regional. Sus grupos de instancias de backend o NEG deben estar ubicados en la región que usa la dirección IP externa y la regla de reenvío del balanceador de cargas.

Regiones y zonas

Después de que el balanceador de cargas HTTP(S) externo seleccione una región:

  • Si configuraste backends en varias zonas dentro de la región, el balanceador de cargas HTTP(S) externo intenta balancear las solicitudes de la manera más uniforme posible en todas las zonas, sujeto a la capacidad de la instancia de backend y la afinidad de sesión.

  • Dentro de una zona, el balanceador de cargas HTTP(S) externo intenta balancear las solicitudes mediante el algoritmo de balanceo de cargas, sujeto a la capacidad disponible y a la afinidad de sesión.

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.

El balanceo de cargas de HTTP(S) de Google Cloud ofrece tres tipos de afinidad de sesión:

  • NONE. No se configuró la afinidad de sesión para el balanceador de cargas.
  • La afinidad de IP de cliente envía solicitudes desde la misma dirección IP de cliente al mismo backend.
  • La afinidad de cookie generada establece una cookie de cliente cuando se realiza la primera solicitud y, luego, envía las solicitudes con esa cookie al mismo backend.

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

Conmutación por error

Si un backend se encuentra en mal estado, el tráfico se redireccionará de forma automática a los backends en buen estado dentro de la misma región. Si todos los backends de una región están en mal estado, el tráfico se distribuirá a los backends en buen estado en otras regiones (solo nivel Premium). Si todos los backends están en mal estado, el balanceador de cargas muestra una respuesta HTTP 502 Bad Gateway.

Compatible con WebSocket

Los balanceadores de cargas basados en HTTP(S) de Google Cloud tienen compatibilidad nativa con 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 WebSocket proporciona un canal de comunicación dúplex completo entre clientes y servidores. Una solicitud HTTP(S) inicia el canal. Para obtener información detallada sobre el protocolo, consulta RFC 6455.

Cuando el balanceador de cargas reconoce una solicitud Upgrade de WebSocket de un cliente HTTP(S) seguida de una respuesta Upgrade correcta de la instancia de backend, el balanceador de cargas usa proxies para el tráfico bidireccional mientras dure la conexión actual. Si la instancia de backend no muestra una respuesta Upgrade correcta, el balanceador de cargas cierra la conexión.

El tiempo de espera para una conexión de WebSocket depende del tiempo de espera del servicio de backend configurable del balanceador de cargas, que es de 30 segundos según la configuración predeterminada. Este tiempo de espera se aplica a las conexiones de WebSocket sin importar si están en uso.

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

Compatibilidad con los protocolos HTTP/3 y QUIC

HTTP/3 es un protocolo de Internet de última generación. Se basa en QUIC, un protocolo desarrollado a partir del protocolo Google QUIC original (gQUIC). HTTP/3 es compatible entre el balanceador de cargas HTTP(S) externo, Cloud CDN y los clientes.

En particular, haz lo siguiente:

  • QUIC es un protocolo de capa de transporte que proporciona control de congestión similar a TCP. También proporciona seguridad equivalente a SSL/TLS para HTTP/2 con un rendimiento mejorado.
  • HTTP/3 es una capa de aplicación basada en IETF QUIC y utiliza QUIC para manejar la multiplexación, el control de la congestión y los reintentos.
  • 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.
  • Afecta las conexiones entre los clientes y el balanceador de cargas, no aquellas conexiones entre el balanceador de cargas y sus backends.
  • Las conexiones HTTP/3 usan el protocolo de control de congestión BBR.

Habilitar HTTP/3 en el balanceador de cargas de HTTP(S) externo 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.

Configura HTTP/3

Puedes habilitar de forma explícita la compatibilidad con HTTP/3 para tu balanceador de cargas de HTTP(S) externo si configuras quicOverride como ENABLE. En el futuro, HTTP/3 se habilitará de forma predeterminada para todos los clientes externos de balanceador de cargas HTTP(S).

Los clientes que no admiten HTTP/3 ni gQUIC no negocian una conexión HTTP/3. No es necesario que inhabilites HTTP/3 de forma explícita, a menos que hayas identificado implementaciones cliente dañadas o antiguas.

El balanceador de cargas HTTP(S) externo proporciona tres modos para configurar HTTP/3 como se muestra en la siguiente tabla.

Valor quicOverride Comportamiento
NONE

HTTP/3 y Google QUIC no se anuncian a los clientes.

Nota: Esto podría cambiar en el futuro, y HTTP/3 se anunciará a los clientes de forma predeterminada.

ENABLE

La compatibilidad con HTTP/3 y Google QUIC se anuncia a los clientes. HTTP/3 se anuncia con mayor prioridad. Los clientes que admiten ambos protocolos deben preferir HTTP/3 sobre Google QUIC.

Nota: TLS 0-RTT (también conocido como datos anticipados de TLS) es compatible de manera implícita cuando el cliente negocia Google QUIC, pero no lo es actualmente cuando se usa 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 Google Cloud Console, ve a la página Balanceo de cargas.

    Ir a Balanceo de cargas

  2. Selecciona el balanceador de cargas HTTP(S) externo que deseas editar.

  3. Haga clic en Configuración de frontend.

  4. Selecciona la dirección IP y el puerto de frontend que deseas editar. Para editar la configuración de HTTP/3, la dirección IP y el puerto deben ser HTTPS (puerto 443).

Habilita HTTP/3

  1. Selecciona el menú desplegable 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ú desplegable 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) le permite a Google controlar cuándo se negocia QUIC.

    En este momento, cuando seleccionas NONE, QUIC está inhabilitado. Si seleccionas esta opción, permitirás que Google habilite de forma automática las negociaciones de QUIC y HTTP/3 en el futuro para este balanceador de cargas. En Cloud Console, 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.

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) le permite a Google controlar cuándo se negocia QUIC.

    En este momento, cuando seleccionas NONE, QUIC está inhabilitado. Si seleccionas esta opción, permitirás que Google habilite de forma automática las negociaciones de QUIC y HTTP/3 en el futuro para este balanceador de cargas. En Cloud Console, 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.

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 QUIC.
  • 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 QUIC 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 se configura como ENABLE en el recurso targetHttpsProxy del balanceador de cargas HTTP(S) externo, las respuestas del balanceador de cargas HTTP(S) externo incluyen el siguiente valor de encabezado alt-svc:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,
h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,
quic=":443"; ma=2592000; v="46,43"

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

Cuando tienes QUIC 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 QUIC. Esto incluye los siguientes casos:

  • 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 QUIC
  • 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 debido a estas circunstancias, no consideramos esto como una falla del balanceador de cargas.

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

Compatibilidad con TLS

De forma predeterminada, un proxy HTTPS de destino solo acepta TLS 1.0, 1.1, 1.2 y 1.3 cuando finaliza las solicitudes SSL del cliente. Puedes usar las políticas de SSL para cambiar este comportamiento predeterminado y controlar cómo el balanceador de cargas negocia SSL con los clientes.

Cuando el balanceador de cargas HTTP(S) externo usa HTTPS como un protocolo de servicio de backend, puede negociar TLS 1.0, 1.1 o 1.2 con el backend.

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

  • Los balanceadores de cargas de HTTPS no admiten la autenticación basada en certificados de cliente, también conocida como autenticación TLS mutua.
  • 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.

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.
  • 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 Cloud Console. Si el extremo de gRPC muestra un error, los registros del balanceador de cargas y los datos de supervisión informan el código de respuesta HTTP “OK 200”.

Restricción de Cloud CDN

  • No puedes habilitar Identity-Aware Proxy y Cloud CDN en el mismo servicio de backend. Si intentas hacerlo, el proceso de configuración fallará.

¿Qué sigue?