Descubrimiento de servicios de Traffic Director

Traffic Director proporciona descubrimiento de servicios y extremos. Estas características te permiten agrupar las instancias de máquina virtual (VM) y las instancias de contenedor que ejecutan el código como extremos de los servicios.

Traffic Director supervisa estos servicios para que pueda compartir información actualizada con sus clientes. Por lo tanto, cuando una de las aplicaciones usa su cliente de Traffic Director (como un proxy de sidecar de Envoy) para enviar una solicitud, se beneficia de la información actualizada sobre los 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.

Descubrimiento de servicios

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 sidecar de Envoy que se conecta a Traffic Director y maneja las solicitudes salientes en nombre de la aplicación.
  • Configuraste un servicio de backend llamado payments. Este servicio de backend tiene dos backends de grupo de extremos de red (NEG) que apuntan a varias instancias de contenedores 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 de gRPC que actúa como un cliente de Traffic Director solo obtiene información sobre los servicios para los que especificas un agente de resolución de xDS. De forma predeterminada, Envoy obtiene información sobre todos los servicios configurados en la red de nube privada virtual (VPC) 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. Estos backends son VM en grupos de instancias administrados (MIG) o contenedores en 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 que los clientes obtengan información sobre los extremos nuevos y aprovechen la capacidad adicional que estos ofrecen.

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.

Interceptació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, iptables intercepta el tráfico y lo redirecciona al proxy del archivo adicional en el host en el que 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 una dirección IP virtual (VIP) 10.0.0.1:80 donde Traffic Director puede descubrirlo y balancearlo. 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.
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.

¿Qué sigue?