Descubrimiento de servicios

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 tu código como extremos de tus servicios.

Traffic Director supervisa estos servicios para poder compartir información actualizada con sus clientes. Por lo tanto, cuando una de tus 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 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 formula solicitudes que se envían a un servidor. Un servidor es un código de la aplicación que recibe esas solicitudes. Un cliente de Traffic Director es un cliente de xDS de Envoy o gRPC u otro 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 está conectado a Traffic Director y controla las solicitudes salientes en nombre de la aplicación.
• Configuraste un servicio de backend llamado payments. Este servicio de backend tiene dos backends de grupos de extremos de red (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 usas 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 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 a los clientes obtener información sobre extremos nuevos y 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.

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, iptables intercepta el tráfico y lo 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 la dirección IP virtual (VIP) 10.0.0.1:80 en la que Traffic Director puede descubrirlo y balancear las 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)

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.

Opciones de interceptación de tráfico con implementación automática de Envoy

Si usaste la implementación automática de Envoy con las VM, Traffic Director tiene opciones adicionales de interceptación de tráfico. Puedes hacer lo siguiente con estas opciones:

• Interceptar todo el tráfico
• Excluir puertos, rangos de puertos, direcciones IP o rangos CIDR específicos

Si usas los nuevos recursos Mesh y Gateway de la API de enrutamiento de servicio, todo el tráfico se intercepta de forma automática.

Si deseas obtener más información, consulta Opciones para la configuración de VM de Compute Engine con implementación automática de Envoy.

¿Qué sigue?

• Si deseas obtener información sobre cómo Traffic Director ofrece balanceo de cargas global para los microservicios internos con proxies de sidecar, consulta Balanceo de cargas de Traffic Director.
• Para obtener más información sobre Traffic Director, consulta la descripción general de Traffic Director.