Descripción general de Traffic Director

Traffic Director para mallas de servicios abiertas

Las mallas de servicios son cada vez más populares para la implementación de microservicios y otras aplicaciones modernas. En una malla de servicios, el plano de datos usa proxies de servicio, como Envoy, para controlar el flujo de tráfico, mientras que el plano de control de la malla de servicios proporciona políticas, inteligencia y configuración a los proxies de sidecar.

Malla de servicios como plano de control (haz clic para ampliar)
Malla de servicios como plano de control (haz clic para ampliar)

La malla de servicios reduce la cantidad de código de herramientas de redes que debes escribir y mantener para ejecutar tus servicios. En su lugar, el proxy de sidecar realiza funciones de herramientas de redes junto con tu lógica empresarial. Se requiere un plano de control de servicios para administrar los proxies de sidecar.

Traffic Director es el plano de control de tráfico completamente administrado de Google Cloud para las mallas de servicios. Traffic Director te permite implementar con facilidad el balanceo de cargas global en los clústeres y las instancias de VM en varias regiones y descargar la verificación de estado de los proxies de sidecar. Traffic Director usa API de código abierto (xDS v2) para comunicarse con los proxies de sidecar en el plano de datos, lo que garantiza que puedas usar el plano de datos de la malla de servicios que elijas.

Traffic Director como el plano de control en un entorno de microservicios (haz clic para ampliar)
Traffic Director como el plano de control en un entorno de microservicios (haz clic para ampliar)

Funciones de Traffic Director

Traffic Director ofrece las siguientes funciones:

  • Un plano de control de administración de tráfico administrado por Google Cloud (Google Cloud) para proxies de sidecar de estándar abierto (xDS v2), como Envoy
  • Capacidad para implementar instancias de servicio de VM administradas por Traffic Director que se ejecutan en grupos de instancias administrados o no administrados y en instancias de contenedores que usan grupos de extremos de red
  • Administración del tráfico
  • Descubrimiento de servicios para extremos
  • Balanceo de cargas global, ya que puedes implementar servicios en varias regiones mediante una sola dirección IP de servicio
  • Ajuste de escala automático impulsado por la demanda
  • Enrutamiento de solicitudes y políticas de tráfico
  • Verificación de estado a gran escala
  • Observabilidad

Istio y Traffic Director

Istio proporciona un plano de control para proteger, conectar y supervisar microservicios. Tiene tres componentes: Pilot para la administración del tráfico, Istio Security para la seguridad de servicio a servicio y Mixer para la observabilidad.

Traffic Director ofrece un Pilot administrado por Google Cloud junto con capacidades adicionales, como el balanceo de cargas global y la verificación de estado centralizada. Sin embargo, ten en cuenta que Traffic Director no se puede configurar mediante las API de Istio. Puedes usar las API de GCP para la configuración. Traffic Director y Pilot usan API de estándar abierto (xDS v2) para comunicarse con proxies de sidecar.

Balanceo de cargas global con Traffic Director

Traffic Director ofrece balanceo de cargas global para tus microservicios internos con proxies de sidecar. Puedes implementar microservicios internos (basados en proxies de sidecar) con instancias en varias regiones. Traffic Director proporciona información de estado, enrutamiento y backend a los proxies de sidecar, lo que les permite realizar un enrutamiento de tráfico óptimo a varias instancias de aplicaciones en varias regiones en la nube para un servicio.

En la siguiente ilustración, el tráfico del usuario ingresa a una implementación de Google Cloud a través de un balanceador de cargas global externo. El balanceador de cargas externo distribuye el tráfico al microservicio de frontend en us-central1 o asia-southeast1, según la ubicación del usuario final.

La implementación interna cuenta con tres microservicios globales: frontend, carrito de compras y pagos. Cada servicio se ejecuta en grupos de instancias administrados en dos regiones, us-central1 y asia-southeast1. Traffic Director usa un algoritmo de balanceo de cargas global que dirige el tráfico del usuario en California a los microservicios implementados en us-central1, mientras que las solicitudes del usuario en Singapur se dirigen a los microservicios en asia-southeast1.

Una solicitud de usuario entrante se enruta al microservicio de frontend. Luego, el proxy de servicio instalado en el host con el frontend dirige el tráfico al carrito de compras. El proxy de sidecar instalado en el host con el carrito de compras dirige el tráfico al microservicio de pagos.

Traffic Director en una implementación de balanceo de cargas global (haz clic para ampliar)
Traffic Director en una implementación de balanceo de cargas global (haz clic para ampliar)

En el siguiente ejemplo, si Traffic Director recibe resultados de una verificación de estado que indican que las VM que ejecutan el microservicio del carrito de compras en us-central1 no están en buen estado, Traffic Director le indica al proxy de sidecar que los microservicios de frontend deben realizar una conmutación por error del tráfico al microservicio de carrito de compras que se ejecuta en asia-southeast1. Debido a que el ajuste de escala automático está integrado con la administración de tráfico en Google Cloud, Traffic Director notifica al grupo de instancias administrado en asia-southeast1 sobre el tráfico adicional y el grupo de instancias administrado aumenta de tamaño.

Traffic Director detecta que todos los backends del microservicio de pagos están en buen estado, por lo que Traffic Director le indica al proxy de Envoy que el carrito de compras debe enviar una parte del tráfico, que incluya hasta la capacidad configurada por el cliente, a asia-southeast1 y desbordar el resto del tráfico a us-central1.

Conmutación por error con Traffic Director en una implementación de balanceo de cargas global (haz clic para ampliar)
Conmutación por error con Traffic Director en una implementación de balanceo de cargas global (haz clic para ampliar)

Componentes del balanceo de cargas en Traffic Director

Durante la configuración de Traffic Director, configuras varios componentes del balanceo de cargas:

  • Una regla de reenvío global, que incluye la dirección VIP, el proxy de destino y el mapa de URL. Todas son parte del mecanismo de enrutamiento de tráfico de Traffic Director. El proxy de destino debe ser un proxy HTTP de destino
  • El servicio de backend, que contiene valores de configuración
  • Una verificación de estado, que proporciona verificaciones de estado para las VM y los pods en tu implementación

En el siguiente diagrama, se muestra una aplicación que se ejecuta en VM de Compute Engine o pods de Google Kubernetes Engine, los componentes y el flujo de tráfico en una implementación de Traffic Director:

Recursos de Traffic Director que se configurarán (haz clic para ampliar)
Recursos de Traffic Director que se configurarán (haz clic para ampliar)

En el diagrama, se muestra Traffic Director y los recursos de balanceo de cargas de Google Cloud que se usan para determinar el enrutamiento de tráfico. Un proxy de sidecar compatible con la API de xDS (como Envoy, como se muestra) se ejecuta en una instancia de VM de cliente o en un pod de Kubernetes. Traffic Director sirve como plano de control y se comunica directamente con cada proxy mediante las API de xDS. En el plano de datos, la aplicación envía tráfico a la dirección VIP configurada en la regla de reenvío de Google Cloud. El proxy de sidecar intercepta el tráfico y lo redirecciona al backend correspondiente. La siguiente sección contiene más información sobre la intercepción del tráfico y el balanceo de cargas.

Descubrimiento de servicios

Traffic Director proporciona descubrimiento de servicios en extremos de contenedores y VM. Puedes agregar tus extremos de servicio a un grupo de instancias administrado (MIG) para VM o a un grupo de extremos de red (NEG) para contenedores. Estos extremos de servicio están asociados con un nombre de servicio. Traffic Director proporciona descubrimiento de servicios para servicios. Para ello, asigna el nombre de host del cliente a un nombre de servicio de destino y proporciona extremos de balanceo de cargas y de verificación de estado para el nombre del servicio.

Descubrimiento de servicios de Traffic Director (haz clic para ampliar)
Descubrimiento de servicios de Traffic Director (haz clic para ampliar)

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 mediante un proxy de sidecar 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 VIP 10.0.0.1, puerto TCP:80 y Traffic Director puede detectarlo 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, TCP:8080.

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, TCP:80.
  2. El netfilter en el host está configurado para que el tráfico destinado a 10.0.0.1 TCP:80 se redireccione a la dirección IP 127.0.0.1 TCP: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.

Límites

Todas las reglas de reenvío, el servicio de backend y otros límites y cuotas de balanceo de cargas existentes por proyecto se aplican a las implementaciones de Traffic Director.

Limitaciones

  • Traffic Director solo es compatible con las API de Google Cloud. Traffic Director no es compatible con las API de Istio.
  • Traffic Director solo es compatible con el tráfico HTTP (HTTP/1.1 o HTTP/2) y gRPC.
  • Traffic Director es compatible con la VPC compartida. Ten en cuenta lo siguiente:
    • Una regla de reenvío y su mapa de URL, servicios de backend, backends y proxy de destino asociados deben estar en un solo proyecto, que puede ser un proyecto host o de servicio. Si tienes varios proyectos de servicio, cada proyecto de servicio puede tener su propio conjunto de estos recursos.
    • De forma predeterminada, una regla de reenvío que hace referencia a una red de VPC compartida se anuncia a todos los proxies de Envoy en los proyectos host y de servicio adjuntos al proyecto host, siempre que estos proxies especifiquen la red de VPC compartida en sus archivos bootstrap/sidecar.env. Puedes adaptar este comportamiento mediante el filtrado de configuración.
    • Solo se puede acceder a Traffic Director desde las cuentas de servicio de los proyectos que tengan al menos una regla de reenvío con el esquema de balanceo de cargas INTERNAL_SELF_MANAGED asociado a la red de VPC compartida.
  • Traffic Director no es compatible con el intercambio de tráfico entre redes de VPC.
  • Traffic Director solo admite el balanceo de cargas de clientes dentro de una red de VPC cuyo nombre se especifica en la regla de reenvío.
  • Todas las VM o extremos de backend de Traffic Director deben estar en la misma red de VPC que el cliente.
  • No puedes usar Traffic Director con servicios que se ejecutan en Knative o la computación sin servidores de Google Cloud.
  • Solo puedes conectar servicios que se ejecutan en Google Cloud mediante Traffic Director.
  • En esta versión, solo puedes configurar extremos de Google Cloud con Traffic Director. No admitimos extremos en instalaciones locales o en otra nube.
  • En esta versión, solo puedes configurar VM o extremos de backend de Google Cloud en un NEG con Traffic Director. No admitimos VM ni extremos en instalaciones locales o en otra nube.
  • En este documento, se analizan los proxies de Envoy, pero puedes usar cualquier proxy de API de estándar abierto (xDS v2) con Traffic Director. Sin embargo, ten en cuenta que Google probó Traffic Director solo con el proxy de Envoy.
  • Se debe contar con la versión 1.9.1 de Envoy o una posterior para que funcione con Traffic Director.
  • Recomendamos usar la versión de Envoy más reciente para garantizar que se mitiguen todas las vulnerabilidades de seguridad conocidas.
  • Para obtener información sobre la asesoría de seguridad de Envoy, consulta Asesoría de seguridad de Envoy.

Próximos pasos