Présentation de Traffic Director
Ce document est destiné aux administrateurs réseau et aux propriétaires de services qui souhaitent se familiariser avec Traffic Director et ses fonctionnalités.
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 ?
Traffic Director vous aide à résoudre ces problèmes lors d'un déploiement moderne basé sur les services. Traffic Director repose sur une infrastructure gérée par Google Cloud. Vous n'avez donc pas besoin de 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.
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 et d'autres documents Traffic Director, 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.
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.
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'équilibreur de charge d'application 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.
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.
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 d'application externe active l'entrée pour les clients externes, le trafic étant acheminé vers les services d'un cluster Kubernetes. Un équilibreur de charge d'application interne achemine le trafic interne vers le service exécuté sur la VM.
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 de l'Internet public atteignent vos services via l'équilibreur de charge d'application externe. Les clients, tels que les microservices résidant sur votre réseau cloud privé virtuel (VPC), utilisent un équilibreur de charge d'application interne pour accéder à vos services.
Dans certains cas d'utilisation, il se peut que vous souhaitiez configurer Traffic Director pour configurer une passerelle. Une 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. Pour savoir quand utiliser une passerelle, consultez la section Trafic d'entrée pour votre réseau maillé.
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 d'application externe et d'un équilibreur de charge d'application interne est acheminé vers la passerelle, puis vers les trois services.
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.
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 la console Google Cloud (pour certaines fonctionnalités et configurations), Google Cloud CLI, 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. Vous n'avez donc pas besoin d'installer, de configurer ni de 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 des fonctionnalités de mise en réseau d'applications (Envoy ou gRPC, selon votre cas d'utilisation) est également Open Source. Vous n'avez donc pas à craindre d'être dépendant d'une infrastructure propriétaire.
Échelle
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 mondial et les vérifications d'état de Google pour équilibrer de façon optimale le trafic en fonction de l'emplacement du client et du backend, de la proximité, de l'état et de la capacité du backend. Pour améliorer la disponibilité de vos services, faites basculer automatiquement le trafic vers des backends opérationnels avec une capacité suffisante. Vous pouvez personnaliser l'équilibrage de charge pour répartir le trafic afin de répondre aux besoins de votre entreprise.
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 d'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 Google Cloud Observability. 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.
Étapes suivantes
Pour déployer Traffic Director:
- Pour Compute Engine avec des VM, utilisez les API de routage de service.
- Pour Google Kubernetes Engine avec des pods, utilisez les API Gateway.
Pour découvrir les cas d'utilisation et les modèles d'architecture applicables aux services gRPC sans proxy, consultez la page Présentation des services gRPC sans proxy.
Pour en savoir plus sur la manière de gérer le trafic, consultez la page Présentation de la gestion avancée du trafic.
Pour savoir comment Traffic Director assure la compatibilité avec des environnements qui vont au-delà de Google Cloud, consultez les documents suivants :
- Intégration de Traffic Director à l'Annuaire des services
- Traffic Director avec groupes de points de terminaison du réseau de connectivité hybride (anciennes API uniquement)
- Traffic Director avec des groupes de points de terminaison du réseau Internet (anciennes API uniquement)