Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la page Présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Présentation de la gestion avancée du trafic pour les API d'équilibrage de charge

Ce document est destiné aux administrateurs de maillage ou de plate-forme et aux développeurs de services qui possèdent un niveau de connaissance intermédiaire à avancé des concepts de Cloud Service Mesh et du maillage de services, et qui déterminent et configurent la façon dont le trafic est géré dans un déploiement Cloud Service Mesh. Ce document ne s'applique qu'aux API d'équilibrage de charge, et non aux API de routage de service. Si votre déploiement Cloud Service Mesh utilise les API de routage de services, consultez la page Présentation de la gestion avancée du trafic.

Cloud Service Mesh offre 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 service
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 pour ces cas d'utilisation est que vous pouvez mettre à jour la façon dont le trafic est géré sans avoir à modifier le code de votre application.

Lorsque vous utilisez le proxy HTTP cible pour configurer les proxys Envoy pour envoyer des requêtes HTTP, toutes les fonctionnalités décrites dans ce document sont disponibles.
Lorsque vous utilisez des services ou des applications gRPC sans proxy avec Cloud Service Mesh, certaines fonctionnalités ne sont pas disponibles.
Lorsque vous utilisez le proxy TCP cible pour configurer les proxys Envoy pour envoyer des requêtes TCP, aucune de ces fonctionnalités n'est disponible, car il n'existe pas de mappage d'URL dans les configurations avec un proxy TCP cible.

Pour en savoir plus, consultez la page Fonctionnalités.

Pour configurer la gestion avancée du trafic, vous devez utiliser la carte des règles de routage et les ressources des services de backend que vous avez utilisées lors de la configuration de Cloud Service Mesh. Cloud Service Mesh configure à son tour vos proxys Envoy et vos applications gRPC sans proxy pour appliquer les règles de gestion avancée du trafic que vous avez définies.

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

Configurez la carte des règles de routage 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.
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.

Configuration du filtrage

L'une des principales responsabilités de Cloud Service Mesh est de générer des informations de configuration à partir de la règle de transfert, du proxy cible et du mappage d'URL, puis d'envoyer ces informations aux clients Cloud Service Mesh, par exemple des proxys Envoy et des applications gRPC. Cloud Service Mesh contrôle votre maillage de services en envoyant des informations de configuration à ses clients qui leur indiquent comment se comporter et comment acheminer le trafic. Cloud Service Mesh est le plan de contrôle.

Lorsque vous créez ou mettez à jour des informations de configuration dans Cloud Service Mesh, Cloud Service Mesh traduit cette configuration dans un langage compréhensible par ses clients. Par défaut, Cloud Service Mesh partage cette configuration avec tous ses clients. Dans certains cas, vous pouvez choisir les clients Cloud Service Mesh qui reçoivent des informations de configuration spécifiques, autrement dit filtrer la configuration en fonction de clients spécifiques.

Bien qu'il s'agisse d'une fonctionnalité avancée, les exemples suivants illustrent comment filtrer la configuration peut vous aider:

Votre organisation utilise le modèle de réseau VPC partagé, et plusieurs équipes utilisent Cloud Service Mesh dans différents projets de service. Si vous souhaitez isoler votre configuration des autres projets de service, vous pouvez la filtrer afin que des clients Cloud Service Mesh spécifiques ne reçoivent qu'un sous-ensemble de la configuration.
Vous avez un très grand nombre de règles de routage et de services configurés dans Cloud Service Mesh et vous souhaitez éviter d'envoyer une quantité anormalement élevée de configurations à chaque client Cloud Service Mesh. Gardez à l'esprit qu'un client devant évaluer une requête sortante à l'aide d'une configuration complexe et volumineuse peut être moins performant qu'un client qui n'a besoin d'évaluer une requête que via une configuration simplifiée.

Le filtrage de la configuration est basé sur le concept de filtres de métadonnées :

Lorsqu'un client Cloud Service Mesh se connecte, il présente les informations de son fichier d'amorçage à Cloud Service Mesh.
Ces informations contiennent le contenu des champs de métadonnées, sous la forme de paires clé/valeur, que vous spécifiez dans le fichier d'amorçage lorsque vous déployez vos proxys Envoy et vos applications gRPC.
Vous pouvez ajouter des filtres de métadonnées à la règle de transfert. L'ensemble de la configuration liée à la règle de transfert est filtrée.
Vous pouvez ajouter des filtres de métadonnées au mappage d'URL. Le filtre de métadonnées est appliqué sur le routage par chemin.
Cloud Service Mesh ne partage la configuration qu'avec les clients qui présentent des métadonnées correspondant aux conditions de filtre de métadonnées.

Pour en savoir plus sur la configuration des filtres de métadonnées pour Envoy, consultez la page Configurer un filtrage des configurations en fonction de la correspondance MetadataFilter.

Routage du trafic et actions

Dans Cloud Service Mesh, le mappage des règles de routage fait référence à la combinaison de la règle de transfert, du proxy cible et des ressources de mappage d'URL. Toutes les fonctionnalités avancées de gestion du trafic liées au routage et aux actions sont configurées à l'aide du mappage d'URL.

Les sections suivantes décrivent les fonctionnalités avancées de gestion du trafic que vous pouvez configurer dans la carte des règles de routage.

Gestion des requêtes

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

La requête est mise en correspondance avec une carte de règles de routage spécifique, comme suit :
- Si vous utilisez Envoy :
  - L'adresse IP et le port de destination de la requête sont comparés à l'adresse IP et au port des règles de transfert dans toutes les cartes de règles de routage. Seules les cartes de règles de routage comportant des règles de transfert avec le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED sont prises en compte.
  - La règle de transfert qui correspond à la requête fait référence à un proxy HTTP ou gRPC cible, qui fait référence à un mappage d'URL. Ce mappage d'URL contient des informations utilisées pour le routage et les actions.
