Présentation de Cloud Service Mesh
Ce document s'adresse aux administrateurs réseau et aux propriétaires de services qui souhaitent se familiariser avec Cloud Service Mesh et ses fonctionnalités. Cet ancien document 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 fournir des services mondiaux à disponibilité élevée avec des fonctionnalités avancées de mise en réseau d'applications, telles que la gestion du trafic et l'observabilité.
À 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 déploiement moderne basé sur les services. Cloud Service Mesh repose sur l'infrastructure gérée par Google Cloud, de sorte que vous n'avez pas à gérer votre propre infrastructure. Vous vous concentrez sur l'envoi de code d'application qui résout vos problèmes métier tout en laissant Cloud Service Mesh 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 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 faces 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 du code de votre 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.
En quoi Cloud Service Mesh est différent
Cloud Service Mesh fonctionne de la même manière que ce modèle, mais présente des différences importantes. Tout commence par le fait que 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. Ce cluster Kubernetes comporte quatre services, chacun avec 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 accepte plus de types de déploiements qu'un maillage de services classique.
Kubernetes multicluster
Avec Cloud Service Mesh, vous bénéficiez d'une mise en réseau d'applications qui fonctionne sur les clusters Kubernetes. Dans le schéma suivant, Cloud Service Mesh fournit le plan de contrôle pour les clusters Kubernetes dans 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 à 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 permet également de mettre en réseau les 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 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 intégrer des fonctionnalités de mise en réseau d'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 page 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 que celles utilisées par Envoy.
Une fois vos applications connectées, la bibliothèque gRPC se charge 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 sont exécutées de manière native dans gRPC. Les proxys de service ne sont donc pas nécessaires. C'est pourquoi ils sont appelés 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 active 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 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 de l'Internet public atteignent vos services via l'équilibreur de charge d'application externe. Les clients, tels que les microservices résidant sur votre réseau cloud privé virtuel (VPC), utilisent un équilibreur de charge d'application interne pour accéder à vos services.
Dans certains cas d'utilisation, vous pouvez 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 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, exécuté 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 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 tout à 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 une infrastructure réseau d'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 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 l'infrastructure réseau de votre application.
L'infrastructure gère la mise en réseau des applications
Lorsqu'une application envoie une requête à my-service, son infrastructure réseau (par exemple, un proxy side-car Envoy) gère 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éé. Sur la base de ces informations, Cloud Service Mesh met à jour en continu l'infrastructure de mise en réseau de vos applications.
Fonctionnalités
Les fonctionnalités de Cloud Service Mesh fournissent des capacités de mise en réseau d'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 les projets Open Source courants tels qu'Envoy et Istio. Pour afficher les versions d'API compatibles, consultez les API du plan de contrôle xDS.
L'infrastructure qui fournit des fonctionnalités de mise en réseau d'applications (Envoy ou gRPC, selon votre cas d'utilisation) est également Open Source. Vous n'avez donc pas à craindre d'être dépendant d'une infrastructure propriétaire.
Échelle
Des solutions ponctuelles de mise en réseau d'applications aux déploiements massifs de maillage de services avec 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 les adresses IP, les protocoles ou les autres complexités du réseau.
Équilibrage de charge global et basculement
Cloud Service Mesh utilise l'équilibrage de charge mondial et les vérifications d'état de Google pour équilibrer de façon optimale le trafic en fonction de l'emplacement du client et du backend, de la proximité, de l'état et de la capacité du backend. Pour améliorer la disponibilité de vos services, faites basculer automatiquement le trafic vers des backends opérationnels avec une capacité suffisante. 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 circulation du trafic 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 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 qui protègent les ressources et les services (tels que 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.
Étapes suivantes
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 service.
- 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 est compatible avec les environnements qui s'étendent au-delà de Google Cloud, consultez les documents suivants:
- Intégration de Cloud Service Mesh à l'Annuaire des services
- Cloud Service Mesh avec groupes de points de terminaison du réseau à connectivité hybride (anciennes API uniquement)
- Cloud Service Mesh avec groupes de points de terminaison du réseau Internet (anciennes API uniquement)