Descripción general de Traffic Director
Este documento está dirigido a los administradores de red y a los propietarios de servicios que deseen familiarizarse con Traffic Director y sus capacidades.
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?
Traffic Director te ayuda a resolver estos tipos de desafíos en una implementación moderna basada en servicios. Traffic Director se basa en la infraestructura administrada por Google Cloud, por lo que no tienes 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.
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 y otros documentos de Traffic Director, los íconos rosados de seis lados representan los proxies. El plano de control se conecta a cada proxy y proporciona información que los proxies necesitan para controlar 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.
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 herramientas de 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 en us-central1, entre los dos servicios en europe-west1 y entre los servicios en los dos clústeres.
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 tu implementación a través del balanceador de cargas de aplicaciones 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.
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 maneja 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 marco de trabajo 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 capacidades de herramientas de redes de aplicaciones (como el descubrimiento de servicios, el balanceo de cargas y la administración de tráfico) a tus aplicaciones de gRPC. Si deseas obtener más información, consulta Traffic Director y gRPC: servicios sin proxy para tu 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.
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 usa Envoy.
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 los proxies de servicio no son necesarios (es por esto que se llaman aplicaciones de gRPC sin proxy).
Entrada y puertas de enlace
Para muchos casos prácticos, 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 se recomienda configurar un balanceador de cargas como un proxy inverso que controle el tráfico desde un cliente antes de enviarlo a un destino.
En el siguiente diagrama, un balanceador de cargas de aplicaciones externo habilita la entrada para clientes externos, con tráfico enrutado a servicios en un clúster de Kubernetes. Un balanceador de cargas de aplicaciones interno enruta el tráfico interno al servicio que se ejecuta en la VM.
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 los servicios a través del balanceador de cargas de aplicaciones externo. Los clientes, como los microservicios que residen en tu red de nube privada virtual (VPC), usan un balanceador de cargas de aplicaciones interno para llegar a tus servicios.
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. Para obtener más información sobre cuándo usar una puerta de enlace, consulta Tráfico de entrada para la malla.
En el siguiente diagrama, una VM en la región europe-west1 ejecuta un proxy que actúa como una puerta de enlace a tres servicios que no ejecutan proxies. El tráfico de un balanceador de cargas de aplicaciones externo y un balanceador de cargas de aplicaciones interno se enruta a la puerta de enlace y, luego, a los tres servicios.
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.
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, implementas el código de la aplicación en contenedores o VM. Google proporciona mecanismos que te permiten agregar con facilidad infraestructuras de redes de aplicaciones (por lo general, proxies de Envoy) a tus instancias de VM y Pods. 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 la consola de Google Cloud (para algunas funciones y opciones de configuración), la CLI de Google Cloud, la API de Traffic Director o alguna otra herramienta, 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.
Funciones
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 ofrece capacidades de red de aplicaciones (ya sea Envoy o gRPC, según tu caso de uso) también es de código abierto, por lo que no necesitas preocuparte por estar bloqueado en la infraestructura propia.
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 y la verificación de estado de Google para equilibrar de forma óptima el tráfico según la ubicación del cliente y del backend, la proximidad de backend, el estado y la capacidad. Para mejorar la disponibilidad del servicio, haz que el tráfico realice una conmutación por error automática a backends en buen estado con capacidad. Puedes personalizar el balanceo de cargas para distribuir el tráfico y satisfacer las necesidades de tu empresa de forma adecuada.
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 las implementaciones de versiones 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 red de tu aplicación recopila información de telemetría, como métricas, registros y seguimientos, que se pueden agregar de manera centralizada en la Observabilidad de Google Cloud. Después de recopilar esta información, puedes obtener estadísticas y crear alertas para que, si algo sale mal, se te notifique.
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 los 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?
Para implementar Traffic Director, haz lo siguiente:
- Para Compute Engine con VMs, usa las APIs de enrutamiento de servicios.
- Para Google Kubernetes Engine con Pods, usa las APIs de Gateway.
Si deseas encontrar casos prácticos y patrones de arquitectura para servicios de gRPC sin proxy, consulta la descripción general de los servicios de gRPC sin proxy.
Para obtener información sobre cómo la administración del tráfico te permite controlar la manera en que se maneja el tráfico, consulta la Descripción general de la administración avanzada del tráfico.
Para obtener información sobre cómo Traffic Director admite entornos que se extienden más allá de Google Cloud, consulta los siguientes documentos: