Présentation des cartes des règles de routage

Ce document ne s'applique qu'à Cloud Service Mesh avec les API d'équilibrage de charge. Nous vous recommandons vivement d'utiliser les API de routage de services.

Une carte des règles de routage comprend les éléments suivants :

Lorsque vous créez et configurez ces ressources pour Cloud Service Mesh, celui-ci utilise ces valeurs pour créer la configuration qu'il envoie à votre plan de données, y compris les clients xDS tels que les proxys Envoy et les applications gRPC sans proxy. Le plan de données gère ensuite le trafic en fonction de cette configuration.

Une règle de transfert renvoie à un proxy cible et possède une adresse IP ainsi qu'un port. Pour les déploiements de Cloud Service Mesh, le schéma d'équilibrage de charge de la règle de transfert doit être défini sur INTERNAL_SELF_MANAGED. Le proxy cible, à son tour, renvoie à un mappage d'URL. Ces trois ressources sont combinées pour former une carte des règles de routage.

L'adresse IP d'une règle de transfert renvoyant à un proxy gRPC cible dont le champ validateForProxyless est défini sur TRUE doit être 0.0.0.0. Lorsque validateForProxyless est défini sur TRUE, les configurations qui spécifient une adresse IP autre que 0.0.0.0 sont refusées.

La carte des règles de routage définit la manière dont le trafic passe des clients aux serveurs au sein d'un maillage de services.

Types de proxys cibles compatibles

Cloud Service Mesh est compatible avec les types de proxys cibles suivants:

  • Un proxy HTTP cible, que vous configurez lorsque vos clients et vos serveurs envoient ou reçoivent du trafic HTTP ou HTTP/2.
  • Le proxy HTTPS cible, que vous configurez lorsque vos clients et vos serveurs envoient ou reçoivent du trafic HTTPS. Cela est nécessaire lorsque vous configurez la sécurité du service avec des proxys Envoy.
  • Le proxy TCP cible, que vous configurez lorsque vos clients et vos serveurs envoient ou reçoivent du trafic TCP.
  • Un proxy gRPC cible, que vous configurez lorsque vos clients et vos serveurs envoient ou reçoivent du trafic gRPC. Les proxys gRPC cibles comportent le champ validateForProxyless défini sur TRUE lorsque vous déployez des services gRPC sans proxy.

Router le trafic avec des proxys side-car Envoy

Lorsque vous utilisez Cloud Service Mesh avec des proxys side-car Envoy, les requêtes client sont acheminées comme suit:

  • La pile réseau intercepte la requête et la redirige vers votre proxy side-car Envoy.
  • Le proxy side-car Envoy examine l'adresse IP et le port de la requête.
  • L'adresse IP et la paire de ports sont comparées à l'adresse IP et au port spécifiés dans toutes les règles de transfert dont le schéma d'équilibrage de charge est défini sur INTERNAL_SELF_MANAGED.
  • Si une règle de transfert dont une adresse IP et un port correspondent est trouvée, Envoy examine le proxy HTTP ou gRPC cible auquel renvoie la règle de transfert.
  • Envoy vérifie le mappage d'URL auquel renvoie le proxy cible.
  • Envoy achemine la requête selon les règles spécifiées dans le mappage d'URL.

Pour en savoir plus sur la manière dont le trafic est acheminé avec un proxy TCP cible, consultez la page Router le trafic TCP avec Cloud Service Mesh.

Router le trafic avec des applications gRPC sans proxy

Ce comportement est différent pour les applications gRPC sans proxy. Lorsque vous configurez un client gRPC, vous spécifiez l'URI cible du service qu'il doit contacter. Cet URI utilise le schéma de résolution des noms xds et le format hostname:port, par exemple xds:///example.hostname:8080.

Lorsque le client gRPC sans proxy se connecte à Cloud Service Mesh, celui-ci lui envoie les informations correspondant au service comme suit:

  • Cloud Service Mesh recherche des règles de transfert dont le schéma d'équilibrage de charge est défini sur INTERNAL_SELF_MANAGED pour rechercher les règles de transfert dont le port correspond au port spécifié dans l'URI cible.
  • Cloud Service Mesh trouve le proxy gRPC cible ou le proxy HTTP cible pour chacune de ces règles de transfert.
  • Cloud Service Mesh recherche les mappages d'URL référencés par ces proxys gRPC cibles ou proxys HTTP cibles.
  • Cloud Service Mesh vérifie les règles d'hôte du mappage d'URL, qui sont également au format hostname[:port], puis recherche une correspondance.
  • Lorsqu'il existe une correspondance, Cloud Service Mesh renvoie les règles de routage et les informations de service au client gRPC.

Si plusieurs correspondances existent, le comportement n'est pas défini et peut entraîner un comportement imprévisible. Cela se produit généralement lorsque les deux conditions suivantes sont remplies :

  • Le même nom d'hôte est utilisé dans plusieurs mappages d'URL.
  • Plusieurs règles de transfert avec le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED spécifient le même port.

Pour cette raison, nous vous recommandons de ne pas réutiliser le même nom d'hôte dans plusieurs mappages d'URL référencés par des règles de transfert spécifiant un même port.

Étape suivante