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

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

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 HTTP(S) externos abordan muchos casos prácticos. En esta sección, se proporcionan algunos ejemplos de alto nivel.

Balanceo de cargas con varios 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, también, IPv6 externos pueden solicitar contenido de imágenes, API y video mediante la misma URL base, con las rutas /api, /video y /images.

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

  • Las solicitudes a la ruta /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 /images van a un depósito de backend con un backend de Cloud Storage.
  • Las solicitudes a la ruta /video van a un servicio de backend que apunta a un NEG de Internet que contiene un extremo externo ubicado en las instalaciones, 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 origen personalizado (haz clic para agrandar)
Diagrama de balanceo de cargas con un origen personalizado (haz clic para ampliar)

En cada servicio de backend, puedes habilitar 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 evita que esa solicitud llegue al servidor de origen de CDN.

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

Servicios web de tres niveles

Puedes usar el balanceo de cargas 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 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 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 HTTP(S) a un conjunto de balanceadores de cargas HTTP(S) internos y regionales.
  3. Los balanceadores de cargas 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 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 (haz clic si deseas ampliar)
Enrutamiento basado en la capa 7 para niveles internos en una app de varios niveles

Arquitectura y recursos

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

Componentes de balanceo de cargas HTTP(S) (haz clic para ampliar)
Componentes del balanceo de cargas HTTP(S)

Los siguientes recursos definen un balanceador de cargas 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 HTTPS, el proxy HTTPS de destino usa certificados SSL globales para demostrar su identidad a los clientes. Un proxy HTTP(S) de destino admite hasta un número documentado 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 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 enviar redireccionamientos a los clientes.

  • Un servicio de backend o un depósito de backend distribuye las solicitudes a backends en buen estado (grupos de instancias que contienen VM de Compute Engine, NEG que contienen contenedores de GKE).

  • Uno o más backends deben estar conectados al servicio de backend o al depósito 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 periódicamente la preparación de tus backends. Esto reduce el riesgo de que las solicitudes se envíen a backends que no pueden procesar la solicitud.

  • Un firewall para que tus backends acepten sondeos de verificación de estado.

Direcciones IP de origen

Las direcciones IP de origen de los paquetes, vistas por cada contenedor o instancia 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/16 o 130.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).

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 HTTPS.
  • No puedes inhabilitar HTTP/2 si realizas 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 HTTPS no admiten la autenticación basada en certificados de cliente, también conocida como autenticación TLS mutua.

Puertos abiertos

Los balanceadores de cargas HTTP(S) son balanceadores de cargas de proxy inverso. El balanceador de cargas finaliza las conexiones entrantes y abre nuevas conexiones del balanceador de cargas a los backends. Google Front End (GFE) proporciona la función de proxy inverso.

Las reglas de firewall que configuras bloquean el tráfico de los GFE a los backends, pero no bloquean el tráfico entrante a los GFE.

Los balanceadores de cargas HTTP(S) externos tienen varios puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Si ejecutas un análisis de puertos o de seguridad en función de la dirección IP externa de un balanceador de cargas HTTP(S) externo de Google Cloud, parecerá que hay puertos adicionales abiertos.

Esto no afecta a los balanceadores de cargas HTTP(S) externos. Las reglas de reenvío externas, que se usan en la definición de un balanceador de cargas HTTP(S) externo, solo pueden hacer referencia a los puertos TCP 80, 8080 y 443. El tráfico con un puerto de destino TCP diferente no se reenvía al backend del balanceador de cargas.

Componentes

Los siguientes son componentes de balanceadores de cargas HTTP(S) externos.

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 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 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 HTTP(S) externos depende del nivel de servicio de red en el que se encuentre el balanceador de cargas.

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

