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:
- Dirección del tráfico Dirige el tráfico de forma inteligente en función de los parámetros HTTP(S):
- Acciones de tráfico Realizar acciones basadas en solicitudes:
- Políticas de tráfico Ajustar el comportamiento del balanceo de carga:
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 estepathMatcher
. - 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:
- Lee la URL entrante de la solicitud.
- 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:
- Un usuario de Japón envía una solicitud para la URL
www.mydomain.com/static/images/someimage.jpg
. - 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
. - (Opcional) En este ejemplo, el mapa de URLs envía la solicitud a un backend externo.
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:
- Un usuario de Japón envía una solicitud de
GET http://example.com/img1
. - 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. - El navegador del usuario envía una solicitud
GET https://example.com/img1
.
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 llamadoBackendServiceForProcessingOptionA
. - Todas las solicitudes con el valor del parámetro de consulta
B
se envían al servicio de backend llamadoBackendServiceForProcessingOptionB
.
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.
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:
- 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 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
esexample.net
. En la solicitud, el nombre de host procede del encabezadoHost
, como se muestra en este comando curl de ejemplo, donde10.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:
La documentación de la API de mapa de URLs global
Proporciona una lista completa de campos, incluida la semántica relativa a las relaciones, las restricciones y la cardinalidad.
Ejemplos de la página de configuración de la gestión del tráfico: