- Dirección del tráfico. Dirige el tráfico de forma inteligente en función de los parámetros HTTP(S) (por ejemplo, el host, la ruta, los encabezados y otros parámetros de solicitud).
- Acciones de tráfico. Realizar acciones basadas en solicitudes y respuestas (por ejemplo, redirecciones y transformaciones de encabezados).
- Políticas de tráfico. Ajustar el comportamiento del balanceo de carga (por ejemplo, algoritmos de balanceo de carga avanzados).
Puede configurar estas funciones mediante mapas de URLs y servicios de backend. Para obtener más información, consulta los siguientes temas:
Ejemplos de uso
La gestión del tráfico abarca muchos casos prácticos. En esta sección se ofrecen algunos ejemplos generales.
Dirección de tráfico: enrutamiento basado en encabezados
La dirección de tráfico te permite dirigir el tráfico a instancias de servicio en función de parámetros HTTP, como los encabezados de solicitud. Por ejemplo, si el dispositivo de un usuario es un dispositivo móvil con user-agent:Mobile en el encabezado de la solicitud, la dirección del tráfico puede enviar ese tráfico a instancias de servicio designadas para gestionar el tráfico móvil y enviar el tráfico que no tenga user-agent:Mobile a instancias designadas para gestionar el tráfico de otros dispositivos.
Acciones de tráfico: división del tráfico basada en el peso
Desplegar una nueva versión de un servicio de producción ya disponible suele conllevar ciertos riesgos. Aunque las pruebas se superen en el entorno de preproducción, probablemente no quieras someter al 100% de tus usuarios a la nueva versión de inmediato. Con la gestión del tráfico, puedes definir divisiones del tráfico basadas en porcentajes entre 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. Una vez que hayas validado que la nueva versión de producción funciona correctamente, puedes ir cambiando los porcentajes hasta que el 100% del tráfico llegue a la nueva versión de tu servicio. La división del tráfico se suele usar para desplegar versiones nuevas, hacer pruebas A/B, migrar servicios y procesos similares.
Políticas de tráfico: replicación de solicitudes
Es posible que tu organización tenga requisitos de cumplimiento específicos que exijan que todo el tráfico se refleje en un servicio adicional que pueda, por ejemplo, registrar los detalles de la solicitud en una base de datos para reproducirlos más adelante.
Extensibilidad con extensiones de servicio
La integración con extensiones de servicio te permite insertar lógica personalizada en la ruta de datos de balanceo de carga de los balanceadores de carga de aplicaciones compatibles.
Para obtener más información, consulta Información general de las extensiones de servicio.
Componentes de gestión del tráfico
A grandes rasgos, los balanceadores de carga gestionan el tráfico mediante recursos de mapas de URLs regionales y servicios de backend regionales.En el caso de los balanceadores de carga de aplicación internos entre regiones, la gestión del tráfico usa los recursos de mapas de URLs globales y servicios de backend globales.
Puede configurar la dirección y las acciones del tráfico mediante mapas de URLs. Google Cloud Los recursos asociados a los mapas de URLs son los siguientes:
- Regla de ruta
- Coincidencia con la regla
- Acción de regla
Puedes configurar políticas de tráfico mediante servicios de backend. Google Cloud Los recursos asociados a los servicios de backend incluyen los siguientes:
- Interruptores
- Política de balanceo de carga según ubicación
- Configuración del balanceador de carga de hash coherente
- Detección de valores atípicos
En el siguiente diagrama se muestran los recursos que se usan para implementar cada función.
Dirigir solicitudes a back-ends
En los balanceadores de carga de aplicación internos regionales, 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 instancias de máquinas virtuales (VMs) de Compute Engine en un grupo de instancias no gestionado, VMs de Compute Engine en un grupo de instancias gestionado (MIG) o contenedores mediante un nodo de Google Kubernetes Engine (GKE) en un grupo de endpoints de red (NEG). El balanceador de carga elige un servicio de backend en función de las reglas definidas en un mapa de URLs regional.
- El servicio de backend selecciona una instancia de backend en función de las políticas definidas en un servicio de backend regional.
Cuando configures el enrutamiento, podrás elegir entre los siguientes modos:
- Regla sencilla de host y ruta
- Regla 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.
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 habitual 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 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 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 tienen un valor de prioridad asociado y se interpretan en orden de prioridad (en lugar de usar la semántica de la coincidencia de 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. Por ejemplo, el siguiente mapa de URLs configura el enrutamiento de forma que el 95% del tráfico se dirige a un servicio backend y el 5% del tráfico se dirige a otro servicio 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 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.
hostRules[] y defaultService en la documentación de la API de mapa de URLs regionales.
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 lo siguiente:
- Una o varias 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 coincide ningún otro servicio de backend.
pathMatchers[], pathMatchers[].pathRules[] y pathMatchers[].routeRules[] en la documentación de la API de mapas de URLs regionales.
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.
pathRules[] en la documentación de la API de asignación de URLs regionales.
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). Por ejemplo, esto te permite enviar solicitudes HTTP(S) a un conjunto de backends en función de la presencia de un encabezado HTTP definido de forma personalizada.
Nota: Las opciones de coincidencia y la semántica varían en función de la parte de la solicitud con la que coincidas. Para obtener más información, consultematchRules[] en la documentación de la API de asignación de URLs regionales.
Si tiene varias reglas de ruta, el balanceador de carga las ejecuta por orden de prioridad (según el campo priority), lo que le 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:
- Busca la primera regla de coincidencia que coincida con la solicitud.
- Deja de buscar otras reglas de coincidencia.
- 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 comparador de rutas concreto. La prioridad determina el orden de evaluación de las reglas 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.
Los números de prioridad pueden tener huecos. No puedes crear más de una regla 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) |
Te permite especificar qué acciones se deben llevar a cabo cuando se cumplan los criterios de la regla de coincidencia. Entre ellas se incluyen la división del tráfico, la reescritura de URLs, la reintento y la creación de réplicas, la inyección de errores y las políticas de CORS. |
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. |
Acción de encabezado (headerAction) |
Puede configurar reglas de transformación de encabezados de solicitud y respuesta cuando se cumplan los criterios de matchRules.
|
routeRules[]routeRules[].priorityrouteRules[].descriptionrouteRules[].servicerouteRules[].matchRules[]routeRules[].routeActionrouteRules[].urlRedirectrouteRules[].headerAction
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/hdesexample.net. En la solicitud, el nombre de host procede del encabezadoHost, como se muestra en este comando curl de ejemplo, donde10.1.2.9es 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).
pathMatchers[].routeRules[].matchRules[] en la documentación de la API de mapa de URLs regionales.
Acciones de ruta
Las acciones de ruta son acciones específicas que se deben llevar a cabo cuando una regla de ruta coincide con los atributos de una solicitud.
Acción de ruta (API field name) |
Descripción |
|---|---|
Redirecciones (urlRedirect) |
Devuelve un código de respuesta 3xx configurable. También define el encabezado de respuesta Location
con el URI adecuado, sustituyendo el host y la ruta según se especifica en
la acción de redirección.
|
Reescrituras de URLs (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 de encabezado (headerAction) |
Añade o elimina encabezados de solicitud antes de enviar una solicitud al servicio backend. También puedes añadir o quitar encabezados de respuesta después de recibir una respuesta del servicio backend. Si intentas añadir y quitar el mismo encabezado, se quitará, a menos que se use la marca replace: True con la operación requestHeadersToAdd.
|
Proyección del tráfico (requestMirrorPolicy) |
Además de reenviar la solicitud al servicio de backend seleccionado, envía una solicitud idéntica al servicio de backend de réplica configurado de forma fire and forget. El balanceador de carga no espera una respuesta del backend al que envía la solicitud duplicada. Ten en cuenta las siguientes limitaciones al usar la creación de reflejo del tráfico:
|
División del tráfico ponderada (weightedBackendServices) |
Permite que el tráfico de una regla coincidente se distribuya entre varios servicios de backend, de forma proporcional al peso definido por el usuario que se haya asignado a cada servicio de backend. Esta función es útil para configurar implementaciones por fases o pruebas A/B. Por ejemplo, la acción de ruta se puede configurar de forma que el 99% del tráfico se envíe a un servicio que ejecute una versión estable de una aplicación, mientras que el 1% del tráfico se envíe a un servicio independiente que ejecute una versión más reciente de esa aplicación. |
Reintentos (retryPolicy) |
Configura las condiciones en las que el balanceador de carga vuelve a intentar las solicitudes fallidas, el tiempo que espera el balanceador de carga antes de volver a intentarlo y el número máximo de reintentos permitidos. |
Tiempo de espera agotado (timeout) |
Especifica el tiempo de espera de la ruta seleccionada. El tiempo de espera se calcula desde el momento en que se procesa por completo la solicitud hasta el momento en que se procesa por completo la respuesta. El tiempo de espera incluye todos los reintentos. |
Inyección de fallos (faultInjectionPolicy) |
Introduce errores al atender solicitudes para simular fallos, como alta latencia, sobrecarga del servicio, fallos del servicio y partición de la red. Esta función es útil para probar la resiliencia de un servicio ante fallos simulados. |
Retrasar la inyección (faultInjectionPolicy) |
Introduce retrasos en una parte de las solicitudes definida por el usuario antes de enviar la solicitud al servicio de backend seleccionado. |
Abortar inyecció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) gestionan la configuración para aplicar las solicitudes CORS. |
Puedes especificar una de las siguientes acciones de ruta:
- Dirigir tráfico hacia un solo servicio (
service). - Dividir el tráfico entre varios servicios (
weightedBackendServices weight:x, donde x debe ser un número entre 0 y 1000). - URLs de redirección (
urlRedirect).
Además, puedes combinar cualquiera de las acciones de ruta mencionadas anteriormente con una o varias de las siguientes acciones de ruta:
- Duplicar tráfico (
requestMirrorPolicy). - Vuelve a escribir el host y la ruta de la URL (
urlRewrite). - Reintenta las solicitudes fallidas (
retryPolicy). - Define el tiempo de espera (
timeout). - Introduce fallos en un porcentaje del tráfico (
faultInjectionPolicy). - Añade una política de CORS (
corsPolicy). - Manipular encabezados de solicitud o respuesta (
headerAction).
urlRedirecturlRewriteheaderActionrequestMirrorPolicyweightedBackendServicesretryPolicytimeoutfaultInjectionPolicycorsPolicy
Redirecciones de HTTP a HTTPS
Si necesita redirigir el tráfico HTTP a HTTPS, puede 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, debe reservar la dirección IP e incluir la marca--purpose=SHARED_LOADBALANCER_VIP:
gcloud compute addresses create NAME \
--region=us-west1 \
--subnet=backend-subnet \
--purpose=SHARED_LOADBALANCER_VIP
Para ver un ejemplo completo, consulta Configurar el redireccionamiento de HTTP a HTTPS en balanceadores de carga de aplicaciones internos.
Políticas de tráfico
Con los recursos de servicio de backend, puedes configurar políticas de tráfico para ajustar el balanceo de carga en un grupo de instancias o en un grupo de puntos finales de red (NEG). Estas políticas solo se aplican después de que se haya seleccionado un servicio backend mediante tu mapa de URLs (como se ha descrito anteriormente).
Las políticas de tráfico te permiten hacer lo siguiente:
- Controla el algoritmo de balanceo de carga entre las instancias del servicio de backend.
- Controla el volumen de las conexiones a un servicio upstream.
- Controla la expulsión de los hosts que no están en buen estado de un servicio de backend.
Política de tráfico (API field name) |
Descripción |
|---|---|
Política de localidad de balanceo de carga (LocalityLbPolicy) |
En un servicio de backend, la distribución del tráfico se basa en un modo de balanceo de carga y en una política de localidad de balanceo de carga. El modo de balanceo determina la ponderación o la fracción del tráfico que se debe enviar a cada backend (grupo de instancias o Para ver los modos de balanceo admitidos, consulta Modo de balanceo. Para consultar los algoritmos de la política de balanceo de carga admitidos, consulta |
Afinidad de sesión (consistentHash) |
Incluye la afinidad basada en cookies HTTP, la afinidad basada en encabezados HTTP, la afinidad basada en direcciones IP de clientes, la afinidad de sesión basada en cookies con estado y la afinidad de cookies generadas. La afinidad de sesión intenta enviar las solicitudes de un cliente concreto al mismo backend mientras este 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) |
Conjunto de políticas que especifican los criterios para expulsar las VMs o los endpoints de backend en mal estado de los NEGs, así como los criterios que definen cuándo se considera que un backend o un endpoint está lo suficientemente en buen estado como para volver a recibir tráfico. Para obtener más información sobre la detección de valores atípicos, consulte |
Interrupción de circuitos (circuitBreakers) |
Define los límites superiores del volumen de conexiones y solicitudes por conexión a un servicio de backend. Para obtener más información sobre la interrupción de circuitos, consulta |
Siguientes pasos
- Para configurar la gestión del tráfico de los balanceadores de carga de aplicación internos, consulta Configurar la gestión del tráfico de los balanceadores de carga de aplicación internos.