Descripción general de la gestión avanzada del tráfico para las APIs de balanceo de carga

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. Este documento solo se aplica a las APIs de balanceo de carga, no a las APIs de enrutamiento de servicios. Si tu implementación de Cloud Service Mesh usa las APIs de enrutamiento de servicios, consulta la descripción general de la gestión avanzada del tráfico.

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

• Enrutamiento pormenorizado del tráfico 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
• Distribución de tráfico optimizada 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.

• Cuando usas el proxy HTTP de destino para configurar los proxies de Envoy de forma que envíen solicitudes HTTP, todas las funciones de este documento están disponibles.

• Cuando usas servicios o aplicaciones gRPC sin proxy con Cloud Service Mesh, algunas de las funciones no están disponibles.

• Cuando usas el proxy TCP de destino para configurar los proxies de Envoy de forma que envíen solicitudes TCP, ninguna de las funciones está disponible porque no hay ninguna asignación de URLs en las configuraciones con un proxy TCP de destino.

Para obtener más información, consulta la página Funciones.

Para configurar la gestión avanzada del tráfico, se usan los mismos recursos de mapa de reglas de enrutamiento y de servicios de backend que se utilizan 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 el mapa de reglas de enrutamiento para que haga 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.

2. 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.

Configuración de filtros

Una de las responsabilidades principales de Cloud Service Mesh es generar información de configuración a partir de la regla de reenvío, el proxy de destino y el mapa de URLs, y, a continuación, enviar esa información a los clientes de Cloud Service Mesh, como los proxies de Envoy y las aplicaciones gRPC. Cloud Service Mesh controla tu malla de servicios enviando información de configuración a sus clientes para indicarles cómo deben comportarse y cómo deben enrutar el tráfico. Cloud Service Mesh es el plano de control.

Cuando creas o actualizas información de configuración en Cloud Service Mesh, este servicio traduce la configuración a un lenguaje que sus clientes puedan entender. De forma predeterminada, Cloud Service Mesh comparte esta configuración con todos sus clientes. En algunos casos, puede que quieras adaptar qué clientes de Cloud Service Mesh reciben información de configuración específica. En otras palabras, filtrar la configuración para clientes específicos.

Aunque se trata de una función avanzada, los siguientes ejemplos muestran cuándo puede ser útil la configuración de filtros:

• Tu organización usa el modelo de red de VPC compartida y varios equipos utilizan Cloud Service Mesh en diferentes proyectos de servicio. Si quieres aislar tu configuración de otros proyectos de servicio, puedes filtrar la configuración para que determinados clientes de Cloud Service Mesh reciban solo un subconjunto de la configuración.
• Tienes un número muy elevado de reglas de ruta y servicios configurados en Cloud Service Mesh y quieres evitar enviar una cantidad inusualmente grande de configuración a cada cliente de Cloud Service Mesh. Ten en cuenta que un cliente que necesite evaluar una solicitud saliente mediante una configuración grande y compleja puede tener un rendimiento inferior al de un cliente que solo necesite evaluar una solicitud mediante una configuración optimizada.

El filtrado de configuración se basa en el concepto de filtros de metadatos:

1. Cuando se conecta un cliente de Cloud Service Mesh, presenta información de su archivo de arranque a Cloud Service Mesh.
2. Esta información contiene el contenido de los campos de metadatos, en forma de pares clave-valor, que especifica en el archivo de arranque al implementar sus proxies de Envoy y aplicaciones gRPC.
3. Puede añadir filtros de metadatos en la regla de reenvío. Se filtra toda la configuración vinculada a la regla de reenvío.
4. Puede añadir filtros de metadatos en el mapa de URLs. El filtro de metadatos se aplica por ruta.
5. Cloud Service Mesh solo comparte la configuración con los clientes que presentan metadatos que coinciden con las condiciones del filtro de metadatos.

Para obtener información sobre cómo configurar filtros de metadatos para Envoy, consulta Configurar el filtrado de configuraciones en función de la coincidencia de MetadataFilter.

Rutas y acciones de tráfico

En Cloud Service Mesh, el mapa de reglas de enrutamiento hace referencia a la combinación de los recursos de regla de reenvío, proxy de destino y mapa de URLs. Todas las funciones avanzadas de gestión del tráfico relacionadas con el enrutamiento y las acciones se configuran mediante el mapa de URLs.

