- 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 de uso
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 HTTP, 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.
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. Con la administración del tráfico, puedes definir 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.
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.
Extensibilidad con extensiones del servicio
Los textos destacados de las extensiones de servicio te permiten incorporar lógica personalizada en la ruta de acceso de los datos del balanceo de cargas. Estas extensiones te permiten indicarle a los balanceadores de cargas de aplicaciones compatibles que realicen llamadas gRPC a aplicaciones o servicios administrados por el usuario durante el procesamiento de datos.
Para obtener más información, consulta la Descripción general de las extensiones de servicio.
Componentes de la administración del tráfico
En un nivel alto, los balanceadores de cargas proporcionan administración del tráfico cuando se aprovechan los recursos de mapas de URL regionales y servicios de backend regionales.Para los balanceadores de cargas de aplicaciones internos entre regiones, la administración del tráfico usa los recursos de mapas de URL globales y de servicios de backend globales.
Puedes configurar el direccionamiento del tráfico y las acciones de tráfico con mapas de URL. 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. Los recursos de Google Cloud que están asociados a los servicios de backend incluyen lo siguiente:
- Disyuntores
- Política de balanceador de cargas de localidad
- Configuración del balanceador de cargas hash coherente
- Detección de valores atípicos
En el siguiente diagrama, se muestran los recursos que se usan para implementar cada función.
Enrutamiento de solicitudes a backends
En los balanceadores de cargas de aplicaciones internos regionales, el backend de tu tráfico se determina con 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 simple de host y ruta de acceso
- Regla avanzada 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 sencilla 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.
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 lb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
- '*'
pathMatcher: pathmap
name: lb-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 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 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. 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 lb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: lb-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 definen hostRules, la solicitud se direcciona al defaultService.
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 se compone de lo siguiente:
- Una o más reglas de ruta de acceso (
pathRules) o reglas de enrutamiento (routeRules). - Un servicio predeterminado (
defaultService), que es el servicio de backend predeterminado que se usa cuando no hay otros servicios de backend compatibles.
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 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.
pathRules[] en la documentación de la API de mapas URL regionales.
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.
Nota: Las opciones de concordancia y la semántica varían según la parte de la solicitud con la que coincida. Para obtener más información, consultamatchRules[] en la documentación de la API de mapas URL regionales.
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 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:
- Busca la primera regla de coincidencia que coincida con la solicitud.
- Deja de mirar a las otras reglas de coincidencia.
- 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. |
routeRules[]routeRules[].priorityrouteRules[].descriptionrouteRules[].servicerouteRules[].matchRules[]routeRules[].routeActionrouteRules[].urlRedirectrouteRules[].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/hdesexample.net. En la solicitud, el nombre de host proviene del encabezado delHost, como se muestra en este comando curl de ejemplo, en el que10.1.2.9es 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).
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. |
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 para aplicar las solicitudes de CORS. |
Puedes especificar una de las siguientes acciones de ruta:
- Enrutar el tráfico a un solo servicio (
service) - Dividir el tráfico entre varios servicios (
weightedBackendServices weight:x, en el que x debe ser de 0 a 1000). - Redireccionar las URL (
urlRedirect)
Además, puedes combinar cualquiera de las acciones de ruta mencionadas antes con una o más de las siguientes acciones de ruta:
- Tráfico de duplicación (
requestMirrorPolicy) - Reescribe la ruta de acceso y el 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 o solicitud (
headerAction).
urlRedirecturlRewriteheaderActionrequestMirrorPolicyweightedBackendServicesretryPolicytimeoutfaultInjectionPolicycorsPolicy
Redireccionamientos HTTP a HTTPS
Si necesitas redireccionar el tráfico HTTP a HTTPS, puedes crear dos reglas de reenvío con una dirección IP común.
Para que dos reglas de reenvío compartan una dirección IP interna común, debes reservar la dirección IP y, también, incluir la marca--purpose=SHARED_LOADBALANCER_VIP:
gcloud compute addresses create NAME \
--region=us-west1 \
--subnet=backend-subnet \
--purpose=SHARED_LOADBALANCER_VIP
Si quieres ver un ejemplo completo, consulta Configura el redireccionamiento de HTTP a HTTPS para balanceadores de cargas de aplicaciones internos.
Políticas de tráfico
Mediante los recursos de servicios de backend, puedes configurar políticas de tráfico para ajustar el balanceo de cargas dentro de 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 (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
Política de tráfico (API field name) |
Descripción |
|---|---|
Política de balanceo de cargas de la localidad (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 de la localidad. El modo de balanceo determina el peso o la fracción del tráfico que se debe enviar a cada backend (grupo de instancias o NEG Para conocer los modos de balanceo admitidos, consulta Modos de balanceo. Para obtener información sobre los algoritmos de la política de balanceo de cargas compatibles, consulta |
Afinidad de sesión (consistentHash) |
Incluye afinidad basada en cookies HTTP, afinidad basada en encabezados HTTP, afinidad de direcciones IP de clientes, afinidad de sesión basada en cookies con estado 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 |
Detección de valores atípicos (outlierDetection) |
Un conjunto de políticas que especifican los criterios para retirar VM o extremos de backend en mal estado de los NEG, junto con criterios que definen cuándo un backend o extremo se considera lo bastante saludable como para volver a recibir tráfico. Para obtener más información sobre la detección de valores atípicos, consulta |
Disyuntores (circuitBreakers) |
Establece los 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 interrupción del circuito, consulta |
¿Qué sigue?
- Si quieres configurar la administración del tráfico en los balanceadores de cargas de aplicaciones internos, consulta Configuración de la administración del tráfico en balanceadores de cargas de aplicaciones internos.