Proxys cibles pour Traffic Director

Ce document ne s'applique qu'à Traffic Director avec les API d'équilibrage de charge. Nous vous recommandons vivement d'utiliser les API de routage de services ou les API Google Kubernetes Engine Gateway pour déployer 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 :

  • Définir le protocole utilisé par les clients Traffic Director lorsqu'ils ouvrent une connexion aux backends ou aux points de terminaison associés à un service.

  • Utiliser 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.

Types de proxys cibles et protocoles de requête

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

Proxy cible Protocole de la requête
HTTPS Les clients initient des connexions HTTPS
HTTP Les clients initient des connexions HTTP
gRPC Les clients initient des connexions gRPC.
TCP Les clients initient des connexions TCP.

Vous n'êtes pas obligé de sélectionner 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 HTTPS cible global > Mappage d'URL > un ou plusieurs services de backend
  • 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)

Si vous utilisez Google Cloud Console pour configurer un proxy HTTP cible, le proxy cible est configuré implicitement lors de la configuration du mappage des règles de routage. La configuration du proxy TCP n'est pas encore disponible dans la console Google Cloud.

Si vous utilisez Google Cloud CLI ou les API, vous devez configurer explicitement le proxy cible.

Gestion du trafic

Les sections suivantes décrivent les différentes manières de gérer le trafic en fonction du type de proxy cible que vous utilisez.

Utiliser un proxy HTTP ou HTTPS cible

Lorsque vous configurez des services basés sur HTTP ou HTTPS, chaque instance de service dispose généralement d'un proxy Envoy déployé avec celui-ci. Traffic Director configure ce proxy Envoy. Il fait partie de votre plan de données du maillage de services et gère le trafic comme suit.

Le proxy Envoy reçoit la requête sortante. Il compare ensuite l'adresse IP et le port de destination de la requête à l'adresse IP et au port configurés dans chaque règle de transfert faisant référence à un proxy HTTP ou HTTPS cible. Si une correspondance est trouvée, le proxy Envoy évalue la requête en fonction du mappage d'URL correspondant du proxy cible.

Utiliser 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. Traffic Director configure ce proxy Envoy. Il fait partie de votre plan de données du maillage de services et gère le trafic comme suit.

Le proxy Envoy reçoit la requête sortante. Il compare ensuite l'adresse IP et le port de destination de la 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 qui pointe vers un service de backend par défaut. Le service de backend spécifie une vérification d'état et détermine le backend approprié.

Utiliser 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, Traffic Director configure la bibliothèque gRPC. La bibliothèque 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 auxquels un proxy gRPC cible fait référence. 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.

Ressources de proxy cible

Pour ajouter, supprimer, lister et obtenir des informations sur les proxys cibles, vous pouvez utiliser l'API REST ou gcloud CLI.

En outre, pour obtenir des informations sur un proxy cible, vous pouvez utiliser les commandes gcloud suivantes :

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 ressources suivantes compatibles avec Traffic Director:

gcloud CLI

Pour Google Cloud CLI, consultez les ressources suivantes :

Étapes suivantes