En las siguientes secciones se describen las funciones de gestión avanzada del tráfico que puedes configurar en tu mapa de reglas de enrutamiento.

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 mapa de reglas de enrutamiento específico de la siguiente manera:

   • Si usas Envoy, sigue estos pasos:

     • La dirección IP y el puerto de destino de la solicitud se comparan con la dirección IP y el puerto de las reglas de reenvío de todos los mapas de reglas de enrutamiento. Solo se tienen en cuenta los mapas de reglas de enrutamiento con reglas de reenvío que tengan el esquema de balanceo de carga INTERNAL_SELF_MANAGED.
     • La regla de reenvío que coincide con la solicitud hace referencia a un proxy HTTP o gRPC de destino, que a su vez hace referencia a un mapa de URLs. Este mapa de URLs contiene información que se usa para las rutas y las acciones.

   • Si utilizas gRPC sin proxy:

     • Un cliente de gRPC que usa el esquema de resolución de nombres xds no realiza una búsqueda de DNS para resolver el nombre de host en el URI del canal. En su lugar, este cliente resuelve el hostname[:port] en el URI de destino enviando una solicitud LDS a Cloud Service Mesh.
     • Solo se compara el puerto de una regla de reenvío con el esquema de balanceo de carga INTERNAL_SELF_MANAGED con el puerto del URI de destino (por ejemplo, xds:///example.hostname:8080). No se usa la dirección IP de la regla de reenvío. El valor predeterminado del puerto es 80 si no se especifica ningún puerto en el URI de destino.
     • La regla de reenvío que coincide con la solicitud hace referencia a un proxy gRPC de destino, que a su vez hace referencia a un mapa de URLs. Este mapa de URLs contiene información que se usa para las rutas y las acciones.
     • Si más de una regla de reenvío coincide con la solicitud, se usará el mapa de URLs que contenga la regla de host que coincida con hostname[:port] en el URI de destino para el enrutamiento y las acciones.

2. Cuando se determina el mapa de URLs adecuado, se evalúa para determinar el servicio backend de destino y, opcionalmente, aplicar acciones.

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 al que se debe dirigir una 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:

• Una regla de reenvío global
• Un proxy HTTP de destino, un proxy HTTPS de destino o un proxy gRPC de destino
• Un mapa de URLs

La mayor parte de la configuración se realiza en el mapa de URLs. Después de crear el mapa de reglas de enrutamiento inicial, solo tienes que modificar la parte del mapa de URLs del mapa de reglas de enrutamiento. En el siguiente diagrama, las reglas de ruta tienen acciones similares a las del diagrama siguiente.

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 una regla de host:

  1. A continuación, se evalúa el matcher de ruta.
  2. Cada matcher de ruta contiene una o varias reglas 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 la regla de ruta.
  4. Si la regla de host coincide, pero ninguna regla de ruta coincide, las solicitudes se dirigen a un servicio predeterminado que contiene cada comparador de rutas.

• Si la solicitud no coincide con ninguna de las reglas de host que ha especificado, se dirige al servicio especificado en la regla predeterminada.

Para obtener más información sobre los campos de recursos del mapa de URLs y cómo funcionan, consulta la página de la urlMaps API REST.

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 configuras en el mapa de URLs. Si el host de una solicitud coincide con una regla de host, se evalúa el comparador de rutas de la regla de host.
2. El comparador de rutas contiene una o varias reglas de ruta que se evalúan en función de la solicitud. Estas reglas de ruta se evalúan por orden de prioridad. Para ello, se comparan los atributos de la solicitud (host, ruta, encabezado y parámetros de consulta) con condiciones de coincidencia específicas, como la coincidencia de prefijo.
3. Una vez que hayas seleccionado una regla de ruta, podrás aplicar acciones. La acción predeterminada es enrutar la solicitud a un único servicio de destino, pero también puedes configurar otras acciones.

Enrutamiento avanzado

El enrutamiento avanzado es similar al enrutamiento simple que hemos descrito anteriormente, pero con la diferencia de que puedes especificar la prioridad de las reglas y otras condiciones de coincidencia.

Con el enrutamiento avanzado, debes especificar una prioridad única para cada regla. Esta prioridad determina el orden en el que se evalúan las reglas de ruta. Los valores de prioridad más bajos tienen prioridad sobre los valores de prioridad más altos. Cuando una solicitud coincide con una regla, esta se aplica y el resto se ignora.

El enrutamiento avanzado también admite 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 urlMaps.

Al combinar el host, la ruta, el encabezado y los parámetros de consulta con prioridades y 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	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 encabezados	headerAction	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	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 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 urlMapsAPI REST.

En cada regla de ruta, puede especificar una de las siguientes acciones de ruta (denominadas Acciones principales en la consola de Google Cloud ):

• Dirigir tráfico hacia un solo servicio (service)
• Dividir el tráfico entre varios servicios (weightedBackendServices)
• 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 (denominadas Acciones complementarias en la consola Google Cloud ):

• Manipular encabezados de solicitud/respuesta (headerAction)
• 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 de ruta 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.

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 la página de la backendServicesAPI REST.

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 las guías Configurar la gestión avanzada del tráfico y Configurar servicios de gRPC sin proxy con gestión avanzada del tráfico.

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.

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.

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.

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.

Siguientes pasos

• Para obtener más información sobre los mapas de URLs, consulte la descripción general de los mapas de URLs y el artículo Usar mapas de URLs.
• Para dirigir el tráfico desde fuera de tu malla hacia tu malla, consulta Tráfico de entrada para tu malla.
• Para configurar funciones con implementaciones de proxy de sidecar, consulta Configurar la gestión avanzada del tráfico con Envoy.
• Para configurar funciones con despliegues de gRPC sin proxy, consulta Configurar la gestión avanzada del tráfico con servicios de gRPC sin proxy.