Información general sobre el balanceador de carga de aplicación externo

En este documento se presentan los conceptos que debes conocer para configurar un balanceador de carga de aplicaciones externo.

Un balanceador de carga de aplicaciones externo es un balanceador de carga de capa 7 basado en proxy que te permite ejecutar y escalar tus servicios mediante una única dirección IP externa. El balanceador de carga de aplicaciones externo distribuye el tráfico HTTP y HTTPS a los backends alojados en variasTrusted Cloud plataformas (como Compute Engine, Google Kubernetes Engine [GKE] y Cloud Storage), así como a los backends externos conectados a través de Internet o mediante conectividad híbrida. Para obtener más información, consulta el artículo Descripción general de Application Load Balancer: casos prácticos.

Modos de funcionamiento

Este balanceador de carga está disponible en el modo regional y, a partir de ahora, se denominará balanceador de carga de aplicaciones externo regional. El balanceador de carga se implementa como un servicio gestionado basado en el proxy Envoy de código abierto. Incluye funciones avanzadas de gestión del tráfico, como la proyección de tráfico, la división del tráfico basada en el peso y las transformaciones de encabezados basadas en peticiones o respuestas. El modo regional asegura que todos los clientes y back-ends se encuentren en una región específica. Usa este balanceador de carga si quieres servir contenido desde una sola geolocalización (por ejemplo, para cumplir normativas).

Arquitectura

Para implementar un balanceador de carga de aplicaciones externo, se necesitan los siguientes recursos:

• Solo en el caso de los balanceadores de carga de aplicación externos regionales, se usa una subred solo de proxy para enviar conexiones desde el balanceador de carga a los backends.

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

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

  • En el balanceo de carga HTTPS, el proxy HTTPS de destino usa certificados SSL para demostrar su identidad a los clientes. Un proxy HTTPS de destino admite hasta el número documentado de certificados SSL.

• El proxy HTTP(S) usa un mapa de URLs para tomar una decisión de enrutamiento basada en atributos HTTP (como la ruta de la solicitud, las cookies o los encabezados). En función de la decisión de enrutamiento, el proxy reenvía las solicitudes del cliente a servicios de backend o a buckets de backend específicos. El mapa de URLs puede especificar acciones adicionales, como enviar redirecciones a los clientes.

• Un servicio de backend distribuye las solicitudes a backends

• Una comprobación de estado monitoriza periódicamente la disponibilidad de tus backends. De esta forma, se reduce el riesgo de que las solicitudes se envíen a back-ends que no puedan atenderlas.

• Reglas de cortafuegos para que tus backends acepten las sondas de comprobación del estado. Los balanceadores de carga de aplicación externos regionales requieren una regla de cortafuegos adicional para permitir que el tráfico de la subred de solo proxy llegue a los backends.

Regional

En este diagrama se muestran los componentes de una implementación de un balanceador de carga de aplicación externo regional.

Subred de solo proxy

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 carga de aplicaciones externos regionales. La marca --purpose de esta subred de solo proxy tiene el valor REGIONAL_MANAGED_PROXY. Todos los balanceadores de carga regionales basados en Envoy de 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 únicamente para los proxies de Envoy, no para tus back-ends.
• Las máquinas virtuales o los endpoints de backend de todos los balanceadores de carga de aplicaciones externos regionales de una región y una red de VPC reciben conexiones de la subred de solo proxy.
• La dirección IP del balanceador de carga de aplicación externo regional no se encuentra en la subred de solo proxy. La dirección IP del balanceador de carga se define mediante su regla de reenvío gestionada externa, que se describe más abajo.

Si has creado una subred de solo proxy con --purpose=INTERNAL_HTTPS_LOAD_BALANCER, migra el valor de "purpose" de la subred a REGIONAL_MANAGED_PROXY para poder crear otros balanceadores de carga basados en Envoy en la misma región de la red VPC.

Reglas de reenvío y direcciones IP

Las reglas de reenvío dirigen el tráfico a una configuración de balanceo de carga según la dirección IP, el puerto y el protocolo. Esta configuración consta de un proxy de destino, un mapa de URLs y uno o varios servicios de backend.

Especificación de la dirección IP. Cada regla de reenvío proporciona una sola dirección IP que se puede usar en los registros DNS de tu aplicación. No es necesario el balanceo de carga basado en DNS. Puedes especificar la dirección IP que se va a usar o dejar que Cloud Load Balancing te asigne una.

Especificación de puerto. Cada regla de reenvío de un balanceador de carga de aplicaciones puede hacer referencia a un único puerto del intervalo 1-65535. Para admitir varios puertos, debes configurar varias reglas de reenvío. Puedes configurar varias reglas de reenvío para que usen la misma dirección IP externa (VIP) y hagan referencia al mismo proxy HTTP(S) de destino, siempre que la combinación general de dirección IP, puerto y protocolo sea única para cada regla de reenvío. De esta forma, puedes usar un único balanceador de carga con un mapa de URLs compartido como proxy de varias aplicaciones.

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

