Información general sobre la gestión del tráfico de un balanceador de carga de aplicaciones clásico

En esta página se ofrece una descripción general de las funciones de gestión del tráfico disponibles para el balanceador de carga de aplicación clásico. Esta página solo está dirigida al balanceador de carga de aplicación clásico. Si usas un balanceador de carga en otro modo que admita el conjunto ampliado de funciones de gestión del tráfico, consulta una de las páginas siguientes:

El balanceador de carga de aplicación clásico admite funciones de gestión del tráfico que te permiten usar las siguientes características:

Estas funciones se configuran mediante el mapa de URLs del balanceador de carga. Para obtener información general, consulta los siguientes temas:

Componentes de gestión del tráfico

A grandes rasgos, los balanceadores de carga de aplicaciones externos gestionan el tráfico mediante mapas de URLs globales.

El balanceador de carga ofrece las siguientes acciones principales mutuamente excluyentes:

  • Dirigir solicitudes a un servicio backend
  • Realizar una redirección

Cuando configuras un balanceador de carga, puedes configurar una acción de reescritura de URL antes de que el balanceador de carga envíe solicitudes al servicio de backend o al segmento de backend.

Las reescrituras o redirecciones se pueden aplicar en tres niveles del mapa de URLs:

  • En el pathRule donde la acción se aplica cuando se encuentra una ruta
  • En pathMatcher, donde la acción tiene efecto cuando no se encuentra ninguna ruta para este pathMatcher.
  • En el urlMap donde la acción se aplica cuando no se encuentra ninguna coincidencia con los hosts especificados en ninguna de las reglas de host

Usar routeRules en un pathMatcher es una alternativa a usar pathRules. pathRules y routeRules no pueden aparecer en el mismo pathMatcher. A diferencia de pathRules, donde el orden no importa, los routeRules se examinan en orden. Un routeRule puede probar la ruta de la URL, los encabezados HTTP y los parámetros de consulta de la URL.

Ejemplos de uso

La gestión del tráfico abarca muchos casos prácticos. En esta sección se ofrecen algunos ejemplos generales.

Reescrituras

La reescritura de URLs te permite mostrar a los usuarios externos URLs que sean diferentes de las que usan tus servicios.

La reescritura de URLs separa una URL de un recurso. Puedes traducir URLs fáciles de usar para los usuarios, que son más fáciles de recordar y usar, a URLs optimizadas para buscadores, que son más fáciles de encontrar para los buscadores, o a URLs internas específicas de la implementación.

La función de reescritura de URLs hace lo siguiente:

  1. Lee la URL entrante de la solicitud.
  2. Sustituye el host, la ruta o ambos, transformando la URL antes de dirigir el tráfico al servicio de backend o al segmento de backend.

En el siguiente diagrama:

  1. Un usuario de Japón envía una solicitud para la URL www.mydomain.com/static/images/someimage.jpg.
  2. Cuando la solicitud llega al balanceador de carga de aplicación externo, este usa la información del mapa de URLs para reescribir la URL como www.myorigin.com/august_snapshot/images/someimage.jpg.
  3. (Opcional) En este ejemplo, el mapa de URLs envía la solicitud a un backend externo.
Reescritura de URLs con el balanceador de carga de aplicación clásico.
Imagen 1. Reescritura de URLs con el balanceador de carga de aplicación clásico.

Para ver un ejemplo de configuración, consulta Reescrituras.

Redireccionamientos

Con las redirecciones de URL, puedes redirigir las solicitudes de los clientes de una URL a otra.

Esto incluye la capacidad de:

  • Redirige todas las solicitudes HTTP a solicitudes HTTPS.
  • Redirigir a otra URL formada modificando el host, la ruta o ambos elementos de la URL, y eliminando o conservando los parámetros de consulta.
  • Elige qué códigos de respuesta de redirección quieres emitir.

Utilice redirecciones de URL para las siguientes funciones:

  • Proporciona acortamiento de URLs. Las URLs visibles para los clientes pueden ser mucho más cortas. Este servicio emite una redirección a la página web con la URL larga.
  • Evita que los enlaces se rompan cuando se muevan o se queden obsoletas las páginas web.
  • Permite que varios nombres de dominio pertenecientes al mismo propietario hagan referencia a un único sitio web.
  • Evita el trabajo pesado y las ineficiencias de configurar soluciones alternativas en el servidor backend para admitir la redirección necesaria.
  • Reduce la latencia. Las redirecciones creadas en el perímetro pueden provocar una latencia menor que las redirecciones creadas en los endpoints de backend.

