Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Présentation de Traffic Director avec services gRPC sans proxy

Ce guide présente l'architecture de Traffic Director avec des services gRPC sans proxy, y compris des cas d'utilisation et des modèles d'architecture. Ce guide couvre les anciennes API de Traffic Director. Pour en savoir plus sur les API de routage de service, consultez la présentation.

Le plan de contrôle géré de Traffic Director permet le routage global, l'équilibrage de charge et le basculement régional pour les cas d'utilisation du maillage de services avec l'équilibrage de charge. Cela inclut les déploiements intégrant des proxys side-car et des proxys de passerelle. Traffic Director est compatible avec les applications gRPC sans proxy qui offrent un modèle de déploiement supplémentaire dans lequel les applications gRPC peuvent participer à un maillage de services sans nécessiter de proxy side-car.

Dans un cas d'utilisation standard, un client gRPC établit une connexion avec un serveur gRPC qui héberge votre logique de backend. Traffic Director indique à vos clients gRPC des informations sur les serveurs à contacter, comment équilibrer la charge des requêtes sur plusieurs instances d'un serveur et quoi faire des requêtes lorsqu'aucun serveur n'est en cours d'exécution.

Pour obtenir une présentation complète du fonctionnement de Traffic Director, consultez la présentation de Traffic Director.

Fonctionnement de Traffic Director avec des applications gRPC

Traffic Director configure les clients gRPC avec une version de gRPC compatible, de la même manière que les proxys side-car tels que Envoy sont configurés. Toutefois, les applications gRPC sans proxy connectées directement à Traffic Director n'ont pas besoin de proxys side-car. À la place, Traffic Director utilise des API Open Source xDS pour configurer directement les applications gRPC. Ces applications gRPC agissent en tant que clients xDS, en se connectant au plan de contrôle global de Traffic Director. Une fois connectées, les applications gRPC reçoivent une configuration dynamique du plan de contrôle, ce qui permet la découverte des points de terminaison, l'équilibrage de charge, le basculement régional et les vérifications d'état. Cette approche permet d'utiliser des modèles de déploiement supplémentaires dans Traffic Director.

Dans la première illustration, un maillage de services est activé à l'aide d'un proxy side-car.

Maillage de services activé à l'aide d'un proxy side-car
Maillage de services activé à l'aide d'un proxy side-car (cliquez pour agrandir)

Pour configurer un proxy side-car, Traffic Director utilise les API xDS. Les clients communiquent avec le serveur via le proxy side-car.

Sur la seconde illustration, un maillage de services est activé sans proxy side-car à l'aide d'un client gRPC sans proxy.

Maillage de services activé à l'aide de gRPC sans proxy
Maillage de services activé à l'aide de gRPC sans proxy (cliquez pour agrandir)

Si vous ne déployez que des services gRPC configurés par Traffic Director, vous pouvez créer un maillage de services sans déployer de proxys. Cela facilite l'intégration des fonctionnalités du maillage de services à vos applications gRPC.

Schéma de résolution de noms

La résolution de noms pour les déploiements sans proxy fonctionne de la façon suivante :

  1. Vous définissez xds comme schéma de résolution de noms dans le canal client gRPC lors de la connexion à un service. L'URI cible est au format xds:///hostname:port. Lorsque le port n'est pas spécifié, la valeur par défaut est 80, par exemple dans l'URI cible xds:///example.hostname.
  2. Le client gRPC résout le hostname:port dans l'URI cible en envoyant une requête de service de détection d'écouteurs à Traffic Director.
  3. Traffic Director recherche les règles de transfert configurées qui disposent d'un port correspondant. Il recherche ensuite le mappage d'URL correspondant à une règle d'hôte conforme à hostname:port. Il renvoie la configuration de routage associée au client gRPC.

Les règles d'hôte que vous configurez dans Traffic Director doivent être uniques pour tous les mappages d'URL. Par exemple, example.hostname, example.hostname:80 et example.hostname:8080 sont toutes des règles différentes.

Résolution du nom avec différents types de déploiements

