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 variasGoogle 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

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

• Balanceador de carga de aplicación externo global. Se trata de un balanceador de carga global que se implementa como un servicio gestionado en Google Front Ends (GFEs). Usa el proxy Envoy de código abierto para admitir funciones de gestión avanzada del tráfico, como la proyección del tráfico, la división del tráfico basada en el peso y las transformaciones de encabezados basadas en peticiones o respuestas.
• Balanceador de carga de aplicaciones clásico. Se trata del balanceador de carga de aplicaciones externo clásico, que es global en el nivel Premium, pero se puede configurar para que sea regional en el nivel Estándar. Este balanceador de carga se implementa en Google Front Ends (GFEs). Los GFE se distribuyen por todo el mundo y operan conjuntamente mediante la red global y el plano de control de Google.
• Balanceador de carga de aplicación externo regional. Se trata de un balanceador de carga regional que se implementa como un servicio gestionado 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.

Modo del balanceador de carga	Casos prácticos recomendados	Funciones
Balanceador de carga de aplicación externo global	Usa este balanceador de carga para cargas de trabajo HTTP(S) externas con usuarios dispersos por todo el mundo o servicios de backend en varias regiones.	Compatible con GKE mediante Gateway (orquestación completa) o NEGs independientes (orquestación manual) Admite la gestión avanzada del tráfico. Direcciones IP externas globales Anycast en el nivel Premium Puede acceder a backends de varias regiones Compatible con Cloud CDN Admite Cloud Armor
Balanceador de carga de aplicación clásico	Este balanceador de carga es global en el nivel Premium. En el nivel Premium del servicio de red, este balanceador de carga ofrece balanceo de carga multirregional, intenta dirigir el tráfico al backend en buen estado más cercano que tenga capacidad y termina el tráfico HTTP(S) lo más cerca posible de tus usuarios. Para obtener información sobre el proceso de distribución de solicitudes, consulta Distribución del tráfico. En el nivel de servicio de red estándar, este balanceador de carga solo puede distribuir tráfico a backends de una región.	Compatible con GKE mediante Gateway (totalmente orquestado), Ingress (totalmente orquestado) o NEGs independientes (orquestación manual) Admite Google Cloud Armor Menos funciones de enrutamiento del tráfico Consulta la página de funciones de balanceo de carga para ver la lista completa de funciones.
Balanceador de carga de aplicación externo regional	Este balanceador de carga incluye muchas de las funciones del balanceador de carga de aplicaciones clásico, así como funciones avanzadas de gestión del tráfico. Usa este balanceador de carga si quieres servir contenido desde una sola geolocalización (por ejemplo, para cumplir normativas). Este balanceador de carga se puede configurar en el nivel Premium o Estándar.	Compatible con GKE mediante NEGs independientes (orquestación manual) Admite funciones avanzadas de gestión del tráfico VIPs regionales que usan el nivel de red estándar Finaliza TLS en una sola región que configures Solo sirve contenido de la región configurada Para ver la lista completa, consulta Funciones de balanceo de carga.

Identificar el modo

Consola

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

   Ir a Balanceo de carga

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

Modo del balanceador de carga	Tipo de balanceador de carga	Tipo de acceso	Región
Balanceador de carga de aplicación externo global	Aplicación	Externo
Balanceador de carga de aplicación clásico	Application(Classic)	Externo
Balanceador de carga de aplicación externo regional	Aplicación	Externo	Especifica una región.

gcloud

Para determinar el modo de un balanceador de carga, ejecuta el siguiente comando:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

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

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

Importante: Una vez que hayas creado un balanceador de carga, no podrás editar su modo. En su lugar, debe eliminar el balanceador de carga y crear uno nuevo.

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 en buen estado.Los balanceadores de carga de aplicaciones externos globales también admiten contenedores de backend. Uno o varios backends deben estar conectados al servicio de backend o al segmento de backend.

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

Global

En este diagrama se muestran los componentes de una implementación de un balanceador de carga de aplicación externo global. Esta arquitectura se aplica tanto al balanceador de carga de aplicaciones externo global como al balanceador de carga de aplicaciones clásico del nivel Premium.

Componentes del balanceador de carga de aplicación externo global (haz clic para ampliar).

Regional

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

Componentes del balanceador de carga de aplicación externo regional (haz clic para ampliar).

Subred de solo proxy

Las subredes de solo proxy solo son necesarias para los balanceadores de carga de aplicación externos regionales.

La subred de solo proxy proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de 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.