Para ver la lista completa de protocolos admitidos por las reglas de reenvío de los balanceadores de carga de aplicaciones externos en cada modo, consulta las funciones de los balanceadores de carga.

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 carga de aplicaciones externos con las redes de VPC.

Proxies de destino

Los proxies de destino terminan las conexiones HTTP(S) de los clientes. Una o varias reglas de reenvío dirigen el tráfico al proxy de destino, y este consulta el mapa de URLs para determinar cómo enrutar el tráfico a los back-ends.

No confíe en el proxy para conservar las mayúsculas y minúsculas de los nombres de los encabezados de las solicitudes o respuestas. Por ejemplo, un encabezado de respuesta Server: Apache/1.0 puede aparecer 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 carga de aplicaciones externos.

Además de los encabezados que añade el proxy de destino, el balanceador de carga ajusta otros encabezados HTTP de las siguientes formas:

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

Encabezado de host

Cuando el balanceador de carga hace la solicitud HTTP, conserva el encabezado Host de la solicitud original.

Encabezado X-Forwarded-For

El balanceador de carga añade dos direcciones IP al encabezado X-Forwarded-For, separadas por una sola coma, en el siguiente orden:

1. La dirección IP del cliente que se conecta al balanceador de carga.
2. La dirección IP de la regla de reenvío del balanceador de carga

Si la solicitud entrante no incluye un encabezado X-Forwarded-For, el encabezado resultante es el siguiente:

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

Si la solicitud entrante ya incluye un encabezado X-Forwarded-For, el balanceador de carga añade sus valores al encabezado:

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

Quitar valores de encabezado con un encabezado de solicitud personalizado

Puedes eliminar los valores de encabezado que ya tengas mediante encabezados de solicitud personalizados en el servicio de backend. En el siguiente ejemplo se usa la marca --custom-request-header para recrear el encabezado X-Forwarded-For mediante las variables client_ip_address y server_ip_address. Esta configuración sustituye el encabezado X-Forwarded-For entrante por la dirección IP del cliente y del balanceador de carga.

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

Cómo puede modificar el software de proxy inverso de backend el encabezado X-Forwarded-For

Si los backends de tu balanceador de carga ejecutan un software de proxy inverso HTTP, es posible que el software añada una o ambas de las siguientes direcciones IP al final del encabezado X-Forwarded-For:

1. La dirección IP del GFE que se ha conectado al backend. Las direcciones IP de GFE se encuentran en los intervalos 130.211.0.0/22 y 35.191.0.0/16.

2. La dirección IP del propio sistema backend.

Como resultado, un sistema upstream puede ver un encabezado X-Forwarded-For estructurado de la siguiente manera:

<existing-value>,<client-ip>,<load-balancer-ip>,<GFE-ip>,<backend-ip>

Asistencia de Cloud Trace

El seguimiento no es compatible con los balanceadores de carga de aplicaciones. Los balanceadores de carga de aplicación globales y clásicos añaden el encabezado X-Cloud-Trace-Context si no está presente. El balanceador de carga de aplicación externo regional no añade este encabezado. Si el encabezado X-Cloud-Trace-Context ya está presente, pasa por los balanceadores de carga sin modificaciones. Sin embargo, el balanceador de carga no exporta ningún rastro ni intervalo.

Mapas de URL

Los mapas de URLs definen patrones de coincidencia para el enrutamiento de solicitudes basado en URLs a los servicios de backend adecuados. El mapa de URLs te permite dividir el tráfico examinando los componentes de la URL para enviar solicitudes a diferentes conjuntos de back-ends. Se define un servicio predeterminado para gestionar las solicitudes que no coincidan con una regla de host o una regla de coincidencia de ruta especificadas.

Los mapas de URLs admiten varias funciones avanzadas de gestión del tráfico, como la dirección del tráfico basada en encabezados, la división del tráfico basada en el peso y la duplicación de solicitudes. Para obtener más información, consulta las siguientes secciones:

• Descripción general de la gestión del tráfico del balanceador de carga de aplicación externo regional

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

Certificados SSL

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

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

Los balanceadores de carga de aplicaciones externos regionales admiten certificados SSL de Compute Engine autogestionados.

Políticas de SSL

Las políticas de SSL especifican el conjunto de funciones de SSL que usan los balanceadores de carga Trusted Cloud al negociar el protocolo SSL con los clientes.

De forma predeterminada, el balanceo de carga HTTPS usa un conjunto de funciones SSL que proporciona una buena seguridad y una amplia compatibilidad. Algunas aplicaciones requieren más control sobre las versiones y los cifrados de SSL que se utilizan en sus conexiones HTTPS o SSL. Puedes definir una política de SSL para especificar el conjunto de funciones de SSL que usa tu balanceador de carga al negociar el protocolo 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 con la política de SSL de los balanceadores de carga en cada modo.

Servicios de backend

Un servicio de backend proporciona información de configuración al balanceador de carga para que pueda dirigir las solicitudes a sus backends, como grupos de instancias de Compute Engine o grupos de puntos finales de red (NEGs). Para obtener más información sobre los servicios de backend, consulta el resumen de los servicios de backend.

Ámbito del servicio de backend

En la siguiente tabla se indica qué recurso y ámbito de servicio de backend utilizan los balanceadores de carga de aplicaciones externos:

Protocolo a los backends

Los servicios de backend de los balanceadores de carga de aplicaciones deben usar uno de los siguientes protocolos para enviar solicitudes a los backends:

• HTTP, que usa HTTP/1.1 y no usa TLS
• HTTPS, que usa HTTP/1.1 y TLS
• HTTP/2, que usa HTTP/2 y TLS (no se admite HTTP/2 sin cifrado).
• H2C, que usa HTTP/2 a través de TCP. No se requiere TLS. H2C no es compatible con los balanceadores de carga de aplicación clásicos.

El balanceador de carga solo usa el protocolo de servicio de backend que especifiques para comunicarse con sus backends. El balanceador de carga no recurre a otro protocolo si no puede comunicarse con los backends mediante el protocolo del servicio de backend especificado.

No es necesario que el protocolo del servicio de backend coincida con el protocolo que usan los clientes para comunicarse con el balanceador de carga. Por ejemplo, los clientes pueden enviar solicitudes al balanceador de carga mediante HTTP/2, pero el balanceador de carga puede comunicarse con los backends mediante HTTP/1.1 (HTTP o HTTPS).

Backends

Un balanceador de carga de aplicaciones externo regional admite los siguientes tipos de back-ends:

• Grupos de instancias
• NEGs por zonas
• NEGs de Internet

Back-ends y redes de VPC

En el caso de los backends de balanceadores de carga de aplicaciones externos regionales, se aplican las siguientes condiciones:

• En el caso de los grupos de instancias, los NEGs zonales y los NEGs de conectividad híbrida, todos los backends deben estar ubicados en el mismo proyecto y en la misma región que el servicio de backend. Sin embargo, un balanceador de carga puede hacer referencia a un backend que utilice una red de VPC diferente en el mismo proyecto que el servicio de backend. La conectividad entre la red VPC del balanceador de carga y la red VPC de backend se puede configurar mediante el peering de redes VPC, los túneles de Cloud VPN o las vinculaciones de VLAN de Cloud Interconnect.

  Definición de la red de backend

  • En el caso de los NEG zonales y los NEG híbridos, debes especificar explícitamente la red de VPC al crear el NEG.
  • En el caso de los grupos de instancias gestionados, la red VPC se define en la plantilla de instancia.
  • En los grupos de instancias no gestionados, la red VPC del grupo de instancias se configura para que coincida con la red VPC de la interfaz nic0 de la primera VM que se añade al grupo de instancias.

  Requisitos de red del backend

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

  • La red de VPC del backend debe coincidir exactamente 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 emparejamiento entre redes de VPC. Debes configurar los intercambios de rutas de subred para permitir la comunicación entre la subred solo proxy de la red de VPC de la regla de reenvío y las subredes que usan las instancias o los endpoints de backend.

• En el resto de los tipos de backend, todos los backends deben estar ubicados en la misma red VPC y región.

  Los balanceadores de carga de aplicaciones externos regionales también admiten entornos de VPC compartida, en los que puedes compartir redes de VPC y sus recursos asociados entre proyectos. Si quieres que el servicio de backend y los backends del balanceador de carga de aplicaciones externo regional estén en un proyecto diferente al de la regla de reenvío, debes configurar el balanceador de carga en un entorno de VPC compartida con referencia de servicios entre proyectos.

Backends e interfaces de red

Si usas backends de grupos de instancias, los paquetes siempre se envían a nic0. Si quieres enviar paquetes a interfaces que no sean nic0 (ya sean NICs virtuales o interfaces de red dinámicas), usa back-ends de NEG.

Si usas backends de NEG por zonas, los paquetes se envían a la interfaz de red que represente el endpoint en el NEG. Los endpoints del NEG deben estar en la misma red VPC que la red VPC definida explícitamente del NEG.

Comprobaciones del estado

Cada servicio de backend especifica una comprobación del estado que monitoriza periódicamente la disponibilidad de los backends para recibir una conexión del balanceador de carga. De esta forma, se reduce el riesgo de que las solicitudes se envíen a backends que no puedan atenderlas. Las comprobaciones de estado no comprueban si la aplicación funciona.

Para las comprobaciones del estado, debe crear una regla de cortafuegos de entrada que permita que las comprobaciones del estado lleguen a sus instancias de backend. Por lo general, las sondas de comprobación del estado proceden del mecanismo de comprobación del estado centralizado de Google.

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

Protocolo de comprobación del estado

Aunque no es obligatorio y no siempre es posible, es recomendable usar una comprobación de estado cuyo protocolo coincida con el protocolo del servicio backend. Por ejemplo, una comprobación del estado de HTTP/2 prueba con mayor precisión la conectividad HTTP/2 con los back-ends. Por el contrario, los balanceadores de carga de aplicación externos regionales que usan backends de NEG híbridos no admiten comprobaciones del estado de gRPC. Para ver la lista de protocolos de comprobación del estado admitidos, consulta las funciones de balanceo de carga.

En la siguiente tabla se especifica el ámbito de las comprobaciones de estado admitidas por los balanceadores de carga de aplicaciones externos en cada modo.

Para obtener más información sobre las comprobaciones del estado, consulta lo siguiente:

• Información general sobre las comprobaciones del estado
• Crear comprobaciones del estado

Reglas de cortafuegos

El balanceador de carga requiere las siguientes reglas de cortafuegos:

• En el caso de los balanceadores de carga de aplicación externos regionales, una regla de entrada permitida para permitir que el tráfico de la subred de solo proxy llegue a tus backends.
• Una regla de permiso de entrada para permitir el tráfico de los intervalos de las sondas de comprobación del estado. Para obtener más información sobre las sondas de comprobación de estado y por qué es necesario permitir el tráfico procedente de ellas, consulta Intervalos de IP de las sondas y reglas de firewall.

Las reglas de cortafuegos se implementan a nivel de instancia de VM, no en proxies de GFE. No puedes usar Trusted Cloud reglas de cortafuegos para evitar que el tráfico llegue al balanceador de carga.

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

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

• En el caso de los backends de grupos de instancias, determine los puertos que se van a configurar mediante la asignación entre el puerto con nombre del servicio de backend y los números de puerto asociados a ese puerto con nombre en cada grupo de instancias. Los números de puerto pueden variar entre los grupos de instancias asignados al mismo servicio de backend.

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

Asistencia de GKE

GKE usa balanceadores de carga de aplicaciones externos de las siguientes formas:

• Las pasarelas externas creadas con el controlador de pasarela de GKE pueden usar cualquier modo de un balanceador de carga de aplicación externo. Puedes controlar el modo del balanceador de carga eligiendo un GatewayClass. El controlador de pasarela de GKE siempre usa back-ends de NEG zonales GCE_VM_IP_PORT.

• Puedes usar GCE_VM_IP_PORT NEG zonales creados y gestionados por Servicios de GKE como backends de cualquier balanceador de carga de aplicaciones o balanceador de carga de red proxy. Para obtener más información, consulta Balanceo de carga nativo de contenedores mediante NEG de zona independientes.

Arquitectura de VPC compartida

Los balanceadores de carga de aplicaciones externos admiten redes que usan VPC compartida. La VPC compartida permite a las organizaciones conectar recursos de varios proyectos a una red de VPC común para que puedan comunicarse entre sí de forma segura y eficiente mediante direcciones IP internas de esa red. Si no conoces la VPC compartida, consulta la descripción general de la VPC compartida.

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

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

Todos los componentes y backends del balanceador de carga de un proyecto de servicio

En el siguiente diagrama de arquitectura se muestra una implementación estándar de VPC compartida en la que todos los componentes y backends del balanceador de carga se encuentran en un proyecto de servicio. Todos los balanceadores de carga de aplicaciones admiten este tipo de implementación.

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

Referencia de servicios entre proyectos

La referencia de servicios entre proyectos es un modelo de implementación en el que el frontend y el mapa de URLs del balanceador de carga se encuentran en un proyecto, mientras que el servicio de backend y los backends del balanceador de carga están en otro proyecto.

La referencia de servicios entre proyectos permite a las organizaciones configurar un balanceador de carga central y dirigir el tráfico a cientos de servicios distribuidos en varios proyectos diferentes. Puede gestionar de forma centralizada todas las reglas y políticas de enrutamiento del tráfico en un solo mapa de URLs. También puedes asociar el balanceador de carga a un único conjunto de nombres de host y certificados SSL. Por lo tanto, puedes optimizar el número de balanceadores de carga necesarios para desplegar tu aplicación y reducir los costes operativos, los requisitos de cuota y la capacidad de gestión.

Si asignas un proyecto diferente a cada uno de tus equipos funcionales, también puedes separar los roles dentro de tu organización. Los propietarios de los servicios pueden centrarse en crear servicios en proyectos de servicios, mientras que los equipos de redes pueden aprovisionar y mantener balanceadores de carga en otro proyecto. Ambos pueden conectarse mediante la referencia de servicios entre proyectos.

Los propietarios de los servicios pueden mantener la autonomía sobre la exposición de sus servicios y controlar qué usuarios pueden acceder a ellos mediante el balanceador de carga. Esto se consigue mediante un rol de gestión de identidades y accesos especial llamado rol de usuario de servicios de balanceador de carga de Compute (roles/compute.loadBalancerServiceUser).

La compatibilidad con las referencias de servicios entre proyectos varía en función del tipo de balanceador de carga:

• En el caso de los balanceadores de carga de aplicación externos globales, el frontend y el mapa de URLs de tu balanceador de carga pueden hacer referencia a servicios de backend o a cubos de backend de cualquier proyecto de la misma organización. No se aplican restricciones de redes de VPC. Aunque puedes usar un entorno de VPC compartida para configurar una implementación entre proyectos, como se muestra en este ejemplo, no es obligatorio.

• En el caso de los balanceadores de carga de aplicación externos regionales, debes crear el balanceador de carga en un entorno de VPC compartida. El frontend y el mapa de URLs del balanceador de carga deben estar en un proyecto host o de servicio, y los servicios de backend y los backends del balanceador de carga se pueden distribuir entre proyectos host o de servicio en el mismo entorno de VPC compartida.

Para saber cómo configurar una VPC compartida para un balanceador de carga de aplicaciones externo regional (con y sin referencia de servicio entre proyectos), consulta Configurar un balanceador de carga de aplicaciones externo regional con una VPC compartida.

Notas de uso de la referencia de servicios entre proyectos

• Trusted Cloud No diferencia entre recursos (por ejemplo, servicios backend) que tengan el mismo nombre en varios proyectos. Por lo tanto, cuando utilices referencias de servicios entre proyectos, te recomendamos que uses nombres de servicios backend únicos en todos los proyectos de tu organización.
• Si aparece un error como "No se permiten referencias entre proyectos para este recurso", asegúrate de que tienes permiso para usar el recurso. Un administrador del proyecto propietario del recurso debe concederte el rol Usuario de servicios de balanceador de carga de Compute (roles/compute.loadBalancerServiceUser). Este rol se puede conceder a nivel de proyecto o de recurso. Para ver un ejemplo, consulta Conceder permisos al administrador de balanceadores de carga de Compute para usar el servicio de backend o el bucket de backend.

Ejemplo 1: Frontend y backend del balanceador de carga en diferentes proyectos de servicio

A continuación, se muestra un ejemplo de una implementación de VPC compartida en la que el frontend y el mapa de URLs del balanceador de carga se crean en el proyecto de servicio A, y el mapa de URLs hace referencia a un servicio de backend en el proyecto de servicio B.

En este caso, los administradores de red o los administradores de balanceadores de carga del proyecto de servicio A necesitan acceder a los servicios backend del proyecto de servicio B. Los administradores del proyecto de servicio B conceden el rol Usuario de servicios de balanceador de carga de Compute (roles/compute.loadBalancerServiceUser) a los administradores del balanceador de carga del proyecto de servicio A que quieran hacer referencia al servicio de backend del proyecto de servicio B.

Ejemplo 2: Frontend del balanceador de carga en el proyecto host y backends en proyectos de servicio

A continuación, se muestra un ejemplo de una implementación de VPC compartida en la que el frontend y el mapa de URLs del balanceador de carga se crean en el proyecto del host, y los servicios de backend (y los backends) se crean en proyectos de servicio.

En este caso, los administradores de red o los administradores de balanceadores de carga del proyecto host necesitan acceder a los servicios backend del proyecto de servicio. Los administradores del proyecto de servicio conceden el rol Usuario de servicios de balanceador de carga de Compute (roles/compute.loadBalancerServiceUser) a los administradores del balanceador de carga del proyecto host A que quieran hacer referencia al servicio de backend del proyecto de servicio.

Ejemplo 3: Frontend y backends de un balanceador de carga en diferentes proyectos

A continuación, se muestra un ejemplo de una implementación en la que el frontend y el mapa de URLs del balanceador de carga de aplicación externo global se crean en un proyecto distinto del servicio de backend y los backends del balanceador de carga. Este tipo de despliegue no usa VPC compartida y solo se admite en balanceadores de carga de aplicación externos globales.

Para obtener más información sobre esta configuración, consulta el artículo Configurar referencias de servicios entre proyectos con un servicio backend y un backend bucket.

Alta disponibilidad y conmutación por error

La alta disponibilidad y la conmutación por error de los balanceadores de carga de aplicaciones externos se pueden configurar a nivel del balanceador de carga. Para ello, se crean balanceadores de carga de aplicaciones externos regionales de copia de seguridad en cualquier región en la que necesites una copia de seguridad.

En la siguiente tabla se describe el comportamiento de la conmutación por error.

Compatibilidad con HTTP/2

HTTP/2 es una revisión importante del protocolo HTTP/1. Hay dos modos de compatibilidad con HTTP/2:

• HTTP/2 sobre TLS
• HTTP/2 en texto sin cifrar a través de TCP

HTTP/2 sobre TLS

Se admite HTTP/2 a través de TLS para las conexiones entre los clientes y el balanceador de carga de aplicaciones externo, así como para las conexiones entre el balanceador de carga y sus backends.

El balanceador de carga negocia automáticamente HTTP/2 con los clientes como parte del handshake TLS mediante la extensión TLS ALPN. Aunque un balanceador de carga esté configurado para usar HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla en el cliente, no en el balanceador de carga.

Si un cliente no admite HTTP/2 y el balanceador de carga está configurado para usar HTTP/2 entre el balanceador de carga y las instancias de backend, el balanceador de carga puede negociar una conexión HTTPS o aceptar solicitudes HTTP no seguras. A continuación, el balanceador de carga transforma esas solicitudes HTTPS o HTTP para proxy las solicitudes a través de HTTP/2 a las instancias de backend.

