Présentation de Traffic Director

Traffic Director est un plan de contrôle géré pour la mise en réseau des applications. Il vous permet de proposer des services mondiaux à disponibilité élevée et dotés de capacités avancées de mise en réseau des applications, telles que la gestion et l'observabilité du trafic.

À mesure que le nombre de services et de microservices dans votre déploiement augmente, vous commencez généralement à rencontrer des problèmes courants de mise en réseau des applications, tels que les suivants :

  • Comment rendre mes services résilients ?
  • Comment générer du trafic vers mes services, et comment les services se connaissent-ils et communiquent-ils entre eux ?
  • Comment comprendre ce qui se passe lorsque mes services communiquent entre eux ?
  • Comment mettre à jour mes services sans risquer une panne ?
  • Comment gérer l'infrastructure qui permet mon déploiement ?
Les services doivent communiquer entre eux.
Les services doivent communiquer entre eux (cliquez pour agrandir)

Traffic Director vous aide à résoudre ces problèmes lors d'un déploiement moderne basé sur les services. Cerise sur le gâteau, il s'appuie sur l'infrastructure gérée par Google Cloud afin de vous offrir les meilleures fonctionnalités possibles, sans avoir à gérer votre propre infrastructure. Vous vous concentrez sur la fourniture du code d'application qui résout les problèmes de votre entreprise tout en laissant Traffic Director gérer les complexités de la mise en réseau des applications.

Traffic Director pour le maillage de services

Pour résoudre les problèmes de mise en réseau des applications, une approche classique consiste à utiliser un maillage de services. Traffic Director est compatible avec le maillage de services, ainsi qu'avec de nombreux autres modèles de déploiement qui répondent à vos besoins.

Maillage de services type.
Un maillage de services type (cliquez pour agrandir)

Dans un maillage de services type, les conditions suivantes s'appliquent :

  • Vous déployez vos services sur un cluster Kubernetes.
  • Chaque pod des services dispose d'un proxy dédié (généralement Envoy) qui s'exécute en tant que proxy side-car.
  • Chaque proxy side-car communique avec l'infrastructure de mise en réseau (plan de contrôle) installée dans votre cluster. Le plan de contrôle fournit aux proxys side-car des informations sur les services, les points de terminaison et les règles de votre maillage de services.
  • Lorsqu'un pod envoie ou reçoit une requête, celle-ci est transmise au proxy side-car du pod. Le proxy side-car traite la requête, par exemple en l'envoyant à la destination voulue.

Dans les schémas de ce document, les icônes roses à six côtés représentent les proxys. Le plan de contrôle est connecté à chaque proxy et fournit les informations dont les proxys ont besoin pour traiter les requêtes. Les flèches entre les zones indiquent les flux de trafic. Par exemple, le code d'application du Service A envoie une requête. Le proxy traite la requête et la transmet au Service B.

Ce modèle vous permet de retirer la logique de mise en réseau de votre code d'application. Vous pouvez vous concentrer sur la création de valeur ajoutée tout en laissant votre infrastructure s'occuper de la mise en réseau des applications.

Spécificités de Traffic Director

Traffic Director fonctionne de la même manière que ce modèle, mais il présente des différences importantes. Pour commencer, Traffic Director est un service géré par Google Cloud. Vous ne l'installez pas, il ne s'exécute pas dans votre cluster et vous n'avez pas besoin de le gérer.

Dans le schéma suivant, Traffic Director est le plan de contrôle. Le cluster Kubernetes comprend quatre services, chacun ayant des proxys side-car connectés à Traffic Director. Traffic Director fournit les informations dont les proxys ont besoin pour acheminer les requêtes. Par exemple, le code d'application sur un pod appartenant au Service A envoie une requête. Le proxy side-car exécuté avec ce pod traite la requête et l'achemine vers un pod appartenant au Service B.

Exemple de maillage de services avec Traffic Director.
Exemple de maillage de services avec Traffic Director (cliquez pour agrandir)

Au-delà du maillage de services

Traffic Director est compatible avec plus de types de déploiements qu'un maillage de services type.

Kubernetes multicluster

Avec Traffic Director, vous bénéficiez d'une mise en réseau des applications qui fonctionne sur plusieurs clusters Kubernetes. Dans le schéma suivant, Traffic Director fournit le plan de contrôle des clusters Kubernetes dans les régions us-central1 et europe-west1. Les requêtes peuvent être acheminées entre les trois services de la région us-central1, entre les deux services de la région europe-west1 et entre les services des deux clusters.

Exemple de Kubernetes multicluster avec Traffic Director.
Exemple de Kubernetes multicluster avec Traffic Director (cliquez pour agrandir)

Votre maillage de services peut s'étendre sur plusieurs clusters Kubernetes, situés dans plusieurs régions Google Cloud. Les services d'un cluster peuvent communiquer avec ceux d'un autre cluster. Vous pouvez même avoir des services composés de pods de plusieurs clusters.

Avec l'équilibrage de charge global basé sur la proximité de Traffic Director, les requêtes destinées au Service B sont dirigées vers le pod le plus proche pouvant répondre à la requête. Vous bénéficiez également d'un basculement fluide : si un pod tombe en panne, la requête bascule automatiquement vers un autre pod pouvant diffuser dans la requête, même si ce pod se trouve dans un autre cluster Kubernetes.

Machines virtuelles

Kubernetes est de plus en plus populaire, mais de nombreuses charges de travail sont déployées sur des instances de machines virtuelles (VM). Traffic Director résout également les problèmes de mise en réseau des applications pour ces charges de travail ; vos charges de travail basées sur des VM interagissent facilement avec vos charges de travail basées sur Kubernetes.

Dans le schéma suivant, le trafic entre dans votre déploiement via l'équilibrage de charge HTTP(S) externe. Il est acheminé vers le Service A dans le cluster Kubernetes de la région asia-southeast1 et vers le Service D sur une VM de la région europe-west1.

Exemple de VM et de Kubernetes avec Traffic Director.
Exemple de VM et de Kubernetes avec Traffic Director (cliquez pour agrandir)

Google fournit un mécanisme simple pour configurer les charges de travail basées sur des VM avec Traffic Director. Il vous suffit d'ajouter une option à votre modèle d'instance de VM Compute Engine et Google gère la configuration de l'infrastructure. Cela inclut l'installation et la configuration des proxys fournissant des capacités de mise en réseau des applications.

Services gRPC sans proxy

gRPC est un framework RPC Open Source et riche en fonctionnalités qui vous permet d'écrire des microservices hautes performances. Avec Traffic Director, vous pouvez facilement intégrer des capacités de mise en réseau des applications (telles que la détection de services, l'équilibrage de charge et la gestion du trafic) à vos applications gRPC. Pour en savoir plus, consultez la section Traffic Director et gRPC : services sans proxy pour votre maillage de services.

Dans le schéma suivant, les applications gRPC acheminent le trafic vers des services basés sur des clusters Kubernetes dans une région et vers des services s'exécutant sur des VM dans différentes régions. Deux des services incluent des proxys side-car et d'autres sont sans proxy.

Exemple d'applications gRPC sans proxy avec Traffic Director.
Exemple d'applications gRPC sans proxy avec Traffic Director (cliquez pour agrandir)

Traffic Director est compatible avec les services gRPC sans proxy. Ces services utilisent une version récente de la bibliothèque gRPC Open Source compatible avec les API xDS. Vos applications gRPC peuvent se connecter à Traffic Director à l'aide des mêmes API xDS qu'Envoy.

Une fois qu'elles sont connectées, la bibliothèque gRPC s'occupe des fonctionnalités de mise en réseau des applications telles que la détection de services, l'équilibrage de charge et la gestion du trafic. Ce processus s'effectue de manière native dans gRPC. Par conséquent, les proxys de service ne sont pas nécessaires, d'où l'appellation "applications gRPC sans proxy.

Entrée et passerelles

Dans de nombreux cas d'utilisation, vous devez gérer le trafic provenant de clients non configurés par Traffic Director. Par exemple, vous devrez peut-être acheminer le trafic Internet public vers vos microservices. Vous pourriez aussi configurer un équilibreur de charge en tant que proxy inverse qui gère le trafic d'un client avant de l'envoyer à une destination.

Dans le schéma suivant, un équilibreur de charge HTTP(S) externe permet l'entrée pour les clients externes, le trafic étant acheminé vers les services d'un cluster Kubernetes. Un équilibreur de charge HTTP(S) interne achemine le trafic interne vers le service s'exécutant sur la VM.

Traffic Director avec Cloud Load Balancing pour l'entrée.
Traffic Director avec Cloud Load Balancing pour l'entrée (cliquez pour agrandir)

Traffic Director fonctionne avec Cloud Load Balancing pour offrir une expérience d'entrée gérée. Configurez un équilibreur de charge externe ou interne, puis configurez-le pour envoyer du trafic vers vos microservices. Dans le schéma précédent, les clients Internet publics atteignent vos services via un équilibrage de charge HTTP(S) externe. Les clients, tels que les microservices résidant sur votre réseau de cloud privé virtuel (VPC), accèdent à vos services à l'aide de l'équilibrage de charge HTTP(S) interne.

Dans le schéma suivant, une VM de la région europe-west1 exécute un proxy qui sert de passerelle vers trois services n'exécutant pas de proxys. Le trafic provenant à la fois d'un équilibreur de charge HTTP(S) externe et d'un équilibreur de charge HTTP(S) interne est acheminé vers la passerelle, puis vers les trois services.

Traffic Director utilisé pour configurer une passerelle.
Traffic Director utilisé pour configurer une passerelle (cliquez pour agrandir)

Dans certains cas d'utilisation, il se peut que vous souhaitiez configurer Traffic Director pour configurer une passerelle. Cette passerelle est essentiellement un proxy inverse, généralement Envoy qui s'exécute sur une ou plusieurs VM, écoute les requêtes entrantes, les traite et les envoie à une destination. La destination peut se trouver dans n'importe quelle région Google Cloud ou n'importe quel cluster Google Kubernetes Engine (GKE). Il peut même s'agir d'une destination externe à Google Cloud, accessible depuis Google Cloud à l'aide de la connectivité hybride.

Environnements multiples

Que vos services se trouvent dans Google Cloud, sur site, dans d'autres clouds ou dans tous ces emplacements, les principaux problèmes que vous rencontrez en termes de mise en réseau des applications restent les mêmes. Comment générer du trafic vers ces services ? Comment ces services communiquent-ils entre eux ?

Dans le schéma suivant, Traffic Director achemine le trafic des services exécutés dans Google Cloud vers le Service G, qui s'exécute dans un autre cloud public, et vers le Service E et le Service F, tous deux exécutés dans un centre de données sur site. Le Service A, le Service B et le Service C, utilisent Envoy comme proxy side-car, tandis que le Service D est un service gRPC sans proxy.

Traffic Director utilisé pour la communication entre les environnements.
Traffic Director utilisé pour la communication entre les environnements (cliquez pour agrandir)

Lorsque vous utilisez Traffic Director, vous pouvez envoyer des requêtes à des destinations situées en dehors de Google Cloud. Cela vous permet d'utiliser Cloud Interconnect ou Cloud VPN pour acheminer le trafic de manière privée depuis les services dans Google Cloud vers des services ou des passerelles dans d'autres environnements.

Configurer Traffic Director

La configuration de Traffic Director s'effectue en deux étapes. Une fois le processus de configuration terminé, votre infrastructure gère la mise en réseau des applications, et Traffic Director maintient toutes les informations à jour en fonction des modifications apportées à votre déploiement.

Déployer les applications

Commencez par déployer votre code d'application sur des conteneurs ou des VM. Google fournit des mécanismes qui vous permettent d'ajouter facilement une infrastructure de mise en réseau des applications (généralement des proxys Envoy) à vos instances de VM et vos pods. Cette infrastructure est configurée pour communiquer avec Traffic Director et recueillir des informations sur vos services.

Configurer Traffic Director

Ensuite, configurez vos services globaux et définissez la manière dont le trafic doit être géré. Pour configurer Traffic Director, vous pouvez utiliser Google Cloud Console, l'outil de ligne de commande gcloud, l'API Traffic Director ou d'autres outils tels que Terraform.

Une fois ces étapes terminées, Traffic Director est prêt à configurer votre infrastructure de mise en réseau des applications.

L'infrastructure gère la mise en réseau des applications

