Información general sobre la gestión avanzada del tráfico

Este documento está dirigido a administradores de mallas o plataformas y desarrolladores de servicios que tengan un nivel de familiarización intermedio o avanzado con Cloud Service Mesh y los conceptos de malla de servicios, y que determinen y configuren cómo se gestiona el tráfico en una implementación de Cloud Service Mesh.

Cloud Service Mesh ofrece funciones avanzadas de gestión del tráfico que te permiten controlar de forma granular cómo se gestiona el tráfico. Cloud Service Mesh admite los siguientes casos prácticos:

  • Enrutamiento de tráfico detallado de solicitudes a uno o varios servicios.
  • División del tráfico basada en el peso para distribuir el tráfico entre varios servicios.
  • Políticas de duplicación de tráfico que envían solicitudes a un servicio de depuración y copias a otro. La duplicación del tráfico no se admite con el recurso TCPRoute ni con el recurso TLSRoute.
  • Distribución del tráfico ajustada entre los backends de un servicio para mejorar el balanceo de carga.

Estas funciones avanzadas de gestión del tráfico te permiten cumplir tus objetivos de disponibilidad y rendimiento. Una de las ventajas de usar Cloud Service Mesh en estos casos prácticos es que puedes actualizar la forma en que se gestiona el tráfico sin necesidad de modificar el código de tu aplicación.

La gestión del tráfico en una malla de servicios de Cloud Service Mesh se basa en los siguientes recursos:

  • Recurso Mesh, que identifica la malla de servicios y representa el componente responsable de reenviar el tráfico y aplicar las políticas. El recurso Mesh también identifica el puerto de intercepción del tráfico.
  • Recurso Gateway, que identifica proxies intermedios y representa el componente que escucha una lista de pares de direcciones IP y puertos, reenvía el tráfico y aplica políticas.
  • Recurso Route, que puede ser de varios tipos y que contiene información de enrutamiento del tráfico de la malla. Los recursos Route identifican los nombres de host y los puertos que los clientes pueden usar para enrutar el tráfico a los servicios de backend. Estos son los tipos de recursos Route:
    • HTTPRoute, que solo está disponible en mallas que usan proxies de Envoy. Cuando usas el recurso HTTPRoute para configurar los proxies de Envoy de forma que envíen solicitudes HTTP, todas las funciones de este documento están disponibles.
    • TCPRoute, que solo está disponible en mallas que usan proxies de Envoy.
    • TLSRoute, que solo está disponible en mallas que usan proxies de Envoy.
    • GRPCRoute, que está disponible en mallas que usan proxies de sidecar de Envoy y gRPC sin proxy. Cuando usas servicios o aplicaciones gRPC sin proxy con Cloud Service Mesh, algunas de las funciones descritas en este documento no están disponibles.
  • Servicio de backend con el que están asociados los recursos de Route.

Configuración

Para configurar la gestión avanzada del tráfico, se utilizan los mismos recursos de Route y servicios de backend que se usan al configurar Cloud Service Mesh. Cloud Service Mesh, a su vez, configura tus proxies Envoy y aplicaciones gRPC sin proxy para aplicar las políticas de gestión avanzada del tráfico que hayas configurado.

A grandes rasgos, debes hacer lo siguiente:

  1. Configura un recurso Mesh para identificar la malla de servicios.

  2. Configura los recursos de Route para que hagan lo siguiente, en función de las características de la solicitud saliente:

    1. Selecciona el servicio de backend al que se dirigen las solicitudes.

    2. De forma opcional, realiza acciones adicionales.

  3. Configura el servicio de backend para controlar cómo se distribuye el tráfico a los backends y los endpoints después de seleccionar un servicio de destino.

Rutas y acciones de tráfico

En Cloud Service Mesh, el tráfico se enruta en función de los valores de los recursos Mesh, Route y de servicio backend. Todas las funciones avanzadas de gestión del tráfico relacionadas con el enrutamiento y las acciones se configuran mediante los objetos Route.

En las siguientes secciones se describen las funciones de gestión avanzada del tráfico que puedes configurar en los objetos Route.

Gestión de solicitudes

Cuando un cliente envía una solicitud, esta se gestiona de la siguiente manera:

  1. La solicitud se asocia a un recurso Route específico de la siguiente manera:

    • Si usas Envoy:
      • El encabezado de host de la solicitud HTTP se compara con el campo hostnames de cada recurso HTTPRoute o GRPCRoute para seleccionar el recurso Route correcto para la solicitud. Solo los recursos HTTPRoute y GRPCRoute tienen el campo hostnames.
      • La dirección IP coincide con el enrutamiento del tráfico TCP mediante TCPPRoute.
      • SNI y ALPN se usan para la transferencia directa de TLS mediante TLSRoute.
      • Los recursos HTTPRoute y GRPCRoute asociados a un Mesh o a un Gateway deben tener nombres de host únicos. Si intentas adjuntar varias rutas que tengan nombres de host conflictivos, se rechazará la configuración.
      • Del mismo modo, el campo IP:Port del TCPRoute debe ser único. De lo contrario, se rechazará la configuración.
      • Del mismo modo, SNI y ALPN deben ser únicos para TLSRoute.
      • Si hay nombres de host que se solapan, como a.example.com y *.example.com, la solicitud coincidirá con la ruta más específica.
    • Si usas gRPC sin proxy:
      • Los clientes de gRPC sin proxy usan el esquema de resolución de nombres xds. Resuelven el hostname[:port] en el URI de destino enviando una solicitud a Cloud Service Mesh.
      • Solo se compara el puerto de un recurso GRPCRoute con el puerto del URI de destino (por ejemplo, xds:///example.hostname:8080). El URI de destino debe coincidir exactamente con la cadena del campo hostnames del GRPCRoute.

  2. El recurso Route puede contener más información y reglas de enrutamiento.

  3. Una vez que se ha seleccionado el servicio de backend de destino, el tráfico se distribuye entre los backends o los endpoints de ese servicio de backend de destino en función de la configuración del recurso de servicio de backend.

El segundo paso se describe en la siguiente sección, Enrutamiento sencillo basado en el host y la ruta. El tercer paso se explica en Rutas y acciones avanzadas.

Enrutamiento sencillo basado en el host y la ruta

Cloud Service Mesh admite un esquema de enrutamiento simplificado y otro más avanzado. En el esquema sencillo, se especifica un host y, opcionalmente, una ruta. Se evalúan el host y la ruta de la solicitud para determinar el servicio de backend al que se dirige la solicitud.

  • El host de la solicitud es la parte del nombre de dominio de una URL. Por ejemplo, la parte del host de la URL http://example.com/video/ es example.com.
  • La ruta de la solicitud es la parte de la URL que va después del nombre de host. Por ejemplo, la parte de la ruta de la URL http://example.com/video/ es /video.

Configuras un enrutamiento sencillo basado en el host y la ruta en el mapa de reglas de enrutamiento, que consta de lo siguiente:

  • Un Mesh global
  • HTTPRoute o GRPCRoute

La mayor parte de la configuración se realiza en HTTPRoute. Una vez que hayas creado el mapa de reglas de enrutamiento inicial, solo tendrás que modificar el recurso HTTPRoute.

La regla más sencilla es una regla predeterminada, en la que solo se especifica una regla de host comodín (*) y un comparador de rutas con un servicio predeterminado. Después de crear la regla predeterminada, puede añadir reglas adicionales que especifiquen hosts y rutas diferentes. Las solicitudes salientes se evalúan en función de estas reglas de la siguiente manera:

  • Si el host de una solicitud (como example.com) coincide con el nombre de host de HTTPRoute:

    1. A continuación, se evalúa el RouteRule. El RouteRule especifica cómo se debe buscar el tráfico y cómo se debe enrutar cuando se encuentra.
    2. Cada RouteRule contiene una o varias coincidencias de ruta que se evalúan en función de la ruta de la solicitud.
    3. Si se encuentra una coincidencia, la solicitud se enruta al servicio especificado en RouteAction.

Para obtener más información sobre los campos de recursos de HTTPRoute y cómo funcionan, consulta la documentación de la API del servicio de red.

Enrutamiento y acciones avanzadas

Si quieres hacer algo más que enrutar una solicitud en función del host y la ruta de la solicitud, puedes configurar reglas avanzadas para enrutar solicitudes y realizar acciones.

A grandes rasgos, el enrutamiento y las acciones avanzadas funcionan de la siguiente manera:

  1. Al igual que con el enrutamiento simple, el host de la solicitud se compara con las reglas de host que configures en HTTPRoute o GRPCRoute. Si el host de una solicitud coincide con el nombre de host, se evalúa HTTPRoute o GRPCRoute.
  2. Una vez que hayas seleccionado una ruta, podrás aplicar acciones.

Enrutamiento avanzado

El enrutamiento avanzado es similar al enrutamiento simple que hemos descrito anteriormente, pero con la diferencia de que puedes especificar condiciones de coincidencia adicionales. Por ejemplo, puede especificar que una regla coincida con el encabezado de una solicitud si el nombre del encabezado coincide exactamente o solo parcialmente (por ejemplo, en función del prefijo o el sufijo). Una regla puede coincidir en función de la evaluación del nombre del encabezado con una expresión regular o con otros criterios, como comprobar la presencia de un encabezado.

Para obtener más información sobre las condiciones de coincidencia de headerMatches y queryParameterMatches, consulta la página de la API REST de network services.

Al combinar los parámetros de host, ruta, encabezado y consulta con las condiciones de coincidencia, puede crear reglas muy expresivas que se ajusten a sus requisitos exactos de gestión del tráfico. Para obtener más información, consulta la tabla que se incluye más abajo.

Aplicación basada en HTTP Aplicación basada en gRPC
Hosts HTTP frente a hosts gRPC

El host es la parte del nombre de dominio de la URL a la que llama la aplicación.

Por ejemplo, la parte del host de la URL http://example.com/video/ es example.com.

El host es el nombre que usa un cliente en el URI del canal para conectarse a un servicio específico.

Por ejemplo, la parte del host del URI del canal xds:///example.com es example.com.
Rutas HTTP frente a rutas gRPC

La ruta es la parte de la URL que va después del nombre de host.

Por ejemplo, la parte de la ruta de la URL http://example.com/video es /video.

La ruta se encuentra en el encabezado :path de la solicitud HTTP/2 y tiene el siguiente aspecto: /SERVICE_NAME/METHOD_NAME.

Por ejemplo, si llamas al método Download en el servicio Example de gRPC, el contenido del encabezado :path tendrá el siguiente aspecto: /Example/Download.
Otros encabezados de gRPC (metadatos) gRPC admite el envío de metadatos entre el cliente y el servidor gRPC para proporcionar información adicional sobre una llamada RPC. Estos metadatos se presentan en forma de pares clave-valor que se incluyen como encabezados en la solicitud HTTP/2.

Acciones

Cloud Service Mesh te permite especificar las acciones que realizan tus proxies Envoy o tus aplicaciones gRPC sin proxy al gestionar una solicitud. Puedes configurar las siguientes acciones con Cloud Service Mesh.

.
Acción Nombre del campo de la API Descripción
Redireccionamientos redirect [pathredirect?] 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 encabezados requestHeaderModifier/responseHeaderModifier? Añade o quita encabezados de solicitud antes de enviar una solicitud al servicio de backend. También puede añadir o eliminar encabezados de respuesta después de recibir una respuesta del servicio backend.
Duplicació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 reflejada.

La duplicación es útil para probar una nueva versión 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 backend en lugar de en la versión de producción.
División del tráfico basada en el peso weightDestination.serviceName

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 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 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 latencia alta, 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.
Políticas de seguridad corsPolicy Las políticas de uso compartido de recursos entre dominios (CORS) gestionan la configuración para aplicar solicitudes CORS.

Para obtener más información sobre las acciones y cómo funcionan, consulta la página de la API de servicios de red.

En cada regla de ruta, puede especificar una de las siguientes acciones de ruta:

  • Dirigir tráfico hacia un solo servicio (destination.serviceName)
  • Dividir el tráfico entre varios servicios (destination.weight)
  • URLs de redirección (redirect)

Además, puedes combinar cualquiera de las acciones de ruta mencionadas anteriormente con una o varias de las siguientes acciones de ruta (denominadas Acciones complementarias en la consola Google Cloud ):

  • Manipular encabezados de solicitud o respuesta (requestHeaderModifier/responseHeaderModifier)
  • Duplicar tráfico (requestMirrorPolicy)
  • Volver a escribir el host, la ruta o ambos de la URL (urlRewrite)
  • Reintentar solicitudes incorrectas (retryPolicy)
  • Definir tiempo de espera (timeout)
  • Introduce fallos en un porcentaje del tráfico (faultInjectionPolicy)
  • Añadir política de CORS (corsPolicy)

Como las acciones están asociadas a reglas específicas, el proxy de Envoy o la aplicación de gRPC sin proxy pueden aplicar diferentes acciones en función de la solicitud que estén gestionando.

Distribuir el tráfico entre los backends de un servicio

Como se explica en Gestión de solicitudes, cuando un cliente gestiona una solicitud saliente, primero selecciona un servicio de destino. Después de seleccionar un servicio de destino, debe determinar qué backend o endpoint debe recibir la solicitud.

Distribuir el tráfico entre los back-ends.
Distribución del tráfico entre back-ends (haz clic en la imagen para ampliarla)

En el diagrama anterior, se ha simplificado la regla. Una regla suele ser una regla de host, un comparador de rutas y una o varias reglas de ruta. El servicio de destino es el servicio de backend. Backend 1, … y Backend n reciben y gestionan la solicitud. Estos backends pueden ser, por ejemplo, instancias de máquina virtual de Compute Engine que alojan el código de la aplicación del lado del servidor.

De forma predeterminada, el cliente que gestiona la solicitud envía solicitudes al backend correcto más cercano que tenga capacidad. Para evitar sobrecargar un backend específico, usa el algoritmo de balanceo de carga Round Robin para balancear la carga de las solicitudes posteriores entre otros backends del servicio de destino. Sin embargo, en algunos casos, puede que quieras tener un control más preciso sobre este comportamiento.

Balanceo de carga, afinidad de sesión y protección de backends

Puede definir las siguientes políticas de distribución del tráfico en cada servicio.

Política Nombre del campo de la API Descripción
Modo de balanceo de carga balancingMode Controla cómo se selecciona un grupo de puntos finales de red (NEG) o un grupo de instancias gestionado (MIG) después de seleccionar un servicio de destino. Puede configurar el modo de balanceo para distribuir la carga en función de las conexiones simultáneas y el porcentaje de solicitudes.
Política de balanceo de carga localityLbPolicy Define el algoritmo de balanceo de carga que se usa para distribuir el tráfico entre los backends de un NEG o un MIG. Para optimizar el rendimiento, puede elegir entre varios algoritmos (como el de asignación cíclica o el de menor número de solicitudes).
Afinidad de sesión sessionAffinity

Proporciona un intento de enviar solicitudes de un cliente concreto al mismo backend mientras el backend esté en buen estado y tenga capacidad.

Cloud Service Mesh admite cuatro opciones de afinidad de sesión: dirección IP del cliente, basada en cookies HTTP, basada en encabezados HTTP y afinidad de cookies generadas (que genera Cloud Service Mesh).
Hash coherente consistentHash Proporciona afinidad de sesión flexible basada en encabezados HTTP, cookies u otras propiedades.
Interruptores circuitBreakers Define los límites superiores del volumen de conexiones y solicitudes por conexión a un servicio de backend.
Detección de valores atípicos outlierDetection Especifica los criterios para (1) quitar back-ends o endpoints no saludables de los MIGs o NEGs y (2) volver a añadir un back-end o un endpoint cuando se considere que está lo suficientemente en buen estado como para recibir tráfico de nuevo. La comprobación del estado asociada al servicio determina si un backend o un endpoint se considera en buen estado.

Para obtener más información sobre las diferentes opciones de distribución del tráfico y cómo funcionan, consulta los siguientes documentos:

Ejemplos de uso

La gestión avanzada del tráfico abarca muchos casos prácticos. En esta sección se ofrecen algunos ejemplos generales.

Puedes consultar más ejemplos, incluido código de muestra, en Configurar la gestión avanzada del tráfico con Envoy y Configurar la gestión avanzada del tráfico con servicios de gRPC sin proxy.

Rutas de tráfico pormenorizadas para la personalización

Puedes dirigir el tráfico a un servicio en función de los parámetros de la solicitud. Por ejemplo, puedes usar este servicio para ofrecer una experiencia más personalizada a los usuarios de Android. En el siguiente diagrama, Cloud Service Mesh configura tu malla de servicios para enviar solicitudes con el encabezado user-agent:Android a tu servicio de Android en lugar de a tu servicio genérico.

Enrutamiento basado en el encabezado de agente de usuario definido en Android.
Enrutamiento basado en el encabezado user-agent definido como Android (haz clic en la imagen para ampliarla)

División del tráfico basada en el peso para realizar implementaciones más seguras

Desplegar una nueva versión de un servicio de producción puede ser arriesgado. Aunque las pruebas se superen en un entorno de pruebas, es posible que no quieras dirigir a todos los usuarios a la nueva versión de inmediato.

Cloud Service Mesh te permite definir divisiones de tráfico basadas en el peso para distribuir el tráfico entre varios servicios. Por ejemplo, puedes enviar el 1% del tráfico a la nueva versión de tu servicio, comprobar que todo funciona correctamente y, a continuación, aumentar gradualmente la proporción de tráfico que se dirige al nuevo servicio.

División del tráfico basada en el peso de Cloud Service Mesh.
División del tráfico basada en el peso de Cloud Service Mesh (haz clic en la imagen para ampliarla)

Duplicación de tráfico para depuración

Cuando depuras un problema, puede ser útil enviar copias del tráfico de producción a un servicio de depuración. Cloud Service Mesh te permite configurar políticas de creación de reflejo de solicitudes para que las solicitudes se envíen a un servicio y se envíen copias de esas solicitudes a otro servicio.

Replicación del tráfico de Cloud Service Mesh.
Replicación del tráfico de Cloud Service Mesh (haz clic en la imagen para ampliarla)

Balanceo de carga optimizado para mejorar el rendimiento

En función de las características de tu aplicación, puede que consigas mejorar el rendimiento y la disponibilidad ajustando la forma en que se distribuye el tráfico entre los back-ends de un servicio. Con Cloud Service Mesh, puedes aplicar algoritmos de balanceo de carga avanzados para que el tráfico se distribuya según tus necesidades.

En el siguiente diagrama, a diferencia de los anteriores, se muestran tanto un servicio de backend de destino (Servicio de producción) como los backends de ese servicio de backend (Máquina virtual 1, Máquina virtual 2 y Máquina virtual 3). Con la gestión avanzada del tráfico, puedes configurar cómo se selecciona un servicio de backend de destino y cómo se distribuye el tráfico entre los backends de ese servicio de destino.

Balanceo de carga de Cloud Service Mesh.
Balanceo de carga de Cloud Service Mesh (haz clic en la imagen para ampliarla)

Para obtener más información sobre el balanceo de carga con Cloud Service Mesh, consulta la información general sobre el balanceo de carga avanzado.

Siguientes pasos