Présentation des API de routage du service 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 des déploiements via 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 des fonctionnalités de mise en réseau de services à vos telles que la gestion avancée du trafic, l'observabilité 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 de configuration globale du réseau.
Le modèle de routage du 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.
Mesh
ressource- 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
-
- 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:
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 la Google Cloud CLI ou des API REST.
Cas d'utilisation et avantages
Les API de routage des services vous permettent de configurer Cloud Service Mesh pour les deux des déploiements de proxys gRPC et Envoy sans proxy ; Modèle d'API de routage des services présente plusieurs avantages clés.
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.
La conception d'API orientées rôles permet de séparer clairement les responsabilités
Les API de routage des services vous permettent de séparer la configuration du réseau maillé responsabilités en fonction des rôles organisationnels:
- 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.
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és et détenus par des propriétaires de services indépendants. Cette approche comporte 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 ressourcesRoute
du maillage. Le processus de mise à jour est plus fiable, car les propriétaires du service gérer les 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é.
Les API de routage des services vous permettent également de connecter des clients de maillage de services à différentes à 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 présenté dans le schéma suivant achemine tout 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
associée à une ressource Gateway
Le déploiement présenté dans le schéma suivant achemine tout le trafic entrant vers la ressource Gateway
dans 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.
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 d'API de routage des services et ses ressources, et vous aide à comment les ressources de l'API de routage des 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é.
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. Toi
créer une ressource de service de backend qui pointe vers un ou plusieurs backends de MIG ou 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.
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.
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.
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 tous
Passerelles ayant le même champ d'application. Côté plan de données, les proxys Envoy
qui s'exécutent en mode passerelle d'entrée doivent aussi 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.
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 ressourceGateway
et dans la configuration d'amorçage des proxys Envoy, même s'il n'existe qu'une seuleGateway
. - 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 untype
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 estOPEN_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
etTLSRoute
). - 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
.
Dans un scénario typique multiprojet, vous choisissez un projet (projet hôte ou
projet d'administration contrôlé de manière centralisée) que le projet d'administration du réseau maillé dans lequel vous créez
une ressource Mesh
. Le propriétaire du projet d'administration du réseau maillé autorise les ressources Route
provenant d'autres
projets de référencer la ressource Mesh
, ce qui permet de configurer le routage
d'autres projets pour faire partie du maillage. Un plan de données maillé, qu'il s'agisse d'Envoy ou
gRPC demande la configuration au projet d'administration et reçoit une union
des routes associées à 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
.
fonctionne tant que les projets sous-jacents disposent d'un VPC
la connectivité réseau, que ce soit via un VPC partagé
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.*
ounetworkservices.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 d'autorisations networkservices.*
par défaut.
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 services.
- Utilisez les
API xDS version 3
ou 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 ressourceMesh
, 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 ceTCPRoute
.- 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 ressourceMesh
, le trafic acheminé par la ressourceHTTPRoute
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.
- Par exemple, vos déploiements peuvent inclure une ressource
- 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 répertorier les ressources de routage associées à un
Mesh
ouGateway
, consultez la section Répertorier les ressourcesRoute
. Cette fonctionnalité est disponible en version d'évaluation. - Pour plus d'informations sur les API de routage de service, consultez la documentation des API de services réseau.