Présentation de Cloud Service Mesh
Ce document s'adresse aux administrateurs réseau et aux propriétaires de services qui souhaitent à vous 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 d'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 problèmes dans un environnement un déploiement basé sur les services. Cloud Service Mesh s'appuie sur des services gérés par Google Cloud de l'infrastructure afin que vous n'ayez pas à gérer votre propre infrastructure. Toi concentrez-vous sur l'envoi de code d'application qui résout vos problèmes métier tout en ce qui permet à Cloud Service Mesh de gérer la complexité 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 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. Il y a quatre
de ce cluster Kubernetes, chacun avec des proxys side-car
connecté à 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, la mise en réseau d'applications fonctionne
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 la mise en réseau des applications pour ces charges de travail ; vos charges de travail basées sur des VM interagissent pour vos charges de travail basées sur Kubernetes.
Dans le schéma suivant, le trafic entre dans votre déploiement via le
un é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 des 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 utiliser des fonctionnalités (détection de services, équilibrage de charge et gestion du trafic, par exemple) à vos applications gRPC. Pour en savoir plus, consultez 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 vos applications connectées, la bibliothèque gRPC se charge des fonctions de mise en réseau d'applications (détection de services, é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 qui ne sont pas configurées 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 active l'entrée pour des ressources avec des clients, le trafic étant acheminé vers les services d'un cluster Kubernetes. Une un équilibreur de charge d'application interne achemine le trafic interne vers le service exécuté sur la VM.
Cloud Service Mesh fonctionne avec Cloud Load Balancing pour fournir 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 un consultez la section Trafic d'entrée 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 Service G, qui s'exécute dans un autre cloud public, et vers Service E et 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. Après avoir effectué processus de configuration, votre infrastructure gère la mise en réseau des applications Cloud Service Mesh maintient tous les éléments à jour en fonction des modifications apportées à votre le déploiement.
Déployer les applications
Commencez par déployer votre code d'application sur des conteneurs ou des VM. Google fournit qui vous permettent d'ajouter une infrastructure réseau (généralement des proxys Envoy) à vos instances de VM et à vos pods. Cette infrastructure pour communiquer avec Cloud Service Mesh et en savoir plus 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 de mise en réseau d'applications.
L'infrastructure gère la mise en réseau des applications
Lorsqu'une application envoie une requête à my-service, la mise en réseau de votre application
infrastructure (un proxy side-car Envoy, par exemple) gère la requête
d'après les 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, ce qui vous évite d'avoir à installer, configurer ou 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 les projets Open Source populaires comme Envoy et d'Istio. Pour afficher les versions d'API compatibles, consultez la page API de plan de contrôle xDS.
L'infrastructure qui fournit la mise en réseau d'applications (Envoy ou gRPC) en fonction de votre cas d'utilisation, est également Open Source. Vous n'avez donc pas à vous soucier de la dépendance vis-à-vis 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 pas besoin de connaître
Adresses IP, protocoles ou autres complexités 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 répartir le trafic afin de répondre 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 d'applications collecte des informations de télémétrie, telles que (métriques, journaux et traces), qui peuvent être agrégés de manière centralisée Observabilité Google Cloud. 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 :