Descripción general de Traffic Director

Traffic Director es un plano de control administrado para redes de aplicaciones. Traffic Director te permite entregar servicios globales y con alta disponibilidad con capacidades avanzadas de red de aplicaciones, como la administración del tráfico y la observabilidad.

A medida que la cantidad de servicios y microservicios en tu implementación crece, por lo general, comienzas a enfrentar los desafíos comunes de las herramientas de redes de aplicaciones, como los siguientes:

  • ¿Cómo hago que mis servicios sean resilientes?
  • ¿Cómo obtengo tráfico a mis servicios y cómo los servicios se enteran del resto o se comunican entre sí?
  • ¿Cómo puedo entender lo que sucede cuando mis servicios se comunican entre sí?
  • ¿Cómo actualizo mis servicios sin arriesgar una interrupción?
  • ¿Cómo administro la infraestructura que permite mi implementación?
Los servicios deben comunicarse entre sí.
Los servicios deben comunicarse entre sí (haz clic para ampliar)

Traffic Director te ayuda a resolver estos tipos de desafíos en una implementación moderna basada en servicios. Lo mejor de todo es que se basa en la infraestructura administrada por Google Cloud para que obtengas las mejores funciones, sin tener que administrar tu propia infraestructura. Enfócate en el código de la aplicación de envío que resuelve tus problemas empresariales y permite que Traffic Director administre las complejidades de las herramientas de redes de la aplicación.

Traffic Director para mallas de servicios

Un patrón común para resolver los desafíos de la red de aplicaciones es usar una malla de servicios. Traffic Director admite la malla de servicios y muchos otros patrones de implementación que se adaptan a tus necesidades.

Una malla de servicios típica.
Una malla de servicios típica (haz clic para ampliar)

En una malla de servicios típica, ocurre lo siguiente:

  • Implementas tus servicios en un clúster de Kubernetes.
  • Cada Pod de los servicios tiene un proxy dedicado (por lo general, Envoy) que se ejecuta como un proxy de sidecar.
  • Cada proxy de sidecar se comunica con la infraestructura de red (un plano de control) instalado en tu clúster. El plano de control informa a los proxies de sidecar sobre los servicios, los extremos y las políticas en tu malla de servicios.
  • Cuando un Pod envía o recibe una solicitud, la solicitud va al proxy de sidecar del Pod. El proxy de sidecar controla la solicitud, por ejemplo, la envía a su destino previsto.

En los diagramas de este documento, los íconos rosados de seis lados representan proxies. El plano de control está conectado a cada proxy y proporciona información que los proxies necesitan para manejar las solicitudes. Las flechas entre las casillas muestran flujos de tráfico. Por ejemplo, el código de la aplicación en Service A envía una solicitud. El proxy controla la solicitud y la reenvía a Service B.

Este modelo te permite quitar la lógica de red fuera del código de tu aplicación. Puedes enfocarte en ofrecer valor empresarial y dejar que tu infraestructura se encargue de la creación de redes de aplicaciones.

Diferencias entre Traffic Director

Traffic Director funciona de manera similar a ese modelo, pero es diferente en formas importantes. Todo comienza con el hecho de que Traffic Director es un servicio administrado por Google Cloud. No la instalas, no se ejecuta en tu clúster y no necesitas mantenerlo.

En el siguiente diagrama, Traffic Director es el plano de control. Hay cuatro servicios en este clúster de Kubernetes, cada uno con proxies de sidecar que están conectados a Traffic Director. Traffic Director proporciona la información que los proxies necesitan para enrutar las solicitudes. Por ejemplo, el código de la aplicación de un pod que pertenece a Service A envía una solicitud. El proxy de sidecar que se ejecuta junto con este pod controla la solicitud y la enruta a un pod que pertenece a Service B.

Un ejemplo de una malla de servicios con Traffic Director.
Un ejemplo de una malla de servicios con Traffic Director (haz clic para ampliar)
.

Más allá de la malla de servicios