Para usar HTTP/2 sobre TLS, debes habilitar TLS en tus backends y definir el protocolo del servicio de backend comoHTTP2. Para obtener más información, consulta Cifrado desde el balanceador de carga hasta los back-ends.

Número máximo de transmisiones simultáneas de HTTP/2

El ajuste HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS describe el número máximo de flujos que acepta un endpoint, iniciados por el peer. El valor que anuncia un cliente HTTP/2 a un balanceador de carga no tiene ningún sentido, ya que el balanceador de carga no inicia flujos al cliente.Trusted Cloud

En los casos en los que el balanceador de carga usa HTTP/2 para comunicarse con un servidor que se ejecuta en una máquina virtual, el balanceador de carga respeta el valor SETTINGS_MAX_CONCURRENT_STREAMS anunciado por el servidor, hasta un valor máximo de 100. En la dirección de la solicitud (Trusted Cloud balanceador de carga → servidor gRPC), el balanceador de carga usa el marco SETTINGS inicial del servidor gRPC para determinar cuántos flujos por conexión se pueden usar simultáneamente. Si el servidor anuncia un valor superior a 100, el balanceador de carga usa 100 como número máximo de flujos simultáneos. Si se anuncia un valor cero, el balanceador de carga no podrá reenviar solicitudes al servidor, lo que podría provocar errores.

Tamaño de la tabla de encabezados dinámica de HTTP/2

HTTP/2 mejora significativamente HTTP/1.1 con funciones como la multiplexación y la compresión de encabezados HPACK. HPACK usa una tabla dinámica que mejora la compresión de encabezados, lo que hace que todo sea más rápido. Para saber cómo influyen los cambios dinámicos en el tamaño de la tabla de encabezados en HTTP/2, cómo puede mejorar el rendimiento esta función y cómo un error específico en varias bibliotecas de clientes HTTP puede provocar problemas en la compresión de encabezados HPACK, consulta el artículo de la comunidad.

Limitaciones de HTTP/2

• HTTP/2 entre el balanceador de carga y la instancia puede requerir significativamente más conexiones TCP a la instancia que HTTP o HTTPS. La agrupación de conexiones, una optimización que reduce el número de estas conexiones con HTTP o HTTPS, no está disponible con HTTP/2. Por lo tanto, es posible que observes latencias de backend altas porque las conexiones de backend se realizan con más frecuencia.
• HTTP/2 entre el balanceador de carga y el backend no admite la ejecución del protocolo WebSocket a través de un solo flujo de una conexión HTTP/2 (RFC 8441).
• HTTP/2 entre el balanceador de carga y el backend no admite el envío desde el servidor.
• La tasa de errores de gRPC y el volumen de solicitudes no se muestran en laTrusted Cloud API ni en la Trusted Cloud consola. Si el endpoint de gRPC devuelve un error, los registros del balanceador de carga y los datos de monitorización informan del código de estado HTTP 200 OK.

HTTP/2 en texto sin formato a través de TCP (H2C)

HTTP/2 en texto sin cifrar a través de TCP, también conocido como H2C, te permite usar HTTP/2 sin TLS. H2C se admite en las siguientes conexiones:

• Conexiones entre los clientes y el balanceador de carga. No se requiere ninguna configuración especial.

• Conexiones entre el balanceador de carga y sus backends.

  Para configurar H2C en las conexiones entre el balanceador de carga y sus backends, debes definir el protocolo del servicio de backend como H2C.

La compatibilidad con H2C también está disponible para los balanceadores de carga creados con el controlador de GKE Gateway y Cloud Service Mesh.

H2C no es compatible con los balanceadores de carga de aplicación clásicos.

Compatibilidad con WebSocket

Trusted Cloud Los balanceadores de carga basados en HTTP(S) admiten el protocolo WebSocket cuando se usa HTTP o HTTPS como protocolo del backend. El balanceador de carga no requiere ninguna configuración para proxy las conexiones WebSocket.

El protocolo WebSocket proporciona un canal de comunicación bidireccional entre los clientes y el balanceador de carga. Para obtener más información, consulta el RFC 6455.

El protocolo WebSocket funciona de la siguiente manera:

1. El balanceador de carga reconoce una solicitud Upgrade de websocket de un cliente HTTP o HTTPS. La solicitud contiene los encabezados Connection: Upgrade y Upgrade: websocket, seguidos de otros encabezados de solicitud relevantes relacionados con websockets.
2. El backend envía una respuesta Upgrade de WebSocket. La instancia de backend envía una respuesta 101 switching protocol con los encabezados Connection: Upgrade y Upgrade: websocket, así como otros encabezados de respuesta relacionados con websockets.
3. El balanceador de carga proxyiza el tráfico bidireccional durante la conexión actual.

Si la instancia de backend devuelve un código de estado 426 o 502, el balanceador de carga cierra la conexión.

La afinidad de sesión para websockets funciona igual que para cualquier otra solicitud. Para obtener más información, consulta Afinidad de sesión.

Compatibilidad con gRPC

gRPC es un framework de código abierto para llamadas a procedimientos remotos. Se basa en el estándar HTTP/2. Estos son algunos de los usos de gRPC:

• Sistemas distribuidos de baja latencia y alta escalabilidad
• Desarrollar clientes móviles que se comuniquen con un servidor en la nube
• Diseñar nuevos protocolos que deben ser precisos, eficientes e independientes del idioma
• Diseño por capas para habilitar la extensión, la autenticación y el registro

Para usar gRPC con tus aplicaciones, debes proxy las solicitudes de extremo a extremo a través de HTTP/2. Trusted Cloud Para ello, crea un balanceador de carga de aplicación con una de las siguientes configuraciones:

• Para el tráfico sin cifrar de extremo a extremo (sin TLS): crea un balanceador de carga HTTP (configurado con un proxy HTTP de destino). Además, puedes configurar el balanceador de carga para que use HTTP/2 en las conexiones sin cifrar entre el balanceador de carga y sus backends. Para ello, define el protocolo del servicio de backend como H2C.

• Para el tráfico cifrado de extremo a extremo (con TLS): crea un balanceador de carga HTTPS (configurado con un proxy HTTPS de destino y un certificado SSL). El balanceador de carga negocia HTTP/2 con los clientes como parte del handshake SSL mediante la extensión TLS ALPN.

  Además, debes asegurarte de que los backends puedan gestionar el tráfico TLS y configurar el balanceador de carga para que use HTTP/2 en las conexiones cifradas entre el balanceador de carga y sus backends. Para ello, debes definir el protocolo del servicio de backend como HTTP2.

  Es posible que el balanceador de carga siga negociando HTTPS con algunos clientes o que acepte solicitudes HTTP no seguras en un balanceador de carga configurado para usar HTTP/2 entre el balanceador de carga y las instancias de backend. El balanceador de carga transforma esas solicitudes HTTP o HTTPS para proxy las solicitudes a través de HTTP/2 a las instancias de backend.

Si quieres configurar un balanceador de carga de aplicaciones mediante HTTP/2 con Ingress de Google Kubernetes Engine o mediante gRPC y HTTP/2 con Ingress, consulta HTTP/2 para el balanceo de carga con Ingress.

Si quieres configurar un balanceador de carga de aplicaciones externo mediante HTTP/2 con Cloud Run, consulta Usar HTTP/2 detrás de un balanceador de carga.

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

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

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.

Cuando el balanceador de carga de aplicaciones clásico usa HTTPS como protocolo del servicio de backend, puede negociar TLS 1.0, 1.1, 1.2 o 1.3 con el backend.

Compatibilidad con TLS mutuo

TLS mutuo (mTLS) es un protocolo estándar del sector para la autenticación mutua entre un cliente y un servidor. mTLS ayuda a asegurar que tanto el cliente como el servidor se autentiquen entre sí verificando que cada uno tiene un certificado válido emitido por una autoridad de certificación (CA) de confianza. A diferencia de TLS estándar, donde solo se autentica el servidor, mTLS requiere que tanto el cliente como el servidor presenten certificados, lo que confirma la identidad de ambas partes antes de establecer la comunicación.

Todos los balanceadores de carga de aplicaciones admiten mTLS. Con mTLS, el balanceador de carga solicita que el cliente envíe un certificado para autenticarse durante el handshake TLS con el balanceador de carga. Puedes configurar un almacén de confianza de Gestor de certificados que el balanceador de carga usará para validar la cadena de confianza del certificado de cliente.

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

Compatibilidad con datos iniciales de TLS 1.3

Los datos iniciales de TLS 1.3 se admiten en el proxy HTTPS de destino de los siguientes balanceadores de carga de aplicaciones externos, tanto para HTTPS sobre TCP (HTTP/1.1 y HTTP/2) como para HTTP/3 sobre QUIC:

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

TLS 1.3 se definió en el RFC 8446 e introduce el concepto de datos iniciales, también conocidos como datos de tiempo de ida y vuelta cero (0-RTT), que pueden mejorar el rendimiento de las aplicaciones en las conexiones reanudadas entre un 30 y un 50%.

Con TLS 1.2, se necesitan dos ciclos de ida y vuelta para que los datos se puedan transmitir de forma segura. TLS 1.3 reduce este tiempo a un tiempo de ida y vuelta (1-RTT) para las conexiones nuevas, lo que permite a los clientes enviar datos de la aplicación inmediatamente después de la primera respuesta del servidor. Además, TLS 1.3 introduce el concepto de datos iniciales para las sesiones reanudadas, lo que permite a los clientes enviar datos de aplicaciones con el ClientHello inicial, lo que reduce el tiempo de ida y vuelta efectivo a cero (0-RTT). Los datos iniciales de TLS 1.3 permiten que el servidor backend empiece a procesar los datos del cliente antes de que se complete el proceso de handshake con el cliente, lo que reduce la latencia. Sin embargo, se deben tomar medidas para mitigar los riesgos de repetición.

Como los datos iniciales se envían antes de que se complete el handshake, un atacante puede intentar capturar y reproducir solicitudes. Para mitigar este problema, el servidor backend debe controlar cuidadosamente el uso de datos iniciales y limitarlo a solicitudes idempotentes. Los métodos HTTP que están diseñados para ser idempotentes, pero que pueden activar cambios no idempotentes (como una solicitud GET que modifica una base de datos), no deben aceptar datos iniciales. En estos casos, el servidor backend debe rechazar las solicitudes con el encabezado HTTP Early-Data: 1 devolviendo un código de estado HTTP 425 Too Early.

Las solicitudes con datos iniciales tienen el encabezado HTTP Early-Data con el valor 1, lo que indica al servidor backend que la solicitud se ha transmitido en datos iniciales de TLS. También indica que el cliente entiende el código de estado HTTP 425 Too Early.

Modos de datos iniciales de TLS (0-RTT)

Puede configurar los datos iniciales de TLS mediante uno de los siguientes modos en el recurso de proxy HTTPS de destino del balanceador de carga.

• STRICT. De esta forma, se habilita TLS 1.3 Early Data para las solicitudes con métodos HTTP seguros (GET, HEAD, OPTIONS y TRACE) y las solicitudes HTTP que no tienen parámetros de consulta. Las solicitudes que envían datos iniciales que contienen métodos HTTP no idempotentes (como POST o PUT) o con parámetros de consulta se rechazan con un código de estado HTTP 425.

• PERMISSIVE. De esta forma, se habilita la función Early Data de TLS 1.3 para las solicitudes con métodos HTTP seguros (GET, HEAD, OPTIONS y TRACE). En este modo no se deniegan las solicitudes que incluyen parámetros de consulta. El propietario de la aplicación debe asegurarse de que los datos iniciales se puedan usar de forma segura en cada ruta de solicitud, sobre todo en los endpoints en los que la repetición de solicitudes pueda provocar efectos secundarios no deseados, como el registro o las actualizaciones de bases de datos activadas por solicitudes GET.

• DISABLED. No se anuncia TLS 1.3 Early Data y se rechazan todos los intentos (no válidos) de enviar datos iniciales. Si tus aplicaciones no están equipadas para gestionar las solicitudes de datos iniciales de forma segura, debes inhabilitar los datos iniciales. TLS 1.3 Early Data está inhabilitado de forma predeterminada.

• UNRESTRICTED (no se recomienda para la mayoría de las cargas de trabajo). De esta forma, se habilita TLS 1.3 Early Data para las solicitudes con cualquier método HTTP, incluidos los métodos no idempotentes, como POST. Este modo no aplica ninguna otra limitación. Este modo puede ser útil en casos prácticos de gRPC. Sin embargo, no recomendamos este método a menos que hayas evaluado tu postura de seguridad y mitigado el riesgo de ataques de repetición mediante otros mecanismos.

Configurar datos iniciales de TLS

Para habilitar o inhabilitar explícitamente los datos iniciales de TLS, haz lo siguiente:

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

Una vez que hayas configurado TLS Early Data, podrás enviar solicitudes desde un cliente HTTP que admita TLS Early Data. Puedes observar una latencia menor en las solicitudes reanudadas.

Si un cliente que no cumple el RFC envía una solicitud con un método no idempotente o con parámetros de consulta, la solicitud se rechaza. En los registros del balanceador de carga, se muestra un código de estado HTTP 425 Early y la siguiente respuesta HTTP:

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

Limitaciones

• Los balanceadores de carga HTTPS no envían una alerta de cierre close_notify al finalizar las conexiones SSL. Es decir, el balanceador de carga cierra la conexión TCP en lugar de realizar un cierre de SSL.

• Los balanceadores de carga HTTPS solo admiten caracteres en minúsculas en los dominios de un atributo de nombre común (CN) o de un atributo de nombre alternativo del sujeto (SAN) del certificado. Los certificados con caracteres en mayúsculas en los dominios solo se devuelven cuando se definen como certificado principal en el proxy de destino.

• Los balanceadores de carga HTTPS no usan la extensión de indicador del nombre de servidor (SNI) cuando se conectan al backend, excepto los balanceadores de carga con backends de grupos de puntos finales de Internet. Para obtener más información, consulta Cifrado desde el balanceador de carga hasta los back-ends.

• Trusted Cloud no garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el tiempo de espera del servicio backend. Los sistemas cliente deben implementar una lógica de reintento en lugar de depender de que una conexión TCP esté abierta durante largos periodos.

• Cuando creas un balanceador de carga de aplicaciones externo regional en el nivel Premium mediante la consola, solo están disponibles en la consola las regiones que admiten el nivel Standard.Trusted Cloud Trusted Cloud Para acceder a otras regiones, usa la CLI de gcloud o la API.

Siguientes pasos

• Para saber cómo desplegar un balanceador de carga de aplicación externo regional, consulta Configurar un balanceador de carga de aplicación externo regional con un backend de Compute Engine.

• Para saber cómo configurar las funciones de gestión de tráfico avanzadas disponibles con el balanceador de carga de aplicación externo regional, consulta el resumen de la gestión de tráfico para balanceadores de carga de aplicación externos regionales.