Descripción general del balanceador de cargas de aplicaciones externo

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

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

Modos de operación

Este balanceador de cargas está disponible en el modo regional y, a partir de ahora, se denominará balanceador de cargas de aplicaciones externo regional. El balanceador de cargas se implementa como un servicio administrado basado en el proxy de Envoy con código abierto. Incluye capacidades de administración avanzada de tráfico, como duplicación de tráfico, división de tráfico basada en pesos y transformaciones de encabezados basadas en solicitudes o respuestas. El modo regional garantiza que todos los clientes y backends estén en una región especificada. Usa este balanceador de cargas si deseas entregar contenido desde una sola ubicación geográfica (por ejemplo, para cumplir con las reglamentaciones de cumplimiento).

Arquitectura

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

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

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

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

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

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

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

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

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

Regional

En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de aplicaciones 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 cargas de aplicaciones externos regionales. La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas regionales basados en Envoy en la misma región y red de VPC comparten un grupo de proxies de Envoy de la misma subred de solo proxy. Además:

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

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

Reglas de reenvío y direcciones IP

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

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

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

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

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

Reglas de reenvío y redes de VPC

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

Proxies de destino

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

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

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

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

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

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 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 cargas
2. La dirección IP de la regla de reenvío del balanceador de cargas

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 cargas agrega sus valores al encabezado existente:

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

Cómo quitar valores de encabezado existentes con un encabezado de solicitud personalizado

Es posible quitar los valores de encabezado existentes con encabezados de solicitud personalizados en el servicio de backend. En el siguiente ejemplo, se usa la marca --custom-request-header para volver a crear el encabezado X-Forwarded-For con las variables client_ip_address y server_ip_address. Esta configuración reemplaza el encabezado X-Forwarded-For entrante solo con la dirección IP del cliente y del balanceador de cargas.

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

Cómo el software de proxy inverso de backend podría modificar el encabezado X-Forwarded-For

Si los backends de tu balanceador de cargas ejecutan software de proxy HTTP inverso, es posible que el software adjunte una o las siguientes dos direcciones IP al final del encabezado X-Forwarded-For:

1. Es la dirección IP del GFE que se conectó al backend. Las direcciones IP de GFE se encuentran en los rangos 130.211.0.0/22 y 35.191.0.0/16.

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

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

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

Compatibilidad con Cloud Trace

Trace no es compatible con los balanceadores de cargas de aplicaciones. Los balanceadores de cargas de aplicaciones globales y clásicos agregan el encabezado X-Cloud-Trace-Context si no está presente. El balanceador de cargas de aplicaciones externo regional no agrega este encabezado. Si el encabezado X-Cloud-Trace-Context ya está presente, pasa por los balanceadores de cargas sin modificaciones. Sin embargo, el balanceador de cargas no exporta ningún registro ni intervalo.

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. El mapa de URL te permite dividir el tráfico a través del análisis de los componentes de URL para enviar solicitudes a diferentes conjuntos de backends. 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.

Los mapas de URL admiten varias funciones avanzadas de administración de tráfico, como el direccionamiento de tráfico basado en encabezados, la división de tráfico según el peso y la duplicación de solicitudes. Para obtener más información, consulta lo siguiente:

• Descripción general de la administración del tráfico en el balanceador de cargas de aplicaciones externo regional.

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

Certificados SSL

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

Los balanceadores de cargas 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 cargas.

Los balanceadores de cargas de aplicaciones externos regionales admiten certificados SSL de Compute Engine autoadministrados.

Políticas de SSL

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

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

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

Servicios de backend

Un servicio de backend proporciona información de configuración al balanceador de cargas para que pueda dirigir las solicitudes a sus backends, por ejemplo, grupos de instancias de Compute Engine o grupos de extremos de red (NEG). Para obtener más información sobre los servicios de backend, consulta la Descripción general de los servicios de backend.

Permiso del servicio de backend

En la siguiente tabla, se indica qué recurso y alcance del servicio de backend usan los balanceadores de cargas de aplicaciones externos:

Protocolo para los backends

Los servicios de backend para los balanceadores de cargas 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 encriptación)
• H2C, que usa HTTP/2 a través de TCP No se requiere TLS. H2C no es compatible con los balanceadores de cargas de aplicaciones clásicos.

El balanceador de cargas solo usa el protocolo del servicio de backend que especifiques para comunicarse con sus backends. El balanceador de cargas no recurre a un protocolo diferente si no puede comunicarse con los backends usando el protocolo de servicio de backend especificado.

El protocolo del servicio de backend no necesita coincidir con el protocolo que usan los clientes para comunicarse con el balanceador de cargas. Por ejemplo, los clientes pueden enviar solicitudes al balanceador de cargas con HTTP/2, pero el balanceador de cargas puede comunicarse con los backends con HTTP/1.1 (HTTP o HTTPS).

Backends

Un balanceador de cargas de aplicaciones externo regional admite los siguientes tipos de backends:

• Grupos de instancias
• NEG zonales
• NEG de Internet

Backends y redes de VPC

Para los backends de balanceadores de cargas de aplicaciones externos regionales, se aplica lo siguiente:

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

  Definición de la red de backend

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

  Requisitos de red del backend

  La red de tu backend debe satisfacer 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 intercambio de tráfico entre redes de VPC. Debes configurar intercambios de rutas de subred para permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos de backend.

• Para todos los demás tipos de backends, todos deben estar ubicados en la misma red de VPC y región.

  Los balanceadores de cargas 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 cargas de aplicaciones externo regional estén en un proyecto diferente al de la regla de reenvío, debes configurar el balanceador de cargas en un entorno de VPC compartida con referencias a servicios entre proyectos.

Interfaces de red y backends

Si usas backends de grupos de instancias, los paquetes siempre se entregan a nic0. Si quieres enviar paquetes a interfaces que no son de nic0 (ya sean vNICs o interfaces de red dinámicas), usa backends de NEG en su lugar.

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

Verificaciones de estado

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

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

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

Protocolo de verificación de estado

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

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

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

• Descripción general de las verificaciones de estado
• Crea verificaciones de estado

Reglas de firewall

El balanceador de cargas requiere las siguientes reglas de firewall:

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

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

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

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

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

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

Compatibilidad con GKE

GKE usa balanceadores de cargas de aplicaciones externos de las siguientes maneras:

• Las puertas de enlace externas creadas con el controlador de GKE Gateway pueden usar cualquier modo de un balanceador de cargas de aplicaciones externo. Puedes controlar el modo del balanceador de cargas eligiendo un objeto GatewayClass. El controlador de la puerta de enlace de GKE siempre usa back-ends de NEG zonales GCE_VM_IP_PORT.

• Puedes usar el NEG zonal GCE_VM_IP_PORT creado y administrado por los servicios de GKE como backends para cualquier balanceador de cargas de aplicaciones o balanceador de cargas de red de proxy. Para obtener más información, consulta Balanceo de cargas nativo del contenedor a través de NEG zonales independientes.

Arquitectura de VPC compartida

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

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

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

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

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

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

Referencia del servicio entre proyectos

La referencia de servicio entre proyectos es un modelo de implementación en el que el frontend y el mapa de URL del balanceador de cargas se encuentran en un proyecto, y el servicio de backend y los backends del balanceador de cargas se encuentran en un proyecto diferente.

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

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

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

La compatibilidad con la referencia del servicio entre proyectos varía según el tipo de balanceador de cargas:

• Para los balanceadores de cargas de aplicaciones externos globales: El frontend y el mapa de URL de tu balanceador de cargas pueden hacer referencia a servicios de backend o buckets de backend de cualquier proyecto dentro de la misma organización. No se aplican restricciones a la red de VPC. Si bien puedes usar un entorno de VPC compartida para configurar una implementación entre proyectos, como se muestra en este ejemplo, esto no es un requisito.