Además, los redireccionamientos de HTTP a HTTPS te ayudan a lo siguiente:

  • Cumplir los requisitos (como HIPAA) para el tráfico cifrado.
  • Redirige las solicitudes mediante HTTPS en lugar de rechazar las solicitudes enviadas con el protocolo HTTP.
  • Mejora el perfil de seguridad de tu aplicación redirigiendo el tráfico en el propio balanceador de carga de la capa 7, en lugar de implementar la redirección en el servidor backend.

En el siguiente diagrama:

  1. Un usuario de Japón envía una solicitud de GET http://example.com/img1.
  2. En función de la redirección definida en el mapa de URLs, el balanceador de carga envía una redirección HTTP/1.1 302 Found Location: https://example.com/img1, que redirige la solicitud HTTP a una solicitud HTTPS.
  3. El navegador del usuario envía una solicitud GET https://example.com/img1.
Redirección de URLs con el balanceador de carga de aplicación clásico.
Imagen 2. Redirección de URL con el balanceador de carga de aplicación clásico.

Para ver un ejemplo de configuración, consulta Redirecciones.

Códigos de respuesta admitidos

Los códigos de respuesta de redirección admitidos se indican en la tabla.

Código de respuesta Número Notas
MOVED_PERMANENTLY_DEFAULT 301
FOUND 302
PERMANENT_REDIRECT 308 En este caso, se conserva el método de solicitud.
TEMPORARY_REDIRECT 307 En este caso, se conserva el método de solicitud.
SEE_OTHER 303

Enrutamiento basado en encabezados y parámetros

El enrutamiento basado en encabezados y parámetros permite que un balanceador de carga tome decisiones de enrutamiento basadas en encabezados HTTP y parámetros de consulta de URL.

Con esta función, puedes simplificar tu arquitectura de nube sin tener que implementar niveles adicionales de proxies (como NGINX) para enrutar.

Puedes usar el balanceador de carga de aplicación externo para hacer lo siguiente:

  • Pruebas A/B
  • Asignar clientes a diferentes conjuntos de servicios que se ejecutan en back-ends
  • Ofrecer páginas y experiencias diferentes en función de las categorías de dispositivos desde las que se originan las solicitudes

Una vez que se ha seleccionado un pathMatcher en función de la cadena de host, el routeRules de pathMatcher selecciona una ruta de URL. Para obtener más información, consulta la descripción general de los mapas de URLs.

Ejemplo: configurar pruebas A/B con el enrutamiento basado en parámetros de consulta

En el siguiente ejemplo se muestra cómo hacer pruebas A/B haciendo coincidir la cadena de consulta para especificar el experimento y la entrada.

Supongamos que quieres asegurarte de que las solicitudes se gestionen de la siguiente manera:

  • Todas las solicitudes con el valor del parámetro de consulta A se envían al servicio de backend llamado BackendServiceForProcessingOptionA.
  • Todas las solicitudes con el valor del parámetro de consulta B se envían al servicio de backend llamado BackendServiceForProcessingOptionB.

Estos requisitos se resumen en la siguiente tabla.

Solicitud Servicio de backend
http://test.mydomain.com?ABTest=A BackendServiceForProcessingOptionA
http://test.mydomain.com?ABTest=B BackendServiceForProcessingOptionB

Para configurar esta opción en su mapa de URLs global, puede crear los siguientes ajustes.

Match Acción
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest

pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = A
pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionA
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest

pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = B
pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionB

Para ver un ejemplo de configuración, consulta Enrutamiento basado en encabezados y parámetros.

Dirigir solicitudes a back-ends

El backend de tu tráfico se determina mediante un enfoque de dos fases:

  • El balanceador de carga selecciona un servicio de backend con backends. Los backends pueden ser los siguientes:

    • Instancias de máquina virtual (VM) de Compute Engine en un grupo de instancias no gestionado
    • Máquinas virtuales de Compute Engine en un grupo de instancias gestionado (MIG)
    • Contenedores mediante un nodo de Google Kubernetes Engine (GKE) en un grupo de endpoints de red (NEG) zonal
    • Backends externos fuera de Google Cloud en un NEG de Internet
    • Cloud Storage en segmentos de backend
    • Funciones de Cloud Run o servicios de App Engine o Cloud Run en un NEG sin servidor

    El balanceador de carga elige un servicio de backend en función de las reglas definidas en un mapa de URLs global.

  • El servicio de backend selecciona una instancia de backend en función de las políticas definidas en un servicio de backend global.

Cuando configures el enrutamiento, podrás elegir entre los siguientes modos:

  • Pruebas sencillas de host y ruta mediante pathRules
  • Pruebas de solicitudes avanzadas mediante routeRules

En cada mapa de URLs, puede usar reglas de host y ruta sencillas o reglas de host, ruta y direccionamiento avanzadas. Los dos modos se excluyen mutuamente. Cada mapa de URLs solo puede contener un modo u otro.

Regla sencilla de host y ruta

En una regla sencilla de host y ruta, los mapas de URLs funcionan como se describe en la descripción general de los mapas de URLs.

En el siguiente diagrama se muestra el flujo lógico de una regla sencilla de host y ruta.

Flujo de mapa de URLs con una regla sencilla de host y ruta.
Imagen 3. Flujo de mapa de URLs con una regla sencilla de host y ruta.

Una solicitud se evalúa inicialmente mediante reglas de host. Un host es el dominio especificado en la solicitud. Si la solicitud host coincide con una de las entradas del campo hosts, se utiliza el elemento de coincidencia de ruta asociado.

A continuación, se evalúa el matcher de ruta. Las reglas de ruta se evalúan según el criterio de la ruta más larga que coincida primero y se pueden especificar en cualquier orden. Una vez que se encuentra la coincidencia más específica, la solicitud se dirige al servicio de backend correspondiente. Si la solicitud no coincide, se utiliza el servicio backend predeterminado.

Una regla sencilla de host y ruta típica podría ser como la siguiente, donde el tráfico de vídeo va a video-backend-service y el resto del tráfico va a web-backend-service.

$ gcloud compute url-maps describe ext-https-map
defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: ext-https-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: global/backendServices/video-backend-service

Para ver un ejemplo de configuración, consulta Host y ruta.

Regla de host, ruta y direccionamiento avanzadas

Las reglas de host, ruta y direccionamiento avanzadas ofrecen opciones de configuración adicionales en comparación con las reglas de host y ruta sencillas. Estas opciones permiten patrones de gestión del tráfico más avanzados y también modifican parte de la semántica. Por ejemplo, las reglas de ruta se ejecutan en orden (en lugar de usar la semántica de la coincidencia de la ruta más larga primero).

Al igual que en el ejemplo anterior de regla de host y ruta sencilla, puedes configurar la gestión avanzada del tráfico mediante un mapa de URLs global, pero en lugar de usar pathMatchers[].pathRules[], usas pathMatchers[].routeRules[].

En las siguientes secciones se explican los componentes de las reglas de host, ruta y ruta avanzadas.

Reglas de host

Cuando una solicitud llega a tu balanceador de carga, el campo host de la solicitud se evalúa en función del hostRules definido en el mapa de URLs. Cada regla de host consta de una lista de uno o varios hosts y un único comparador de rutas (pathMatcher). Si no se define ningún hostRules, la solicitud se dirige al defaultService.

Para obtener más información, consulta hostRules[] y defaultService en la documentación de la API de mapas de URLs globales.

Comparadores de rutas

Cuando una solicitud coincide con una regla de host, el balanceador de carga evalúa el PathMatcher correspondiente al host.

Un comparador de rutas se compone de los siguientes elementos:

  • Una o varias reglas de ruta (pathRules) o reglas de enrutamiento (routeRules).
  • Una regla predeterminada que se ejecuta cuando no coincide ningún otro servicio backend. La regla tiene las siguientes opciones mutuamente excluyentes:

    • Un servicio predeterminado especifica el servicio de backend predeterminado al que se debe dirigir el tráfico cuando no coincida con ningún otro servicio de backend.
    • Una redirección predeterminada especifica la URL a la que se redirige cuando no coincide ningún otro servicio backend.

Cuando el balanceador de carga se configura para un servicio predeterminado, también se puede configurar para reescribir la URL antes de enviar la solicitud al servicio predeterminado.

Para obtener más información, consulta pathMatchers[], pathMatchers[].pathRules[] y pathMatchers[].routeRules[] en la documentación de la API de mapa de URLs global.

Reglas de ruta

Las reglas de ruta (pathRules) especifican una o varias rutas de URL, como / o /video. Las reglas de ruta suelen estar pensadas para el tipo de enrutamiento sencillo basado en host y ruta que se ha descrito anteriormente.

Para obtener más información, consulta pathRules[] en la documentación de la API de mapa de URLs global.

Reglas de ruta

Una regla de ruta (routeRules) coincide con la información de una solicitud entrante y toma una decisión de enrutamiento en función de la coincidencia.

Las reglas de ruta pueden contener una variedad de reglas de coincidencia (matchRules) y de acciones de ruta (routeAction).

Una regla de coincidencia evalúa la solicitud entrante en función de la ruta, los encabezados y los parámetros de consulta de la solicitud HTTP(S). Las reglas de coincidencia admiten varios tipos de coincidencias (por ejemplo, coincidencias de prefijo) y modificadores (por ejemplo, no distinguir entre mayúsculas y minúsculas). De esta forma, puedes, por ejemplo, enviar solicitudes HTTP(S) a un conjunto de backends en función de la presencia de un encabezado HTTP definido de forma personalizada.

Para ver una lista detallada de las opciones admitidas por matchRules, consulta matchRules[] en la documentación de la API de mapas de URLs globales.

Si tienes varias reglas de ruta, el balanceador de carga las ejecuta en orden, lo que te permite especificar una lógica personalizada para la coincidencia, el enrutamiento y otras acciones.

En una regla de ruta determinada, cuando se encuentra la primera coincidencia, el balanceador de carga deja de evaluar las reglas de coincidencia y se ignoran las reglas de coincidencia restantes.

Google Cloud realiza las siguientes acciones:

  1. Busca la primera regla de coincidencia que coincida con la solicitud.
  2. Deja de buscar otras reglas de coincidencia.
  3. Aplica las acciones de la ruta correspondiente.

Las reglas de ruta tienen varios componentes, tal como se describe en la siguiente tabla.

Componente de regla de ruta (API field name) Descripción
Prioridad (priority) Número comprendido entre 0 y 2.147.483.647 (es decir, (2^31)-1) asignado a una regla de ruta de un matcher de ruta determinado para determinar el orden de evaluación de la regla de ruta.

La prioridad más alta es 0. La prioridad más baja es 2147483647. Por ejemplo, una regla con prioridad 4 se evalúa antes que una regla con prioridad 25. Se aplica la primera regla que coincida con la solicitud.

Los números de prioridad pueden tener huecos; no es necesario que sean contiguos. No puedes crear varias reglas con la misma prioridad.
Descripción (description) Descripción opcional de hasta 1024 caracteres.
Servicio (service) La URL completa o parcial del recurso de servicio de backend al que se dirige el tráfico si se cumple esta regla.
Reglas de coincidencia (matchRules) Una o varias reglas que se evalúan en función de la solicitud. Estos matchRules pueden coincidir con todos los atributos HTTP de la solicitud o con un subconjunto de ellos, como la ruta, las cabeceras HTTP y los parámetros de consulta (GET).

En un matchRule, se deben cumplir todos los criterios que coincidan para que se aplique el routeActions del routeRule. Si un routeRule tiene varios matchRules, el routeActions del routeRule se aplica cuando una solicitud coincide con cualquiera de los matchRules del routeRule.
Acción de ruta (routeAction) Le permite especificar una acción de reescritura de URL que se debe llevar a cabo cuando se cumplan los criterios de la regla de coincidencia.
Acción de redirección (urlRedirect) Puedes configurar una acción para responder con una redirección HTTP cuando se cumplan los criterios de la regla de coincidencia. Este campo no se puede usar junto con una acción de ruta.

Para obtener más información, consulta los siguientes campos en la documentación de la API de asignación de URLs global:

  • routeRules[]
  • routeRules[].priority
  • routeRules[].description
  • routeRules[].service
  • routeRules[].matchRules[]
  • routeRules[].routeAction
  • routeRules[].urlRedirect

Reglas de coincidencia

Las reglas de coincidencia (matchRules) coinciden con uno o varios atributos de una solicitud y realizan las acciones especificadas en la regla de ruta. En la siguiente lista se muestran algunos ejemplos de atributos de solicitud que se pueden asociar mediante reglas de coincidencia:

  • Host: un nombre de host es la parte del nombre de dominio de una URL. Por ejemplo, la parte del nombre de host de la URL http://example.net/video/hd es example.net. En la solicitud, el nombre de host procede del encabezado Host, como se muestra en este comando curl de ejemplo, donde 10.1.2.9 es la dirección IP con balanceo de carga:

    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    
  • Las rutas siguen al nombre de host; por ejemplo, /images. La regla puede especificar si debe coincidir toda la ruta o solo la parte inicial.

  • Otros parámetros de solicitud HTTP, como los encabezados HTTP, que permiten la coincidencia de cookies, así como la coincidencia basada en parámetros de consulta (variables GET). Tenga en cuenta que no se admite la coincidencia de expresiones regulares para los valores de encabezado.

Para ver una lista completa de las reglas de coincidencia admitidas, consulta la pathMatchers[].routeRules[].matchRules[]documentación de la API de mapas de URLs globales.

Configurar la gestión del tráfico

Puede usar la Google Cloud consolagcloud o la API Cloud Load Balancing para configurar la gestión del tráfico. En el entorno de configuración que elijas, puedes configurar la gestión del tráfico mediante configuraciones YAML.

Para obtener ayuda a la hora de escribir estos archivos YAML, puedes usar los siguientes recursos: