Présentation de Cloud Service Mesh avec des services gRPC sans proxy

Ce guide présente l'architecture de Cloud Service Mesh avec des services gRPC sans proxy, y compris des cas d'utilisation et des modèles d'architecture.

Le plan de contrôle géré de Cloud Service Mesh 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. La compatibilité du service de maillage de services Cloud avec les applications gRPC sans proxy offre 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. Cloud Service Mesh 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 Cloud Service Mesh, consultez la Présentation de Cloud Service Mesh

Fonctionnement de Cloud Service Mesh avec les applications gRPC

Cloud Service Mesh configure les clients gRPC avec un version de gRPC compatible, de la même manière que les proxys side-car tels qu'Envoy sont configurés. Toutefois, les applications gRPC sans proxy connectées directement à Cloud Service Mesh n'ont pas besoin de proxys side-car. À la place, Cloud Service Mesh utilise des API xDS Open Source pour configurer directement des applications gRPC. Ces applications gRPC agissent en tant que clients xDS, en se connectant au plan de contrôle global de Cloud Service Mesh. 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 Cloud Service Mesh.

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, Cloud Service Mesh utilise des API xDS. Clients communiquer 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 Cloud Service Mesh, vous pouvez créer un maillage de services sans déployer de proxys du tout. Cela facilite l'intégration des fonctionnalités du maillage de services à vos applications gRPC.

Résolution de nom

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 service de découverte d'écouteurs (LDS) à Cloud Service Mesh.
  3. Cloud Service Mesh recherche les règles de transfert configurées 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 Cloud Service Mesh doivent être uniques 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. permettant au client de recevoir la configuration du service de Cloud Service Mesh. 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 aident à comprendre quand utiliser Cloud Service Mesh 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 Cloud Service Mesh avec des applications gRPC sans proxy pour introduire des services à vos applications gRPC.

Maillage de services hétérogène

Étant donné que les applications gRPC sans proxy et Envoy communiquent avec Cloud Service Mesh, votre maillage de services peut inclure les deux modèles de déploiement. Inclure les deux modèles vous permet de répondre aux exigences opérationnelles, les performances, ainsi que les besoins en fonction des différentes applications et 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 Si Cloud Service Mesh est configuré, 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 pour fournir des fonctionnalités 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éer un service Cloud Service Mesh utilisé par votre client gRPC sans proxy. Vous pouvez utiliser les mêmes API pour configurer Cloud Service Mesh 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 comportant 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 Modèle de configuration Cloud Service Mesh, avec quelques ajouts et limites décrits dans ce guide. Certaines de ces limitations sont temporaires car gRPC sans proxy n'est pas compatible avec toutes les fonctionnalités d'Envoy, entre 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 Cloud Service Mesh.

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)

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 Cloud Service Mesh, le schéma d'équilibrage de charge 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