• Para los balanceadores de cargas de aplicaciones externos regionales: Debes crear el balanceador de cargas en un entorno de VPC compartida. El frontend y el mapa de URL del balanceador de cargas deben estar en un proyecto host o de servicio, y los servicios de backend y los backends del balanceador de cargas se pueden distribuir en proyectos host o de servicio en el mismo entorno de VPC compartida.

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

Notas de uso para la referencia del servicio entre proyectos

• Trusted Cloud no diferencia entre los recursos (por ejemplo, los servicios de backend) que usan el mismo nombre en varios proyectos. Por lo tanto, cuando usas la referencia de servicios entre proyectos, te recomendamos que uses nombres de servicio de backend únicos en todos los proyectos de tu organización.
• Si ves un error como "No se permiten las referencias entre proyectos de este recurso", asegúrate de tener permiso para usar el recurso. Un administrador del proyecto propietario del recurso debe otorgarte el rol de usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser). Este rol se puede otorgar a nivel del proyecto o del recurso. Para ver un ejemplo, consulta Otorga permisos al administrador del balanceador de cargas de Compute para usar el servicio de backend o el bucket de backend.

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

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

En este caso, los administradores de red o del balanceador de cargas en el proyecto de servicio A requieren acceso a los servicios de backend en el proyecto de servicio B. Los administradores del proyecto de servicio B otorgan el rol Usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser) a los administradores del balanceador de cargas en el proyecto de servicio A que desean hacer referencia al servicio de backend en el proyecto de servicio B.

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

Este es un ejemplo de una implementación de VPC compartida en la que se crean el frontend y el mapa de URL del balanceador de cargas en el proyecto host, y los servicios de backend (y los backends) se crean en los proyectos de servicio.

En este caso, los administradores de red o del balanceador de cargas en el proyecto host requieren acceso a los servicios de backend en el proyecto de servicio. Los administradores de proyectos de servicio otorgan el rol Usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser) a los administradores del balanceador de cargas en el proyecto host A que desean hacer referencia al servicio de backend en el proyecto de servicio.

Ejemplo 3: Frontend y backends del balanceador de cargas en diferentes proyectos

Este es un ejemplo de una implementación en la que el frontend y el mapa de URL del balanceador de cargas de aplicaciones externo global se crean en un proyecto diferente del servicio de backend y los backends del balanceador de cargas. Este tipo de implementación no usa la VPC compartida y solo es compatible con los balanceadores de cargas de aplicaciones externos globales.

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

Alta disponibilidad y conmutación por error

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

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. Existen 2 modos de compatibilidad con HTTP/2:

• HTTP/2 sobre TLS
• Texto simple HTTP/2 a través de TCP

HTTP/2 sobre TLS

HTTP/2 a través de TLS es compatible con las conexiones entre los clientes y el balanceador de cargas de aplicaciones externo, y con las conexiones entre el balanceador de cargas y sus backends.

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

Si un cliente no admite HTTP/2 y el balanceador de cargas está configurado para usar HTTP/2 entre el balanceador de cargas y las instancias de backend, es posible que el balanceador de cargas aún negocie una conexión HTTPS o acepte solicitudes HTTP no seguras. Luego, el balanceador de cargas transforma esas solicitudes HTTPS o HTTP para representarlas a través de HTTP/2 en las instancias de backend.

Para usar HTTP/2 a través de TLS, debes habilitar TLS en tus backends y configurar el protocolo del servicio de backend enHTTP2. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.

Transmisiones simultáneas máximas de HTTP/2

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

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

Limitaciones de HTTP/2

• En comparación con HTTP o HTTPS, 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 o HTTPS, no está disponible con HTTP/2. Como resultado, es posible que veas latencias de backend altas porque las conexiones de backend se realizan con más frecuencia.
• El uso de HTTP/2 entre el balanceador de cargas y el backend no admite la ejecución del protocolo WebSocket a través de una sola transmisión de conexión HTTP/2 (RFC 8441).
• El uso de HTTP/2 entre el balanceador de cargas y el backend no admite la extracción de servidor.
• La tasa de errores de gRPC y el volumen de solicitudes no son visibles en la API deTrusted Cloud ni en la consola de Trusted Cloud . Si el extremo de gRPC devuelve un error, los registros del balanceador de cargas y los datos de supervisión informan el código de estado HTTP 200 OK.