Lorsqu'une application envoie une requête à my-service, l'infrastructure de mise en réseau des applications (par exemple, un proxy side-car Envoy) traite la requête en fonction des informations reçues de Traffic Director. Cela permet d'acheminer de manière fluide une requête pour my-service vers une instance d'application capable de la recevoir.

Surveillance et mises à jour continues

Traffic Director surveille les instances d'application qui constituent vos services. Traffic Director peut ainsi détecter qu'un service est opérationnel ou que la capacité d'un service a changé, par exemple lorsqu'un pod Kubernetes est créé. À partir de ces informations, Traffic Director met à jour en continu votre infrastructure de mise en réseau des applications.

Fonctionnalités

Les fonctionnalités de Traffic Director fournissent des capacités de mise en réseau des applications à vos microservices. Cette section aborde des points importants.

Plan de contrôle entièrement géré, vérification de l'état et équilibrage de charge

Vous souhaitez vous consacrer à la création de valeur ajoutée plutôt qu'à la gestion de l'infrastructure. Traffic Director est une solution entièrement gérée dotée d'un contrat de niveau de service avec garantie de disponibilité, ce qui vous évite d'avoir à installer, configurer ou mettre à jour l'infrastructure. Vous bénéficiez de la même infrastructure que celle utilisée par Google pour la vérification de l'état et l'équilibrage de charge global.

Basé sur des produits Open Source

Traffic Director utilise les mêmes API de plan de contrôle (xDS) que des projets Open Source populaires tels que Envoy et Istio. Pour afficher les versions d'API compatibles, consultez la page API de plan de contrôle xDS.

L'infrastructure qui fournit les capacités de mise en réseau des applications (Envoy ou gRPC, selon votre cas d'utilisation) est également Open Source. Vous n'avez donc pas à craindre de vous retrouver prisonnier d'une infrastructure propriétaire.

Effectuer le scaling

Qu'il s'agisse de solutions uniques de mise en réseau des applications ou de déploiements massifs de maillages de services comportant des milliers de services, Traffic Director est conçu pour répondre à vos exigences de scaling.

Détection de services et suivi des points de terminaison et des backends

Lorsque votre application envoie une requête à my-service, votre infrastructure gère la requête de manière transparente et l'envoie à la bonne destination. Votre application n'a besoin d'aucune information sur les adresses IP, les protocoles ou d'autres complexités de la mise en réseau.

Équilibrage de charge global et basculement

Traffic Director utilise l'équilibrage de charge global et la vérification d'état de Google pour équilibrer le trafic de manière optimale en fonction de la proximité du backend, de son état et de sa capacité. Vous améliorez la disponibilité du service en permettant au trafic de basculer automatiquement vers des backends opérationnels disposant de la capacité nécessaire.

Gestion du trafic

La gestion avancée du trafic, y compris le routage et la manipulation des requêtes (en fonction du nom d'hôte, du chemin d'accès, des en-têtes, des cookies, etc.), vous permet de déterminer la manière dont le trafic circule entre vos services. Vous pouvez également appliquer des actions telles que de nouvelles tentatives d'exécution, des redirections et une répartition du trafic en fonction d'une pondération pour les déploiements Canary. Des modèles avancés, tels que l'injection de pannes, la mise en miroir du trafic et la détection d'anomalies, permettent des cas d'utilisation du DevOps qui améliorent votre résilience.

Observabilité

Votre infrastructure de mise en réseau des applications collecte des informations de télémétrie, telles que des métriques, des journaux et des traces, qui peuvent être agrégées de manière centralisée dans la suite Google Cloud Operations. Une fois ces informations collectées, vous pouvez dégager des insights et créer des alertes afin d'être informé en cas de problème.

VPC Service Controls

VPC Service Controls permet de renforcer la sécurité des ressources et des services de votre application. Vous pouvez ajouter des projets aux périmètres de service afin de protéger les ressources et les services (comme Traffic Director) des requêtes provenant de l'extérieur du périmètre. Pour en savoir plus sur VPC Service Controls, consultez la page Présentation de VPC Service Controls.

Pour en savoir plus sur l'utilisation de Traffic Director avec VPC Service Controls, consultez la page Produits compatibles.

Étape suivante