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

El balanceo de cargas HTTP(S) interno admite la funcionalidad avanzada de administración del tráfico que te permite usar las siguientes funciones:
  • Direccionamiento del tráfico: Enrutar de manera inteligente el tráfico en función de los parámetros HTTP(S) (por ejemplo, host, ruta de acceso, encabezados y otros parámetros de solicitud)
  • Acciones de tráfico: Realizar acciones basadas en solicitudes y en respuestas (por ejemplo, redireccionamientos y transformaciones de encabezados)
  • Políticas de tráfico: Ajustar con detalle el comportamiento del balanceo de cargas (por ejemplo, algoritmos de balanceo de cargas avanzados)

Puedes configurar estas funciones mediante mapas de URL y servicios de backend. Para obtener más información, consulta los siguientes temas:

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.

Direccionamiento del tráfico: enrutamiento basado en encabezados

El direccionamiento del tráfico te permite dirigir el tráfico a las instancias de servicio según los parámetros HTTPS, como los encabezados de las solicitudes. Por ejemplo, si el dispositivo de un usuario es un dispositivo móvil con user-agent:Mobile en el encabezado de la solicitud, el direccionamiento del tráfico puede enviar ese tráfico a instancias de servicio designadas para controlar el tráfico de dispositivos móviles y enviar tráfico que no tenga user-agent:Mobile a instancias designadas que controlan el tráfico desde otros dispositivos.

Direccionamiento de tráfico de Cloud Load Balancing (haz clic para agrandar)
Direccionamiento de tráfico de Cloud Load Balancing

Acciones de tráfico: división del tráfico según el peso

Por lo general, implementar una versión nueva de un servicio de producción existente implica cierto riesgo. Incluso si tus pruebas pasan la etapa de pruebas, es probable que no quieras someter al 100% de tus usuarios a la nueva versión de inmediato. El balanceo de cargas de HTTP(S) interno te permite definir las divisiones de tráfico porcentuales en varios servicios de backend.

Por ejemplo, puedes enviar el 95% del tráfico a la versión anterior de tu servicio y el 5% a la nueva versión de tu servicio. Después de verificar que la nueva versión de producción funciona como se espera, puedes cambiar de forma gradual los porcentajes hasta que todo el tráfico llegue a la nueva versión de tu servicio. La división del tráfico suele usarse para implementar versiones nuevas, pruebas A/B, migración de servicios y procesos similares.

División del tráfico de Cloud Load Balancing
División del tráfico de Cloud Load Balancing

Políticas de tráfico: solicitud de duplicación

Tu organización podría tener requisitos de cumplimiento específicos que obliguen a que todo el tráfico se duplique en un servicio adicional que pueda, por ejemplo, registrar los detalles de la solicitud en una base de datos para volver a reproducirlos después.

Componentes de la administración del tráfico

En un nivel alto, los balanceadores de cargas HTTP(S) internos proporcionan administración del tráfico cuando se aprovechan los recursos de mapas de URL regionales y servicios de backend regionales.

Puedes configurar el direccionamiento del tráfico y las acciones de tráfico con mapas de URL regionales. Los recursos de Google Cloud que están asociados a los mapas de URL incluyen los siguientes:

  • Regla de ruta
  • Coincidencias de la regla
  • Acción de la regla

Puedes configurar las políticas de tráfico mediante servicios de backend regionales. Los recursos de Google Cloud que están asociados a los servicios de backend incluyen lo siguiente:

  • Política de balanceador de cargas de localidad
  • Configuración del balanceador de cargas hash coherente
  • Disyuntores
  • Detección de valores atípicos
En el siguiente diagrama, se muestran los recursos que se usan para implementar cada función.

Direccionamiento de tráfico de Cloud Load Balancing (haz clic para agrandar)
Modelo de datos de Cloud Load Balancing (haz clic para ampliar)

Enrutamiento de solicitudes a backends

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

  • El balanceador de cargas selecciona un servicio de backend con backends. Los backends pueden ser 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) o contenedores mediante un nodo de Google Kubernetes Engine (GKE) en un grupo de extremos de red (NEG). El balanceador de cargas elige un servicio de backend basado en reglas definidas en un mapa de URL regional.
  • El servicio de backend selecciona una instancia de backend basada en las políticas definidas en un servicio de backend regional.

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

  • Regla sencilla de host y ruta de acceso
  • Regla avanzada de enrutamiento, ruta de acceso y host

Para cada mapa de URL, puedes elegir usar reglas simples de host y de ruta de acceso o reglas avanzadas de host, ruta de acceso y ruta. 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 de host y ruta de acceso simple típica puede tener un aspecto similar al siguiente: 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 l7-ilb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1

Regla avanzada de enrutamiento, ruta de acceso y host

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 de tráfico más avanzados y también modifican algunas de las semánticas. Por ejemplo, las reglas de ruta tienen un valor de prioridad asociado y se interpretan en orden de prioridad (en lugar de usar la semántica de hacer coincidir primero la ruta de acceso más larga).

Al igual que en el ejemplo de la regla simple de host y ruta de acceso anterior, puedes configurar la administración avanzada del tráfico mediante un mapa de URL regional. Por ejemplo, el siguiente mapa de URL configura el enrutamiento en el que el 95% del tráfico se enruta a un servicio de backend y el 5% del tráfico a otro servicio de backend.

$ gcloud compute url-maps describe l7-ilb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: regions/us-west1/backendServices/service-a
        weight: 95
      - backendService: regions/us-west1/backendServices/service-b
        weight: 5
region: regions/us-west1

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 define ninguna 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 URL regionales.

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 (pathRules) o reglas de ruta (routeRules).
  • Un servicio predeterminado (defaultService), que es el servicio de backend predeterminado que se usa cuando no hay otros servicios de backend compatibles.
Para obtener más información, consulta pathMatchers[], pathMatchers[].pathRules[] y pathMatchers[].routeRules[] en la documentación de la API de mapas URL regionales.

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, en general, están diseñadas para el tipo de enrutamiento simple basado en rutas y en host que se describieron antes.

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

Reglas de ruta

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 basado en la presencia de un encabezado HTTP personalizado.

Si tienes varias reglas de ruta, el balanceador de cargas las ejecuta en orden de prioridad (según el campo priority), lo que te permite especificar lógica personalizada para coincidencias, enrutamiento y otras acciones.

Dentro de una regla de ruta determinada, cuando se realiza la primera coincidencia, el balanceador de cargas 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 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 hasta 2,147,483,647 (es decir, (2^31) - 1) asignado a una regla de ruta dentro de un comparador de rutas de acceso determinado.

La prioridad determina el orden de la evaluación de la regla de ruta. La prioridad de una regla disminuye a medida que aumenta su número, de modo que 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.

Las cifras de prioridad pueden tener brechas. No se puede crear más de una regla 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 qué acciones realizar cuando se cumplen los criterios de la regla de coincidencia. Estas acciones incluyen división de tráfico, reescrituras de URL, reintentos y duplicación, inyección de fallas y políticas de CORS.
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.
Acción del encabezado (headerAction) Puedes configurar reglas de transformación de encabezado de respuesta y solicitud cuando se cumplen los criterios dentro de matchRules.

Para obtener más información, consulta los siguientes campos en la documentación de la API de mapas URL regionales:

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

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 entre cookies, además de la coincidencia basada en parámetros de búsqueda (variables GET).

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

Acciones de ruta

Las acciones de ruta son acciones específicas que se deben realizar cuando una regla de ruta coincide con los atributos de una solicitud.

Acción de ruta (API field name) Descripción
Redireccionamientos (urlRedirect) Muestra un código de respuesta 3xx configurable. También establece el encabezado de respuesta Location con el URI apropiado y reemplaza el host y la ruta como se especifica en la acción de redireccionamiento.
Reescritura de URL (urlRewrite) Reescribe la parte del nombre de host de la URL, la parte de la ruta de la URL o ambas antes de enviar una solicitud al servicio de backend seleccionado.
Transformaciones del encabezado (headerAction) Agrega o quita encabezados de solicitud antes de enviar una solicitud al servicio de backend. También puede agregar o quitar encabezados de respuesta después de recibir una respuesta del servicio de backend.
Duplicación de tráfico (requestMirrorPolicy) Además de reenviar la solicitud al servicio de backend seleccionado, envía una solicitud idéntica al servicio de backend duplicado y configurado en una base enviar y olvidar. El balanceador de cargas no espera una respuesta del backend al que envía la solicitud duplicada.

La duplicación es útil para probar una versión nueva de un servicio de backend. También puedes usarla para depurar errores de producción en una versión de depuración de tu servicio de backend, en lugar de hacerlo en la versión de producción.
División del tráfico ponderado (weightedBackendServices) Permite que el tráfico de una regla coincidente se distribuya a varios servicios de backend, proporcional a un peso definido por el usuario asignado al servicio de backend individual.

Esta capacidad es útil para configurar implementaciones por etapas o pruebas A/B. Por ejemplo, la acción de ruta se podría configurar, de manera que el 99% del tráfico se envíe a un servicio que ejecuta una versión estable de una aplicación, mientras que el 1% del tráfico se envíe a un servicio independiente con una versión más reciente de esa aplicación.
Reintentos (retryPolicy) Configuran las condiciones en las que el balanceador de cargas reintenta enviar solicitudes fallidas, cuánto espera el balanceador de cargas antes de volver a intentarlo y la cantidad máxima de reintentos permitidos.
Tiempo de espera (timeout) Especifica el tiempo de espera para la ruta seleccionada. El tiempo de espera se calcula desde el momento en que la solicitud se procesa por completo hasta el momento en que la respuesta se procesa por completo. El tiempo de espera incluye todos los reintentos.
Inyección de fallas (faultInjectionPolicy) Presenta errores cuando se atienden solicitudes para simular fallas, incluida la latencia alta, la sobrecarga del servicio, las fallas del servicio y la partición de la red. Esta función es útil a fin de probar la resistencia de un servicio para fallas simuladas.
Inyección de demora (faultInjectionPolicy) Presenta retrasos para una parte de solicitudes definidas por el usuario antes de enviar la solicitud al servicio de backend seleccionado.
Inyección de anulación (faultInjectionPolicy) Responde directamente a una fracción de las solicitudes con códigos de estado HTTP definidos por el usuario, en lugar de reenviar esas solicitudes al servicio de backend.
Políticas de seguridad (corsPolicy) Las políticas de uso compartido de recursos entre dominios (CORS) controlan la configuración del balanceo de cargas HTTP(S) interno para aplicar las solicitudes CORS.

Puedes especificar una de las siguientes acciones de ruta (denominadas Acciones principales en Google Cloud Console):

  • Enrutar el tráfico a un solo servicio (service).
  • Dividir el tráfico entre varios servicios (weightedBackendServices weight:x, en el que x < 100).
  • Las URL de redireccionamiento (urlRedirect).

Además, puedes combinar cualquiera de las acciones de ruta mencionadas antes con una o más de las siguientes acciones de ruta (llamadas Acciones de complementos en Cloud Console):

  • Tráfico de duplicación (requestMirrorPolicy)
  • Reescribir la ruta de acceso/host de URL (urlRewrite)
  • Reintentar con las solicitudes que fallaron (retryPolicy)
  • Configurar el tiempo de espera (timeout)
  • Ingresar errores en un porcentaje del tráfico (faultInjectionPolicy)
  • Agregar política de CORS (corsPolicy)
  • Manipular los encabezados de respuesta/solicitud (headerAction)

Para obtener más información sobre la configuración y la semántica de las acciones de ruta, consulta la siguiente información en la documentación de la API de mapas URL regionales:

  • urlRedirect
  • urlRewrite
  • headerAction
  • requestMirrorPolicy
  • weightedBackendServices
  • retryPolicy
  • timeout
  • faultInjectionPolicy
  • corsPolicy

Políticas de tráfico

Mediante los recursos de servicios de backend, puedes configurar políticas de tráfico, que habilitan el balanceo de cargas más preciso en un grupo de instancias o un grupo de extremos de red (NEG). Estas políticas solo se aplican después de que se selecciona un servicio de backend con tu mapa de URL regional (como se describió antes).

Las políticas de tráfico te permiten hacer lo siguiente:

  • Controlar el algoritmo del balanceo de cargas entre instancias dentro del servicio de backend
  • Controlar el volumen de conexiones a un servicio ascendente
  • Controlar el desalojo de hosts que no están en buen estado desde un servicio de backend

Las siguientes funciones de la política de tráfico se configuran en el servicio de backend regional.

Política de tráfico (API field name) Descripción
Política del balanceo de cargas (LocalityLbPolicy) Para un servicio de backend, la distribución del tráfico se basa en un modo de balanceo de cargas y una política de balanceo de cargas.

El servicio de backend primero dirige el tráfico a un backend (grupo de instancias o NEG) según el modo de balanceo del backend. Después de seleccionar un backend, el tráfico se distribuye entre las instancias de ese servicio de backend de acuerdo con la política de balanceo de cargas.

El modo de balanceo permite que el balanceador de cargas seleccione primero una localidad, como una zona de Google Cloud. Luego, la política del balanceo de cargas determina una VM de backend específica o un extremo en un NEG.

Se admiten varios algoritmos del balanceo de cargas (como round robin, solicitud de mínimos y otros). Para obtener una lista completa de los algoritmos, consulta localityLbPolicy en la documentación de la API del servicio de backend regional.
Afinidad de sesión (consistentHash) Incluye afinidad basada en cookies HTTP, afinidad basada en encabezados HTTP, afinidad de direcciones IP de clientes y afinidad de cookie generada. La afinidad de sesión hace su mejor esfuerzo para enviar solicitudes de un cliente en particular al mismo backend, siempre que la parte posterior esté en buen estado y tenga capacidad.

Para obtener más información sobre la afinidad de sesión, consulta consistentHash en la documentación de la API del servicio de backend regional.
Detección de valores atípicos (outlierDetection) Un conjunto de políticas que especifica los criterios para la expulsión de las VM de backend o extremos en mal estado en los NEG, junto con criterios que definen cuándo se considera que un backend o extremo tiene un estado lo suficientemente bueno como para recibir tráfico otra vez.

Si quieres obtener más información sobre la afinidad de sesión, consulta outlierDetection en la documentación de la API del servicio de backend regional.
Disyuntores (circuitBreakers) Establecen límites superiores en el volumen de conexiones y solicitudes por conexión a un servicio de backend.

Para obtener más información sobre la afinidad de sesión, consulta circuitBreakers en el documentación de la API del servicio de backend regional.

Limitaciones

  • Por el momento, RouteRule.service no funciona. La solución alternativa es usar RouteRule.weightedBackendServices con un único WeightedBackendService.
  • Las expresiones regulares de las rutas de acceso pathMatchers.routeRules.matchRules.regexMatch no son compatibles con el balanceo de cargas de HTTP(S) interno.
  • Por el momento, UrlMap.defaultRouteAction y UrlMap.defaultUrlRedirect no funcionan. Debes especificar UrlMap.defaultService para controlar el tráfico que no coincide con ninguno de los hosts en UrlMap.hostRules[] de ese UrlMap.
  • UrlMap.pathMatchers[].defaultRouteAction y UrlMap.pathMatchers[].defaultUrlRedirect no funcionan en este momento. Debes especificar UrlMap.pathMatchers[].defaultService para controlar el tráfico que no coincide con ninguna de los routeRules de ese pathMatcher.
  • Si el valor de BackendService.SessionAffinity no es NINGUNO y BackendService.localityLbPolicy se establece en una política de balanceo de cargas distinta de MAGLEV o RING_HASH, la configuración de afinidad de sesión no se aplicará.
  • Con el comando gcloud compute backend-services import no se borran los campos de nivel superior del recurso, como el servicio de backend y el mapa de URL. Por ejemplo, si creas un servicio de backend con una configuración para circuitBreakers, puedes actualizarla con un comando gcloud compute backend-services import subsiguiente. Sin embargo, no se puede borrar esa configuración del servicio de backend. Puedes borrar y volver a crear el recurso sin la configuración circuitBreakers.

Qué sigue