Détection de services
Cloud Service Mesh permet la détection de services et de points de terminaison. Ces fonctionnalités vous permettent de regrouper les instances de machines virtuelles (VM) et de conteneurs exécuter votre code en tant que points de terminaison de vos services.
Cloud Service Mesh surveille ces services afin de pouvoir partager des informations à jour sur la vérification de l'état avec ses clients. Par conséquent, lorsqu'une de vos applications utilise son client Cloud Service Mesh (par exemple, un proxy side-car Envoy ou une application gRPC sans proxy) pour envoyer une requête, elle bénéficie d'informations à jour sur vos services.
Dans le contexte de Cloud Service Mesh, un client est le code d'application qui s'exécute sur une VM ou un conteneur qui formule des requêtes à envoyer à un serveur. A server est le code d'application qui reçoit de telles requêtes. Un client Cloud Service Mesh est un client Envoy ou gRPC, ou tout autre client xDS qui est connecté à Cloud Service Mesh et fait partie du plan de données.
Dans le plan de données, Envoy ou gRPC effectue les opérations suivantes :
- Il examine une requête et la fait correspondre à un service de backend, une ressource que vous configurez lors du déploiement.
- Une fois la requête mise en correspondance, Envoy ou gRPC applique les règles de trafic ou de sécurité précédemment configurées, choisit un backend ou un point de terminaison, puis dirige la requête vers ce backend ou ce point de terminaison.
Détection de services
Cloud Service Mesh fournit la découverte de services. Lorsque vous configurez vous créez des services de backend. Vous définissez également des règles de routage spécifiant la manière dont une requête sortante (requête envoyée par votre code d'application et gérée par un client Cloud Service Mesh) est associée à un service particulier. Lorsqu'un client Cloud Service Mesh gère une requête qui correspond à une règle, il peut choisir le service qui doit recevoir la requête.
Exemple :
- Une VM exécute votre application. Cette VM dispose d'un proxy side-car Envoy connecté à Cloud Service Mesh et qui gère les requêtes sortantes pour le compte de l'application.
- Vous avez configuré un service de backend nommé
payments
. Ce service de backend comporte deux backends de groupe de points de terminaison du réseau (NEG) qui pointent vers différentes instances de conteneur exécutant le code de votre servicepayments
. - Vous avez configuré une ressource
Mesh
définissant un maillage appelésidecar-mesh
. - Vous avez configuré une ressource
Route
qui définit les destinations du trafic pour le service de backendpayments
et le nom d'hôtehelloworld-gce
.
Avec cette configuration, lorsque votre application (sur la VM) envoie une requête HTTP
à payments.example.com
, le client Cloud Service Mesh sait que
cette requête est destinée au service payments
.
Lorsque vous utilisez Cloud Service Mesh avec des services gRPC sans proxy, la détection de services fonctionne de la même manière. Cependant, une bibliothèque gRPC agissant en tant que client Cloud Service Mesh ne récupère des informations que sur les services pour lesquels vous spécifiez un résolveur xDS. Par défaut, Envoy récupère les informations sur tous les services configurés sur le réseau cloud privé virtuel (VPC) spécifié dans le fichier d'amorçage Envoy.
Détection de points de terminaison
La détection de services permet aux clients de connaître vos services. La détection des points de terminaison permet aux clients de connaître les instances qui exécutent votre code.
Lorsque vous créez un service, vous spécifiez également les backends de ce service. Ces backends sont des VM dans des groupes d'instances gérés (MIG) ou des conteneurs dans des NEG. Cloud Service Mesh surveille ces MIG et NEG afin qu'il sait quand les instances et les points de terminaison sont créés et supprimés.
Cloud Service Mesh partage en permanence des informations à jour sur ces services avec ses clients. Cela permet aux clients d'éviter d'envoyer du trafic vers des points de terminaison qui n'existent plus. Cela permet également aux clients d'en savoir plus sur les nouveaux points de terminaison et de bénéficier de la capacité supplémentaire fournie par ces points de terminaison.
Au-delà de l'ajout de points de terminaison dans des MIG ou des NEG, et de la configuration de Cloud Service Mesh, vous n'avez besoin d'aucune configuration supplémentaire pour activer la détection de services avec Cloud Service Mesh.
Interception du trafic proxy side-car dans Cloud Service Mesh
Cloud Service Mesh est compatible avec le modèle de proxy side-car. Dans le cadre de ce modèle, application envoie du trafic vers sa destination, le trafic est intercepté et l'a redirigée vers un port du proxy side-car de l'hôte où l'application est en cours d'exécution. Le proxy side-car décide comment équilibrer la charge du trafic, puis l'envoie à sa destination.
Avec Cloud Service Mesh et les API de routage de service, l'interception du trafic est sont gérées automatiquement.
Étape suivante
- Pour savoir comment Cloud Service Mesh fournit un équilibrage de charge global pour vos microservices internes à l'aide de proxys side-car, consultez la page Équilibrage de charge Cloud Service Mesh.
- Pour en savoir plus sur Cloud Service Mesh, consultez la Présentation de Cloud Service Mesh