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 crece la cantidad de servicios y microservicios en tu implementación, sueles enfrentarte a 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 capacidades, sin tener que administrar tu propia infraestructura. Enfócate en enviar código de aplicación que resuelva tus problemas empresariales, a la vez que 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 las herramientas de redes de aplicaciones es usar una malla de servicios. Traffic Director admite la malla de servicios y muchos otros patrones de implementación que se ajustan a tus necesidades.

Una malla de servicios común.
Una malla de servicios común (haz clic para ampliar)

En una malla de servicios común, se cumple 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 rosa 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 los cuadros muestran los 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 herramientas de redes del código de tu aplicación. Puedes enfocarte en ofrecer valor empresarial mientras tu infraestructura se encarga de las herramientas de redes de la aplicación.

Diferencias entre Traffic Director

Traffic Director funciona de manera similar a ese modelo, pero es diferente en cuestiones importantes. Todo comienza con el hecho de que Traffic Director es un servicio administrado por Google Cloud. No se instala, 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 en 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
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 común.

Kubernetes de varios clústeres

Con Traffic Director, obtienes redes de aplicaciones que funcionan en 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 de 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.
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 una conmutación por error sin problemas. Si un Pod está inactivo, la solicitud se conmuta por error de forma automática a 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 la implementación a través del balanceo de cargas de 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 la plantilla de instancias de VM de Compute Engine, y Google se encarga de la configuración de la infraestructura. Esta configuración incluye instalar y configurar los proxies que entregan capacidades de herramientas de redes de aplicaciones.

gRPC sin proxy

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

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

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 compatible con las API de xDS. Tus aplicaciones de gRPC pueden conectarse a Traffic Director mediante las mismas API de xDS que usa Envoy.

Después de que tus aplicaciones se conectan, la biblioteca de gRPC se encarga de las funciones de herramientas de redes de aplicaciones, 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 los proxies de servicio no son necesarios, por lo que se llaman aplicaciones de gRPC sin proxy.

Entrada y puertas de enlace

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

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

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

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

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

Traffic Director que 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 que se usa para la comunicación en todos los 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, tu infraestructura controla las redes de la aplicación y Traffic Director mantiene todo actualizado según los cambios en la 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 con facilidad la infraestructura de herramientas de redes de aplicaciones (por lo general, proxies de Envoy) a tus instancias y Pods de VM. Esta infraestructura está configurada para comunicarse con Traffic Director y obtener información sobre tus servicios.

Configura Traffic Director

A continuación, configura los servicios globales y define cómo se debe manejar 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 o algunas 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 descubra que un servicio está en buen estado o que la capacidad de un servicio cambió, por ejemplo, cuando se crea un Pod de Kubernetes nuevo. En función de esta información, Traffic Director actualiza de forma continua 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 entregar 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 necesitas instalar, configurar ni actualizar la infraestructura. Aprovechas la misma infraestructura que usa Google para las verificaciones de estado y el balanceo de cargas global.

Compila en productos de código abierto

Traffic Director usa el mismo plano de control (xDS ) API que proyectos populares de código abierto comoEnvoy yIstio. Para ver las versiones de API compatibles, consulta las API de plano de control xDS de Traffic Director.

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 la aplicación envía una solicitud a my-service, la infraestructura maneja la solicitud sin problemas y la envía al destino correcto. La aplicación no necesita saber nada acerca de las direcciones IP, los protocolos ni otras complejidades de las herramientas de redes.

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, incluido el enrutamiento y la manipulación de solicitudes (según el nombre de host, la ruta de acceso, los encabezados, las cookies y mucho 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 según el peso para implementaciones canary. Los patrones avanzados, como la inserció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 la resiliencia.

Observabilidad

La infraestructura de herramientas de redes de tu aplicación recopila información de telemetría, como métricas, registros y seguimientos, que se pueden agregar de forma centralizada en Google Cloud's operations suite. Después de recopilar esta información, puedes obtener estadísticas y crear alertas para que, si algo sale mal, te notifiquen.

Controles del servicio de VPC

Puedes usar los Controles del servicio de VPC a fin de proporcionar seguridad adicional para los recursos y servicios de tu aplicación. Puedes agregar proyectos a perímetros de servicio que protejan recursos y servicios (como Traffic Director) de las solicitudes que se originan fuera del perímetro. Para obtener más información sobre los Controles del servicio de VPC, consulta la Descripción general de los Controles del servicio de VPC.

Para obtener más información sobre el uso de Traffic Director con Controles del servicio de VPC, consulta la página Productos compatibles.

¿Qué sigue?