Proxies objetivos

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/respuesta HTTP de la siguiente manera:

  • Via: 1.1 google (solicitudes y respuestas)
  • X-Forwarded-Proto: [http | https] (solo invitaciones)
  • X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in Google Cloud> (solo invitaciones)

    El encabezado X-Forwarded-For (XFF) contiene una lista de direcciones IP separadas por comas que representan los proxies por los que pasó la solicitud. Cada proxy puede adjuntar la dirección IP de su cliente a la lista. Debido a esto, la cantidad de direcciones IP en el encabezado XFF puede variar. Un balanceador de cargas HTTP(S) externo de Google Cloud agrega dos direcciones IP al encabezado: la del cliente solicitante y la externa de la regla de reenvío del balanceador de cargas, en ese orden.

    Por lo tanto, la dirección IP que precede inmediatamente a la dirección IP del balanceador de cargas de Google Cloud es la dirección IP del sistema que se comunica con el balanceador de cargas. El sistema puede ser un cliente o, también, podría ser otro servidor proxy fuera de Google Cloud que reenvía las solicitudes en nombre de un cliente.

    Cuando un servidor proxy fuera de Google Cloud contacta al balanceador de cargas HTTP(S) externo de Google Cloud en nombre de un cliente, es posible que el balanceador de cargas no reciba la dirección IP del sistema que contacta al proxy externo. Es posible que el proxy externo no adjunte la dirección IP de su cliente al encabezado XFF. Si todos los proxies externos agregan una dirección IP de cliente al encabezado XFF, la primera dirección IP de la lista es la del cliente original.

    Si las VM de backend de un balanceador de cargas HTTP(S) externo funcionan como proxies internos, es posible que se agreguen más direcciones IP del cliente al encabezado XFF. En este caso, es posible que la dirección IP de la regla de reenvío del balanceador de cargas HTTP(S) externo no sea la última de la lista.

  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (solo invitaciones)

    Contiene parámetros para Cloud Trace.

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

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.

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 entre regiones, es posible que no definas ninguna regla de URL y solo te bases en el servicio predeterminado. Para el enrutamiento de tráfico basado en el contenido, la asignación de URL te permite dividir tu 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 HTTPS, debes instalar uno o más certificados SSL en el proxy HTTPS de destino.

Los proxies SSL de destino utilizan estos certificados para proteger las comunicaciones entre Google Front End (GFE) y el cliente. Estos pueden ser certificados SSL administrados por Google o autoadministrados.

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 HTTPS externo. Para obtener más información, consulta Encriptación del balanceador de cargas en los backends.

Para obtener información sobre cómo Google encripta el tráfico de los usuarios, consulta el informe de 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.

Control geográfico sobre dónde se finaliza 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 control geográfico sobre la ubicación donde finaliza TLS, usa el balanceo de cargas de red de Google Cloud y finaliza TLS en backends ubicados en regiones adecuadas para tus necesidades.

Servicios de backend

Los servicios de backend proporcionan información de configuración al balanceador de cargas. Un balanceador de cargas HTTP(S) externo debe tener al menos un servicio de backend. Además, puede tener varios servicios de backend.

Los balanceadores de cargas usan la información en un servicio de backend para dirigir el tráfico entrante a uno o más backends adjuntos.

Los backends de un servicio de backend pueden ser grupos de instancias o grupos de extremos de red (NEG), pero no una combinación de ambos. Cuando agregas un grupo de instancias de backend o NEG, debes especificar un modo de balanceo, el cual define un método para distribuir solicitudes y una capacidad de destino. Para obtener más información, consulta Algoritmo de distribución de cargas.

El balanceo de cargas HTTP(S) es compatible con el escalador automático de Cloud Load Balancing, que permite a los usuarios realizar ajustes de escalas automáticos en los grupos de instancias de un servicio de backend. Para obtener más información, consulta Escala en función de la capacidad de entrega del balanceo de cargas HTTP(S).

Puedes habilitar el desvío de conexiones en servicios de backend a fin de garantizar una interrupción mínima para tus usuarios cuando se finaliza una instancia que entrega tráfico, se quita de forma manual o la quita un escalador automático. Para obtener más información, consulta Habilita el vaciado de conexiones.

Los cambios en un servicio de backend asociado con un balanceador de cargas HTTP(S) externo no son instantáneos. Pueden demorar varios minutos en propagarse por la red.

Comportamiento del balanceador de cargas en diferentes niveles de servicio de red

El balanceo de cargas HTTP(S) es un servicio global cuando se usa el nivel de servicio de red Premium. Es posible que tengas más de un servicio de backend en una región y que puedas 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 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.

El balanceo de cargas HTTP(S) es un servicio regional cuando se usa el nivel estándar del servicio de red. 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.

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 correctamente, debes crear una regla de firewall que permita que el tráfico de 130.211.0.0/22 y 35.191.0.0/16 llegue a tus 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 HTTP(S) externo, configuras 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 marco de trabajo 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 de proxy de extremo a extremo en HTTP/2. Para hacerlo con un balanceador de cargas 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 HTTP(S) externo configurado para usar HTTP/2 entre el balanceador de cargas y las instancias de backend. 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.

Si quieres configurar un balanceador de cargas HTTP(S) externo mediante HTTP/2 con Google Kubernetes Engine Ingress 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 de HTTP/2, consulta Solución de problemas de HTTP/2 en los backends.

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

Depósitos de backend

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

Como se muestra en el siguiente diagrama, puedes hacer que el balanceador de cargas envíe tráfico con una ruta de /static a un depósito de almacenamiento y todas las demás solicitudes a tus otros backends.

Distribución de tráfico a varios tipos de backends con balanceo de cargas HTTP(S) (haz clic para agrandar)
Distribución de tráfico a varios tipos de backend con balanceo de cargas HTTP(S) (haz clic para agrandar)

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

Reglas de firewall

Debes crear una regla de firewall que permita que el tráfico de 130.211.0.0/22 y 35.191.0.0/16 llegue a tus instancias o a los extremos de backend. Estos rangos de direcciones IP se usan como fuentes 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 configuras para esta regla de firewall deben permitir el tráfico a instancias o a extremos de backend:

  • Debes permitir los puertos que usa cada regla de reenvío
  • Debes permitir los puertos que usa cada verificación de estado configurada para cada servicio de backend.

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/22 y 35.191.0.0/16, consulta Rangos de IP de 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 la sección sobre rutas de acceso de retorno del balanceador de cargas.

Algoritmo de distribución de cargas

El balanceo de cargas HTTP(S) externo admite dos modos de balanceo para backends:

  • RATE para backends de grupos de instancias o NEG
  • UTILIZATION para backends de grupos de instancias

Los backends de un servicio de backend pueden ser grupos de instancias o NEG, pero no una combinación de ambos. Cuando agregas un grupo de instancias de backend o NEG, debes especificar un modo de balanceo, el cual define un método para distribuir solicitudes y una capacidad de destino. Para los backends de grupos de instancias, puedes usar el modo de balanceo UTILIZATION o RATE. Para los NEG, debes usar RATE.

Cuando utilizas el modo de balanceo RATE, debes especificar una cantidad máxima de solicitudes (consultas) por segundo (RPS, QPS). Este objetivo se utiliza para definir cuándo una instancia o extremo llegó al máximo de capacidad. La cantidad máxima de RPS/QPS puede excederse si se alcanza o supera la capacidad de todos los backends.

Cuando un balanceador de cargas HTTP(S) externo está en nivel Premium, las solicitudes enviadas al balanceador de cargas 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.

Cuando un balanceador de cargas HTTP(S) externo está en nivel Estándar, sus grupos de instancias backend o NEG deben ubicarse en la región que usan la dirección IP externa y la regla de reenvío del balanceador de cargas.

A continuación, se describe lo que sucede después de seleccionar una región:

  • Un balanceador de cargas HTTP(S) externo intenta balancear las solicitudes de la manera más uniforme posible dentro de las zonas de una región, sujeto a la afinidad de sesión. Cuando configuras varios NEG o grupos de instancias zonales en la misma región, o uno o más grupos de instancias administrados regionales, el balanceador de cargas HTTP(S) externo se comporta de esta manera.

  • Dentro de una zona, un balanceador de cargas HTTP(S) externo intenta balancear las solicitudes mediante un algoritmo round-robin, sujeto a la afinidad de sesión.

Si quieres ver ejemplos específicos del algoritmo de distribución de cargas, consulta Cómo funciona el balanceo de cargas HTTP(S).

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 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 de la misma dirección IP de cliente al mismo backend.
  • La afinidad de cookie generada establece una cookie 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).

Compatibilidad de proxy con WebSocket

El balanceo de cargas HTTP(S) tiene compatibilidad nativa con el protocolo WebSocket cuando se usa HTTP o HTTPS (no HTTP/2) como protocolo para el backend.

Los backends que usan el protocolo WebSocket para comunicarse con los clientes pueden usar el balanceador de cargas HTTP(S) externo como frontend para mejorar el escalamiento y la disponibilidad. El balanceador de cargas no necesita ninguna configuración adicional para usar un proxy en las conexiones de WebSocket.

El protocolo WebSocket, que se define en RFC 6455, proporciona un canal de comunicación dúplex completo entre clientes y servidores. El canal se inicia a partir de una solicitud HTTP(S).

Cuando el balanceo de cargas HTTP(S) reconoce una solicitud WebSocket Upgrade de un cliente HTTP(S) y la solicitud es seguida por una respuesta Upgrade exitosa de la instancia de backend, el balanceador de cargas procesa el tráfico bidireccional mientras dure la conexión actual. Si el 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 de respuesta configurable del balanceador de cargas, que es de 30 segundos de forma predeterminada. Este tiempo de espera se aplica a las conexiones WebSocket independientemente de si están en uso. Para obtener más información sobre el tiempo de espera de respuesta y cómo configurarlo, consulta Tiempos de espera y reintentos.

Si configuraste la IP de cliente o generaste afinidad de sesión de cookies para tu balanceador de cargas HTTP(S), todas las conexiones de WebSocket de un cliente se envían a la misma instancia de backend, siempre que la instancia no deje de aprobar las verificaciones de estado y tenga capacidad.

El protocolo WebSocket es compatible con Ingress.

Compatibilidad con el protocolo QUIC para el balanceo de cargas HTTPS

