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 Traffic Director et de maillage de services, et qui déterminent et configurent la gestion du trafic dans un déploiement Traffic Director. Ce document ne s'applique qu'aux API de routage de service. Si votre déploiement Traffic Director utilise les anciennes API d'équilibrage de charge, consultez la page Présentation de la gestion avancée du trafic pour les API d'équilibrage de charge. Notez que les fonctionnalités d'équilibrage de charge global de Traffic Director sont disponibles, quelle que soit l'API que vous utilisez.

Traffic Director fournit des fonctionnalités avancées de gestion du trafic qui vous permettent de contrôler avec précision la manière dont le trafic est géré. Traffic Director 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 basée sur la pondération pour répartir le trafic entre plusieurs services
• Règles de mise en miroir du trafic qui envoient des requêtes à un service de débogage et les copie vers 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 améliorer l'é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 Traffic Director dans ces cas d'utilisation est que vous pouvez changer 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 Traffic Director repose sur les ressources suivantes:

• La 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.
• La ressource Gateway, qui identifie les proxys intermédiaires et représente le composant qui écoute une liste de paires adresse IP/port, transfère le trafic et applique des règles.
• La ressource Route, qui peut être de différents types et qui contient des informations de routage du trafic pour le maillage. 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.
• Service de backend, auquel les ressources Route sont associées.

Voici les différents types de ressources Route:

• HTTPRoute, disponible uniquement 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 de ce document sont disponibles.
• TCPRoute, disponible uniquement dans les maillages utilisant des proxys Envoy
• TLSRoute, disponible uniquement dans les maillages utilisant des proxys Envoy
• GRPCRoute, disponible dans les maillages utilisant des proxys side-car Envoy et gRPC sans proxy. Lorsque vous utilisez des services ou des applications gRPC sans proxy avec Traffic Director, certaines des fonctionnalités décrites dans ce document ne sont pas disponibles.

Configuration

Pour configurer la gestion avancée du trafic, utilisez les mêmes ressources de Route et de services de backend que celles utilisées lors de la configuration de Traffic Director. Traffic Director, à 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. Configurer une ressource Mesh pour identifier le maillage de services

2. Configurez les ressources Route pour qu'elles effectuent 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 Traffic Director, 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 de gestion avancée 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. Seules les ressources HTTPRoute et GRPCRoute comportent le champ hostnames.
     • L'adresse IP est mise en correspondance pour le routage du trafic TCP à l'aide de TCPPRoute.
     • SNI et ALPN sont utilisés pour le passthrough TLS à l'aide de TLSRoute.
     • Les ressources HTTPRoute et GRPCRoute associées à un Mesh ou à un Gateway doivent avoir des noms d'hôte uniques. Si vous essayez d'associer plusieurs routes avec des noms d'hôte en conflit, la configuration est refusée.
     • De même, le champ IP:Port de TCPRoute doit être unique, sans quoi la configuration sera rejetée.
     • De même, SNI et ALPN doivent être uniques pour TLSRoute.
     • En cas de chevauchement des noms d'hôte, tels que a.example.com et *.example.com, la requête correspond à la route la plus spécifique.
   • Si vous utilisez gRPC sans proxy :
     • Les clients gRPC sans proxy utilisent le schéma de résolution de noms xds. Ils résolvent le problème hostname[:port] dans l'URI cible en envoyant une requête à Traffic Director.
     • 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

Traffic Director 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 :

• Un Mesh mondial
• HTTPRoute ou GRPCRoute

La plupart de la configuration est effectuée dans HTTPRoute. Après avoir créé la carte des règles de routage initiale, 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. RouteRule est ensuite évalué. RouteRule spécifie comment mettre en correspondance le trafic et comment l'acheminer lorsque le trafic est mis en correspondance.
  2. Chaque RouteRule contient une ou plusieurs correspondances de routes, qui sont é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 ressource de HTTPRoute et leur fonctionnement, consultez la documentation de l'API de 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'une route est sélectionnée, vous pouvez appliquer des actions.

Routage avancé

Le routage avancé est semblable au routage simple décrit précédemment, sauf 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 exactement à vos exigences 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

Traffic Director 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 Traffic Director.

Remarque : Toutes les fonctionnalités suivantes sont disponibles lorsque vous utilisez Envoy avec Traffic Director. Certaines fonctionnalités ne sont pas encore disponibles lorsque vous utilisez des applications gRPC sans proxy avec Traffic Director. 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 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	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'é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 plus d'informations sur les actions et leur fonctionnement, consultez la page API des services réseau.

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 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)

Étant donné que les actions sont associées à des règles spécifiques, le proxy Envoy ou l'application gRPC sans proxy peut appliquer différentes actions en fonction de la requête qu'il traite.

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 instances de machines virtuelles (VM) Compute Engine qui hébergent votre code d'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. Traffic Director 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 Traffic Director 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 API REST backendServices et la page 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 des exemples de code, dans les sections 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, Traffic Director 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.

Traffic Director 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 basée sur la pondération de Traffic Director (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. Traffic Director 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 Traffic Director (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. Traffic Director vous permet d'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 Traffic Director (cliquez pour agrandir)

Étapes suivantes

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