Le schéma de résolution de noms associé aux déploiements sans proxy diffère de celui des déploiements qui utilisent des proxys Envoy.

Le client gRPC utilise le schéma de résolution de noms xds pour se connecter à un service, ce qui lui permet de recevoir la configuration de service de Traffic Director. Le client gRPC communique ensuite directement avec le serveur gRPC.

Vous pouvez combiner des modèles de déploiement avec proxy side-car et sans proxy pour plus de flexibilité. Ceci est particulièrement utile lorsque votre entreprise et votre réseau accueillent plusieurs équipes dont les exigences de fonctionnalités, les besoins opérationnels et les versions de gRPC sont différents.

Sur l'illustration suivante, des clients gRPC sans proxy et des clients gRPC avec proxy side-car communiquent avec un serveur gRPC. Les clients gRPC avec des proxys side-car utilisent le schéma de résolution de noms dns.

Maillage de services composé de clients gRPC sans proxy et de clients gRPC avec des proxys side-car
Maillage de services composé de clients gRPC sans proxy et de clients gRPC avec des proxys side-car (cliquez pour agrandir)

Cas d'utilisation

Les cas d'utilisation suivants vous permettent de comprendre dans quels cas vous pouvez utiliser Traffic Director avec des applications gRPC sans proxy. Votre déploiement peut inclure des applications gRPC sans proxy, des applications gRPC avec des proxys side-car ou une combinaison des deux.

Efficacité des ressources dans un maillage de services à grande échelle

Si votre maillage de services inclut des centaines, voire des milliers de clients et de backends, vous constaterez peut-être que la consommation totale des ressources des proxys side-car en exécution s'accroît. Lorsque vous utilisez des applications gRPC sans proxy, vous n'avez pas besoin d'introduire des proxys side-car dans votre déploiement. Une approche sans proxy peut apporter des gains d'efficacité.

Applications gRPC hautes performances

Dans certains cas d'utilisation, chaque milliseconde de latence des requêtes et des réponses compte. Dans ce cas, vous constaterez peut-être une latence réduite lorsque vous utilisez une application gRPC sans proxy, au lieu de transmettre chaque requête via un proxy side-car côté client et, éventuellement, un proxy side-car côté serveur.

Maillage de services destiné aux environnements dans lesquels vous ne pouvez pas déployer de proxys side-car

Dans certains environnements, vous ne pourrez peut-être pas exécuter un proxy side-car en tant que processus supplémentaire avec votre application cliente ou serveur. Il se peut également que vous ne puissiez pas configurer la pile réseau d'une machine en vue de l'interception et de la redirection des requêtes, par exemple à l'aide d'iptables. Dans ce cas, vous pouvez utiliser Traffic Director avec des applications gRPC sans proxy pour intégrer des fonctionnalités de maillage de services à ces applications.

Maillage de services hétérogène

Étant donné que les applications gRPC sans proxy et Envoy communiquent avec Traffic Director, votre maillage de services peut inclure les deux modèles de déploiement. L'inclusion des deux modèles vous permet de répondre aux besoins opérationnels, de performances et de fonctionnalités spécifiques de différentes applications et équipes de développement.

Migrer depuis un maillage de services avec des proxys vers un maillage sans proxys

Si vous disposez déjà d'une application gRPC avec un proxy side-car configuré par Traffic Director, vous pouvez passer à une application gRPC sans proxy.

Un client gRPC déployé avec un proxy side-car utilise le DNS pour résoudre le nom d'hôte auquel il se connecte. Le proxy side-car intercepte le trafic pour assurer la fonctionnalité de maillage de services.

Vous pouvez configurer un client gRPC pour qu'il utilise la route sans proxy ou la route proxy side-car afin de communiquer avec un serveur gRPC en modifiant le schéma de résolution de noms qu'il utilise. Les clients sans proxy utilisent le schéma de résolution de noms xds, tandis que les proxys side-car utilisent le schéma de résolution de noms dns. Certains clients gRPC peuvent même utiliser la route sans proxy lorsqu'ils communiquent avec un serveur gRPC, mais utiliser la route proxy side-car lorsqu'ils communiquent avec un autre serveur gRPC. Cela vous permet de migrer progressivement vers un déploiement sans proxy.

Pour migrer d'un maillage de services avec des proxys vers un maillage sans proxys, créez un service Traffic Director qui sera utilisé par votre client gRPC sans proxy. Vous pouvez utiliser les mêmes API pour configurer Traffic Director pour les versions existantes et nouvelles.

Maillage de services comportant un client gRPC qui communique avec différents services à l'aide de mécanismes sans proxy et basés sur un proxy.
Maillage de services avec un client gRPC qui communique avec différents services à l'aide de mécanismes sans proxy et basés sur un proxy (cliquez pour agrandir)

Architecture et ressources

Le modèle de données de configuration des services gRPC sans proxy étend le modèle de configuration Traffic Director, moyennant certains ajouts et limites décrits dans ce guide. Certaines de ces limites sont temporaires, car gRPC n'est pas encore compatible avec toutes les fonctionnalités d'Envoy, et d'autres sont inhérentes à l'utilisation des RPC. Par exemple, les redirections HTTP qui utilisent gRPC ne sont pas acceptées. Pour vous aider à comprendre le modèle de configuration de ce guide, nous vous recommandons de vous familiariser avec les concepts et la configuration de Traffic Director.

Le schéma suivant illustre les ressources que vous devez configurer pour les applications gRPC sans proxy.

Ressources acceptées dans gRPC sans proxy pour l'équilibrage de charge.
Ressources acceptées dans gRPC sans proxy pour l'équilibrage de charge (cliquez pour agrandir)

Cartes des règles de routage

Une carte des règles de routage définit la manière dont les requêtes sont acheminées au sein du maillage. Elle se compose d'une règle de transfert, d'un proxy gRPC cible et d'un mappage d'URL.

Règle de transfert

En règle générale, vous créez la règle de transfert à l'aide de l'adresse IP virtuelle et du port du service que vous configurez. Un client gRPC utilisant 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. Un tel client résout plutôt hostname[:port] dans l'URI cible en envoyant une requête LDS à Traffic Director. Cette opération n'implique aucune résolution DNS, et aucune entrée DNS n'est nécessaire pour le nom d'hôte.

Par conséquent, Traffic Director utilise uniquement le port spécifié dans l'URI pour rechercher la règle de transfert, en ignorant l'adresse IP. La valeur par défaut du port est 80. Ensuite, Traffic Director recherche une règle d'hôte correspondante dans le mappage d'URL associé au proxy cible référencé par la règle de transfert.

Par conséquent, l'adresse IP d'une règle de transfert faisant référence à 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.

Veuillez noter les points suivants :

  • Le schéma d'équilibrage de charge de la règle de transfert doit être INTERNAL_SELF_MANAGED.
  • Vous pouvez utiliser plusieurs règles de transfert, mais l'élément IP:port de chaque règle de transfert doit être unique et le port doit correspondre au port spécifié dans la règle d'hôte.
  • Si plusieurs règles de transfert possèdent un port correspondant au port de l'URI cible, Traffic Director recherche un hostname[:port] correspondant parmi les règles d'hôte des mappages d'URL référencés par toutes ces règles de transfert. Traffic Director recherche une correspondance exacte entre le hostname[:port] de la règle d'hôte et le hostname[:port] spécifié dans l'URI cible. Les règles d'hôte et les règles par défaut contenant des caractères génériques sont ignorées.

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.

Proxy gRPC cible

Les proxys cibles pointent vers des mappages d'URL, qui contiennent eux-mêmes des règles utilisées pour acheminer le trafic vers le backend approprié. Lorsque vous configurez Traffic Director pour des applications gRPC, utilisez un proxy gRPC cible, et non un proxy HTTP cible, que ce soit pour des applications gRPC sans proxy ou des applications gRPC utilisant Envoy.

Les proxys gRPC cibles comportent un champ nommé validateForProxyless dans l'API REST. La valeur par défaut est FALSE. Définir ce champ sur TRUE active les vérifications de configuration afin de ne pas activer accidentellement une fonctionnalité qui n'est pas compatible avec gRPC sans proxy.

Dans Google Cloud CLI, l'option --validate-for-proxyless est l'équivalent du champ validateForProxyless.

Bien que Traffic Director soit compatible avec les applications gRPC sans proxy, les fonctionnalités disponibles pour les applications gRPC avec proxy side-car ne sont pas toutes disponibles. Utilisez ce champ pour vous assurer qu'une configuration non valide, susceptible d'être spécifiée dans le mappage d'URL ou le service de backend, sera rejetée. La vérification de la configuration est effectuée en fonction des fonctionnalités de Traffic Director compatibles avec la version la plus récente de gRPC.

Mappage d'URL

Le mappage d'URL définit les règles de routage que vos clients gRPC sans proxy utilisent pour envoyer du trafic. Le mappage d'URL contient une ou plusieurs règles d'hôte au format hostname:port. Chacune de ces règles d'hôte renvoie à un service.

Lorsque vous configurez votre client gRPC, vous spécifiez l'URI cible du service que le client doit contacter. Cet URI utilise également le format hostname:port et correspond à l'entrée de règle d'hôte dans le mappage d'URL.

Par exemple, si vous configurez l'URI cible xds:///myservice:8080 dans votre client gRPC, Traffic Director lui envoie la configuration correspondant à la règle d'hôte de mappage d'URL pour myservice:8080. Cette configuration inclut, entre autres, une liste de points de terminaison dont chacun est représenté par une paire adresse IP/port correspondant à des instances de serveur gRPC spécifiques.

Si vous ne spécifiez pas de port dans l'URI cible, 80 est utilisé comme valeur par défaut. Cela entraîne le comportement suivant :

  • L'URI cible xds:///myservice correspond à la règle d'hôte de mappage d'URL myservice.
  • L'URI cible xds:///myservice:80 correspond à la règle d'hôte de mappage d'URL myservice:80.
  • L'URI cible xds:///myservice ne correspond pas à la règle d'hôte de mappage d'URL myservice:80.
  • L'URI cible xds:///myservice:80 ne correspond pas à la règle d'hôte de mappage d'URL myservice.

La chaîne dans l'URI cible et celle dans la règle d'hôte de mappage d'URL doivent être identiques.

Pour en savoir plus, consultez l'article Limites des mappages d'URL.

Vérifications d'état

Une vérification d'état gRPC peut vérifier l'état d'un service gRPC s'exécutant sur une instance de machine virtuelle (VM) de backend ou sur un groupe de points de terminaison du réseau (NEG).

S'il est impossible d'effectuer une vérification d'état gRPC parce que votre serveur gRPC ne met pas en œuvre le protocole de vérification d'état gRPC, utilisez plutôt une vérification d'état TCP. N'utilisez pas de vérification d'état HTTP, HTTPS ou HTTP/2.

Pour en savoir plus, consultez les pages Vérification de l'état gRPC et Option supplémentaire pour les vérifications de l'état gRPC.

Service backend

Le service de backend définit la manière dont un client gRPC communique avec un serveur gRPC. Lorsque vous créez un service de backend pour gRPC, définissez le champ de protocole sur GRPC.

  • Les applications gRPC peuvent également accéder, par le biais d'un proxy side-car, à un service de backend configuré avec GRPC comme protocole. Dans ce cas, le client gRPC ne doit pas utiliser le schéma de résolution de noms xds.

  • Dans tous les déploiements de Traffic Director, le schéma d'équilibrage de charge du service de backend doit être INTERNAL_SELF_MANAGED.

Backends

Les backends hébergent vos instances de serveur gRPC. Vous pouvez utiliser des groupes d'instances gérés ou non gérés dans Compute Engine et des NEG zonaux dans Google Kubernetes Engine en tant que backends pour héberger vos instances de serveur gRPC.

Étapes suivantes