Équilibrage de charge Cloud Service Mesh

Cloud Service Mesh utilise des proxys side-car ou gRPC sans proxy pour transmettre la charge globale pour vos microservices internes. Vous pouvez déployer des microservices internes (basés sur un proxy side-car ou gRPC sans proxy) avec des instances situées dans plusieurs régions. Cloud Service Mesh fournit des informations sur l'état, le routage et le backend les proxys side-car ou gRPC sans proxy, ce qui leur permet d'optimiser le trafic le routage vers des instances d'application dans plusieurs régions cloud pour un service.

Dans le schéma suivant, le trafic utilisateur entre dans un déploiement Google Cloud via un équilibreur de charge global externe. L'équilibreur de charge externe distribue le trafic vers le microservice Front End us-central1 ou asia-southeast1, selon la zone géographique de l'utilisateur final.

Le déploiement interne comprend trois microservices mondiaux : Front End, Shopping Cart et Payments. Chaque service s'exécute sur des groupes d'instances gérés (MIG) dans deux régions, us-central1 et asia-southeast1. Cloud Service Mesh utilise une couche d'équilibrage de charge qui dirige le trafic de l'utilisateur situé en Californie vers microservices déployés dans la région us-central1. Les requêtes de l'utilisateur à Singapour sont dirigées vers les microservices de asia-southeast1.

La requête entrante d'un utilisateur est acheminée vers le microservice Front End. Le proxy de service installé sur l'hôte avec Front End dirige ensuite le trafic vers le microservice Shopping Cart. Le proxy de service installé sur l'hôte avec Shopping Cart achemine le trafic vers le microservice Payments. Dans un environnement gRPC sans proxy, votre application gRPC gère le trafic.

<ph type="x-smartling-placeholder">
</ph> Cloud Service Mesh dans un déploiement d&#39;équilibrage de charge global.
Cloud Service Mesh dans un déploiement d'équilibrage de charge global (cliquez pour agrandir)

Dans l'exemple suivant, si Cloud Service Mesh reçoit les résultats de la vérification de l'état'état indiquant que les instances de machine virtuelle (VM) exécutant le panier microservices dans us-central1 ne sont pas opérationnels, Cloud Service Mesh indique au un proxy side-car permettant aux microservices Front End de basculer le trafic vers Microservice de panier s'exécutant dans asia-southeast1. Comme l'autoscaling est intégré à la gestion du trafic dans Google Cloud, Cloud Service Mesh informe le MIG du trafic supplémentaire dans la région asia-southeast1, et le MIG augmente en taille.

Cloud Service Mesh détecte que tous les backends du microservice Payments sont opérationnel. Ainsi, Cloud Service Mesh demande au proxy Envoy du panier d'achat de d'envoyer une partie du trafic (jusqu'à la valeur la capacité : à asia-southeast1 et le reste à us-central1.

<ph type="x-smartling-placeholder">
</ph> Basculement avec Cloud Service Mesh dans un déploiement d&#39;équilibrage de charge mondial.
Basculement avec Cloud Service Mesh dans un déploiement d'équilibrage de charge global (cliquez pour agrandir)

Composants d'équilibrage de charge dans Cloud Service Mesh

Lors de la configuration de Cloud Service Mesh, vous configurez plusieurs équilibrages de charge composants:

  • Le service de backend, qui contient les valeurs de configuration.
  • Une vérification de l'état, qui fournit une vérification de l'état pour les VM et les pods Google Kubernetes Engine (GKE) dans votre déploiement.
  • Avec les API de routage des services, une ressource Mesh ou Gateway et une ressource Route.
  • Avec les API d'équilibrage de charge, une règle de transfert globale, qui inclut le service une adresse IP virtuelle, un proxy cible et un mappage d'URL.

Un proxy side-car compatible avec l'API xDS (tel qu'Envoy) s'exécute sur un client une instance de VM ou un pod Kubernetes. Cloud Service Mesh sert de service de contrôle et utilise des API xDS pour communiquer directement avec chaque proxy. Dans les données l'application envoie du trafic à l'adresse IP virtuelle configurée dans une règle de transfert ou une ressource Mesh. Le proxy side-car ou votre application gRPC intercepte le trafic et le redirige vers le backend approprié.

Le schéma suivant illustre une application s'exécutant sur des VM Compute Engine ou les pods GKE, les composants et le flux de trafic Déploiement de Cloud Service Mesh Elle montre Cloud Service Mesh et Ressources Cloud Load Balancing permettant de déterminer le routage du trafic. Le schéma illustre les anciennes API d'équilibrage de charge.

<ph type="x-smartling-placeholder">
</ph> Ressources Cloud Service Mesh à configurer.
Ressources Cloud Service Mesh à configurer (cliquez pour agrandir)

Étape suivante