Présentation des API de routage de service Cloud Service Mesh

Remarque :Ce guide n'est compatible qu'avec Cloud Service Mesh avec les API Google Cloud et non avec les API Istio. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Ce document est destiné aux administrateurs de maillage ou de plate-forme et aux développeurs de services qui connaissent bien ou très bien les concepts de Cloud Service Mesh et de maillage de services, et qui déploient Cloud Service Mesh sur Compute Engine avec des instances de VM. Ce document s'applique aux déploiements utilisant des clients Envoy et gRPC. Pour en savoir plus sur les concepts de Cloud Service Mesh, consultez la présentation générale.

Cloud Service Mesh fournit à vos applications des fonctionnalités de mise en réseau de services, telles que la gestion avancée du trafic, l'observabilité et la sécurité. Cependant, la configuration et l'exploitation d'un maillage de services est une tâche complexe pour les administrateurs de maillage et les développeurs de services.

Ce document décrit les API de routage de services pour configurer Cloud Service Mesh. Ces API sont conçues pour simplifier et améliorer votre expérience de configuration globale du maillage.

Le modèle de routage de service utilise des ressources d'API appelées Mesh, Gateway et Route. Ces ressources fournissent une expérience de configuration plus pertinente en fonction du contexte lorsque vous définissez votre plan de contrôle de mise en réseau de services.

Ce document présente le modèle et les ressources de l'API de routage de services suivant.

• Ressource Mesh
  • Gestion du trafic de service à service (est-ouest) et configuration de la sécurité pour les proxys side-car Envoy et les clients gRPC sans proxy

• Ressource Gateway

  • Gestion du trafic et configuration de la sécurité pour les proxys Envoy agissant en tant que passerelles d'entrée, permettant aux clients externes de se connecter au maillage de services (Nord-Sud).

• Ressources Route des types suivants:

  • HTTPRoute
  • GRPCRoute
  • TCPRoute
  • TLSRoute

La console Google Cloud n'est pas compatible avec les API de routage de service. Vous devez implémenter ces ressources d'API à l'aide de Google Cloud CLI ou des API REST.

Cas d'utilisation et avantages

Les API de routage de services vous permettent de configurer Cloud Service Mesh pour les déploiements de gRPC sans proxy et proxy Envoy. Le modèle d'API de routage de service offre plusieurs avantages essentiels.

Dans le schéma suivant, deux services du maillage de services sont connectés par une ressource Mesh. Les deux ressources HTTPRoute configurent le routage. L'administrateur du maillage ou de la plate-forme gère la ressource Mesh et les deux propriétaires de service créent la configuration de routage pour leurs services.

Trafic de service à service est-ouest dans un maillage de services (cliquez pour agrandir)

La conception d'API orientées rôles permet de séparer clairement les responsabilités

Les API de routage de services vous permettent de séparer les responsabilités de configuration du maillage en fonction des rôles de l'organisation:

• Les administrateurs de maillage peuvent définir le maillage logique ainsi que l'infrastructure de la passerelle d'entrée.
• Les propriétaires de service (développeurs d'applications) peuvent définir indépendamment des modèles d'accès pour leurs services. Ils peuvent également définir et appliquer des règles de gestion du trafic à leurs services.

Dans le schéma suivant, Cloud Load Balancing et une ressource Gateway fournissent une passerelle d'entrée pour le trafic entrant dans le maillage depuis un client qui ne se trouve pas dans le maillage. L'administrateur du maillage configure et gère la ressource Gateway, tandis que les propriétaires de service configurent et gèrent leurs propres services et le routage du trafic.

Trafic nord-sud dans le maillage via une passerelle (cliquez pour agrandir)

Fiabilité améliorée avec un modèle en libre-service

Les API de routage de service utilisent des ressources par protocole et par route pouvant être configurées et détenues par des propriétaires de service indépendants. Cette approche présente plusieurs avantages.

• Les propriétaires de services disposent d'une certaine autonomie sur la manière dont ils souhaitent configurer les règles et la gestion du trafic pour les services dont ils sont propriétaires.
• La mise à jour d'une ressource Route n'a pas d'incidence sur les autres ressources Route du maillage. Le processus de mise à jour est plus fiable, car les propriétaires de service gèrent de petites configurations.
• Le propriétaire du service responsable du nom d'hôte ou du service de destination possède chaque ressource Route.
• Les propriétaires de service n'ont pas besoin de dépendre des administrateurs de maillage pour mettre à jour le routage.

Activer un maillage de services couvrant plusieurs projets dans des environnements VPC partagés

Le modèle d'API de routage de service permet aux propriétaires de services de participer à une infrastructure maillée partagée à l'aide de VPC partagés et d'autres moyens de connectivité, tout en conservant un contrôle indépendant de leurs services. Par exemple, les propriétaires de service peuvent définir les ressources Route dans leurs propres projets. Les administrateurs de plate-forme peuvent définir un Mesh dans un projet hôte géré de manière centralisée, puis accorder aux propriétaires de services les autorisations IAM pour associer leurs ressources Route à une ressource Mesh ou Gateway partagée. Le schéma suivant montre un exemple utilisant un VPC partagé.

Référence multiprojet avec un VPC partagé (cliquez pour agrandir)

Les API de routage de services vous permettent également de connecter des clients de maillage de services à différents réseaux à l'aide de l'appairage de réseaux VPC.

Acheminer le trafic en fonction de l'indicateur du nom de serveur

La ressource TLSRoute vous permet d'acheminer le trafic chiffré en TLS en fonction de l'indication du nom du serveur (SNI) dans le handshake TLS. Vous pouvez configurer le routage du trafic TLS vers les services de backend appropriés en configurant la correspondance SNI dans la ressource TLSRoute. Dans ces déploiements, les proxys n'acheminent que le trafic, et la session TLS est interrompue au niveau de l'instance backend de destination.

La ressource TLSRoute n'est compatible qu'avec les proxys Envoy déployés en tant que proxys side-car ou passerelles.

Ressource TLSRoute associée à une ressource Mesh

Le déploiement illustré dans le schéma suivant achemine tout le trafic du maillage de services où l'extension SNI a la valeur service1 vers le service de backend service1. En outre, tout le trafic du maillage de services où l'extension SNI a la valeur service2 est acheminé vers le service de backend service2. La valeur de l'extension SNI et le nom du service de backend sont indépendants.

Ressource TLSRoute et ressource Mesh (cliquez pour agrandir)

Ressource TLSRoute associée à une ressource Gateway

Le déploiement présenté dans le schéma suivant achemine tout le trafic entrant vers la ressource Gatewaydans laquelle l'extension SNI a la valeur serviceA vers le service de backend serviceA. En outre, tout le trafic entrant vers la ressource Gateway dans laquelle l'extension SNI a la valeur serviceB est acheminé vers le service de backend serviceB. La valeur de l'extension SNI et le nom du service de backend sont indépendants. La valeur de l'extension SNI et l'en-tête des requêtes HTTP sont également indépendants.

La ressource Gateway n'arrête pas la connexion TLS sur le proxy Envoy de Gateway. Au lieu de cela, la connexion TLS est interrompue au niveau du service de backend correspondant. La ressource Gateway ne peut pas inspecter les informations chiffrées dans la couche TLS, à l'exception de ClientHello, qui contient une extension SNI en texte brut. La ressource Gateway effectue une transmission TLS dans ce mode. Notez que la ressource ClientHello n'est pas acceptée.

Ressource TLSRoute et ressource Gateway (cliquez pour agrandir)

Compatibilité avec gRPC de base

Vous pouvez configurer des clients gRPC sans proxy à l'aide d'attributs gRPC de base, tels que la mise en correspondance par méthode.

Répartition du trafic pour le trafic TCP

Vous pouvez mettre en œuvre la répartition du trafic en fonction du poids pour le trafic TCP sur plusieurs services de backend. Vous pouvez configurer des modèles tels que des déploiements Canary (bleu-vert) lorsque vous mettez à jour votre service. La répartition du trafic vous permet également de migrer le trafic de manière contrôlée sans temps d'arrêt.

Interception du trafic

Lorsque vous utilisez les ressources Mesh et Gateway de l'API de routage de service, tout le trafic est intercepté automatiquement. Pour plus d'informations, consultez la section Options de configuration d'une VM Compute Engine avec déploiement Envoy automatique.

Architecture et ressources

Cette section décrit le modèle de l'API de routage de services et ses ressources, et vous aide à comprendre comment les ressources de l'API de routage de services fonctionnent ensemble.

Mesh ressource

La ressource Mesh représente une instance d'un maillage de services. Vous l'utilisez pour créer un maillage de services logique dans votre projet. Chaque ressource Mesh doit posséder un nom unique au sein du projet. Une fois la ressource Mesh créée, son nom ne peut plus être modifié.

Mesh Ressource API avec déploiements side-car Envoy et gRPC sans proxy (cliquez pour agrandir)

La ressource Mesh est référencée dans la ressource Route pour ajouter des routes pour les services faisant partie du maillage.

Les clients proxy Envoy et gRPC sans proxy reçoivent la configuration de Cloud Service Mesh en joignant le maillage de services identifié par le nom de la ressource Mesh. La ressource Mesh est compatible avec les déploiements de plans de données suivants:

• Envoy s'exécutant avec l'application en tant que proxys side-car
• Clients gRPC sans proxy
• Combinaison des clients side-car Envoy et gRPC sans proxy

Ressource Route

La ressource Route permet de configurer le routage vers les services. Il existe quatre types différents de ressources d'API Route. Elles définissent le protocole utilisé pour acheminer le trafic vers un service de backend.

• HTTPRoute
• GRPCRoute
• TCPRoute
• TLSRoute

L'API ne contient pas d'API Route telle quelle. Les seules ressources d'API configurables sont HTTPRoute, GRPCRoute, TCPRoute et TLSRoute.

La ressource Route référence une ou plusieurs ressources Mesh et Gateway pour ajouter les routes faisant partie de la Configuration Mesh ou Gateway correspondante. Une ressource Route peut référencer des ressources Gateway et Mesh.

La ressource Route fait également référence à une ou plusieurs ressources du service de backend. Les services sont configurés à l'aide de l'API du service de backend. Vous créez une ressource de service de backend qui pointe vers un ou plusieurs MIG ou backends de NEG.

Le schéma suivant illustre les relations entre les ressources Mesh, Gateway et Route, ainsi qu'entre la ressource de service de backend et ses backends.

Ressources de l'API Route (cliquez pour agrandir)

Vous définissez d'autres fonctionnalités de gestion du trafic, telles que le routage, les modifications d'en-tête, les délais avant expiration et la répartition du trafic basée sur le poids dans les ressources Route. Par exemple, dans le schéma suivant, une ressource HTTPRoute définit une répartition du trafic de type 70% / 30 % entre deux services de backend.

Répartition du trafic en fonction d'une pondération (cliquez pour agrandir)

Pour simplifier l'administration de votre service mesh, vous pouvez lister toutes les ressources Route associées à une ressource Mesh ou Gateway.

TLSRoute ressource

Utilisez la ressource TLSRoute pour acheminer le trafic TLS vers les services de backend en fonction des noms d'hôtes SNI et du nom ALPN (Application-Layer Protocol Negotiation). La configuration TLSRoute implique une transmission TLS dans laquelle le proxy Envoy ne met pas fin au trafic TLS.

La ressource TLSRoute référence une ou plusieurs ressources Mesh et Gateway pour ajouter les routes faisant partie de la configuration Mesh ou Gateway correspondante.

La ressource TLSRoute fait également référence à une ou plusieurs ressources du service de backend. Les services sont configurés à l'aide de la ressource d'API du service de backend.

Gateway ressource

La ressource Gateway permet de représenter les proxys Envoy agissant en tant que passerelles d'entrée, permettant aux clients externes de se connecter au maillage de services (trafic nord-sud). Cette ressource possède des ports d'écoute ainsi qu'un paramètre scope. Le proxy Envoy qui agit en tant que passerelle d'entrée est lié aux ports spécifiés et à 0.0.0.0, qui représente toutes les adresses IP sur la VM locale. Le schéma suivant montre les proxys Envoy déployés en tant que service d'entrée et configurés par la ressource Gateway. Dans cet exemple, les proxys Envoy sont configurés pour écouter le port 80 pour les connexions entrantes provenant des clients.

La ressource API Gateway n'est compatible qu'avec le plan de données du proxy Envoy. Elle n'est pas compatible avec gRPC sans proxy. gRPCRoutes sont compatibles avec la ressource Gateway, mais le trafic gRPC est acheminé par le proxy Envoy, en tant que proxy intermédiaire.

Entrée du maillage de services via une ressource Gateway (cliquez pour agrandir)

Ressource Gateway (cliquez pour agrandir)

Qu'est-ce qu'un champ d'application Gateway et une configuration Gateway fusionnée ?

Une instance de ressource Gateway représente les ports et la configuration spécifiques au trafic reçu sur ces ports. La ressource API Gateway possède un paramètre, scope, qui permet de regrouper et de fusionner logiquement la configuration de deux ressources Gateway ou plus.

Par exemple, si vous souhaitez que les proxys Gateway écoutent respectivement les ports 80 et 443 pour recevoir le trafic HTTP et HTTPS, vous devez créer deux ressources Gateway. Configurez une ressource Gateway avec le port 80, pour le trafic HTTP, et l'autre avec le port 443, pour le trafic HTTPS. Indiquez le champ scope dans chacune des valeurs. Cloud Service Mesh fusionne de manière dynamique les configurations individuelles de toutes les passerelles ayant le même champ d'application. Du côté du plan de données, les proxys Envoy qui s'exécutent en mode passerelle d'entrée doivent également présenter le même paramètre de champ d'application à Cloud Service Mesh pour recevoir la configuration Gateway. Notez que vous spécifiez le champ d'application lorsque vous créez la ressource Gateway et le même champ d'application que le paramètre d'amorçage pour les proxys.

Comportement de fusion des ressources Gateway (cliquez pour agrandir)

Voici les éléments clés à prendre en compte pour la ressource Gateway :

• Le paramètre de champ d'application Gateway est obligatoire. Spécifiez le champ d'application dans la ressource Gateway et dans la configuration d'amorçage des proxys Envoy, même s'il n'existe qu'une seule Gateway.
• La création d'une ressource Gateway ne déploie pas un service avec un proxy Envoy. Le déploiement du proxy Envoy est une étape distincte.
• La ressource Gateway possède un type qui représente le type de déploiement d'entrée. Ce champ est réservé à une utilisation ultérieure. La seule valeur actuellement acceptée est OPEN_MESH, qui est la valeur par défaut et qui ne peut pas être modifiée.

Déploiements de maillages avec des protocoles mixtes et des plans de données

Vous pouvez disposer d'un déploiement de plan de données mixte, avec un proxy Envoy et gRPC sans proxy dans le même maillage. Lorsque vous créez des déploiements de ce type, tenez compte des points suivants.

• Les déploiements side-car Envoy sont compatibles avec toutes les routes (HTTPRoute, GRPCRoute, TCPRoute et TLSRoute).
• Les déploiements gRPC sans proxy ne sont compatibles qu'avec GRPCRoute.
• GRPCRoute est limité aux fonctionnalités compatibles uniquement avec les déploiements sans proxy gRPC.

Topologies compatibles dans les environnements VPC partagés et multiprojets

Cloud Service Mesh accepte l'ajout de ressources Route définies dans d'autres projets à une ressource Mesh ou Gateway définie dans un projet d'administration centralisé. Les propriétaires de service autorisés peuvent ajouter directement leurs configurations de routage de services au fichier Mesh ou Gateway.

Référence inter-projets entre les ressources Mesh et Route (cliquez pour agrandir)

Dans un scénario multiprojet classique, vous choisissez un projet (projet hôte ou projet d'administration contrôlé de manière centralisée) comme projet d'administration de maillage dans lequel vous créez une ressource Mesh. Le propriétaire du projet d'administration du maillage autorise les ressources Route d'autres projets à référencer la ressource Mesh, ce qui permet à la configuration de routage d'autres projets de faire partie du maillage. Un plan de données du réseau maillé, Envoy ou gRPC, demande la configuration du projet d'administration et reçoit une union de toutes les routes associées au Mesh. Pour un Gateway, les routes sont également fusionnées sur tous les Gateways utilisant le même champ d'application.

Vous pouvez choisir n'importe quel projet d'administration Mesh. La configuration fonctionne à condition que les projets sous-jacents disposent d'une connectivité réseau VPC via un VPC partagé ou un appairage de réseaux VPC.

Autorisations et rôles IAM

Vous trouverez ci-dessous les autorisations IAM requises pour obtenir, créer, mettre à jour, supprimer, répertorier et utiliser les ressources Mesh et Route en toute sécurité.

• Les administrateurs de réseau maillé doivent disposer des autorisations networkservices.mesh.*.
• Les administrateurs de passerelle doivent disposer des autorisations networkservices.gateways.*.
• Les propriétaires de service doivent disposer des autorisations networkservices.grpcRoutes.*, networkservices.httpRoutes.* ou networkservices.tcpRoutes.*.

Les administrateurs de maillage doivent accorder l'autorisation networkservices.mesh.use aux propriétaires du service afin que ceux-ci puissent associer leurs ressources Route à la ressource Mesh. Le même modèle s'applique aux ressources Gateway.

Pour afficher toutes les autorisations IAM pour les ressources Mesh, accédez à la page de référence des autorisations IAM, puis recherchez meshes.

Aucun rôle prédéfini supplémentaire n'est requis. Le rôle prédéfini existant Administrateur de réseaux Compute (roles/compute.networkAdmin) dispose par défaut des autorisations networkservices.*. Vous devrez peut-être ajouter les autorisations décrites précédemment à vos rôles personnalisés.

Remarques et limites

• La console Google Cloud n'est pas compatible avec les API de routage de service.
• Utilisez la version 3 de l'API xDS ou une version ultérieure.
  • Version Envoy minimale de 1.20.0 (car les API de routage de services ne sont compatibles qu'avec xDS version 3)
  • Version minimale du générateur d'amorçage gRPC v0.14.0
• La ressource TLSRoute n'est compatible qu'avec les proxys Envoy déployés en tant que proxys side-car ou passerelles.
• Seules les VM Compute Engine avec déploiement Envoy automatique et les pods GKE avec une injection Envoy automatique sont compatibles. Vous ne pouvez pas utiliser le déploiement manuel avec les API de routage de service.
• Les API de routage de services ne sont pas rétrocompatibles avec les anciennes API.
• Lorsqu'une ressource TCPRoute est associée à une ressource Mesh, le port utilisé pour mettre en correspondance le trafic TCP ne peut pas être utilisé pour diffuser quoi que ce soit, à l'exception du trafic décrit par ce TCPRoute.
  • Par exemple, vos déploiements peuvent inclure une ressource TCPRoute qui correspond au port "8000" et une ressource HttpRoute. Lorsque les deux sont associés à la même ressource Mesh, le trafic acheminé par la ressource HTTPRoute ne peut pas utiliser le port 8000, même si les adresses IP sous-jacentes sont différentes. Cette limitation provient de la mise en œuvre du proxy Envoy, qui attribue en priorité la route correspondante au port.
• La ressource Gateway ne provisionne pas d'équilibreur de charge géré et ne crée pas de service Envoy de manière dynamique.
• Les Envoy déployés automatiquement en tant que passerelles d'entrée ne doivent pas comporter l'argument serving_ports pour l'option --service-proxy.
• Envoy déployé automatiquement n'est pas compatible avec la spécification d'un numéro de projet différent de celui de la VM.

Étape suivante

• Pour savoir comment lister les ressources de parcours associées à une ressource Mesh ou Gateway, consultez Lister les ressources Route. Cette fonctionnalité est disponible en version d'évaluation.
• Pour en savoir plus sur les API de routage de services, consultez la documentation sur les API des services réseau.