HTTP/2 de texto simple a través de TCP (H2C)

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

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

• Conexiones entre el balanceador de cargas y sus backends

  Para configurar H2C para las conexiones entre el balanceador de cargas y sus backends, debes establecer el protocolo del servicio de backend en H2C.

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

H2C no es compatible con los balanceadores de cargas de aplicaciones clásicos.

Compatible con WebSocket

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

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

El protocolo WebSocket funciona de la siguiente manera:

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

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

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

Compatibilidad con gRPC

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 Trusted Cloud aplicaciones, debes enviar solicitudes proxy de extremo a extremo a través de HTTP/2. Para ello, crea un balanceador de cargas de aplicaciones con una de las siguientes configuraciones:

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

• Para el tráfico encriptado de extremo a extremo (con TLS): Crea un balanceador de cargas HTTPS (configurado con un proxy HTTPS de destino y un certificado SSL). El balanceador de cargas negocia HTTP/2 con los clientes como parte del protocolo de enlace SSL a través de la extensión ALPN TLS.

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

  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 configurado para usar HTTP/2 entre las instancias de backend y el balanceador de cargas. El balanceador de cargas transforma esas solicitudes HTTP o HTTPS para representar las solicitudes a través de HTTP/2 en las instancias de backend.

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

Si quieres configurar un balanceador de cargas de aplicaciones externo a través de HTTP/2 con Cloud Run, consulta Usa HTTP/2 detrás de un balanceador de cargas.

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.

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 cargas de aplicaciones clásico usa HTTPS como protocolo de servicio de backend, puede negociar TLS 1.0, 1.1, 1.2 o 1.3 para el backend.

Compatibilidad con TLS mutua

La TLS mutua, o mTLS, es un protocolo estándar de la industria para la autenticación mutua entre un cliente y un servidor. La mTLS ayuda a garantizar que tanto el cliente como el servidor se autentiquen mutuamente verificando que cada uno tenga un certificado válido emitido por una autoridad certificadora (CA) de confianza. A diferencia de la TLS estándar, en la que solo se autentica el servidor, la mTLS requiere que tanto el cliente como el servidor presenten certificados, lo que confirma las identidades de ambas partes antes de que se establezca la comunicación.

Todos los balanceadores de cargas de aplicaciones admiten mTLS. Con la mTLS, el balanceador de cargas solicita que el cliente envíe un certificado para autenticarse durante el protocolo de enlace de TLS con el balanceador de cargas. Puedes configurar un almacén de confianza del Administrador de certificados que el balanceador de cargas 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 anticipados de TLS 1.3

Los datos anticipados de TLS 1.3 se admiten en el proxy HTTPS de destino de los siguientes balanceadores de cargas de aplicaciones externos para HTTPS a través de TCP (HTTP/1.1, HTTP/2) y HTTP/3 a través de QUIC:

• Balanceadores de cargas de aplicaciones externos globales
• Balanceadores de cargas de aplicaciones clásicos

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

Con TLS 1.2, se requieren dos viajes de ida y vuelta antes de que los datos se puedan transmitir de forma segura. TLS 1.3 reduce esto a un viaje de ida y vuelta (1-RTT) para las conexiones nuevas, lo que permite que los clientes envíen datos de la aplicación inmediatamente después de la primera respuesta del servidor. Además, TLS 1.3 introduce el concepto de datos anticipados para las sesiones reanudadas, lo que permite que los clientes envíen datos de la aplicación con el ClientHello inicial y, de este modo, se reduce el tiempo de ida y vuelta efectivo a cero (0-RTT). Los datos anticipados de TLS 1.3 permiten que el servidor de backend comience a procesar los datos del cliente antes de que se complete el proceso de protocolo de enlace con el cliente, lo que reduce la latencia. Sin embargo, se debe tener cuidado para mitigar los riesgos de reproducción.

Dado que los datos anticipados se envían antes de que se complete el protocolo de enlace, un atacante puede intentar capturar y reproducir solicitudes. Para mitigar esto, el servidor de backend debe controlar cuidadosamente el uso de datos anticipados y limitarlo a solicitudes idempotentes. Los métodos HTTP que se consideran idempotentes, pero que podrían activar cambios no idempotentes (como una solicitud GET que modifica una base de datos), no deben aceptar datos anticipados. En estos casos, el servidor de 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 anticipados tienen el encabezado HTTP Early-Data establecido en un valor de 1, lo que indica al servidor de backend que la solicitud se transmitió en datos anticipados de TLS. También indica que el cliente comprende el código de estado HTTP 425 Too Early.

Modos de datos anticipados de TLS (0-RTT)

Puedes configurar los datos anticipados de TLS con uno de los siguientes modos en el recurso de proxy HTTPS de destino del balanceador de cargas.

• STRICT. Esto habilita los datos anticipados de TLS 1.3 para las solicitudes con métodos HTTP seguros (GET, HEAD, OPTIONS, TRACE) y las solicitudes HTTP que no tienen parámetros de consulta. Las solicitudes que envían datos anticipados 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, lo que habilita los datos anticipados de TLS 1.3 para las solicitudes con métodos HTTP seguros (GET, HEAD, OPTIONS, TRACE). Este modo no rechaza las solicitudes que incluyen parámetros de consulta. El propietario de la aplicación debe asegurarse de que los datos iniciales sean seguros para usar en cada ruta de solicitud, en especial para los extremos en los que la reproducción de solicitudes podría causar efectos secundarios no deseados, como actualizaciones de bases de datos o registros activados por solicitudes GET.

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

• UNRESTRICTED (no se recomienda para la mayoría de las cargas de trabajo). Esto habilita los datos anticipados de TLS 1.3 para solicitudes con cualquier método HTTP, incluidos los métodos no idempotentes, como POST. Este modo no aplica otras limitaciones de manera forzosa. Este modo puede ser valioso para los casos de uso de gRPC. Sin embargo, no recomendamos este método, a menos que hayas evaluado tu posición de seguridad y mitigado el riesgo de ataques de reproducción con otros mecanismos.

Configura los datos anticipados de TLS

Para habilitar o inhabilitar explícitamente los datos anticipados 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"
}

Después de configurar los datos anticipados de TLS, puedes emitir solicitudes desde un cliente HTTP que admita datos anticipados de TLS. Puedes observar una latencia más baja en las solicitudes reanudadas.

Si un cliente que no cumple con los estándares de la RFC envía una solicitud con un método no idempotente o con parámetros de consulta, la solicitud se rechaza. Ves un código de estado HTTP 425 Early en los registros del balanceador de cargas 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 cargas HTTPS no envían una alerta de cierre close_notify cuando finalizan conexiones SSL. Es decir, el balanceador de cargas cierra la conexión TCP en lugar de realizar un cierre SSL.

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

• Los balanceadores de cargas HTTPS no usan la extensión de indicación del nombre del servidor (SNI) cuando se conectan al backend, excepto los balanceadores de cargas con backends de NEG de Internet. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.

• Trusted Cloud no garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el valor del tiempo de espera del servicio de backend. Los sistemas cliente deben implementar la lógica de reintento en lugar de depender de una conexión TCP para estar abierta durante períodos prolongados.

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

¿Qué sigue?

• Si deseas obtener información sobre cómo implementar un balanceador de cargas de aplicaciones externo regional, consulta Configura un balanceador de cargas de aplicaciones externo regional con un backend de Compute Engine.

• Si deseas obtener información sobre cómo configurar las capacidades de administración avanzada del tráfico disponibles con el balanceador de cargas de aplicaciones externo regional, consulta Descripción general de la administración del tráfico en los balanceadores de cargas de aplicaciones externos regionales.