- Si vous utilisez une API gRPC sans proxy :
  - Un client gRPC qui utilise le schéma de résolution de noms xds n'effectue pas de résolution DNS pour résoudre le nom d'hôte dans l'URI de canal. À la place, un tel client résout le hostname[:port] dans l'URI cible en envoyant une requête LDS à Cloud Service Mesh.
  - Seul le port d'une règle de transfert avec le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED est comparé au port de l'URI cible (par exemple, xds:///example.hostname:8080). L'adresse IP de la règle de transfert n'est pas utilisée. La valeur par défaut du port est 80 si aucun port n'est spécifié dans l'URI cible.
  - La règle de transfert qui correspond à la requête fait référence à un proxy gRPC cible, qui fait référence à un mappage d'URL. Ce mappage d'URL contient des informations utilisées pour le routage et les actions.
  - Si plusieurs règles de transfert correspondent à la requête, le mappage d'URL contenant la règle d'hôte correspondant à l'élément hostname[:port] dans l'URI cible est utilisé pour le routage et les actions.
Lorsque le mappage d'URL approprié est déterminé, le mappage d'URL est évalué pour déterminer le service de backend de destination et, éventuellement, appliquer des actions.
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 accepte 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 vers lequel une requête doit être 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 :

Une règle de transfert globale
Un proxy HTTP cible, un proxy HTTPS cible ou un proxy gRPC cible
Un mappage d'URL

La plupart des configurations sont effectuées dans le mappage d'URL. Une fois que vous avez créé la carte initiale des règles de routage, il vous suffit de modifier la partie du mappage d'URL dans la carte des règles de routage. Dans le schéma ci-dessous, les règles de chemin d'accès présentent des actions semblables à celles du schéma suivant.

Routage basé sur les ressources hôte et de chemin d'accès. — Routage basé sur les ressources d'hôte et de chemin d'accès (cliquez pour agrandir)

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 à une règle d'hôte :
1. L'outil de mise en correspondance des chemins d'accès est ensuite évalué.
2. Chaque outil de mise en correspondance des chemins d'accès contient une ou plusieurs règles de chemin d'accès évaluées en fonction du chemin de la requête.
3. Si une correspondance est trouvée, la requête est acheminée vers le service spécifié dans la règle de chemin d'accès.
4. Si la règle d'hôte correspond, mais qu'aucune règle de chemin d'accès ne correspond, les requêtes sont acheminées vers un service par défaut que chaque outil de mise en correspondance des chemins d'accès contient.
Si la requête ne correspond à aucune des règles d'hôte que vous avez spécifiées, elle est acheminée vers le service spécifié dans la règle par défaut.

Pour en savoir plus sur les champs de ressources du mappage d'URL et leur fonctionnement, consultez la page de l'API REST urlMaps.

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 :

Comme pour le routage simple, l'hôte de la requête est comparé aux règles d'hôte que vous configurez dans le mappage d'URL. Si l'hôte d'une requête correspond à une règle d'hôte, l'outil de mise en correspondance des chemins d'accès de la règle d'hôte est évalué.
L'outil de mise en correspondance des chemins d'accès contient une ou plusieurs règles de routage évaluées par rapport à la requête. Ces règles de routage sont évaluées par ordre de priorité en fonction des attributs de larequête (hôte, chemin d'accès, en-tête et paramètres de requête) en fonction de conditions de correspondance spécifiques, telles que la correspondance de préfixe.
Une fois qu'une règle de routage est sélectionnée, vous pouvez appliquer des actions. L'action par défaut consiste à acheminer la requête vers un seul service de destination, mais vous pouvez également configurer d'autres actions.

Routage avancé

Le routage avancé est semblable au routage simple décrit ci-dessus, à la différence que vous pouvez spécifier une priorité de règle et des conditions de correspondance supplémentaires.

Avec le routage avancé, vous devez spécifier une priorité unique pour chaque règle. Cette priorité détermine l'ordre d'évaluation des règles de routage, les valeurs de priorité inférieure étant prioritaires sur les valeurs de priorité plus élevée. Une fois qu'une requête correspond à une règle, la règle est appliquée et les autres règles sont ignorées.

Le routage avancé accepte également desconditions 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 urlMaps.

En combinant les paramètres d'hôte, de chemin d'accès, d'en-tête et de requête avec des priorités et 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

	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.

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 que vos proxys Envoy ou vos applications gRPC sans proxy effectuent lors du traitement d'une requête. Les actions suivantes peuvent être configurées à l'aide de Cloud Service Mesh.

Action	Nom de champ de l'API	Description
Redirections	`urlRedirect`	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 d'accès de l'URL, ou les deux, avant d'envoyer une requête au service de backend sélectionné.
Transformations d'en-tête	`headerAction`	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	`weightedBackendServices`	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'équilibreur de charge relance 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 CORS (Cross-Origin Resource Sharing) gèrent les paramètres pour l'application des requêtes CORS.

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

Dans chaque règle de routage, vous pouvez spécifier l'une des actions de routage suivantes (dénommées "actions principales" dans Google Cloud Console) :

Acheminer le trafic vers un service unique (service)
Répartir le trafic entre plusieurs services (weightedBackendServices).
Rediriger des URL (urlRedirect)

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/réponse (headerAction)
Mettre en miroir le trafic (requestMirrorPolicy)
Réécrire l'hôte, le chemin ou les deux de l'URL (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 de routage 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.

Répartition 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 machines virtuelles (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 client, basée sur les cookies HTTP, basée sur l'en-tête HTTP et l'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 pour le 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 la page de l'API REST backendServices.

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 davantage d'exemples, y compris des exemples de code, dans les guides Configurer la gestion avancée du trafic et Configurer des services gRPC sans proxy avec la gestion avancée du trafic.

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 les requêtes avec l'en-tête user-agent:Android à votre service Android plutôt qu'à votre service générique.

Routage basé sur l'en-tête "user-agent" défini sur Android. — 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 basées sur une pondération pour répartir le trafic entre 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 basée sur la pondération de Cloud Service Mesh. — Répartition du trafic basée sur la pondération de 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 que les requêtes soient envoyées à un service et que des copies de ces requêtes soient envoyées à un autre service.

Mise en miroir du trafic Cloud Service Mesh (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 afin de répartir le trafic 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 de Cloud Service Mesh(cliquez pour agrandir)

Étapes suivantes

Pour en savoir plus sur les mappages d'URL, consultez les pages Présentation des mappages d'URL et Utiliser des mappages d'URL.
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é.
Pour configurer des fonctionnalités avec des déploiements de proxy side-car, consultez la page Configurer la gestion avancée du trafic avec Envoy.
Pour configurer les fonctionnalités avec des déploiements gRPC sans proxy, consultez la section Configurer la gestion avancée du trafic avec des services gRPC sans proxy.