El balanceo de cargas HTTPS admite el protocolo QUIC en las conexiones entre el balanceador de cargas y los clientes. QUIC es un protocolo de capa de transporte que proporciona control de congestión similar a TCP y seguridad equivalente a SSL/TLS para HTTP/2, con un rendimiento mejorado. QUIC permite un inicio más rápido de la conexión del cliente, elimina 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.

QUIC afecta las conexiones entre los clientes y el balanceador de cargas, no las conexiones entre el balanceador de cargas y sus backends.

La configuración de anulación QUIC del proxy de destino te permite habilitar una de las siguientes opciones:

  • Cuando sea posible, negociar QUIC para un balanceador de cargas
  • Inhabilitar QUIC siempre para un balanceador de cargas

Si no especificas un valor para la configuración de anulación QUIC, se permite que Google administre cuándo se usa QUIC. Google habilita QUIC solo cuando la marca --quic-override en la herramienta de línea de comandos de gcloud se configura como ENABLE o cuando la marca quicOverride en la API de REST se configura como ENABLE.

Para obtener información sobre cómo inhabilitar y habilitar la compatibilidad con QUIC, consulta Proxies de destino. Puedes habilitar o inhabilitar la compatibilidad con QUIC en la sección de configuración del frontend de Google Cloud Console mediante la herramienta de línea de comandos de gcloud o mediante la API de REST.

Cómo se negocia QUIC

Cuando habilitas QUIC, el balanceador de cargas puede anunciar su capacidad QUIC a los clientes, lo que permite que los clientes que admiten QUIC intenten establecer conexiones QUIC 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. 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.

Cuando tienes QUIC habilitado en el balanceador de cargas 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 QUIC que no son compatibles con las que admite el balanceador de cargas HTTPS
  • Cuando el balanceador de cargas detecta que el tráfico UDP está bloqueado o sometido a un límite de frecuencia tal que impediría el funcionamiento de QUIC
  • Si QUIC está inhabilitado de manera temporal para los balanceadores de cargas HTTPS en respuesta a errores, vulnerabilidades o algunas otras inquietudes

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 QUIC, asegúrate de que los comportamientos descritos anteriormente sean aceptables para tus cargas de trabajo.

Interfaces

Tu servicio de balanceo de cargas HTTP(S) se puede configurar y actualizar a través de las siguientes interfaces:

  • La herramienta de línea de comandos de gcloud: una herramienta de línea de comandos que se incluye en el SDK de Cloud. La documentación de balanceo de cargas HTTP(S) llama a esta herramienta con frecuencia para realizar tareas. Para obtener una descripción general completa de la herramienta, consulta la guía de la herramienta de gcloud. Puedes encontrar comandos relacionados con el balanceo de cargas en el grupo de comandos gcloud compute.

    También puedes obtener ayuda detallada para cualquier comando gcloud con la marca --help:

    gcloud compute http-health-checks create --help
    
  • Cloud Console: Las tareas de balanceo de cargas se pueden realizar con Cloud Console.

  • API de REST: Todas las tareas de balanceo de cargas pueden realizarse con la API de Google Cloud Load Balancing. En los documentos de referencia de la API, se describen los recursos y métodos disponibles.

Compatibilidad con TLS

De forma predeterminada, un proxy de destino HTTPS 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 usa HTTPS como un protocolo de servicio de backend, puede negociar TLS 1.0, 1.1 o 1.2 con el backend.

Tiempos de espera y reintentos

El balanceo de cargas HTTP(S) tiene dos tipos distintos de tiempos de espera:
  • Un tiempo de espera de respuesta HTTP configurable, que representa la cantidad de tiempo que el balanceador de cargas espera que el backend muestre una respuesta HTTP completa. El valor predeterminado para el tiempo de espera de respuesta es de 30 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 la conexión se actualiza a un WebSocket (solo balanceo de cargas HTTP[S])

    Para el tráfico de 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 de WebSocket puede permanecer abierta, ya sea que esté activa o no. Para obtener más información, consulta la 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 de 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;

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

Para obtener más información, consulta Registro y supervisión del balanceo de cargas HTTP(S).

Solicitud ilegal y manejo de respuestas

El balanceador de cargas HTTP(S) externo 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 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 trozos 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 de tamaño máximo de encabezado de respuesta del balanceo de cargas HTTP(S) externo.
  • La versión HTTP es desconocida.

Limitaciones

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 cuando se usa el protocolo HTTP(S), no está disponible actualmente con HTTP/2.
  • El uso de HTTP/2 entre el balanceador de cargas y el backend no es compatible con lo siguiente:
    • Extracción del servidor
    • WebSockets

Restricción sobre el uso de Cloud CDN

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

Qué sigue