Descripción general de la administración avanzada del tráfico

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

Nota: Esta guía solo es compatible con Cloud Service Mesh con las APIs de Google Cloud y no es compatible con las APIs de Istio. Para obtener más información, consulta Descripción general de Cloud Service Mesh.

Cloud Service Mesh proporciona funciones avanzadas de administración del tráfico que te brindan un control detallado sobre cómo se maneja el tráfico. Cloud Service Mesh admite los siguientes casos de uso:

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

Estas funciones de administración avanzada del tráfico te permiten cumplir tus objetivos de disponibilidad y rendimiento. Uno de los beneficios de usar para estos casos de uso es que puedes actualizar la forma sin la necesidad de modificar el código de la aplicación.

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

• El 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 de tráfico.
• El recurso Gateway, que identifica los proxies intermedios y representa el componente que escucha en una lista de pares de direcciones IP y puertos, reenvía el tráfico y aplica políticas.
• Route, que puede ser de varios tipos y que contiene la información de enrutamiento de tráfico para la malla. Route recursos identifican nombres de host y puertos que los clientes pueden usar para enrutar el tráfico al backend de Google Cloud. Los siguientes son los tipos de recursos Route:
  • HTTPRoute, que solo está disponible en mallas que usan proxies de Envoy. Cuando usa el recurso HTTPRoute para configurar los proxies de Envoy y enviar 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 las mallas mediante los proxies de sidecar de Envoy y gRPC sin proxy. Cuando usas servicios o aplicaciones de gRPC sin proxy con Cloud Service Mesh, algunas de las funciones descritas en esta no están disponibles.
• Servicio de backend, con el que se asocian Route recursos.

Configuración

Para configurar la administración avanzada del tráfico, debes usar los mismos Route y de los servicios de backend que usas cuando configuras Cloud Service Mesh. Cloud Service Mesh, a su vez, configura tus proxies de Envoy y gRPC sin proxy aplicaciones para aplicar las políticas de administración avanzada de tráfico que establezcas arriba.

En un alto nivel, puedes seguir los siguientes pasos:

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

2. Configura los recursos Route para que realicen las siguientes acciones, según las características de la solicitud saliente:

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

   2. Realiza acciones adicionales (opcional)

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

Acciones y enrutamiento del tráfico

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

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

Cómo administrar solicitudes

Cuando un cliente envía una solicitud, esta se controla como se describe en los siguientes pasos:

1. La solicitud coincide con un recurso Route específico de la siguiente manera:

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

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

3. Una vez que se selecciona el servicio de backend de destino, el tráfico se distribuye entre los backends o extremos de ese servicio, según la configuración del recurso del servicio de backend.

El segundo paso se describe en la siguiente sección, Enrutamiento simple basado en el host y la ruta de acceso. El tercer paso se analiza en Enrutamiento y acciones avanzados.

Enrutamiento simple basado en el host y la ruta de acceso

Cloud Service Mesh admite un esquema de enrutamiento simplificado y una esquema avanzado. En el esquema simple, se especifica un host y, opcionalmente, un ruta de acceso. El host y la ruta de acceso de la solicitud se evalúan para determinar el servicio de backend. al que se enruta 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 acceso de la solicitud es la parte de la URL que sigue al nombre de host, por ejemplo, la parte de la ruta de acceso de la URL http://example.com/video/ es /video.

Configura el enrutamiento simple basado en el host y la ruta de acceso en el mapa de reglas de enrutamiento, que consta de los siguientes elementos:

• Un Mesh global
• Un HTTPRoute o un GRPCRoute

La mayor parte de la configuración se realiza en HTTPRoute. Después de crear el mapa de reglas de enrutamiento inicial, solo debes modificar el recurso HTTPRoute.

La regla más simple es una regla predeterminada, en la que solo especificas una regla de host comodín (*) y un comparador de rutas de acceso con un servicio predeterminado. Después de crear la regla predeterminada, puedes agregar reglas adicionales que especifiquen diferentes hosts y rutas de acceso. Las solicitudes salientes se evalúan según 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 RouteRule. RouteRule especifica cómo hacer coincidir el tráfico y cómo enrutable cuando se hace coincidir.
  2. Cada RouteRule contiene una o más coincidencias de ruta que se evalúan en función de la ruta de acceso 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 su funcionamiento, consulta la documentación de la API de Network Service.

Enrutamiento y acciones avanzados

Puedes configurar reglas avanzadas para enrutar solicitudes y realizar acciones si deseas hacer más que enrutar una solicitud basada en el host y la regla de acceso de una solicitud.

En un nivel alto, el enrutamiento y las acciones avanzados funcionan de la siguiente manera:

1. Al igual que con el enrutamiento simple, se compara el host de la solicitud con el host las reglas que configuras en HTTPRoute o GRPCRoute. Si el host de una solicitud coincide con el nombre de host, se evalúa HTTPRoute o GRPCRoute.
2. Después de seleccionar una ruta, puedes aplicar acciones.

Enrutamiento avanzado

El enrutamiento avanzado es similar al enrutamiento simple descrito con anterioridad, excepto que puedes especificar condiciones de coincidencia adicionales. Por ejemplo, puedes especificar que una regla coincida con el encabezado de una solicitud si el nombre de ese encabezado coincide de manera exacta o parcial, por ejemplo, según el prefijo o sufijo. Puede coincidir según la evaluación del nombre del encabezado en función de una expresión regular o de acuerdo con otros criterios, como verificar la presencia de un encabezado.

Para ver las condiciones de coincidencia adicionales y los detalles de headerMatches y queryParameterMatches, consulta la página API de REST de network services.

Si combinas el host, la ruta de acceso, el encabezado, los parámetros de consulta con las condiciones de coincidencia, puedes crear reglas muy expresivas que se adapten a tus requisitos exactos de administración del tráfico. Para obtener más información, consulta la siguiente tabla:

	Aplicación basada en HTTP	Aplicación basada en gRPC
Hosts HTTP en comparación con hosts de 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 un cliente usa 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 de acceso de HTTP en comparación con rutas de acceso de gRPC	La ruta de acceso es la parte de la URL que sigue al nombre de host. Por ejemplo, la parte de la ruta de acceso de la URL http://example.com/video es /video.	La ruta de acceso se encuentra en el encabezado :path de la solicitud HTTP/2 y se parece a /SERVICE_NAME/METHOD_NAME. Por ejemplo, si llamas al método Download en el servicio de gRPC de Example, el contenido del encabezado :path se verá como /Example/Download.
Otros encabezados de gRPC (metadatos)		gRPC admite el envío de metadatos entre el cliente de gRPC y el servidor de gRPC para proporcionar información adicional sobre una llamada RPC. Estos metadatos tienen un formato de pares clave-valor que se transfieren como encabezados en la solicitud HTTP/2.

Acciones

La malla de servicios de Cloud te permite especificar las acciones que tus proxies de Envoy o que toman las aplicaciones de gRPC sin proxy cuando controlan una solicitud. Las siguientes acciones se pueden configurar mediante Cloud Service Mesh.

Nota: Todas las siguientes funciones están disponibles cuando usas Envoy con Cloud Service Mesh. Algunas de las funciones no están disponibles cuando usas aplicaciones de gRPC sin proxy con Cloud Service Mesh. Para obtener más información, consulta la página Funciones y la página Limitaciones con gRPC sin proxy.

Acción	Nombre del campo de la API	Descripción
Redireccionamientos	redirect [pathredirect?]	Muestra un código de respuesta 3xx configurable. También establece el encabezado de respuesta Location con el URI apropiado, lo que reemplaza el host y la ruta de acceso como se especifica en la acción de redireccionamiento.
Reescritura de URL	urlRewrite	Vuelve a escribir 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	requestHeaderModifier/responseHeaderModifier?	Agrega o quita encabezados de la solicitud antes de enviar una solicitud al servicio de backend. También puede agregar o quitar los 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 de 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 de tráfico basada en el peso	weiDestination.serviceNameght	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 función es útil para configurar implementaciones publicadas en etapa de pruebas o pruebas A/B. Por ejemplo, la acción de enrutamiento 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 que ejecuta 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 entregan solicitudes para simular fallas, incluida la latencia alta, la sobrecarga del servicio, las fallas del servicio y la partición de la red. Esta característica es útil para probar la resiliencia de un servicio ante fallas simuladas.
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.

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 enrutamiento, puedes especificar una de las siguientes acciones de enrutamiento:

• Enrutar el tráfico a un solo servicio (destination.serviceName)
• Dividir el tráfico entre varios servicios (destination.weight)
• Redireccionar las URL (redirect)

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 la consola de Cloud):

• Manipular los encabezados de solicitud o respuesta (requestHeaderModifier/responseHeaderModifier)
• Tráfico de duplicación (requestMirrorPolicy)
• Reescribe el host de URL, la ruta de acceso o ambos (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)

Debido a que las acciones están asociadas con reglas específicas, el proxy de Envoy o la aplicación de gRPC sin proxy puede aplicar diferentes acciones en función de la solicitud que controla.

Distribuye el tráfico entre los backends de un servicio

Como se explica en Control de solicitudes, cuando un cliente controla una solicitud saliente, primero selecciona un servicio de destino. Una vez que selecciona un servicio de destino, necesita determinar qué backend o extremo debe recibir la solicitud.

Distribución del tráfico entre backends (haz clic para ampliar)

En el diagrama anterior, se simplificó la Regla. La Regla suele ser una regla de host, un comparador de rutas de acceso y una o más reglas de enrutamiento o ruta de acceso. El servicio de destino es el servicio (de backend) En realidad, Backend 1, … y Backend n reciben y controlan la solicitud. Esos backends podrían ser por ejemplo, las instancias de máquina virtual (VM) de Compute Engine que alojan tus el código de la aplicación del servidor.

De forma predeterminada, el cliente que controla la solicitud envía solicitudes al backend en buen estado más cercano y que tenga capacidad. Para evitar la sobrecarga de un backend específico, usa el algoritmo de balanceo de cargas round robin a fin de balancear las solicitudes posteriores en otros backends del servicio de destino. Sin embargo, en algunos casos, recomendamos un control más detallado sobre este comportamiento.

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

Puedes establecer las siguientes políticas de distribución de tráfico en cada servicio.

Política	Nombre del campo de la API	Descripción
Modo de balanceo de cargas	balancingMode	Controla cómo se selecciona un grupo de extremos de red (NEG) o un grupo de instancias administrado (MIG) después de seleccionar un servicio de destino. Puedes 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 cargas	localityLbPolicy	Establece el algoritmo de balanceo de cargas que se usa para distribuir el tráfico entre backends dentro de un NEG o MIG. Para optimizar el rendimiento, puedes elegir entre varios algoritmos (como round robin o solicitud mínima).
Afinidad de sesión	sessionAffinity	Hace su mejor esfuerzo para enviar solicitudes de un cliente en particular al mismo backend, siempre que el backend esté en buen estado y tenga capacidad. Cloud Service Mesh admite cuatro opciones de afinidad de sesión: dirección IP de cliente, basada en cookies HTTP, basada en encabezados HTTP afinidad de cookie generada (que Cloud Service Mesh genera por su cuenta).
Hash coherente	consistentHash	Proporciona afinidad de sesión reducida basada en encabezados HTTP, cookies u otras propiedades.
Disyuntores	circuitBreakers	Establece los límites superiores en el 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 extremos o backends en mal estado de los MIG o NEG y (2) agregar un backend o un extremo cuando se considere que está en buen estado para volver a recibir tráfico. La verificación de estado asociada al servicio determina si un backend o extremo se considera en buen estado.

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

• Página de la API de REST de backendServices
• Descripción general de los servicios de backend.

Ejemplos de casos prácticos

La administración avanzada del tráfico abarca muchos casos de uso. En esta sección se proporcionan algunos ejemplos de alto nivel.

Puedes encontrar más ejemplos, incluido el código de muestra, en Configura la administración avanzada del tráfico con Envoy y Configura la administración avanzada del tráfico con servicios de gRPC sin proxy.

Enrutamiento detallado del tráfico para la personalización

Puedes enrutar el tráfico a un servicio según los parámetros de la solicitud. Por ejemplo, puedes usar esto para proporcionar 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 la a un servicio de Android en lugar de a tu servicio genérico.

Enrutamiento basado en el encabezado user-agent establecido en Android (haz clic para ampliar)

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

Implementar una versión nueva de un servicio de producción existente puede ser arriesgado. Incluso después de que se pasen las pruebas en un entorno de pruebas, no recomendamos enrutar todos los usuarios a la versión nueva 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 versión nueva del servicio, supervisar que todo funcione y, luego, aumentar de forma gradual la proporción del tráfico que se dirige al servicio nuevo.

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

Duplicación del tráfico para la 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 solicitudes políticas de duplicación para que las solicitudes se envíen a un servicio y copias de estas que las solicitudes se envían a otro servicio.

Duplicación del tráfico de la malla de servicios de Cloud (haz clic para ampliar)

Balanceo de cargas más preciso para el rendimiento

Según las características de la aplicación, es posible que puedas mejorar el rendimiento y la disponibilidad si ajustas con precisión la forma en que se distribuye el tráfico entre los backends de un servicio. Con Cloud Service Mesh, puedes aplicar de balanceo de cargas avanzados, de modo que el tráfico se distribuya según tus necesidades.

En el siguiente diagrama, a diferencia de los diagramas anteriores, se muestra un servicio de backend de destino (Production Service) y los backends para ese servicio de backend (Virtual Machine 1, Virtual Machine 2, Virtual Machine 3). Con la administració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 para ese servicio de destino.

Balanceo de cargas de la malla de servicios de Cloud (haz clic para ampliar)

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

¿Qué sigue?

• Si deseas dirigir el tráfico desde el exterior de la malla hacia esta, consulta Tráfico de entrada para la malla.