Présentation de la gestion avancée du trafic

Ce document est destiné aux administrateurs de maillage ou de plate-forme, et aux développeurs de services qui connaissent bien les concepts de Cloud Service Mesh et de maillage de services, et qui déterminent et configurent la gestion du trafic dans un déploiement Cloud Service Mesh.

Remarque :Ce guide n'est compatible qu'avec Cloud Service Mesh avec les API Google Cloud et non avec les API Istio. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cloud Service Mesh fournit des fonctionnalités avancées de gestion du trafic qui vous permettent de contrôler précisément la manière dont le trafic est géré. Cloud Service Mesh est compatible avec les cas d'utilisation suivants:

• Routage précis du trafic des requêtes vers un ou plusieurs services.
• Répartition du trafic en fonction d'une pondération pour distribuer le trafic sur plusieurs services.
• Règles de mise en miroir du trafic qui envoient des requêtes à un service de débogage et des copies à un autre La mise en miroir du trafic n'est pas compatible avec la ressource TCPRoute ou TLSRoute.
• Répartition précise du trafic entre les backends d'un service pour un meilleur équilibrage de charge

Ces fonctionnalités avancées de gestion du trafic vous permettent d'atteindre vos objectifs de disponibilité et de performances. L'un des avantages de Cloud Service Mesh dans ces cas d'utilisation est que vous pouvez modifier la manière dont le trafic est géré sans avoir à modifier le code de votre application.

La gestion du trafic dans un maillage de services Cloud Service Mesh repose sur les ressources suivantes:

• Ressource Mesh, qui identifie le maillage de services et représente le composant chargé de transférer le trafic et d'appliquer les règles. La ressource Mesh identifie également le port d'interception du trafic.
• Ressource Gateway, qui identifie les proxys intermédiaires et représente le composant qui écoute sur une liste de paires d'adresses IP et de ports, transfère le trafic et applique des règles.
• Ressource Route, qui peut être de plusieurs types et qui contient des informations de routage du trafic pour le réseau maillé. Les ressources Route identifient les noms d'hôte et les ports que les clients peuvent utiliser pour acheminer le trafic vers les services de backend. Voici les types de ressources Route :
  • HTTPRoute, qui n'est disponible que dans les maillages utilisant des proxys Envoy. Lorsque vous utilisez la ressource HTTPRoute pour configurer les proxys Envoy pour envoyer des requêtes HTTP, toutes les fonctionnalités décrites dans ce document sont disponibles.
  • TCPRoute, qui n'est disponible que dans les maillages utilisant des proxys Envoy.
  • TLSRoute, qui n'est disponible que dans les maillages utilisant des proxys Envoy.
  • GRPCRoute, qui est disponible dans les maillages à l'aide de proxys side-car Envoy et de gRPC sans proxy. Lorsque vous utilisez des services ou des applications gRPC sans proxy avec Cloud Service Mesh, certaines des fonctionnalités décrites dans ce document ne sont pas disponibles.
• Service de backend auquel les ressources Route sont associées.

Configuration

Pour configurer la gestion avancée du trafic, vous utilisez les mêmes ressources Route et de services de backend que celles que vous utilisez lors de la configuration de Cloud Service Mesh. Cloud Service Mesh, à son tour, configure vos proxys Envoy et vos applications gRPC sans proxy pour appliquer les règles avancées de gestion du trafic que vous configurez.

En règle générale, vous procédez comme suit :

1. Configurez une ressource Mesh pour identifier le service mesh.

2. Configurez les ressources Route pour effectuer les opérations suivantes, en fonction des caractéristiques de la requête sortante:

   1. Sélectionnez le service de backend vers lequel les requêtes sont acheminées.

   2. Effectuez d'autres actions le cas échéant.

3. Configurez le service de backend pour contrôler la manière dont le trafic est distribué aux backends et aux points de terminaison après avoir sélectionnéun service de destination.

Routage du trafic et actions

Dans Cloud Service Mesh, le trafic est acheminé en fonction des valeurs des ressources Mesh, Route et du service de backend. Toutes les fonctionnalités avancées de gestion du trafic liées au routage et aux actions sont configurées à l'aide des objets Route.

Les sections suivantes décrivent les fonctionnalités avancées de gestion du trafic que vous pouvez configurer dans les objets Route.

Gestion des requêtes

Lorsqu'un client envoie une requête, celle-ci est traitée comme décrit dans les étapes suivantes :