Modo del balanceador de carga	Nivel de servicio de red	Regla de reenvío, dirección IP y esquema de balanceo de carga	Enrutamiento de Internet al frontend del balanceador de carga
Balanceador de carga de aplicación externo global	Nivel premium	Regla de reenvío externa global Dirección IP externa global Esquema de balanceo de carga: EXTERNAL_MANAGED	Solicitudes dirigidas al GFE más cercano al cliente en Internet.
Balanceador de carga de aplicación clásico	Nivel premium	Regla de reenvío externa global Dirección IP externa global Esquema de balanceo de carga: EXTERNAL ^1	Solicitudes dirigidas al GFE más cercano al cliente en Internet.
	Nivel Estándar	Regla de reenvío externa regional Dirección IP externa regional Esquema de balanceo de carga: EXTERNAL^1	Las solicitudes se enrutan a un GFE en la región del balanceador de carga.
Balanceador de carga de aplicación externo regional	Nivel Premium o nivel Estándar	Regla de reenvío externa regional Dirección IP externa regional Esquema de balanceo de carga: EXTERNAL_MANAGED	PoP más cercano al cliente. Las solicitudes se enrutan a través de la red troncal premium de Google Cloudhasta que llegan a los proxies de Envoy de la misma región que el balanceador de carga.

¹ Se pueden adjuntar EXTERNAL_MANAGED servicios de backend a EXTERNAL reglas de reenvío. Sin embargo, los servicios de backend de EXTERNAL no se pueden adjuntar a reglas de reenvío de EXTERNAL_MANAGED. Para aprovechar las nuevas funciones disponibles solo con el balanceador de carga de aplicación externo global, te recomendamos que migres tus recursos de EXTERNAL a EXTERNAL_MANAGED mediante el proceso de migración descrito en el artículo Migrar recursos del balanceador de carga de aplicación clásico al balanceador de carga de aplicación externo global.

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.

Modo del balanceador de carga	Asociación de redes VPC
Balanceador de carga de aplicación externo global Balanceador de carga de aplicación clásico	No hay ninguna red de VPC asociada. La regla de reenvío siempre usa una dirección IP que está fuera de la red VPC. Por lo tanto, la regla de reenvío no tiene ninguna red de VPC asociada.
Balanceador de carga de aplicación externo regional	La red VPC de la regla de reenvío es la red en la que se ha creado la subred de solo proxy. La red se especifica al crear la regla de reenvío. En función de si usas un intervalo de direcciones IPv4 o IPv6, siempre habrá una red de VPC explícita o implícita asociada a la regla de reenvío. Las direcciones IPv4 externas regionales siempre están fuera de las redes de VPC. Sin embargo, cuando creas la regla de reenvío, debes especificar la red de VPC en la que se ha creado la subred de solo proxy. Por lo tanto, la regla de reenvío tiene una asociación de red explícita. Los intervalos de direcciones IPv6 externas regionales siempre se encuentran dentro de una red de VPC. Cuando creas la regla de reenvío, debes especificar la subred de la que se toma el intervalo de direcciones IP. Esta subred debe estar en la misma región y red VPC en la que se haya creado una subred de solo proxy. Por lo tanto, hay una asociación de red implícita.

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.

Nota: En el caso de los grupos de puntos finales de red (NEGs) de Internet, las solicitudes del balanceador de carga proceden de diferentes intervalos de IP en función del tipo de NEG (global o regional). Para obtener más información, consulta Autenticar solicitudes

.

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

Modo del balanceador de carga	Tipos de proxy de destino	Encabezados añadidos por el proxy	Se admiten encabezados personalizados
Balanceador de carga de aplicación externo global	HTTP global HTTPS global	Los proxies definen los encabezados de solicitud y respuesta HTTP de la siguiente manera: Via: 1.1 google (solicitudes y respuestas) X-Forwarded-Proto: [http | https] (solo solicitudes) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulta el encabezado X-Forwarded-For) (solo solicitudes) Los proxies también definen el encabezado X-Cloud-Trace-Context si aún no está presente.	Configurado en el servicio de backend o en el segmento de backend No se admite con Cloud CDN
Balanceador de carga de aplicación clásico	HTTP global HTTPS global	Los proxies definen los encabezados de solicitud y respuesta HTTP de la siguiente manera: Via: 1.1 google (solicitudes y respuestas) X-Forwarded-Proto: [http | https] (solo solicitudes) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulta el encabezado X-Forwarded-For) (solo solicitudes) Los proxies también definen el encabezado X-Cloud-Trace-Context si aún no está presente.	Configurado en el servicio de backend o en el segmento de backend
Balanceador de carga de aplicación externo regional	HTTP regional HTTPS regional	X-Forwarded-Proto: [http | https] (solo solicitudes) Via: 1.1 google (solicitudes y respuestas) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulta el encabezado X-Forwarded-For) (solo solicitudes)	Configurado en el mapa de URLs

Nota: De acuerdo con RFC 2616 , el proxy de destino no propaga los siguientes encabezados de salto a salto: Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding y Upgrade.

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

• En el caso del balanceador de carga de aplicación externo global, los encabezados de solicitud y de respuesta se pueden convertir a minúsculas.

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

• En el balanceador de carga de aplicación clásico, los encabezados de solicitud y respuesta se convierten a minúsculas, excepto cuando se usa HTTP/1.1. Con HTTP/1.1, los encabezados se escriben con la capitalización adecuada. La primera letra de la clave del encabezado y todas las letras que siguen a un guion (-) se escriben en mayúsculas para mantener la compatibilidad con los clientes HTTP/1.1. Por ejemplo, user-agent se cambia a User-Agent y content-encoding se cambia a Content-Encoding.

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

Precaución: El balanceador de carga no verifica ninguna dirección IP que preceda a <client-ip>,<load-balancer-ip> en esta cabecera. Las direcciones IP anteriores pueden contener otros caracteres, incluidos espacios.

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}

Nota: Con este método se descartan los valores de X-Forwarded-For que ya haya en la solicitud. Como Google Cloud no registra los valores de los encabezados, estos valores no se pueden recuperar. Si necesitas conservar el contenido original de la cabecera, puedes almacenarlo en una cabecera personalizada independiente.

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.

En algunas situaciones, como en el ejemplo de balanceo de carga multirregión, es posible que no definas ninguna regla de URL y que solo uses el servicio predeterminado.

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 global

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

Modo del balanceador de carga	Tipo de mapa de URLs
Balanceador de carga de aplicación externo global	Global
Balanceador de carga de aplicación clásico	Global (con solo un subconjunto de las funciones admitidas)
Balanceador de carga de aplicación externo regional	Regional

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.

• Google Cloud ofrece dos métodos de configuración para asignar claves privadas y certificados SSL a proxies HTTPS de destino: certificados SSL de Compute Engine y Certificate Manager. Para ver una descripción de cada configuración, consulta Métodos de configuración de certificados en la información general sobre los certificados SSL.

• Google Cloud proporciona dos tipos de certificados: autogestionados y gestionados por Google. Para ver una descripción de cada tipo, consulta Tipos de certificados en la información general sobre los certificados SSL.

El tipo de balanceador de carga de aplicación externo (global, regional o clásico) determina qué métodos de configuración y tipos de certificados se admiten. Para obtener más información, consulta la sección Certificados y balanceadores de carga Google Cloud del artículo Información general sobre los certificados SSL.

Políticas de SSL

Las políticas de SSL especifican el conjunto de funciones de SSL que usan los balanceadores de carga Google 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.

Modo del balanceador de carga	Políticas de SSL admitidas
Balanceador de carga de aplicación externo global
Balanceador de carga de aplicación clásico
Balanceador de carga de aplicación externo regional

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.

Para ver un ejemplo de cómo configurar un balanceador de carga con un servicio de backend y un backend de Compute Engine, consulta Configurar un balanceador de carga de aplicaciones externo con un backend de Compute Engine.

Á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:

Modo del balanceador de carga	Recurso de servicio de backend
Balanceador de carga de aplicación externo global	backendServices (global)
Balanceador de carga de aplicación clásico	backendServices (global)
Balanceador de carga de aplicación externo regional	regionBackendServices (regional)

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

Segmentos de backend

Los segmentos de backend dirigen el tráfico entrante a los segmentos de Cloud Storage. Para ver un ejemplo de cómo añadir un bucket a un balanceador de carga de aplicación externo, consulta Configurar un balanceador de carga con buckets de backend. Para obtener información general sobre Cloud Storage, consulta ¿Qué es Cloud Storage?

Backends

En la siguiente tabla se especifican los back-ends y las funciones relacionadas que admiten los balanceadores de carga de aplicaciones externos en cada modo.

Modo del balanceador de carga	Backends admitidos en un servicio de backend^1						Admite segmentos de backend	Admite Cloud Armor	Compatible con Cloud CDN^2	Admite IAP^2	Admite Service Extensions
	Grupos de instancias^3	NEGs zonales^4	NEGs de Internet	NEGs sin servidor	NEGs híbridas	NEGs de Private Service Connect
Balanceador de carga de aplicación externo global
Balanceador de carga de aplicación clásico									Nivel Premium
Balanceador de carga de aplicación externo regional

¹Los backends de un servicio de backend deben ser del mismo tipo: todos grupos de instancias o todos NEGs del mismo tipo. Una excepción a esta regla es que se pueden usar tanto NEGs zonales como NEGs híbridos en el mismo servicio de backend para admitir una arquitectura híbrida.GCE_VM_IP_PORT

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

