Présentation de Cloud Service Mesh
Ce document est destiné aux administrateurs réseau et aux propriétaires de services qui souhaitent se familiariser avec Cloud Service Mesh et ses fonctionnalités. Il s'agit d'un ancien document qui s'applique aux configurations utilisant les API d'équilibrage de charge.
Cloud Service Mesh est un plan de contrôle géré pour la mise en réseau des applications. Cloud Service Mesh vous permet de proposer des services mondiaux à disponibilité élevée et dotés de capacités avancées de mise en réseau des applications, telles que la gestion et l'observabilité du trafic.
À mesure que le nombre de services et de microservices dans votre déploiement augmente, vous commencez généralement à rencontrer des problèmes courants de mise en réseau des applications, tels que les suivants :
- Comment rendre mes services résilients ?
- Comment générer du trafic vers mes services, et comment les services se connaissent-ils et communiquent-ils entre eux ?
- Comment comprendre ce qui se passe lorsque mes services communiquent entre eux ?
- Comment mettre à jour mes services sans risquer une panne ?
- Comment gérer l'infrastructure qui permet mon déploiement ?
Cloud Service Mesh vous aide à résoudre ces types de défis lors d'un déploiement moderne basé sur les services. Cloud Service Mesh repose sur une infrastructure gérée par Google Cloud. Vous n'avez donc pas besoin de gérer votre propre infrastructure. Vous vous concentrez sur la fourniture du code d'application qui résout les problèmes de votre entreprise tout en laissant Cloud Service Mesh gérer les complexités de la mise en réseau des applications.
Cloud Service Mesh
Pour résoudre les problèmes de mise en réseau des applications, une approche classique consiste à utiliser un maillage de services. Cloud Service Mesh est compatible avec le maillage de services et d'autres modèles de déploiement qui répondent à vos besoins.
Dans un maillage de services type, les conditions suivantes s'appliquent :
- Vous déployez vos services sur un cluster Kubernetes.
- Chaque pod des services dispose d'un proxy dédié (généralement Envoy) qui s'exécute en tant que proxy side-car.
- Chaque proxy side-car communique avec l'infrastructure de mise en réseau (plan de contrôle) installée dans votre cluster. Le plan de contrôle fournit aux proxys side-car des informations sur les services, les points de terminaison et les règles de votre maillage de services.
- Lorsqu'un pod envoie ou reçoit une requête, celle-ci est transmise au proxy side-car du pod. Le proxy side-car traite la requête, par exemple en l'envoyant à la destination voulue.
Dans les schémas de ce document et d'autres documents Cloud Service Mesh, les icônes roses à six côtés représentent les proxys. Le plan de contrôle est connecté à chaque proxy et fournit les informations dont les proxys ont besoin pour traiter les requêtes. Les flèches entre les zones indiquent les flux de trafic. Par exemple, le code d'application du Service A envoie une requête. Le proxy traite la requête et la transmet au Service B.
Ce modèle vous permet de retirer la logique de mise en réseau de votre code d'application. Vous pouvez vous concentrer sur la création de valeur ajoutée tout en laissant votre infrastructure s'occuper de la mise en réseau des applications.
Différences entre Cloud Service Mesh et les autres solutions
Cloud Service Mesh fonctionne de la même manière que ce modèle, mais il présente des différences importantes. Pour commencer, Cloud Service Mesh est un service géré par Google Cloud. Vous ne l'installez pas, il ne s'exécute pas dans votre cluster et vous n'avez pas besoin de le gérer.
Dans le schéma suivant, Cloud Service Mesh est le plan de contrôle. Le cluster Kubernetes comprend quatre services, chacun ayant des proxys side-car connectés à Cloud Service Mesh. Cloud Service Mesh fournit les informations dont les proxys ont besoin pour acheminer les requêtes. Par exemple, le code d'application sur un pod appartenant au Service A envoie une requête. Le proxy side-car exécuté avec ce pod traite la requête et l'achemine vers un pod appartenant au Service B.
Au-delà du maillage de services
Cloud Service Mesh est compatible avec plus de types de déploiements qu'un maillage de services type.
Kubernetes multicluster
Avec Cloud Service Mesh, vous bénéficiez d'une mise en réseau des applications qui fonctionne sur plusieurs clusters Kubernetes. Dans le schéma suivant, Cloud Service Mesh fournit le plan de contrôle des clusters Kubernetes dans les régions us-central1 et europe-west1.
Les requêtes peuvent être acheminées entre les trois services de la région us-central1, entre les deux services de la région europe-west1 et entre les services des deux clusters.
Votre maillage de services peut s'étendre sur plusieurs clusters Kubernetes, situés dans plusieurs régions Google Cloud. Les services d'un cluster peuvent communiquer avec ceux d'un autre cluster. Vous pouvez même avoir des services composés de pods de plusieurs clusters.
Avec l'équilibrage de charge global basé sur la proximité de Cloud Service Mesh, les requêtes destinées au Service B sont dirigées vers le pod le plus proche pouvant répondre à la requête. Vous bénéficiez également d'un basculement fluide : si un pod tombe en panne, la requête bascule automatiquement vers un autre pod pouvant diffuser dans la requête, même si ce pod se trouve dans un autre cluster Kubernetes.
Machines virtuelles
Kubernetes est de plus en plus populaire, mais de nombreuses charges de travail sont déployées sur des instances de machines virtuelles (VM). Cloud Service Mesh résout également les problèmes de mise en réseau des applications pour ces charges de travail ; vos charges de travail basées sur des VM interagissent avec vos charges de travail basées sur Kubernetes.
Dans le schéma suivant, le trafic entre dans votre déploiement via l'équilibreur de charge d'application externe. Il est acheminé vers le Service A dans le cluster Kubernetes de la région asia-southeast1 et vers le Service D sur une VM de la région europe-west1.
Google fournit un mécanisme simple pour configurer les charges de travail basées sur des VM avec Cloud Service Mesh. Il vous suffit d'ajouter une option à votre modèle d'instance de VM Compute Engine et Google gère la configuration de l'infrastructure. Cela inclut l'installation et la configuration des proxys fournissant des capacités de mise en réseau des applications.
Services gRPC sans proxy
gRPC est un framework RPC Open Source et riche en fonctionnalités qui vous permet d'écrire des microservices hautes performances. Avec Cloud Service Mesh, vous pouvez intégrer des capacités de mise en réseau des applications (telles que la détection de services, l'équilibrage de charge et la gestion du trafic) à vos applications gRPC. Pour en savoir plus, consultez la section Cloud Service Mesh et gRPC : services sans proxy pour votre maillage de services.
Dans le schéma suivant, les applications gRPC acheminent le trafic vers des services basés sur des clusters Kubernetes dans une région et vers des services s'exécutant sur des VM dans différentes régions. Deux des services incluent des proxys side-car et d'autres sont sans proxy.
Cloud Service Mesh est compatible avec les services gRPC sans proxy. Ces services utilisent une version récente de la bibliothèque gRPC Open Source compatible avec les API xDS. Vos applications gRPC peuvent se connecter à Cloud Service Mesh à l'aide des mêmes API xDS qu'Envoy.
Une fois qu'elles sont connectées, la bibliothèque gRPC s'occupe des fonctions de mise en réseau des applications telles que la détection de services, l'équilibrage de charge et la gestion du trafic. Ces fonctions s'effectuent de manière native dans gRPC. Par conséquent, les proxys de service ne sont pas nécessaires, d'où l'appellation "applications gRPC sans proxy.
Entrée et passerelles
Dans de nombreux cas d'utilisation, vous devez [gérer le trafic provenant de clients non configurés par Cloud Service Mesh. Par exemple, vous devrez peut-être acheminer le trafic Internet public vers vos microservices. Vous pourriez aussi configurer un équilibreur de charge en tant que proxy inverse qui gère le trafic d'un client avant de l'envoyer à une destination.
Dans le schéma suivant, un équilibreur de charge d'application externe permet l'entrée pour les clients externes, le trafic étant acheminé vers les services d'un cluster Kubernetes. Un équilibreur de charge d'application interne achemine le trafic interne vers le service s'exécutant sur la VM.
Cloud Service Mesh fonctionne avec Cloud Load Balancing pour offrir une expérience d'entrée gérée. Configurez un équilibreur de charge externe ou interne, puis configurez-le pour envoyer du trafic vers vos microservices. Dans le schéma précédent, les clients Internet publics atteignent vos services via l'équilibreur de charge d'application externe. Les clients, tels que les microservices résidant sur votre réseau de cloud privé virtuel (VPC), accèdent à vos services à l'aide d'un équilibreur de charge d'application interne.
Dans certains cas d'utilisation, il se peut que vous souhaitiez configurer Cloud Service Mesh pour configurer une passerelle. Une passerelle est essentiellement un proxy inverse, généralement Envoy, qui s'exécute sur une ou plusieurs VM, écoute les requêtes entrantes, les traite et les envoie à une destination. La destination peut se trouver dans n'importe quelle région Google Cloud ou n'importe quel cluster Google Kubernetes Engine (GKE). Il peut même s'agir d'une destination externe à Google Cloud, accessible depuis Google Cloud à l'aide de la connectivité hybride. Pour savoir quand utiliser une passerelle, consultez la section Trafic entrant pour votre réseau maillé.
Dans le schéma suivant, une VM de la région europe-west1 exécute un proxy qui sert de passerelle vers trois services n'exécutant pas de proxys. Le trafic provenant à la fois d'un équilibreur de charge d'application externe et d'un équilibreur de charge d'application interne est acheminé vers la passerelle, puis vers les trois services.
Environnements multiples
Que vos services se trouvent dans Google Cloud, sur site, dans d'autres clouds ou dans tous ces emplacements, les principaux problèmes que vous rencontrez en termes de mise en réseau des applications restent les mêmes. Comment générer du trafic vers ces services ? Comment ces services communiquent-ils entre eux ?
Dans le schéma suivant, Cloud Service Mesh achemine le trafic des services exécutés dans Google Cloud vers le Service G, qui s'exécute dans un autre cloud public, et vers le Service E et le Service F, tous deux exécutés dans un centre de données sur site.
Le Service A, le Service B et le Service C, utilisent Envoy comme proxy side-car, tandis que le Service D est un service gRPC sans proxy.
Lorsque vous utilisez Cloud Service Mesh, vous pouvez envoyer des requêtes à des destinations situées en dehors de Google Cloud. Cela vous permet d'utiliser Cloud Interconnect ou Cloud VPN pour acheminer le trafic de manière privée depuis les services dans Google Cloud vers des services ou des passerelles dans d'autres environnements.
Configurer Cloud Service Mesh
La configuration de Cloud Service Mesh comprend deux étapes. Une fois le processus de configuration terminé, votre infrastructure gère la mise en réseau des applications, et Cloud Service Mesh maintient toutes les informations à jour en fonction des modifications apportées à votre déploiement.
Déployer les applications
Commencez par déployer votre code d'application sur des conteneurs ou des VM. Google fournit des mécanismes qui vous permettent d'ajouter facilement une infrastructure de mise en réseau des applications (généralement des proxys Envoy) à vos instances de VM et vos pods. Cette infrastructure est configurée pour communiquer avec Cloud Service Mesh et recueillir des informations sur vos services.
Configurer Cloud Service Mesh
Ensuite, configurez vos services globaux et définissez la manière dont le trafic doit être géré. Pour configurer Cloud Service Mesh, vous pouvez utiliser la console Google Cloud (pour certaines fonctionnalités et configurations), Google Cloud CLI, l'API Traffic Director ou d'autres outils, tels que Terraform.
Une fois ces étapes terminées, Cloud Service Mesh est prêt à configurer votre infrastructure de mise en réseau des applications.
L'infrastructure gère la mise en réseau des applications
Lorsqu'une application envoie une requête à my-service, l'infrastructure de mise en réseau des applications (par exemple, un proxy side-car Envoy) traite la requête en fonction des informations reçues de Cloud Service Mesh. Cela permet d'acheminer de manière fluide une requête pour my-service vers une instance d'application capable de la recevoir.
Surveillance et mises à jour continues
Cloud Service Mesh surveille les instances d'application qui constituent vos services. Cette surveillance permet à Cloud Service Mesh de détecter qu'un service est opérationnel ou que la capacité d'un service a changé, par exemple lorsqu'un pod Kubernetes est créé. À partir de ces informations, Cloud Service Mesh met à jour en continu votre infrastructure de mise en réseau des applications.
Fonctionnalités
Les fonctionnalités de Cloud Service Mesh fournissent des capacités de mise en réseau des applications à vos microservices. Cette section aborde des points importants.
Plan de contrôle entièrement géré, vérification de l'état et équilibrage de charge
Vous souhaitez vous consacrer à la création de valeur ajoutée plutôt qu'à la gestion de l'infrastructure. Cloud Service Mesh est une solution entièrement gérée. Vous n'avez donc pas besoin d'installer, de configurer ni de mettre à jour l'infrastructure. Vous bénéficiez de la même infrastructure que celle utilisée par Google pour la vérification de l'état et l'équilibrage de charge global.
Basé sur des produits Open Source
Cloud Service Mesh utilise le même plan de contrôle (API xDS) que des projets Open Source populaires tels que Envoy et Istio. Pour afficher les versions d'API compatibles, consultez la page API de plan de contrôle xDS.
L'infrastructure qui fournit les capacités de mise en réseau des applications (Envoy ou gRPC, selon votre cas d'utilisation) est également Open Source. Vous n'avez donc pas à craindre de vous retrouver prisonnier d'une infrastructure propriétaire.
Échelle
Qu'il s'agisse de solutions uniques de mise en réseau des applications ou de déploiements massifs de maillages de services comportant des milliers de services, Cloud Service Mesh est conçu pour répondre à vos exigences de scaling.
Détection de services et suivi des points de terminaison et des backends
Lorsque votre application envoie une requête à my-service, votre infrastructure gère la requête de manière transparente et l'envoie à la bonne destination. Votre application n'a besoin d'aucune information sur les adresses IP, les protocoles ou d'autres complexités de la mise en réseau.
Équilibrage de charge global et basculement
Cloud Service Mesh utilise l'équilibrage de charge global et la vérification d'état de Google pour équilibrer le trafic de manière optimale en fonction de l'emplacement du client et du backend, de la proximité du backend, de son état et de sa capacité. Vous améliorez la disponibilité du service en permettant au trafic de basculer automatiquement vers des backends opérationnels disposant de la capacité nécessaire. Vous pouvez personnaliser l'équilibrage de charge pour distribuer le trafic afin de répondre correctement aux besoins de votre entreprise.
Gestion du trafic
La gestion avancée du trafic, y compris le routage et la manipulation des requêtes (en fonction du nom d'hôte, du chemin d'accès, des en-têtes, des cookies, etc.), vous permet de déterminer la manière dont le trafic circule entre vos services. Vous pouvez également appliquer des actions telles que de nouvelles tentatives d'exécution, des redirections et une répartition du trafic en fonction d'une pondération pour les déploiements Canary. Des modèles avancés, tels que l'injection de pannes, la mise en miroir du trafic et la détection d'anomalies, permettent des cas d'utilisation du DevOps qui améliorent votre résilience.
Observabilité
Votre infrastructure de mise en réseau des applications collecte des informations de télémétrie, telles que des métriques, des journaux et des traces, qui peuvent être agrégées de manière centralisée dans Google Cloud Observability. Une fois ces informations collectées, vous pouvez dégager des insights et créer des alertes afin d'être informé en cas de problème.
VPC Service Controls
VPC Service Controls permet de renforcer la sécurité des ressources et des services de votre application. Vous pouvez ajouter des projets aux périmètres de service afin de protéger les ressources et les services (comme Cloud Service Mesh) des requêtes provenant de l'extérieur du périmètre. Pour en savoir plus sur VPC Service Controls, consultez la page Présentation de VPC Service Controls.
Pour en savoir plus sur l'utilisation de Cloud Service Mesh avec VPC Service Controls, consultez la page Produits compatibles.
Étape suivante
Il s'agit d'un ancien document qui s'applique principalement aux API d'équilibrage de charge. Nous vous recommandons vivement de ne pas configurer Cloud Service Mesh à l'aide des API d'équilibrage de charge.
Pour déployer Cloud Service Mesh:
- Pour Compute Engine avec des VM, utilisez les API de routage de services.
- Pour Google Kubernetes Engine avec des pods, utilisez les API Gateway.
Pour découvrir les cas d'utilisation et les modèles d'architecture applicables aux services gRPC sans proxy, consultez la page Présentation des services gRPC sans proxy.
Pour en savoir plus sur la manière de gérer le trafic, consultez la page Présentation de la gestion avancée du trafic.
Pour savoir comment Cloud Service Mesh assure la compatibilité avec des environnements qui vont au-delà de Google Cloud, consultez les documents suivants: