Descripción general de la administración del tráfico para balanceadores de cargas de HTTP(S) externos

El balanceo de cargas de HTTP(S) externo admite la función avanzada de administración del tráfico que te permite usar las siguientes características:

Puedes configurar estas características con el mapa de URL del balanceador de cargas. Para obtener información general, consulta los siguientes temas:

Componentes de la administración del tráfico

En un nivel alto, los balanceadores de cargas de HTTP(S) externos proporcionan administración del tráfico mediante mapas de URL globales.

El balanceador de cargas proporciona las siguientes acciones principales que son mutuamente excluyentes:

  • Enruta solicitudes a un servicio de backend.
  • Realiza un redireccionamiento.

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

Las reescrituras o los redireccionamientos se pueden aplicar en tres niveles en el mapa de URL:

  • En pathRule, nivel en el que la acción tiene efecto cuando una ruta de acceso coincide
  • En pathMatcher, nivel en el que la acción tiene efecto cuando no hay coincidencias de rutas de acceso para este pathMatcher
  • En urlMap, nivel en el que la acción tiene efecto cuando no coincide ninguno de los hosts especificados en ninguna de las reglas de host

El uso de routeRules en un pathMatcher es una alternativa al uso de pathRules. pathRules y routeRules no pueden aparecer en el mismo pathMatcher. A diferencia de pathRules, en las que el orden no es importante, las routeRules se examinan en orden. Una routeRule puede probar la ruta de acceso de URL, los encabezados HTTP y los parámetros de consulta de URL.

Ejemplos de casos prácticos

La administración del tráfico abarca muchos casos prácticos. En esta sección, se proporcionan algunos ejemplos de alto nivel.

Reescrituras

Las reescrituras de URL te permiten proporcionarles a los usuarios externos URL que son diferentes de las que usan tus servicios.

Una reescritura de URL separa una URL de un recurso. Puedes traducir a partir de URL sencillas, que los usuarios pueden recordar y usar con mayor facilidad, y transformarlas en URL adecuadas para los motores de búsqueda, de modo que puedan encontrarlas sin problemas, o bien en URL internas y específicas de la implementación.

La función de reescritura de URL del balanceo de cargas de HTTP(S) realiza las siguientes acciones:

  1. Lee la URL entrante en la solicitud.
  2. Reemplaza el host, la ruta de acceso o ambos, y transforma la URL antes de dirigir el tráfico al servicio de backend o al depósito de backend.

En el diagrama que se muestra a continuación, se ilustra lo siguiente:

  1. Un usuario en Japón envía una solicitud para la URL www.mydomain.com/static/images/someimage.jpg.
  2. Cuando la solicitud llega al balanceador de cargas de HTTP(S) externo, este usa la información en el mapa de URL para reescribir la URL como www.myorigin.com/august_snapshot/images/someimage.jpg.
  3. En este ejemplo, el mapa de URL envía la solicitud a un origen personalizado (opcional).
Reescritura del balanceo de cargas de HTTP(S) (haz clic para ampliar)
Reescritura de un balanceador de cargas de HTTP(S) externo

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

Redireccionamientos

Con los redireccionamientos de URL, puedes redireccionar solicitudes de clientes de una URL a otra.

De este modo, tienes las siguientes capacidades:

  • Puedes redireccionar todas las solicitudes HTTP a solicitudes HTTPS.
  • Puedes redireccionar a una URL diferente formada mediante la modificación del host, de la ruta de acceso o de ambas partes de la URL, y mediante la eliminación o retención de cualquier parámetro de consulta.
  • Puedes elegir los códigos de respuesta de redireccionamiento que se emitirán.

Con los redireccionamientos de URL, haz lo siguiente:

  • Proporciona acortamiento de URL. Acorta las URL para clientes de manera considerable. Este servicio emite un redireccionamiento a la página web con la URL extensa.
  • Evita los vínculos rotos cuando las páginas web se trasladan o quedan desactualizadas.
  • Permite que varios nombres de dominio que pertenecen al mismo propietario hagan referencia a un solo sitio web.
  • Evita las dificultades y las ineficacias de configurar soluciones alternativas en el servidor de backend para admitir el redireccionamiento necesario.
  • Reduce la latencia. Los redireccionamientos creados en el perímetro pueden generar una latencia más baja en comparación con aquellos creados en los extremos de backend.

Los redireccionamientos de HTTP a HTTPS son útiles en los siguientes aspectos:

  • Te ayudan a satisfacer los requisitos de cumplimiento (como HIPAA) para el tráfico encriptado.
  • Contribuyen en el redireccionamiento de solicitudes mediante HTTPS en lugar del rechazo de solicitudes enviadas con el protocolo HTTP.
  • Te permiten mejorar el perfil de seguridad de tu aplicación mediante el redireccionamiento del tráfico en el balanceador de cargas de capa 7, en lugar de implementar el redireccionamiento en el servidor de backend.

En el diagrama que se muestra a continuación, se ilustra lo siguiente:

  1. Un usuario en Japón envía una solicitud GET http://example.com/img1.
  2. Según el redireccionamiento definido en el mapa de URL, el balanceador de cargas envía un redireccionamiento HTTP/1.1 302 Found Location: https://example.com/img1 que redirecciona la solicitud HTTP a una solicitud HTTPS.
  3. El navegador del usuario envía una solicitud GET https://example.com/img1.
Reescritura del balanceador de cargas de HTTP(S) externo
Redireccionamiento del balanceo de cargas de HTTP(S)

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

Códigos de respuesta admitidos

Los códigos de respuesta de redireccionamiento admitidos se enumeran en la siguiente 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 la solicitud.
TEMPORARY_REDIRECT 307 En este caso, se conserva el método de la solicitud.
SEE_OTHER 303

Enrutamiento basado en encabezados y parámetros

El enrutamiento basado en encabezados y parámetros permite que un balanceador de cargas tome decisiones de enrutamiento en función de encabezados HTTP y parámetros de búsqueda de URL.

Con esta función, puedes simplificar la arquitectura de la nube sin implementar niveles adicionales de proxies (NGINX, por ejemplo) para realizar el enrutamiento.

Puedes usar el balanceador de cargas de HTTP(S) externo para las siguientes tareas:

  • Pruebas A/B
  • Asignación de clientes a diferentes conjuntos de servicios que se ejecutan en backends
  • Publicación de diferentes páginas y experiencias según las distintas categorías de dispositivos desde las que se originan las solicitudes

Después de seleccionar un pathMatcher en función de la string del host, las routeRules en el pathMatcher seleccionan una ruta de URL. Para obtener más información, consulta la descripción general de mapas de URL.

Ejemplo: configuración de pruebas A/B con enrutamiento basado en parámetros de consulta

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

Supongamos que deseas asegurarte de que las solicitudes se manejen de la siguiente manera:

  • Todas las solicitudes con el valor del parámetro de consulta A van al servicio de backend llamado BackendServiceForProcessingOptionA.
  • Todas las solicitudes con el valor del parámetro de consulta B van 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 esto en tu mapa de URL global, puedes crear la siguiente configuración.

Comparación 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.

Enrutamiento de solicitudes a backends

En el balanceo de cargas de HTTP(S), el backend para tu tráfico se determina mediante un enfoque de dos fases:

  • El balanceador de cargas selecciona un servicio de backend con backends. Las siguientes opciones pueden ser los backends:

    • Instancias de máquina virtual (VM) de Compute Engine en un grupo de instancias no administrado
    • VM de Compute Engine en un grupo de instancias administrado (MIG)
    • Contenedores mediante un nodo de Google Kubernetes Engine (GKE) en un grupo de extremos de red (NEG) zonal
    • Orígenes personalizados fuera de Google Cloud en un NEG de Internet
    • Cloud Storage en depósitos de backend

    El balanceador de cargas elige un servicio de backend según las reglas definidas en un mapa de URL global.

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

Cuando configuras el enrutamiento, puedes elegir entre los siguientes modos:

  • La prueba simple de host y ruta de acceso mediante pathRules
  • La prueba avanzada de solicitudes mediante routeRules

Para cada mapa de URL, puedes elegir usar reglas simples de host y ruta de acceso o reglas avanzadas de host, ruta de acceso y enrutamiento. Los dos modos son mutuamente exclusivos. Cada mapa de URL puede contener solo un modo o el otro.