Traffic Director admite más tipos de implementaciones que una malla de servicios típica.

Kubernetes de varios clústeres

Con Traffic Director, obtienes redes de aplicaciones que funcionan en los clústeres de Kubernetes. En el siguiente diagrama, Traffic Director proporciona el plano de control para los clústeres de Kubernetes en us-central1 y europe-west1. Las solicitudes se pueden enrutar entre los tres servicios en us-central1, entre los dos servicios en europe-west1, y entre los servicios de los dos clústeres.

Un ejemplo de Kubernetes de varios clústeres con Traffic Director.
Un ejemplo de Kubernetes de varios clústeres con Traffic Director (haz clic para ampliar)

La malla de servicios se puede extender a múltiples clústeres de Kubernetes en varias regiones de Google Cloud. Los servicios en un clúster pueden comunicarse con los servicios en otro clúster. Incluso puedes tener servicios que tienen pods en varios clústeres.

Con el balanceo de cargas global basado en la proximidad de Traffic Director, las solicitudes enviadas para Service B van al Pod más cercano que puede entregar la solicitud. También obtienes conmutación por error sin interrupciones. Si un pod deja de funcionar, la solicitud se realiza de forma automática en otro pod que puede entregar la solicitud, incluso si este pod está en un clúster de Kubernetes diferente.

Máquinas virtuales

Kubernetes se está volviendo más popular, pero muchas cargas de trabajo se implementan en instancias de máquina virtual (VM). Traffic Director también resuelve las redes de aplicaciones en estas cargas de trabajo; tus cargas de trabajo basadas en VM interoperan fácilmente con tus cargas de trabajo basadas en Kubernetes.

En el siguiente diagrama, el tráfico ingresa a tu implementación a través del balanceo de cargas HTTP(S) externo. Se enruta a Service A en el clúster de Kubernetes en asia-southeast1 y a Service D en una VM en europe-west1.

Un ejemplo de VM y Kubernetes con Traffic Director
Un ejemplo de VM y Kubernetes con Traffic Director (haz clic para ampliar)

Google proporciona un mecanismo sin interrupciones para configurar cargas de trabajo basadas en VM con Traffic Director. Solo agregas una marca a tu plantilla de instancias de VM de Compute Engine y Google se encarga de la configuración de la infraestructura. Esta configuración incluye la instalación y configuración de los proxies que entregan capacidades de red de aplicaciones.

gRPC sin proxy

gRPC es un framework de RPC de código abierto con muchas funciones que puedes usar para escribir microservicios de alto rendimiento. Con Traffic Director, puedes llevar con facilidad las funciones de red de aplicaciones (como el descubrimiento de servicios, el balanceo de cargas y la administración del tráfico) a tus aplicaciones de gRPC. Si deseas obtener más información, consulta Traffic Director y gRPC sin servicio para tu malla de servicios.

En el siguiente diagrama, las aplicaciones de gRPC enrutan el tráfico a los servicios en función de los clústeres de Kubernetes en una región y a los servicios que se ejecutan en las VM en otras regiones. Dos de los servicios incluyen proxies de sidecar, y los otros no tienen proxy.

Un ejemplo de aplicaciones de gRPC sin proxy con Traffic Director
Un ejemplo de aplicaciones de gRPC sin proxy con Traffic Director (haz clic para ampliar)
.

Traffic Director admite servicios de gRPC sin proxy. Estos servicios usan una versión reciente de la biblioteca de gRPC de código abierto que admite las API de xDS. Tus aplicaciones de gRPC pueden conectarse a Traffic Director mediante las mismas API de xDS que Envoy usa.

Después de conectar tus aplicaciones, la biblioteca de gRPC se encarga de la funcionalidad de las herramientas de redes de la aplicación, como el descubrimiento de servicios, el balanceo de cargas y la administración del tráfico. Esta funcionalidad ocurre de forma nativa en gRPC, por lo que no se requieren proxies de servicio; este es el motivo por el que se denominan aplicaciones gRPC sin proxy.

Entrada y puertas de enlace

Para muchos casos de uso, necesitas manejar el tráfico que se origina en clientes que no están configurados por Traffic Director. Por ejemplo, es posible que debas ingresar tráfico de Internet público a tus microservicios. También puedes configurar un balanceador de cargas como un proxy inverso que controla el tráfico de un cliente antes de enviarlo a un destino.

En el siguiente diagrama, un balanceador de cargas HTTP(S) externo permite la entrada de clientes externos, con el tráfico enrutado a los servicios en un clúster de Kubernetes. Un balanceador de cargas HTTP(S) interno enruta el tráfico interno al servicio que se ejecuta en la VM.

Traffic Director con Cloud Load Balancing para recursos de entrada
Traffic Director con Cloud Load Balancing para la entrada (haz clic para ampliar)

Traffic Director trabaja con Cloud Load Balancing para proporcionar una experiencia de entrada administrada. Configura un balanceador de cargas interno o externo y, luego, configura ese balanceador de cargas para enviar tráfico a tus microservicios. En el diagrama anterior, los clientes de la Internet pública llegan a tus servicios a través del balanceo de cargas de HTTP(S) externo. Los clientes, como microservicios que residen en tu red de nube privada virtual (VPC), usan el balanceo de cargas HTTP(S) interno para alcanzar tus servicios.

En el siguiente diagrama, una VM en la región europe-west1 ejecuta un proxy que actúa como puerta de enlace a tres servicios que no ejecutan proxies. El tráfico de un balanceador de cargas HTTP(S) externo y de un balanceador de cargas HTTP(S) interno se enruta a la puerta de enlace y, luego, a los tres servicios.

Traffic Director se usa para configurar una puerta de enlace.
Traffic Director usado para configurar una puerta de enlace (haz clic para ampliar)

En algunos casos de uso, puedes configurar Traffic Director para configurar una puerta de enlace. Esta puerta de enlace es, en esencia, un proxy inverso, por lo general, Envoy que se ejecuta en una o más VM, que escucha las solicitudes entrantes, las administra y las envía a un destino. El destino puede estar en cualquier región de Google Cloud o clúster de Google Kubernetes Engine (GKE). Incluso puede ser un destino fuera de Google Cloud al que se pueda acceder desde Google Cloud mediante la conectividad híbrida.

Varios entornos

Si tienes servicios en Google Cloud, de manera local, en otras nubes o en todos los anteriores, los desafíos fundamentales de las herramientas de redes de la aplicación son los mismos. ¿Cómo obtienes tráfico a estos servicios? ¿Cómo los servicios se comunican entre sí?

En el siguiente diagrama, Traffic Director enruta el tráfico desde los servicios que se ejecutan en Google Cloud hasta Service G, que se ejecuta en otra nube pública y a Service E y Service F, que se ejecutan en un centro de datos local. Service A, Service B y Service C, usan Envoy como un proxy de sidecar, mientras que Service D es un servicio de gRPC sin proxy.

Traffic Director se usa para la comunicación entre entornos.
Traffic Director usado para la comunicación entre entornos (haz clic para ampliar)

Cuando usas Traffic Director, puedes enviar solicitudes a destinos fuera de Google Cloud. Esto te permite usar Cloud Interconnect o Cloud VPN para enrutar el tráfico de forma privada desde servicios dentro de Google Cloud hasta servicios o puertas de enlace en otros entornos.

Configura Traffic Director

La configuración de Traffic Director consta de dos pasos. Después de completar el proceso de configuración, la infraestructura controla las redes de la aplicación y Traffic Director mantiene todo actualizado en función de los cambios en tu implementación.

Implementa tus aplicaciones

Primero, implementa el código de la aplicación en contenedores o VM. Google proporciona mecanismos que te permiten agregar fácilmente infraestructuras de herramientas de redes de aplicaciones (por lo general, proxies de Envoy) a tus instancias de VM y pods. Esta infraestructura se configura para que hable con Traffic Director y aprenda sobre tus servicios.

Configura Traffic Director

A continuación, configura tus servicios globales y define cómo debe manejarse el tráfico. Para configurar Traffic Director, puedes usar Google Cloud Console, la herramienta de línea de comandos de gcloud, la API de Traffic Director y otras herramientas, como Terraform.

Después de completar estos pasos, Traffic Director está listo para configurar la infraestructura de red de tu aplicación.

Infraestructura maneja las redes de aplicaciones

Cuando una aplicación envía una solicitud a my-service, la infraestructura de red de tu aplicación (por ejemplo, un proxy de sidecar de Envoy) controla la solicitud según la información recibida de Traffic Director. Esto habilita una solicitud con el objetivo de que my-service se enrute sin interrupciones a una instancia de aplicación que puede recibir la solicitud.

Supervisión y actualizaciones continuas

Traffic Director supervisa las instancias de la aplicación que constituyen tus servicios. Esta supervisión permite que Traffic Director detecte que un servicio está en buen estado o que cambió la capacidad del servicio, por ejemplo, cuando se crea un pod de Kubernetes nuevo. En función de esta información, Traffic Director actualiza continuamente la infraestructura de red de tu aplicación.

Características

Las características de Traffic Director ofrecen capacidades de red de aplicaciones a tus microservicios. En esta sección, se analizan algunos aspectos destacados.

Plano de control completamente administrado, verificación de estado y balanceo de cargas

Deseas invertir tu tiempo en la entrega de valor empresarial, no en administrar la infraestructura. Traffic Director es una solución completamente administrada con un ANS de tiempo de actividad, por lo que no tienes que instalar, configurar ni actualizar la infraestructura. Aprovechas la misma infraestructura que usa Google para la verificación de estado y el balanceo de cargas global.

Compila en productos de código abierto

Traffic Director usa las mismas API de plano de control (xDS) que usan proyectos populares de código abierto, como Envoy e Istio. Para ver las versiones de API compatibles, consulta las API del plano de control de xDS.

La infraestructura que entrega las capacidades de herramientas de redes de la aplicación, ya sea Envoy o gRPC, según el caso de uso, también es de código abierto, por lo que no tienes que preocuparte por el bloqueo a la infraestructura de propiedad.

Escala

Desde soluciones de herramientas de redes de aplicaciones únicas hasta implementaciones de malla de servicios masivas con miles de servicios, Traffic Director está diseñado para satisfacer tus requisitos de escalamiento.

Descubrimiento de servicios y seguimiento de tus extremos y backends

Cuando tu aplicación envía una solicitud a my-service, tu infraestructura controla sin problemas la solicitud y la envía al destino correcto. Tu aplicación no necesita saber nada sobre las direcciones IP, los protocolos ni otras complejidades de la red.

Balanceo de cargas y conmutación por error global

Traffic Director usa el balanceo de cargas global de Google y la verificación de estado para equilibrar el tráfico de forma óptima según la proximidad, el estado y la capacidad del backend. Cuando conmutas por error el tráfico de forma automática a backends en buen estado con capacidad, podrás mejorar la disponibilidad del servicio.

Administración del tráfico

La administración avanzada del tráfico, que incluye el enrutamiento y la manipulación de solicitudes (según el nombre de host, la ruta, los encabezados, las cookies y más), te permite determinar cómo fluye el tráfico entre tus servicios. También puedes aplicar acciones como reintentos, redireccionamientos y división de tráfico basada en el peso para implementaciones canary. Los patrones avanzados, como la inyección de errores, la duplicación de tráfico y la detección de valores atípicos, permiten casos de uso de DevOps que mejoran tu resiliencia.

Observabilidad

La infraestructura de red de tu aplicación recopila información de telemetría, como métricas, registros y seguimientos, que se pueden agregar de forma centralizada en el Google Cloud's operations suite. Después de recopilar esta información, puedes obtener estadísticas y crear alertas para que, si hay algún problema, se te notifique.

¿Qué sigue?