Proxys cibles pour Traffic Director

Lorsque vous configurez Traffic Director, l'une des ressources que vous configurez est le proxy cible.

Dans le contexte de Traffic Director, les proxys cibles ont deux objectifs principaux :

  1. Ils sont associés à un type spécifique. Ce type permet aux clients Traffic Director de savoir quel protocole utiliser pour ouvrir une connexion aux backends/points de terminaison associés à un service.

  2. Ils sont associés à d'autres ressources (par exemple, des règles de transfert et des mappages d'URL) pour créer une carte des règles de routage. La carte des règles de routage offre des fonctionnalités supplémentaires (telles que des règles de routage), en fonction du type de proxy cible. Les sélections non valides sont généralement masquées dans l'interface utilisateur ou rejetées par l'API.

Les types de proxys cibles correspondent à différents protocoles de requête

Traffic Director génère une configuration différente pour ses clients en fonction du type de proxy cible que vous configurez. Lorsque vous configurez un type de proxy cible différent, le client utilise un protocole de requête spécifique.

  • Proxys HTTP cibles : les clients de Traffic Director initient des connexions HTTP.
  • Proxys gRPC cibles : les clients de Traffic Director initient des connexions gRPC.
  • Proxys TCP cibles : les clients de Traffic Director initient des connexions TCP.

Notez que vous n'êtes pas obligé de vous limiter à un seul type. Par exemple, votre application peut vouloir utiliser HTTP pour s'adresser à certains services, mais TCP pour s'adresser à d'autres services. Dans ce cas, vous devez créer à la fois un proxy HTTP cible et un proxy TCP cible.

Combinaisons de ressources valides dans une carte des règles de routage

Pour éviter les erreurs de configuration, Traffic Director ne vous permet de créer que des cartes des règles de routage semblables à l'exemple suivant :

  • Règle de transfert -> Proxy HTTP cible global -> Mappage d'URL -> (un ou plusieurs services de backend)
  • Règle de transfert -> Proxy gRPC cible global -> Mappage d'URL -> (un ou plusieurs services de backend)
  • Règle de transfert -> Proxy TCP cible global -> (un service de backend)

Notez que les vérifications d'état et les groupes de backend ne figurent pas dans la liste ci-dessus.

Si vous utilisez Google Cloud Console pour configurer un proxy HTTP cible, le proxy cible est configuré implicitement lors de la configuration de votre carte des règles de routage. Notez qu'il n'est pas encore possible de configurer un proxy TCP avec la console.

Si vous utilisez l'interface de ligne de commande gcloud ou les API, vous devez configurer explicitement le proxy cible.

Gérer le trafic en cas d'utilisation d'un proxy HTTP cible

Lorsque vous configurez des services basés sur HTTP, un proxy Envoy est généralement déployé avec chaque instance de service. Ce proxy Envoy est configuré par Traffic Director, fait partie du plan de données de votre maillage de services et gère le trafic comme suit.

Le proxy Envoy reçoit la requête sortante, puis compare l'adresse IP et le port de destination de cette requête à l'adresse IP et au port configurés dans chaque règle de transfert faisant référence à un proxy HTTP cible. En cas de correspondance, le proxy Envoy évalue la requête en fonction du mappage d'URL correspondant du proxy HTTP cible.

Gérer le trafic en cas d'utilisation d'un proxy TCP cible

Lorsque vous configurez des services basés sur TCP, un proxy Envoy est généralement déployé avec chaque instance de service. Ce proxy Envoy est configuré par Traffic Director, fait partie du plan de données de votre maillage de services et gère le trafic comme suit.

Le proxy Envoy reçoit la requête sortante, puis compare l'adresse IP et le port de destination de cette requête à l'adresse IP et au port configurés dans chaque règle de transfert faisant référence à un proxy TCP cible. Chaque règle de transfert achemine le trafic TCP vers un proxy cible, lequel pointe vers un service de backend par défaut, qui spécifie une vérification d'état et détermine le backend approprié.

Gérer le trafic en cas d'utilisation d'un proxy gRPC cible

Lorsque vous configurez des services basés sur gRPC, aucun proxy Envoy n'est généralement déployé avec vos instances de service. À la place, la bibliothèque gRPC est configurée par Traffic Director, fait partie du plan de données de votre maillage de services et gère le trafic comme suit.

La bibliothèque gRPC compare le hostname[:port] spécifié dans l'URI aux règles d'hôte dans tous les mappages d'URL référencés par un proxy gRPC cible. En cas de correspondance, la bibliothèque gRPC évalue la requête en fonction des règles de chemin d'accès associées à la règle d'hôte correspondante.

Configurer l'interception du trafic pour les proxys intermédiaires et passerelles

Dans un maillage de services, vous disposez généralement des éléments suivants :

  • Les instances de service disposent chacune d'un proxy side-car Envoy dédié ou d'une bibliothèque gRPC.
    • Si vous utilisez Envoy, les instances de service sont configurées pour intercepter et rediriger les requêtes sortantes vers le proxy Envoy.
  • Le proxy Envoy ou la bibliothèque gRPC gère les requêtes sortantes.

Toutefois, vous pouvez également utiliser Traffic Director pour configurer un proxy intermédiaire ou passerelle. Dans cette configuration, le proxy Envoy est séparé de vos instances de service. Il écoute les requêtes entrantes sur un port et traite les requêtes lorsqu'il les reçoit.

Pour ce type de configuration, il n'est pas nécessaire de configurer l'interception ou la redirection. Il vous suffit d'activer l'option --proxy-bind sur le proxy HTTP cible. Cela configure l'interception du trafic entrant et oblige le proxy Envoy à écouter les requêtes entrantes sur l'adresse IP et le port (configurés dans la règle de transfert).

Rappelez-vous que la règle de transfert fait référence à un proxy cible. Ainsi, si vous activez --proxy-bind sur un proxy HTTP cible, ce proxy écoute l'adresse IP et le port de la règle de transfert qui fait référence à ce proxy HTTP cible.

Veuillez noter les points suivants :

  • Si vous utilisez Traffic Director pour un maillage de services, vous n'avez pas besoin d'utiliser --proxy-bind, car en général les proxys side-car reçoivent le trafic sortant et le transfèrent.
  • L'option --proxy-bind n'est pas disponible pour les proxys gRPC cibles.

Ressources de proxy cible

Pour ajouter, supprimer, répertorier et obtenir des informations sur les proxys cibles, vous pouvez utiliser l'API REST ou le SDK gcloud.

Vous pouvez toutefois utiliser les commandes gcloud suivantes pour obtenir ces informations :

gcloud compute [target-http-proxies | target-tcp-proxies | target-grpc-proxies ] list
gcloud compute [target-http-proxies | target-tcp-proxies | target-grpc-proxies ] describe target-proxy-name

API

Pour obtenir une description des propriétés et des méthodes disponibles lorsque vous travaillez avec des proxys cibles via l'API REST, consultez les pages suivantes :

SDK gcloud

Pour l'outil de ligne de commande gcloud, consultez les pages suivantes :

Étape suivante

Pour en savoir plus, consultez les pages suivantes :