Regla simple de host y ruta de acceso

En una regla simple de host y ruta de acceso, los mapas de URL funcionan como se indica en la descripción general de los mapas de URL.

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

Flujo de mapa de URL simple
Flujo de mapa de URL simple

Una solicitud se evalúa en un inicio mediante reglas de host. Un host es el dominio que la solicitud especifica. Si la solicitud host coincide con una de las entradas del campo hosts, se usa el comparador de rutas de acceso asociado.

A continuación, se evalúa el comparador de rutas de acceso. Las reglas de ruta de acceso se pueden especificar en cualquier orden y se evalúan según el principio de hacer coincidir primero la ruta de acceso más larga. Después de encontrar la coincidencia más específica, la solicitud se enruta al servicio de backend correspondiente. Si la solicitud no coincide, se usa el servicio de backend predeterminado.

Una regla típica y simple de host y ruta de acceso puede tener un aspecto similar al siguiente, en el que el tráfico de video se dirige a video-backend-service y el resto del tráfico 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 de acceso.

Regla avanzada de host, ruta de acceso y enrutamiento

Las reglas avanzadas de host, ruta de acceso y enrutamiento proporcionan opciones de configuración adicionales en comparación con las reglas simples de host y ruta de acceso. Estas opciones habilitan patrones de administración del tráfico más avanzados y también modifican algunas de las semánticas. Por ejemplo, las reglas de enrutamiento se ejecutan en orden (en lugar de usar la semántica de hacer coincidir la ruta de acceso más larga).

Al igual que en el ejemplo anterior de la regla simple de host y ruta de acceso, puedes configurar la administración del tráfico avanzada con un mapa de URL global, pero en lugar de usar pathMatchers[].pathRules[], debes usar pathMatchers[].routeRules[].

En las siguientes secciones, se explican los componentes avanzados de la regla de host, ruta de acceso y enrutamiento.

Reglas de host

Cuando una solicitud llega al balanceador de cargas, el campo host de la solicitud se evalúa en comparación con las hostRules que se definen en el mapa de URL. Cada regla de host consta de una lista de uno o más hosts y un solo comparador de rutas de acceso (pathMatcher). Si no se definen hostRules, la solicitud se direcciona al defaultService.

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

Comparador de rutas de acceso

Una vez que una solicitud coincide con una regla de host, el balanceador de cargas evalúa el comparador de rutas de acceso correspondiente al host.

Un comparador de rutas de acceso tienen los siguientes componentes:

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

    • Un servicio predeterminado especifica el servicio de backend predeterminado al que se debe enrutar cuando ningún otro servicio de backend coincide.
    • Un redireccionamiento predeterminado especifica la URL a la que se redireccionará cuando ningún otro servicio de backend coincida.

Cuando el balanceador de cargas está configurado para un servicio predeterminado, también se lo puede configurar a fin de que reescriba 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 mapas de URL globales.

Reglas de ruta de acceso

Las reglas de ruta de acceso (pathRules) especifican una o más rutas de URL, como / o /video. Las reglas de ruta de acceso, en general, están diseñadas para el tipo de enrutamiento simple basado en hosts y rutas de acceso que se describió antes.

Para obtener más información, consulta pathRules[] en la documentación de la API de mapas de URL globales.

Reglas de enrutamiento

Una regla de enrutamiento routeRules compara la información de una solicitud entrante y toma una decisión de enrutamiento en función de la coincidencia.

Las reglas de enrutamiento pueden contener una variedad de reglas de coincidencia diferentes (matchRules) y una variedad de acciones de rutas diferentes (routeAction).

Una regla de coincidencia evalúa la solicitud entrante según la ruta de acceso, los encabezados y los parámetros de búsqueda de la solicitud HTTP(S). Las reglas de coincidencia admiten varios tipos de coincidencia (por ejemplo, coincidencia de prefijo), así como modificadores (por ejemplo, distinción entre mayúsculas y minúsculas). Esto te permite enviar solicitudes HTTP(S) a un conjunto de backends según la presencia de un encabezado HTTP personalizado.

Para obtener una lista detallada de las opciones compatibles con matchRules, consulta matchRules[] en la documentación de la API de mapas de URL globales.

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

Dentro de una regla de enrutamiento determinada, cuando se realiza la primera coincidencia, el balanceador de cargas deja de evaluar las reglas de coincidencia, y se ignoran las reglas restantes.

Google Cloud realiza las siguientes acciones:

  1. Busca la primera regla de coincidencia que coincida con la solicitud.
  2. Deja de mirar a las otras reglas de coincidencia.
  3. Aplica las tareas en las acciones de ruta correspondientes.

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

Componente de regla de ruta (API field name) Descripción
Prioridad (priority) Un número del 0 al 2,147,483,647 (es decir, 2^31) -1) asignado a una regla de enrutamiento dentro de un comparador de rutas de acceso en particular a fin de determinar el orden de la evaluación de la regla de enrutamiento.

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 brechas; no necesitan ser contiguos. No puedes crear varias reglas con la misma prioridad.
Descripción (description) Una descripción opcional de hasta 1,024 caracteres.
Servicio (service) La URL completa o parcial del recurso de servicio de backend al que se dirige el tráfico si esta regla coincide.
Reglas de coincidencia (matchRules) Una o más reglas que se evalúan en relación con la solicitud. Estas matchRules pueden coincidir con todos los atributos HTTP de la solicitud o con un subconjunto de ellos, como la ruta de acceso, los encabezados HTTP y los parámetros de consulta (GET).

En una matchRule, deben cumplirse todos los criterios de coincidencia para que se apliquen las routeActions de la routeRule. Si una routeRule tiene varias matchRules, las routeActions de la routeRule tienen efecto cuando una solicitud coincide con cualquiera de las matchRules de la routeRule.
Acción de ruta (routeAction) Te permite especificar una acción de reescritura de URL cuando se cumplen los criterios de la regla de coincidencia.
Acción de redireccionamiento (urlRedirect) Puedes configurar una acción para responder con un redireccionamiento 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 mapas de URL globales:

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

Reglas de coincidencia

Las reglas de coincidencia (matchRules) comparan uno o más atributos de una solicitud y realizan acciones especificadas en la regla de enrutamiento. En la siguiente lista, se brindan algunos ejemplos de atributos de solicitud que pueden coincidir mediante las reglas de coincidencia:

  • Host: Un nombre de host es la parte del nombre de dominio de una URL, por ejemplo, la parte del nombre del host de la URL http://example.net/video/hd es example.net. En la solicitud, el nombre de host proviene del encabezado del Host, como se muestra en este comando curl de ejemplo, en el que 10.1.2.9 es la dirección IP del balanceo de cargas:

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

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

Para obtener una lista completa de las reglas de coincidencia compatibles, consulta pathMatchers[].routeRules[].matchRules[] en la documentación de la API de mapas de URL globales.

Configura la administración del tráfico

Puedes usar Cloud Console, gcloud o la API de Cloud Load Balancing para configurar la administración del tráfico. En el entorno de configuración elegido, configura la administración del tráfico mediante opciones de configuración YAML.

Para obtener ayuda con la escritura de estos archivos YAML, puedes usar los siguientes recursos:

Limitaciones

  • Por el momento, UrlMap.tests admite pruebas de enrutamiento simple.
  • Los comandos gcloud import no borran los campos de nivel superior del mapa de URL, como defaultService, defaultRouteAction y defaultUrlRedirect. La solución consiste en crear un nuevo mapa de URL con el archivo YAML con valores actualizados para estos campos de nivel superior y asociar el nuevo mapa de URL con el proxy de destino correspondiente.
  • No se admiten expresiones regulares.
  • No se admiten acciones de encabezado en el mapa de URL, como agregar o quitar encabezados.
  • Límites de complejidad:
    • No puede haber más de 50 routeRules por pathMatcher.
    • No puede haber más de 50 matchRules por routeRule.
    • No puede haber más de 50 headerMatches por matchRule.
    • No puede haber más de 50 queryParameterMatches por matchRule.
  • No puedes tener un pathMatcher con pathRules y otro con routeRules.
  • No puedes especificar depósitos de backend en routeRules.

Próximos pasos