Détection de services Traffic Director

Traffic Director permet la détection de services et de points de terminaison. Ainsi, vous pouvez regrouper les VM et les conteneurs qui exécutent votre code en tant que points de terminaison de vos services. Traffic Director surveille ces services afin qu'il puisse partager des informations à jour avec ses clients. Ainsi, lorsqu'une application envoie une requête à l'aide de son client Traffic Director, par exemple un proxy side-car Envoy, elle tire parti d'informations à jour sur vos services.

Dans le contexte de Traffic Director, un client est un code d'application exécuté sur une VM ou un conteneur et qui formule les requêtes à envoyer à un serveur. Un serveur est un code d'application qui reçoit de telles requêtes. Un client Traffic Director est un client Envoy ou gRPC, ou tout autre client xDS qui est connecté à Traffic Director et fait partie du plan de données.

Dans le plan de données, Envoy ou gRPC effectue les opérations suivantes :

  1. Il examine une requête et la fait correspondre à un service de backend, une ressource que vous configurez lors du déploiement.
  2. Une fois la requête mise en correspondance, Envoy ou gRPC choisit un backend ou un point de terminaison, puis dirige la requête vers ce backend ou ce point de terminaison.

Service Discovery

Traffic Director permet la détection de services. Lorsque vous configurez Traffic Director, vous créez des services (services de backend). Vous définissez également des règles de routage spécifiant la manière dont une requête sortante (requête envoyée par votre code d'application et gérée par un client Traffic Director) est associée à un service particulier. Ainsi, lorsqu'un client Traffic Director gère une requête correspondant à une règle, il peut choisir le service qui doit recevoir la requête.

Exemple :

  • Une VM exécute votre application. Cette VM dispose d'un proxy side-car Envoy connecté à Traffic Director et gère les requêtes sortantes pour le compte de l'application.
  • Vous avez configuré un service de backend nommé payments. Ce service de backend comporte deux backends NEG qui pointent vers diverses instances de conteneur exécutant le code de votre service payments.
  • Vous avez configuré une carte de règles de routage qui dispose d'une règle de transfert (par exemple, adresse IP 0.0.0.0 et port 80), d'un proxy cible et d'un mappage d'URL (avec le nom d'hôte payments.example.com indiquant le service payments.

Avec cette configuration, lorsque votre application (sur la VM) envoie une requête HTTP à payments.example.com sur le port 80, le client Traffic Director sait qu'il s'agit d'une requête destinée au service payments.

Lorsque vous utilisez Traffic Director avec des services gRPC sans proxy, la détection de services fonctionne de la même manière. Cependant, une bibliothèque gRPC, agissant en tant que client Traffic Director, obtient uniquement des informations sur les services pour lesquels vous spécifiez un résolveur xDS. Par défaut, Envoy récupère les informations sur tous les services configurés sur le réseau cloud privé virtuel spécifié dans le fichier d'amorçage Envoy.

Détection de points de terminaison

La détection de services permet aux clients de connaître vos services. La détection des points de terminaison permet aux clients de connaître les instances qui exécutent votre code.

Lorsque vous créez un service, vous spécifiez également les backends de ce service. Ces VM sont des VM appartenant à des groupes d'instances gérés ou des MIG, ou en général, des conteneurs dans des groupes de points de terminaison du réseau (NEG). Traffic Director surveille ces MIG et ces NEG afin qu'il sache quand des instances et des points de terminaison sont créés et supprimés.

Traffic Director partage en permanence des informations à jour sur ces services avec ses clients. Cela permet aux clients d'éviter d'envoyer du trafic vers des points de terminaison qui n'existent plus. Il permet également aux clients d'en savoir plus sur les nouveaux points de terminaison et de tirer parti de la capacité supplémentaire fournie par ces points de terminaison.

Dans l'exemple ci-dessus, Traffic Director renvoie deux points de terminaison opérationnels dans le groupe MIG-1 et trois points de terminaison opérationnels dans le groupe MIG-2 pour le service shopping-cart. Hormis ajouter des points de terminaison dans les groupes d'instances géré ou les NEG et configurer Traffic Director, vous n'avez pas d'autre configuration à effectuer pour activer la détection de services avec Traffic Director.

Fonctionnement de l'interception du trafic de proxy side-car dans Traffic Director

Traffic Director est compatible avec le modèle de proxy side-car. Sous ce modèle, lorsqu'une application envoie du trafic vers sa destination, le trafic est intercepté par iptables et redirigé vers le proxy side-car sur l'hôte où l'application s'exécute. Le proxy side-car décide comment équilibrer la charge du trafic, puis l'envoie à sa destination.

Dans le schéma suivant, en partant du principe que Traffic Director est correctement configuré, Envoy est le proxy side-car. Le proxy side-car s'exécute sur le même hôte que l'application.

Un exemple de service, appelé Web, est configuré sur l'adresse IP virtuelle 10.0.0.1:80, où il peut être détecté et équilibré par Traffic Director. Traffic Director détecte la configuration via la configuration de la règle de transfert, qui fournit l'adresse IP virtuelle et le port. Les backends du service Web sont configurés et fonctionnent, mais, dans le schéma, ils sont situés en dehors de l'hôte de VM Compute Engine.

Traffic Director détermine que le backend optimal pour le trafic vers le service Web depuis l'hôte est l'adresse 192.168.0.1:80.

Mise en réseau de l'hôte Traffic Director (cliquez pour agrandir)
Mise en réseau de l'hôte Traffic Director (cliquez pour agrandir)

Le flux de trafic dans le schéma est le suivant :

  1. L'application envoie du trafic au service Web, qui pointe vers l'adresse IP 10.0.0.1:80.
  2. Le filtre réseau de l'hôte est configuré de sorte que le trafic destiné à 10.0.0.1:80 soit redirigé vers 10.0.0.1:15001.
  3. Le trafic est redirigé vers 127.0.0.1:15001, le port d'interception du proxy Envoy.
  4. L'écouteur d'interception du proxy Envoy sur 127.0.0.1:15001 reçoit le trafic et recherche la destination d'origine de la requête (10.0.0.1:80). La recherche aboutit à la sélection de 192.168.0.1:8080 en tant que backend optimal, comme programmé par Traffic Director.
  5. Envoy établit une connexion sur le réseau avec 192.168.0.1:8080 et transmet le trafic HTTP entre l'application et ce backend jusqu'à ce que la connexion soit interrompue.