³ Se admiten combinaciones de grupos de instancias sin gestionar zonales, gestionados zonales y gestionados regionales en el mismo servicio de backend. Cuando uses el autoescalado en un grupo de instancias gestionado que sea un backend de dos o más servicios de backend, configura la política de autoescalado del grupo de instancias para que use varias señales.

⁴ Los NEGs por zonas deben usar endpoints GCE_VM_IP_PORT.

Back-ends y redes de VPC

Las restricciones sobre la ubicación de los back-ends dependen del tipo de balanceador de carga.

En el caso de los backends de balanceadores de carga de aplicación externos globales, se aplican las siguientes condiciones:

• Las instancias de backend (en el caso de los backends de grupos de instancias) y los endpoints de backend (en el caso de los backends de grupos de endpoints de red) pueden estar ubicados en cualquier red de VPC de la misma organización. No es necesario que las distintas redes de VPC estén conectadas mediante el emparejamiento entre redes de VPC, ya que los GFEs se comunican directamente con los back-ends de sus respectivas redes de VPC.

• Los segmentos de Cloud Storage no están asociados a ninguna red de VPC. Pueden estar en cualquier proyecto de la misma organización.

  Los balanceadores de carga de aplicaciones externos globales también admiten entornos de VPC compartida, en los que puedes compartir redes de VPC y sus recursos asociados entre proyectos. Sin embargo, en el caso de los balanceadores de carga de aplicaciones externos globales, no es necesario configurar la VPC compartida para poder hacer referencia a servicios de backend o a cubos de backend de otros proyectos de tu organización.

En el caso de los backends de balanceadores de carga de aplicación clásicos, se aplica lo siguiente:

• Todas las instancias de backend de los backends de grupos de instancias y todos los endpoints de backend de los backends de NEG deben estar ubicados en el mismo proyecto. Sin embargo, un backend de grupo de instancias o un NEG pueden usar una red de VPC diferente en ese proyecto. No es necesario que las distintas redes VPC estén conectadas mediante el emparejamiento entre redes VPC, ya que los GFEs se comunican directamente con los back-ends de sus respectivas redes VPC.

• Los segmentos de Cloud Storage no están asociados a ninguna red de VPC. Sin embargo, deben estar en el mismo proyecto que el balanceador de carga.

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 de VPC del balanceador de carga y la red de VPC de backend se puede configurar mediante el emparejamiento entre redes de VPC, los túneles de Cloud VPN, las vinculaciones de VLAN de Cloud Interconnect o un marco de Network Connectivity Center.

  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.

• Tanto la red de VPC del backend como la red de VPC de la regla de reenvío deben ser radios de VPC conectados al mismo hub de Network Connectivity Center. Los filtros de importación y exportación deben permitir la comunicación entre la subred de 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.

Modo del balanceador de carga	Tipo de comprobación del estado
Balanceador de carga de aplicación externo global	Global
Balanceador de carga de aplicación clásico	Global
Balanceador de carga de aplicación externo regional	Regional

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 globales, una regla de entrada permitida para permitir que el tráfico de los front-ends de Google (GFEs) llegue a tus backends. 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 Google Cloud reglas de cortafuegos para evitar que el tráfico llegue al balanceador de carga. En el caso del balanceador de carga de aplicación externo global y del balanceador de carga de aplicación clásico, puedes usar Google Cloud Armor para conseguirlo.

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.

En la siguiente tabla se resumen los intervalos de direcciones IP de origen necesarios para las reglas de cortafuegos:

Modo del balanceador de carga	Intervalos de origen de las comprobaciones del estado	Intervalos de origen de la solicitud
Balanceador de carga de aplicación externo global	35.191.0.0/16 130.211.0.0/22 Para el tráfico IPv6 a los back-ends: 2600:2d00:1:b029::/64	La fuente del tráfico de GFE depende del tipo de backend: Grupos de instancias y NEGs por zonas (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Para el tráfico IPv6 a los back-ends: 2600:2d00:1:1::/64 NEGs de conectividad híbrida (NON_GCP_PRIVATE_IP_PORT): 130.211.0.0/22 35.191.0.0/16 NEGs de Internet (INTERNET_FQDN_PORT y INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEGs y cubos de backend: la red de producción de Google gestiona el enrutamiento de paquetes
Balanceador de carga de aplicación clásico	35.191.0.0/16 130.211.0.0/22	La fuente del tráfico de GFE depende del tipo de backend: Grupos de instancias, NEGs por zonas (GCE_VM_IP_PORT) y NEGs de conectividad híbrida (NON_GCP_PRIVATE_IP_PORT): 35.191.0.0/16 130.211.0.0/22 NEGs de Internet (INTERNET_FQDN_PORT y INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEGs y cubos de backend: la red de producción de Google gestiona el enrutamiento de paquetes.
Balanceador de carga de aplicación externo regional	35.191.0.0/16 130.211.0.0/22 Para el tráfico IPv6 a los back-ends: 2600:2d00:1:b029::/64 No es necesario permitir el tráfico de los intervalos de sondeo de comprobación del estado de Google para los NEGs híbridos. Sin embargo, si utilizas una combinación de NEGs híbridos y zonales en un mismo servicio de backend, debes permitir el tráfico de los intervalos de sondeo de comprobación de estado de Google para los NEGs zonales.	La subred de solo proxy que configures.

Importante: Asegúrate de permitir paquetes de los intervalos de comprobación de estado completos. Si tu regla de cortafuegos solo permite paquetes de un subconjunto de los intervalos, es posible que veas errores de comprobación del estado porque el balanceador de carga no puede comunicarse con tus backends. Esto provoca respuestas con el código de estado HTTP 502.

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.

• Los objetos Ingress externos creados con el controlador de Ingress de GKE siempre son balanceadores de carga de aplicaciones clásicos. El controlador Ingress de GKE prefiere usar GCE_VM_IP_PORT backends de NEG de zona, aunque también admite backends de grupos de instancias.

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

Balanceador de carga	Componentes de frontend	Componentes de backend
Balanceador de carga de aplicación externo global	Si utilizas una red de VPC compartida para tus back-ends, crea la red necesaria en el proyecto del host de la VPC compartida. La dirección IP externa global, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URLs asociado deben definirse en el mismo proyecto. Este proyecto puede ser un proyecto del host o un proyecto de servicio.	Puedes hacer una de las siguientes acciones: Crea servicios de backend, segmentos de backend y backends (grupos de instancias, NEGs sin servidor u otros tipos de backend admitidos) en el mismo proyecto de servicio que los componentes de frontend. Crea servicios de backend, buckets de backend y backends (grupos de instancias, NEGs sin servidor u otros tipos de backend admitidos) en proyectos de servicio. Un solo mapa de URLs puede hacer referencia a servicios de backend de diferentes proyectos. Este tipo de implementación se conoce como referencia de servicio entre proyectos. Cada servicio de backend debe definirse en el mismo proyecto que los backends a los que hace referencia. Las comprobaciones de estado asociadas a los servicios de backend también deben definirse en el mismo proyecto que el servicio de backend. Los back-ends pueden formar parte de una red de VPC compartida del proyecto del host o de una red de VPC independiente, es decir, una red de VPC no compartida en el proyecto de servicio.
Balanceador de carga de aplicación clásico	La dirección IP externa global, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URLs asociado deben definirse en el mismo proyecto de host o de servicio que los backends.	Un servicio de backend global debe definirse en el mismo proyecto de host o de servicio que los backends (grupos de instancias o NEGs). Las comprobaciones de estado asociadas a los servicios de backend también deben definirse en el mismo proyecto que el servicio de backend.
Balanceador de carga de aplicación externo regional	Crea la red y la subred de solo proxy necesarias en el proyecto host de la VPC compartida. La dirección IP externa regional, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URLs asociado deben definirse en el mismo proyecto. Este proyecto puede ser el proyecto del host o un proyecto de servicio.	Puedes hacer una de las siguientes acciones: Crea servicios de backend y backends (grupos de instancias, NEGs sin servidor o cualquier otro tipo de backend admitido) en el mismo proyecto de servicio que los componentes de frontend. Crea servicios de backend y backends (grupos de instancias, NEGs sin servidor u otros tipos de backend admitidos) en tantos proyectos de servicio como necesites. Un solo mapa de URLs puede hacer referencia a servicios de backend de diferentes proyectos. Este tipo de implementación se conoce como referencia de servicio entre proyectos. Cada servicio de backend debe definirse en el mismo proyecto que los backends a los que hace referencia. Las comprobaciones de estado asociadas a los servicios de backend también deben definirse en el mismo proyecto que el servicio de backend.

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.

Balanceador de carga de aplicación externo regional en una red de VPC compartida (haz clic para ampliar).

Back-ends sin servidor en un entorno de VPC compartida

En el caso de un balanceador de carga que utilice un backend de NEG sin servidor, el servicio de backend de Cloud Run o Cloud Run functions debe estar en el mismo proyecto que el NEG sin servidor.

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

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 aplicación externo global (con y sin referencias de servicio entre proyectos), consulta el artículo Configurar un balanceador de carga de aplicación externo global con una 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

• Se pueden usar referencias de servicios entre proyectos con grupos de instancias, NEGs sin servidor y la mayoría de los demás tipos de backend admitidos. Sin embargo, se aplican las siguientes limitaciones:

  • Con los balanceadores de carga de aplicaciones externos globales, no puedes hacer referencia a un servicio de backend entre proyectos si el servicio de backend tiene backends de NEG sin servidor con App Engine.

  • Con los balanceadores de carga de aplicaciones externos regionales, no puedes hacer referencia a un servicio de backend entre proyectos si el servicio de backend tiene backends de NEG de Internet regionales.
• La referencia de servicios entre proyectos no se admite en el balanceador de carga de aplicaciones clásico.
• Google 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.

Componentes frontend y backend del balanceador de carga en diferentes proyectos de servicio (haz clic para ampliar).

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.

Frontend del balanceador de carga y mapa de URLs en el proyecto host (haga clic para ampliar).

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.

Componentes frontend y backend del balanceador de carga en diferentes proyectos (haz clic para ampliar).

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.

Modo del balanceador de carga	Métodos de conmutación por error
Balanceador de carga de aplicación externo global Balanceador de carga de aplicación clásico	Puede configurar una configuración de conmutación por error activo-pasivo en la que el tráfico se conmute por error a un balanceador de carga de aplicaciones externo regional de copia de seguridad. Las comprobaciones de estado se usan para detectar interrupciones y las políticas de enrutamiento de Cloud DNS para enrutar el tráfico cuando se activa la conmutación por error.
Balanceador de carga de aplicación externo regional	Utilice uno de los siguientes métodos para asegurarse de que la implementación tenga una alta disponibilidad: Puede configurar una configuración de conmutación por error activo-pasivo en la que el tráfico se conmute por error a un balanceador de carga de aplicaciones externo regional de copia de seguridad. Las comprobaciones del estado se usan para detectar interrupciones y una política de enrutamiento de conmutación por error de Cloud DNS para enrutar el tráfico cuando se activa la conmutación por error debido a que las comprobaciones del estado fallan. Para obtener más información, consulta Conmutación por error de balanceadores de carga de aplicación externos. Puedes configurar una configuración de conmutación por error activa-activa en la que implementes varios balanceadores de carga de aplicación externos regionales en las regiones que consideres que mejor admiten el tráfico de tu aplicación. Utilizas una política de enrutamiento por geolocalización de Cloud DNS para enrutar el tráfico a la región adecuada en función del origen de la solicitud del cliente. También puedes usar comprobaciones del estado para detectar interrupciones y dirigir el tráfico solo a los balanceadores de carga en buen estado. Para obtener más información, consulta Alta disponibilidad de los balanceadores de carga de aplicación externos regionales.

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.Google 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 (Google 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 laGoogle Cloud API ni en la Google 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 HTTP/3

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

La compatibilidad con Google QUIC (también conocido como gQUIC) se retiró en abril del 2023 en favor de HTTP/3 sobre IETF QUIC, que es un estándar de IETF y se ha demostrado que supera a gQUIC.

En concreto, este cambio afecta a las siguientes acciones:

• QUIC de IETF es un protocolo de capa de transporte que proporciona control de congestión y fiabilidad similares a los de TCP, usa TLS 1.3 para la seguridad y ofrece un mejor rendimiento.
• HTTP/3 es una capa de aplicación creada sobre IETF QUIC y se basa en QUIC para gestionar la multiplexación, el control de congestión, la detección de pérdidas y la retransmisión.
• HTTP/3 permite iniciar la conexión del cliente más rápido, elimina el bloqueo de inicio de línea en flujos multiplexados y admite la migración de conexiones cuando cambia la dirección IP de un cliente.
• HTTP/3 se admite en las conexiones entre los clientes y el balanceador de carga, pero no en las conexiones entre el balanceador de carga y sus backends.
• Las conexiones HTTP/3 usan el algoritmo de control de la congestión BBR.

HTTP/3 en tu balanceador de carga puede mejorar los tiempos de carga de las páginas web, reducir el rebuffering de los vídeos y mejorar el rendimiento en conexiones con mayor latencia.

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

Modo del balanceador de carga	Compatibilidad con HTTP/3
Balanceador de carga de aplicación externo global (siempre en el nivel Premium)
Balanceador de carga de aplicación clásico en el nivel Premium
Balanceador de carga de aplicación clásico en el nivel estándar
Balanceador de carga de aplicación externo regional (nivel Premium o Standard)

Cómo se negocia HTTP/3

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

• Los clientes implementados correctamente siempre recurren a HTTPS o HTTP/2 cuando no pueden establecer una conexión HTTP/3.
• Los clientes que admiten HTTP/3 usan sus conocimientos previos almacenados en caché sobre la compatibilidad con HTTP/3 para evitar viajes de ida y vuelta innecesarios en el futuro.
• Debido a esta alternativa, habilitar o inhabilitar HTTP/3 en el balanceador de carga no interrumpe la capacidad del balanceador de carga para conectarse a los clientes.

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

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

Nota: El encabezado Alt-Svc anuncia varias versiones de HTTP/3 para admitir borradores anteriores que usan algunos clientes, como h3-29.

Si HTTP/3 se ha definido explícitamente como DISABLE, las respuestas no incluyen un encabezado de respuesta alt-svc.

Si tienes habilitado HTTP/3 en tu balanceador de carga HTTPS, en algunas circunstancias, el cliente puede volver a HTTPS o HTTP/2 en lugar de negociar HTTP/3. Entre ellas, se incluyen las siguientes:

• Cuando un cliente admite versiones de HTTP/3 que no son compatibles con las versiones de HTTP/3 admitidas por el balanceador de carga HTTPS.
• Cuando el balanceador de carga detecta que el tráfico UDP está bloqueado o limitado de forma que impide que HTTP/3 funcione.
• El cliente no admite HTTP/3 y, por lo tanto, no intenta negociar una conexión HTTP/3.

Cuando una conexión vuelve a HTTPS o HTTP/2, no lo consideramos un fallo del balanceador de carga.

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

Configurar HTTP/3

Tanto NONE (el valor predeterminado) como ENABLE habilitan la compatibilidad con HTTP/3 en tu balanceador de carga.

Cuando HTTP/3 está habilitado, el balanceador de carga lo anuncia a los clientes, lo que permite que los clientes que lo admiten negocien una versión de HTTP/3 con el balanceador de carga. Los clientes que no admiten HTTP/3 no negocian una conexión HTTP/3. No es necesario inhabilitar explícitamente HTTP/3 a menos que haya identificado implementaciones de cliente incorrectas.

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

Valor de quicOverride	Comportamiento
NONE	Se anuncia a los clientes la compatibilidad con HTTP/3.
ENABLE	Se anuncia a los clientes la compatibilidad con HTTP/3.
DISABLE	Inhabilita explícitamente la publicidad de HTTP/3 y Google QUIC para los clientes.

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

Consola: HTTPS

Nota: Actualmente, no se puede definir la negociación de HTTP/3 en la página de proxies de destino. Para configurarla, debe editar la configuración del balanceador de carga.

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

Ir a Balanceo de carga

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

Habilitar HTTP/3

1. Seleccione el menú Negociación de QUIC.
2. Para habilitar explícitamente HTTP/3 en este frontend, selecciona Habilitado.
3. Si tienes varias reglas de frontend que representan IPv4 e IPv6, asegúrate de habilitar HTTP/3 en cada una de ellas.

Inhabilitar HTTP/3

1. Seleccione el menú Negociación de QUIC.
2. Para inhabilitar explícitamente HTTP/3 en este frontend, selecciona Inhabilitado.
3. Si tiene varias reglas de frontend que representan IPv4 e IPv6, asegúrese de inhabilitar HTTP/3 en cada regla.

gcloud: HTTPS

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

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

Sustituye QUIC_SETTING por una de las siguientes opciones:

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

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

• ENABLE: anuncia HTTP/3 a los clientes.

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

API: HTTPS

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

{
  "quicOverride": QUIC_SETTING
}

Sustituye QUIC_SETTING por una de las siguientes opciones:

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

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

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

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

Compatibilidad con WebSocket

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

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

La afinidad de sesión para websockets funciona 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. Google 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 externo global o el balanceador de carga de aplicaciones externo regional usan HTTPS como protocolo del servicio de backend, pueden negociar TLS 1.2 o 1.3 con el backend.

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

Nota: Los datos iniciales de TLS 1.3 o 0-RTT solo se admiten para reanudar sesiones anteriores entre los clientes y Cloud CDN o el balanceador de carga. Cloud CDN o el balanceador de carga no pueden usar datos iniciales de TLS al reenviar solicitudes a los servidores de origen.

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:

Consola

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

   Ir a Balanceo de carga

2. Selecciona el balanceador de carga para el que quieras habilitar los datos iniciales.

3. Haz clic en Editar.

4. Haz clic en Configuración de frontend.

5. Selecciona la dirección IP y el puerto de frontend que quieras editar. Para habilitar los datos iniciales de TLS, el protocolo debe ser HTTPS.

6. En la lista Datos iniciales (0-RTT), selecciona un modo de datos iniciales de TLS.

7. Haz clic en Listo.

8. Para actualizar el balanceador de carga, haz clic en Actualizar.

gcloud

1. Configura el modo de datos iniciales de TLS en el proxy HTTPS de destino de un balanceador de carga de aplicación.

   gcloud compute target-https-proxies update TARGET_HTTPS_PROXY \
     --tls-early-data=TLS_EARLY_DATA_MODE
   

   Haz los cambios siguientes:

   • TARGET_HTTPS_PROXY: el proxy HTTPS de destino de tu balanceador de carga
   • TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED o UNRESTRICTED

API

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

Haz los cambios siguientes:

• TARGET_HTTPS_PROXY: el proxy HTTPS de destino de tu balanceador de carga
• TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED o UNRESTRICTED
• FINGERPRINT: una cadena codificada en Base64. Se debe proporcionar una huella digital actualizada para parchear el proxy HTTPS de destino. De lo contrario, la solicitud fallará y se devolverá el código de estado HTTP 412 Precondition Failed.

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.

• Google 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.Google Cloud Google Cloud Para acceder a otras regiones, usa la CLI de gcloud o la API.

• Los proxies de GFE que usan los balanceadores de carga de aplicaciones globales y clásicos no admiten respuestas tempranas 200 OK que se envían antes de que la carga útil POST de la solicitud se haya proxyizado por completo al backend. Si se envía una respuesta 200 OK antes de tiempo, el GFE cerrará la conexión con el backend.

  Tu backend debe responder con respuestas 100 Continue después de recibir los encabezados de la solicitud y, a continuación, esperar hasta que se haya enviado por proxy toda la carga útil POST de la solicitud antes de responder con el código de respuesta 200 OK final.

• Cuando se usan balanceadores de carga de aplicaciones externos regionales con Cloud Run en un entorno de VPC compartida, las redes de VPC independientes de los proyectos de servicio pueden enviar tráfico a cualquier otro servicio de Cloud Run implementado en cualquier otro proyecto de servicio del mismo entorno de VPC compartida. Se trata de un problema conocido.

• Cloud CDN te permite forzar que la caché ignore un objeto o un conjunto de objetos solicitando una invalidación de caché. Cuando usas un balanceador de carga de aplicaciones externo global con referencias de servicio entre proyectos de VPC compartida, de forma predeterminada, los administradores de proyectos de servicio no tendrán los permisos necesarios para solicitar invalidaciones de caché. Esto se debe a que la invalidación de la caché se configura en el proyecto frontend (es decir, el proyecto que tiene la regla de reenvío, el proxy de destino y el mapa de URLs del balanceador de carga). Por lo tanto, las invalidaciones de caché solo pueden emitirlas los principales que tengan los roles de gestión de identidades y accesos para configurar los recursos relacionados con el balanceador de carga en los proyectos de frontend (por ejemplo, el rol de administrador de redes de Compute). Los administradores de servicios, que controlan el aprovisionamiento de los servicios de backend en un proyecto independiente, deben colaborar con el administrador del balanceador de carga del proyecto de frontend para invalidar la caché de sus servicios entre proyectos.

Siguientes pasos

• Para saber cómo gestionan las conexiones, enrutan el tráfico y mantienen la afinidad de sesión los balanceadores de carga de aplicación externos, consulta Distribución de solicitudes en balanceadores de carga de aplicación externos.

• Para saber cómo desplegar un balanceador de carga de aplicación externo global, consulta el artículo Configurar un balanceador de carga de aplicación externo con un backend de Compute Engine.

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

• Si ya usas el balanceador de carga de aplicación clásico, consulta el resumen de la migración cuando planifiques una nueva implementación con el balanceador de carga de aplicación externo global.

• Para saber cómo automatizar la configuración de tu balanceador de carga de aplicación externo con Terraform, consulta los ejemplos de módulos de Terraform para balanceadores de carga de aplicación externos.

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

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

• Para obtener información sobre cómo servir sitios web, consulta Servir sitios web.

• Para encontrar las ubicaciones de los PoPs de Google, consulta las ubicaciones de GFE.

• Para obtener información sobre la gestión de la capacidad, consulta el tutorial sobre gestión de la capacidad con balanceo de carga y el artículo Optimizaciones de la capacidad de las aplicaciones con balanceo de carga global.

• Para saber cómo usar Certificate Manager para aprovisionar y gestionar certificados SSL, consulta la descripción general de Certificate Manager.

• Para insertar lógica personalizada en la ruta de datos del balanceo de carga, configura complementos o llamadas de extensiones de servicio.

• En el caso de los balanceadores de carga de aplicaciones externos regionales, puedes probar a usar Apigee Shadow API Discovery para encontrar APIs de sombra (también conocidas como APIs no documentadas) en tu infraestructura deGoogle Cloud . Antes de habilitar la detección de APIs de Shadow, asegúrate de leer las limitaciones asociadas.