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.

Identificar el modo

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

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.

Regional

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

Subred de solo proxy

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.

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

Reglas de reenvío y redes de VPC

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

Proxies de destino

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

No confíe en el proxy para conservar las mayúsculas y minúsculas de los nombres de los encabezados de las solicitudes o respuestas. Por ejemplo, un encabezado de respuesta Server: Apache/1.0 puede aparecer en el cliente como server: Apache/1.0.

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

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

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

Quitar valores de encabezado con un encabezado de solicitud personalizado

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

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

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

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

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

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

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

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

Asistencia de Cloud Trace

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

Mapas de URL

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

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.