Descubrimiento de servicios de Traffic Director

Traffic Director proporciona descubrimiento de servicios y extremos. Esto te permite agrupar las VM y los contenedores que ejecutan tu código como extremos de tus servicios. Traffic Director supervisa estos servicios para que pueda compartir información actualizada con sus clientes. Por lo tanto, cuando una de tus aplicaciones envía una solicitud con su cliente de Traffic Director, como un proxy de sidecar de Envoy, se beneficia de la información actualizada sobre tus servicios.

En el contexto de Traffic Director, un cliente es un código de la aplicación que se ejecuta en una VM o contenedor y que crea fórmulas que se envían a un servidor. Un servidor es el código de la aplicación que recibe esas solicitudes. Un cliente de Traffic Director es un cliente de Envoy o gRPC o de otro cliente de xDS que se conecta a Traffic Director y es parte del plano de datos.

En el plano de datos, Envoy o gRPC realiza lo siguiente:

  1. Examina una solicitud y hace coincidir la solicitud con un servicio de backend, un recurso que configuras durante la implementación.
  2. Una vez que la solicitud coincide, Envoy o gRPC elige un backend o extremo y dirige la solicitud a ese backend o extremo.

Service Discovery

Traffic Director proporciona descubrimiento de servicios. Cuando configuras Traffic Director, creas servicios (servicios de backend). También defines las reglas de enrutamiento que especifican cómo se hace coincidir una solicitud saliente (una solicitud enviada por el código de tu aplicación y manejada por un cliente de Traffic Director) a un servicio en particular. Por lo tanto, cuando un cliente de Traffic Director maneja una solicitud que coincide con una regla, puede elegir el servicio que debe recibir la solicitud.

Por ejemplo:

  • Tienes una VM que ejecuta tu aplicación. Esta VM tiene un proxy de archivo adicional de Envoy que está conectado a Traffic Director y controla las solicitudes salientes por la aplicación.
  • Configuraste un servicio de backend llamado payments. Este servicio de backend tiene dos backends NEG que apuntan a varias instancias de contenedor que ejecutan el código para tu servicio payments.
  • Configuraste un mapa de reglas de enrutamiento que tiene una regla de reenvío (con la IP 0.0.0.0 y el puerto 80 de ejemplo), un proxy de destino y un mapa de URL (con el nombre de host payments.example.com de ejemplo que apunta al servicio payments).

Con esta configuración, cuando tu aplicación (en la VM) envía una solicitud HTTP a payments.example.com en el puerto 80, el cliente de Traffic Director sabe que esta es una solicitud dirigida al servicio payments.

Cuando se usa Traffic Director con servicios de gRPC sin proxy, el descubrimiento de servicios funciona de manera similar. Sin embargo, una biblioteca gRPC, que actúa como cliente de Traffic Director, solo obtiene información sobre los servicios para los que especificas un agente de resolución xDS. Envoy, de forma predeterminada, obtiene información sobre todos los servicios configurados en la red de nube privada virtual especificada en el archivo de arranque de Envoy.

Descubrimiento de extremos

Service Discovery permite que los clientes conozcan tus servicios. La detección de extremos permite que los clientes conozcan las instancias que ejecutan tu código.

Cuando creas un servicio, también especificas sus backends. Estas son VM en grupos de instancias administrados (MIG) o, por lo general, contenedores en grupos de extremos de red (NEG). Traffic Director supervisa estos MIG y NEG para que sepa cuándo se crean y quitan las instancias y los extremos.

Traffic Director comparte de forma continua información actualizada sobre estos servicios con sus clientes. Esto permite que los clientes eviten enviar tráfico a extremos que ya no existen. También permite a los clientes obtener información sobre extremos nuevos y comenzar a aprovechar la capacidad adicional que proporcionan estos extremos.

En el ejemplo anterior, Traffic Director muestra los dos extremos en buen estado en MIG-1 y tres extremos en buen estado en MIG-2 para el servicio shopping-cart. Además de agregar extremos a MIG o NEG y configurar Traffic Director, no necesitas ninguna configuración adicional para habilitar el descubrimiento de servicios con Traffic Director.

Cómo funciona la intercepción de tráfico del proxy de sidecar en Traffic Director

Traffic Director usa el modelo de proxy de sidecar. En este modelo, cuando una aplicación envía tráfico a su destino, el tráfico se intercepta por iptables y se redirecciona al proxy de sidecar en el host donde se ejecuta la aplicación. El proxy de sidecar decide cómo balancear las cargas del tráfico y, luego, envía el tráfico a su destino.

En el siguiente diagrama, en el que se supone que Traffic Director está configurado de forma correcta, Envoy es el proxy de sidecar. El proxy de sidecar se ejecuta en el mismo host que la aplicación.

Un servicio de muestra, llamado Web, se configura en VIP 10.0.0.1:80, donde se puede detectar y Traffic Director puede balancear sus cargas. Traffic Director descubre la configuración a través de la configuración de la regla de reenvío, que proporciona el VIP y el puerto. Los backends para el servicio Web están configurados y funcionan, pero se encuentran fuera del host de VM de Compute Engine en el diagrama.

Traffic Director decide que el backend óptimo para el tráfico al servicio Web desde el host es 192.168.0.1:80.

Herramientas de redes de host de Traffic Director (haz clic para ampliar)
Herramientas de redes de host de Traffic Director (haz clic para ampliar)

El flujo de tráfico en el diagrama es el siguiente:

  1. La aplicación envía tráfico al servicio Web, que se resuelve en la dirección IP 10.0.0.1:80.
  2. El netfilter en el host está configurado para que el tráfico destinado a 10.0.0.1:80 se redireccione a 10.0.0.1:15001.
  3. El tráfico se redirecciona a 127.0.0.1:15001, el puerto de intercepción del proxy de Envoy.
  4. El objeto de escucha de intercepción del proxy de Envoy en 127.0.0.1:15001 recibe el tráfico y realiza una búsqueda del destino original de la solicitud (10.0.0.1:80). La búsqueda hace que 192.168.0.1:8080 se seleccione como un backend óptimo, según lo que programó Traffic Director.
  5. Envoy establece una conexión a través de la red con 192.168.0.1:8080 y actúa como proxy para el tráfico HTTP entre la aplicación y este backend hasta que finalice la conexión.