En este laboratorio vamos a desplegar la siguiente infraestructura, representada en un diagrama:

La idea principal será utilizar un Balanceador de Carga HTTP Interno Regional [my-ilb] para dirigir el tráfico utilizando una regla avanzada de reenvío para ponderar los backends para recibir un % del tráfico.

HTTP(S) Load Balancer en GCP

Un Balanceador de Carga HTTP(S) en Google Cloud Platform (GCP) es un servicio gestionado, totalmente distribuido y definido por software, diseñado para manejar grandes cantidades de tráfico. Puede funcionar a nivel global, lo que significa que puede dirigir el tráfico a la instancia regional más cercana basándose en la ubicación geográfica del cliente, reduciendo la latencia.

Una característica clave que utilizaremos en este laboratorio es que soporta estrategias avanzadas de gestión de tráfico, como mapas de URL, que permiten dirigir las solicitudes a diferentes backends basados en la ruta de la solicitud, y también soporta enrutamiento basado en contenido.

Este LB es un Servicio Gestionado de GCP basado en el proxy de código abierto Envoy proxy.

Recursos del Lab

Usaremos la VPC “my-internal-app”. Esta red tiene 2 subredes ya creadas:

• Subred-a: 10.10.20.0/24
• Subred-b: 10.10.30.0/24

Esta red tiene reglas de Firewall configuradas para ejecutar el laboratorio.

We’ll use the following Compute Engine resources:

• Instance-group-1: va a ser “blue-service” backend
• Instance-group-2: va a ser “green-service” backend
• Utility-vm: esta maquina la utilizaremos como utilidad para consumir los servicios internamente.

Si ejecutamos un comando Curl a las VMs, encontraremos las siguientes respuestas:

Esto nos permitirá saber cómo está funcionando el Balanceo de Carga para conocer el hostname en las respuestas del backend.

Crear HTTP Load Balancer

Ahora vamos a pasar por la creación del Balanceador de Carga utilizando la Consola de GCP.

Crear y configurar el Balanceador de Carga

Ahora vamos a pasar por la creación del Balanceador de Carga HTTP Interno Regional. Este tipo de Balanceador de Carga en GCP es un tráfico de Capa 7 OSI para aplicaciones HTTP y HTTPs. También soporta el protocolo HTTP/2.

• Primero buscaremos “Balanceo de Carga” en la sección “Servicios de Red” en nuestra Consola de GCP.

• Luego haremos clic en “Crear” y seleccionaremos la opción “Balanceador de Carga de Aplicaciones”.

• Vamos a configurarlo como interno seleccionando la opción resaltada en la imagen anterior.

• Ahora lo conectaremos a la VPC “my-internal-app”.

• Aquí el LB nos pedirá reservar una Subred para su uso.

• Reserva la subred.
• La subred solo para proxy será creada:

Crear backends

Ahora tendremos que crear los backends:

• Selecciona “Crear Servicio de Backend”:

• Ahora crearemos el backend “servicio-azul” asociado al MIG-1.

• Configurar el Grupo de Instancias y el número de puerto “80” para HTTP.

• Necesitamos crear la Verificación de Salud para que el Balanceador de Carga pueda monitorear el servicio de backend y chequear su salud.

• Especifica el puerto TCP 80. También cambia las áreas resaltadas en la sección “Criterios de Salud”.

• Haz clic en “Crear”.

Ahora repetimos el mismo proceso de generación de backend para nuestro Grupo de Instancias 2, lo llamaremos servicio-verde.

• Después de la creación del 2º servicio de backend. Seleccionaremos ambos para la configuración de backend en el LB:

Routing Rules

Ahora vamos a configurar las Reglas de Enrutamiento. Como escribí anteriormente en el post, vamos a configurar una regla avanzada para ponderar los backends.

• Primero haremos clic en la sección de Reglas de Enrutamiento en el asistente de configuración del Balanceador de Carga.
• Luego seleccionaremos el modo “Regla avanzada de host y ruta”.
• Y vamos a configurar la siguiente regla en formato yaml:

https://github.com/mdiloreto/gcp-lb-advanced-configs/blob/main/weight/weighted_backend.txt

defaultService: projects/{proj-name}/regions/{region}/backendServices/{backend} #reemplazar
name: matcher1
routeRules:
 - matchRules:
     - prefixMatch: /
   priority: 0
   routeAction:
     weightedBackendServices:
       - backendService:projects/{proj-name}/regions/{region}/backendServices/{backend} #reemplazar
         weight: 70
       - backendService: projects/{proj-name}/regions/{region}/backendServices/{backend} #reemplazar
         weight: 30

Debemos reemplazar los servicios de backend.

Aquí está la traducción al español del texto proporcionado:

¿Qué hace esta regla yaml?

• defaultService: Esto especifica el servicio de backend predeterminado que el balanceador de carga debe usar si ninguna de las reglas de ruta coincide con la solicitud entrante. El servicio de backend se identifica por una ruta que incluye el nombre del proyecto ({proj-name}), la región ({region}) y el nombre del servicio de backend ({backend}).
• name: Esto es simplemente un nombre dado al coincidente, en este caso, matcher1.
• routeRules: define un conjunto de reglas para dirigir solicitudes entrantes a servicios de backend.
• matchRules: lista de reglas que determinan cómo el balanceador de carga hace coincidir una solicitud entrante con una regla de ruta.
• prefixMatch: indica que la regla debe coincidir con cualquier solicitud porque es la ruta raíz.
• priority: Esto establece la prioridad de la regla. Dado que está establecido en 0, esta regla tiene la máxima prioridad (cuanto más bajo es el número, mayor es la prioridad).
• routeAction: Esto define qué acción tomar cuando se encuentra una coincidencia.
• weightedBackendServices: Esta es una lista de servicios de backend y sus pesos asociados. Cuando se enumeran varios servicios de backend, los pesos determinan cómo se distribuye el tráfico entre ellos.
  • El primer servicio de backend se asigna un peso de 70, lo que significa que recibirá aproximadamente el 70% del tráfico.
  • El segundo servicio de backend se asigna un peso de 30, por lo que recibirá aproximadamente el 30% del tráfico.

Luego hacer click in “Done”.

¿Qué es la “Regla Predeterminada”? Es una regla necesaria que actuará para cualquier host no coincidente. Configuraremos el servicio-azul como nuestro predeterminado.

Configuración de Frontend

Para finalizar nuestra configuración, configuraremos una IP privada interna en el frontend de nuestro balanceador de carga. Todas las solicitudes serán redirigidas a esta IP. En un entorno de producción, solo recibirá el tráfico a través de estos servicios y bloqueará/deshabilitará cualquier tráfico directo a nuestros backends.

• Configura la IP privada 10.10.30.5 con tráfico HTTP en el puerto 80.

• Ahora revisa y finaliza:

Test de tráfico

¡Ahora enviamos el tráfico directamente al Balanceador de Carga y podemos ver que nuestra regla está funcionando!