1. La requête est mise en correspondance avec une ressource Route spécifique, comme suit:

   • Si vous utilisez Envoy :
     • L'en-tête d'hôte de la requête HTTP est mis en correspondance avec le champ hostnames de chaque ressource HTTPRoute ou GRPCRoute afin de sélectionner la ressource Route appropriée pour la requête. Seuls les champs hostnames sont disponibles pour les ressources HTTPRoute et GRPCRoute.
     • L'adresse IP est mise en correspondance pour acheminer le trafic TCP à l'aide de TCPPRoute.
     • Le SNI et l'ALPN sont utilisés pour le passthrough TLS à l'aide de TLSRoute.
     • Les noms d'hôte des ressources HTTPRoute et GRPCRoute associées à un Mesh ou à un Gateway doivent être uniques. Si vous essayez d'associer plusieurs routes dont les noms d'hôte sont en conflit, la configuration est rejetée.
     • De même, le champ IP:Port de TCPRoute doit être unique, sinon la configuration est rejetée.
     • De même, le SNI et l'ALPN doivent être uniques pour le TLSRoute.
     • Si des noms d'hôte se chevauchent, comme a.example.com et *.example.com, la requête correspond à la route la plus spécifique.
   • Si vous utilisez une API gRPC sans proxy :
     • Les clients gRPC sans proxy utilisent le schéma de résolution de noms xds. Ils résolvent le hostname[:port] dans l'URI cible en envoyant une requête à Cloud Service Mesh.
     • Seul le port d'une ressource GRPCRoute est comparé au port de l'URI cible (par exemple, xds:///example.hostname:8080). L'URI cible doit correspondre exactement à la chaîne du champ hostnames de GRPCRoute.

2. La ressource Route peut contenir d'autres informations et règles de routage.

3. Une fois le service de backend de destination sélectionné, le trafic est réparti entre les backends ou les points de terminaison de ce service de destination, en fonction de la configuration dans la ressource du service de backend.

La deuxième étape est décrite dans la section suivante, Routage simple basé sur l'hôte et le chemin d'accès. La troisième étape est décrite dans la section Routage et actions avancés.

Routage simple en fonction de l'hôte et du chemin d'accès

Cloud Service Mesh est compatible avec un schéma de routage simplifié et un schéma plus avancé. Dans le schéma simple, vous spécifiez un hôte et, éventuellement, un chemin d'accès. L'hôte et le chemin d'accès de la requête sont évalués pour déterminer le service de backend vers lequel la requête est acheminée.

• L'hôte de la requête est la partie nom de domaine d'une URL. Par exemple, dans l'URL http://example.com/video/, la partie nom d'hôte est example.com.
• Le chemin de la requête correspond à la partie de l'URL qui suit le nom d'hôte. Par exemple, dans l'URL http://example.com/video/, le chemin d'accès est /video.

Configurez un routage simple basé sur l'hôte et le chemin d'accès dans la carte des règles de routage, composée des éléments suivants :

• Mesh global
• HTTPRoute ou GRPCRoute

La plupart des configurations sont effectuées dans HTTPRoute. Une fois que vous avez créé la carte initiale des règles de routage, il vous suffit de modifier la ressource HTTPRoute.

La règle la plus simple est une règle par défaut, dans laquelle vous ne spécifiez qu'une règle d'hôte générique (*) et un outil de mise en correspondance des chemins d'accès avec un service par défaut. Après avoir créé la règle par défaut, vous pouvez ajouter des règles supplémentaires, qui spécifient des hôtes et des chemins d'accès différents. Les requêtes sortantes sont évaluées selon ces règles :

• Si l'hôte d'une requête (par exemple, example.com) correspond au nom d'hôte de HTTPRoute:

  1. L'RouteRule est ensuite évalué. RouteRule spécifie comment faire correspondre le trafic et comment l'acheminer lorsqu'il est mis en correspondance.
  2. Chaque RouteRule contient une ou plusieurs correspondances de routage évaluées par rapport au chemin de la requête.
  3. Si une correspondance est trouvée, la requête est acheminée vers le service spécifié dans le RouteAction.

Pour en savoir plus sur les champs de ressources de HTTPRoute et leur fonctionnement, consultez la documentation de l'API du service réseau.

Routage avancé et actions

Si vous souhaitez aller plus loin que le routage d'une requête en fonction de l'hôte et du chemin d'accès de la requête, vous pouvez configurer des règles avancées pour acheminer les requêtes et effectuer des actions.

De manière générale, les options de routage et d'action avancées fonctionnent comme suit :

1. Comme pour le routage simple, l'hôte de la requête est comparé aux règles d'hôte que vous configurez dans HTTPRoute ou GRPCRoute. Si l'hôte d'une requête correspond au nom d'hôte, HTTPRoute ou GRPCRoute est évalué.
2. Une fois qu'un itinéraire est sélectionné, vous pouvez appliquer des actions.

Routage avancé

Le routage avancé est semblable au routage simple décrit ci-dessus, à la différence que vous pouvez spécifier des conditions de correspondance supplémentaires. Par exemple, vous pouvez spécifier qu'une règle correspond à l'en-tête d'une requête si son nom correspond exactement ou partiellement, par exemple en fonction du préfixe ou du suffixe. La mise en correspondance peut s'effectuer en fonction de l'évaluation du nom de l'en-tête par rapport à une expression régulière, ou en fonction d'autres critères comme la vérification de la présence d'un en-tête.

Pour obtenir des conditions de correspondance et des informations détaillées supplémentaires sur headerMatches et queryParameterMatches, consultez la page API REST network services.

En combinant les paramètres d'hôte, de chemin d'accès, d'en-tête et de requête avec des conditions de correspondance, vous pouvez créer des règles très expressives qui répondent à vos besoins précis en termes de gestion du trafic. Pour en savoir plus, consultez le tableau suivant.

	Application basée sur HTTP	Application basée sur gRPC
Hôtes HTTP et hôtes gRPC	L'hôte est la partie du nom de domaine de l'URL vers laquelle l'application effectue les appels. Par exemple, la partie hôte de l'URL http://example.com/video/ est example.com.	L'hôte est le nom qu'un client utilise dans l'URI du canal pour se connecter à un service spécifique. Par exemple, la partie hôte de l'URI du canal xds:///example.com est example.com.
Chemins d'accès HTTP et gRPC	Le chemin correspond à la partie de l'URL qui suit le nom d'hôte. Par exemple, la partie du chemin d'accès de l'URL http://example.com/video est /video.	Le chemin d'accès se trouve dans l'en-tête :path de la requête HTTP/2 et ressemble à /SERVICE_NAME/METHOD_NAME. Par exemple, si vous appelez la méthode Download sur le service gRPC Example, le contenu de l'en-tête :path ressemble à /Example/Download.
Autres en-têtes gRPC (métadonnées)		gRPC est compatible avec l'envoi de métadonnées entre le client gRPC et le serveur gRPC pour fournir des informations supplémentaires sur un appel RPC. Ces métadonnées se présentent sous la forme de paires clé/valeur transmises en tant qu'en-têtes dans la requête HTTP/2.

Actions

Cloud Service Mesh vous permet de spécifier les actions effectuées par vos proxys Envoy ou vos applications gRPC sans proxy lors du traitement d'une requête. Les actions suivantes peuvent être configurées à l'aide de Cloud Service Mesh.

Remarque :Toutes les fonctionnalités suivantes sont disponibles lorsque vous utilisez Envoy avec Cloud Service Mesh. Certaines fonctionnalités ne sont pas disponibles lorsque vous utilisez des applications gRPC sans proxy avec Cloud Service Mesh. Pour en savoir plus, consultez les pages Fonctionnalités et Limites avec les applications gRPC sans proxy.

Action	Nom de champ de l'API	Description
Redirections	redirect [pathredirect?]	Renvoie un code de réponse 3xx configurable. Définit également l'en-tête de réponse Location à l'aide de l'URI approprié, en remplaçant l'hôte et le chemin d'accès comme spécifié dans l'action de redirection.
Réécriture d'URL	urlRewrite	Réécrit la partie nom d'hôte de l'URL, la partie chemin de l'URL, ou les deux, avant d'envoyer une requête au service de backend sélectionné.
Transformations d'en-tête	requestHeaderModifier/responseHeaderModifier?	Ajoute ou supprime des en-têtes de requête avant de transférer une requête au service de backend. Peut également ajouter ou supprimer des en-têtes de réponse après avoir reçu une réponse du service de backend.
Mise en miroir du trafic	requestMirrorPolicy	En plus de transmettre la requête au service de backend sélectionné, envoie une requête identique au service de backend en miroir, selon une configuration de type fire and forget. L'équilibreur de charge n'attend pas de réponse du backend auquel il envoie la requête en miroir. La mise en miroir est utile pour tester une nouvelle version d'un service de backend. Elle permet également de déboguer les erreurs de production sur une version de débogage du service de backend, plutôt que sur la version de production.
Répartition du trafic en fonction d'une pondération	weiDestination.serviceNameght	Permet au trafic d'une règle en correspondance d'être distribué à plusieurs services de backend, en fonction d'une pondération définie par l'utilisateur pour un service de backend particulier. Cette fonctionnalité est utile pour configurer des déploiements par étapes ou des tests A/B. Par exemple, l'action de routage peut être configurée pour envoyer 99 % du trafic à un service qui exécute une version stable d'une application, et 1 % à un service distinct exécutant une version plus récente.
Tentatives	retryPolicy	Configure les conditions dans lesquelles l'équilibrage effectue une nouvelle tentative pour les requêtes ayant échoué, le délai d'attente de l'équilibreur de charge avant une nouvelle tentative et le nombre maximal de tentatives autorisées.
Délai avant expiration	timeout	Indique le délai avant expiration pour la route sélectionnée. Le délai avant expiration est calculé à partir du moment où la requête est entièrement traitée et jusqu'à ce que la réponse soit elle aussi entièrement traitée. Le délai avant expiration inclut l'ensemble des nouvelles tentatives.
Injection de pannes	faultInjectionPolicy	Introduit des erreurs lors du traitement de demandes afin de simuler des pannes, y compris une latence élevée, une surcharge de service, des défaillances de service et un partitionnement réseau. Cette fonctionnalité est utile pour tester la résilience d'un service aux pannes simulées.
Règles de sécurité	corsPolicy	Les règles de partage des ressources entre origines multiples (CORS, Cross-origin resource sharing) permettent de gérer les paramètres d'application des requêtes CORS.

Pour en savoir plus sur les actions et leur fonctionnement, consultez la page de l'API Network Services.

Dans chaque règle de routage, vous pouvez spécifier l'une des actions de routage suivantes:

• Acheminer le trafic vers un service unique (destination.serviceName)
• Répartir le trafic entre plusieurs services (destination.weight).
• Rediriger des URL (redirect)

Vous pouvez également combiner l'une des actions de routage ci-dessus aux actions de routage suivantes (appelées actions complémentaires dans Cloud Console) :

• Manipuler les en-têtes de requête ou de réponse (requestHeaderModifier/responseHeaderModifier)
• Mettre en miroir le trafic (requestMirrorPolicy)
• Réécrire l'hôte, le chemin ou les deux (urlRewrite)
• Réessayer les requêtes ayant échoué (retryPolicy)
• Définir un délai avant expiration (timeout)
• Introduire des erreurs dans un pourcentage du trafic (faultInjectionPolicy)
• Ajouter une règle CORS (corsPolicy)

Comme les actions sont associées à des règles spécifiques, le proxy Envoy ou l'application gRPC sans proxy peut appliquer des actions différentes en fonction de la requête à gérer.

Distribuer le trafic entre les backends d'un service

Comme indiqué dans la section Gérer les requêtes, lorsqu'un client traite une requête sortante, il sélectionne d'abord un service de destination. Après avoir sélectionné un service de destination, il doit déterminer quel backend ou point de terminaison doit recevoir la requête.

Distribution du trafic entre les backends (cliquez pour agrandir)

Dans le diagramme ci-dessus, la Règle a été simplifiée. La règle est généralement une règle d'hôte, une mise en correspondance de chemins d'accèset une ou plusieurs règles de chemin ou de routage. Le service de destination est le service de backend. Les Backend 1, … et Backend n reçoivent et gèrent la requête. Ces backends peuvent être, par exemple, des instances de machine virtuelle (VM) Compute Engine qui hébergent le code de votre application côté serveur.

Par défaut, le client qui gère la requête envoie des requêtes au backend opérationnel le plus proche disposant d'une capacité suffisante. Pour éviter de surcharger un backend spécifique, il utilise l'algorithme à équilibrage de charge à tour de rôle pour équilibrer la charge des requêtes suivantes entre les autres backends du service de destination. Toutefois, dans certains cas, vous souhaiterez peut-être contrôler plus précisément ce comportement.

Équilibrage de charge, affinité de session et protection des backends

Vous pouvez définir les règles suivantes de distribution du trafic pour chaque service.

Règle	Nom de champ de l'API	Description
Mode d'équilibrage de charge	balancingMode	Contrôle la manière dont un groupe de points de terminaison du réseau (NEG) ou un groupe d'instances géré (MIG) est sélectionné après la sélection d'un service de destination. Vous pouvez configurer le mode d'équilibrage pour répartir la charge en fonction des connexions simultanées et du taux de demandes.
Règle d'équilibrage de charge	localityLbPolicy	Définit l'algorithme d'équilibrage de charge utilisé pour répartir le trafic entre les backends au sein d'un NEG ou d'un MIG. Pour optimiser les performances, vous pouvez choisir parmi plusieurs algorithmes (tels que round robin ou plus faible nombre de requêtes).
Affinité de session	sessionAffinity	Constitue une tentative d'envoi optimale de requêtes d'un client spécifique vers le même backend tant qu'il est opérationnel et dispose de la capacité nécessaire. Cloud Service Mesh est compatible avec quatre options d'affinité de session : adresse IP cliente, cookie HTTP, en-tête HTTP et affinité basée sur les cookies générés (que Cloud Service Mesh génère lui-même).
Hachage cohérent	consistentHash	Fournit une affinité de session souple en fonction des en-têtes HTTP, des cookies ou d'autres propriétés.
Disjoncteurs	circuitBreakers	Définit les limites supérieures du volume de connexions et de requêtes par connexion à un service de backend.
Détection des anomalies	outlierDetection	Spécifie les critères pour (1) supprimer les backends ou les points de terminaison non opérationnels des MIG ou des NEG et (2) ajouter un backend ou un point de terminaison lorsque celui-ci est considéré comme suffisamment opérationnel pour recevoir à nouveau le trafic. La vérification de l'état associée au service détermine si un backend ou un point de terminaison est considéré comme opérationnel.

Pour en savoir plus sur les différentes options de distribution du trafic et leur fonctionnement, consultez les documents suivants:

• Page backendServices API REST
• Présentation des services de backend

Exemples de cas d'utilisation

La gestion avancée du trafic convient à de nombreux cas d'utilisation. Cette section fournit quelques exemples généraux.

Vous trouverez d'autres exemples, y compris du code, dans les articles Configurer la gestion avancée du trafic avec Envoy et Configurer la gestion avancée du trafic avec des services gRPC sans proxy.

Routage de trafic ultraprécis pour la personnalisation

Vous pouvez acheminer le trafic vers un service en fonction des paramètres de la requête. Par exemple, vous pouvez utiliser ce service pour offrir une expérience plus personnalisée aux utilisateurs Android. Dans le schéma suivant, Cloud Service Mesh configure votre maillage de services pour envoyer des requêtes avec l'en-tête user-agent:Android à votre service Android au lieu de votre service générique.

Routage basé sur l'en-tête user-agent défini sur Android (cliquez pour agrandir)

Répartition du trafic en fonction d'une pondération pour des déploiements plus sûrs

Le déploiement d'une nouvelle version d'un service de production existant peut s'avérer risqué. Même après avoir réussi les tests dans un environnement de test, vous souhaiterez peut-être ne pas diriger immédiatement tous les utilisateurs vers la nouvelle version.

Cloud Service Mesh vous permet de définir des répartitions du trafic en fonction d'une pondération pour distribuer le trafic sur plusieurs services. Par exemple, vous pouvez envoyer 1 % du trafic vers la nouvelle version de votre service, vérifier que tout fonctionne, puis augmenter progressivement la part de trafic dirigé vers le nouveau service.

Répartition du trafic en fonction d'une pondération avec Cloud Service Mesh (cliquez pour agrandir)

Mise en miroir du trafic pour le débogage

Lorsque vous déboguez un problème, il peut être utile d'envoyer des copies du trafic de production à un service de débogage. Cloud Service Mesh vous permet de configurer des règles de mise en miroir des requêtes afin d'envoyer celles-ci à un service et d'envoyer leurs copies à un autre service.

Mise en miroir du trafic du service de réseau maillé Cloud (cliquez pour agrandir)

Équilibrage de charge adapté aux performances

Selon les caractéristiques de votre application, vous pourrez peut-être améliorer les performances et la disponibilité en ajustant avec précision la distribution du trafic sur les backends d'un service. Avec Cloud Service Mesh, vous pouvez appliquer des algorithmes avancés d'équilibrage de charge pour que le trafic soit distribué en fonction de vos besoins.

Le schéma suivant, contrairement aux schémas précédents, montre à la fois un service de backend de destination (service de production) et les backends de ce service de backend (VM 1, VM 2, VM 3). La gestion avancée du trafic vous permet de configurer la manière dont un service de backend de destination est sélectionné, ainsi que la manière dont le trafic est réparti entre les backends de ce service.

Équilibrage de charge du service de réseau Cloud (cliquez pour agrandir)

Pour en savoir plus sur l'équilibrage de charge avec Cloud Service Mesh, consultez la présentation de l'équilibrage de charge avancé.

Étape suivante

• Pour diriger le trafic provenant de l'extérieur de votre réseau maillé vers votre réseau maillé, consultez la section Trafic entrant pour votre réseau maillé.