Présentation des API de routage de service Traffic Director

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 Traffic Director et de maillage de services. Ce document s'applique aux déploiements utilisant des clients Envoy et gRPC. Pour en savoir plus sur les concepts de Traffic Director, consultez la présentation générale et la présentation des services gRPC sans proxy.

Traffic Director 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 service pour la configuration de Traffic Director. Ces API sont conçues pour simplifier et améliorer votre expérience globale de configuration du maillage.

Ce modèle d'API remplace les anciennes ressources de règle de transfert, de proxy cible et de mappage d'URL par des ressources d'API appelées Mesh, Gateway et Route. Ces ressources offrent une expérience de configuration plus pertinente en contexte lorsque vous définissez votre plan de contrôle de réseau de services.

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

  • 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
    • Identifie le maillage de services et représente le composant chargé d'intercepter et de router le trafic, et d'appliquer des règles, et identifie le port d'interception du trafic.
  • 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).
    • Identifie les proxys intermédiaire et représente le composant qui écoute une liste de paires adresse IP/port, achemine le trafic et applique des règles.
  • Route
    • Identifie les noms d'hôtes et le port que les clients utilisent pour acheminer le trafic vers les services de backend, et contient des informations de routage du trafic complexes. Il existe plusieurs types de ressources Route.
    • HTTPRoute
    • GRPCRoute
    • TCPRoute
    • TLSRoute

La console Google Cloud ne prend pas en charge les API de routage de service. Vous devez mettre en œuvre ces ressources d'API à l'aide de la Google Cloud CLI ou des API REST. De plus, il n'existe pas de chemin de migration automatisé des anciennes API vers les API de routage de services. Pour remplacer un déploiement existant, vous devez créer un déploiement Traffic Director avec les API de routage de services, puis arrêter l'ancien déploiement.

Cas d'utilisation et avantages

Les API de routage de services vous permettent de configurer Traffic Director pour les déploiements de proxys Envoy et gRPC sans proxy. Le modèle d'API de routage des services offre 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 services créent la configuration de routage pour leurs services.

Trafic de service à service est-ouest dans un maillage de 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 des services vous permettent de séparer les responsabilités de la configuration du réseau maillé 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.

Trafic Nord-Sud dans le réseau maillé via une passerelle
Trafic nord-sud dans le maillage via une passerelle (cliquez pour agrandir)

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

Dans l'ancienne API Traffic Director, le mappage d'URL définit le routage pour les communications de service à service dans le maillage, ainsi que pour le trafic externe entrant dans le maillage via un équilibreur de charge géré. Plusieurs équipes peuvent modifier une ressource de mappage d'URL unique, ce qui présente des problèmes de fiabilité potentiels et complique le processus de délégation de la configuration par service aux propriétaires de service.

Les API de routage de services introduisent des ressources par protocole et par route qui peuvent ê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ésormais 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'affecte pas les autres ressources Route du maillage. Le processus de mise à jour est également moins sujet aux erreurs, car les propriétaires de service gèrent des configurations beaucoup plus petites.
  • 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 services n'ont pas besoin de dépendre des administrateurs du maillage pour mettre à jour le routage à l'aide de la ressource de mappage d'URL centralisée.

Configurez uniquement les éléments pertinents

Les API de routage de services remplacent les règles de transfert, les proxys cibles et les mappages d'URL. Vous n'avez plus besoin d'allouer des adresses IP virtuelles de votre réseau VPC (Virtual Private Cloud) pour la communication de service à service avec les proxys side-car et gRPC sans proxy.

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

Le modèle d'API de routage des services permet aux propriétaires de services de participer à une infrastructure de maillage partagée à l'aide d'un VPC partagé et d'autres moyens de connectivité, tout en maintenant un contrôle indépendant sur 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érencer plusieurs projets avec 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
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
Ressource TLSRoute et ressource Gateway (cliquez pour agrandir)

Compatibilité avec gRPC intégrée

Vous pouvez configurer des clients gRPC sans proxy à l'aide d'attributs gRPC intégrés tels que la mise en correspondance par méthode, au lieu de les traduire en chemins d'accès équivalents et d'utiliser des outils de mise en correspondance des chemins d'accès.

Répartition du trafic pour le trafic TCP

Vous pouvez désormais 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 des services, tout le trafic est automatiquement intercepté. 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 Service Routage et ses ressources, et vous aide à comprendre comment ces ressources interagissent.

Ressource Mesh

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é.

Ressource API Mesh avec déploiements side-car Envoy et gRPC sans proxy
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 Traffic Director en joignant le maillage de services identifié par le nom de la ressource Mesh. Le nom du Mesh en tant que paramètre d'amorçage, est accepté par le déploiement Envoy automatisé sur Compute Engine et par l'Injecteur Envoy automatique sur GKE.

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.

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 avec le flux de configuration existant. Les API de routage de services ne modifient pas la façon dont les services de backend et les vérifications d'état sont définis dans la configuration de Traffic Director. Pour ce faire, créez une ressource de service de backend qui pointe vers un ou plusieurs backends MIG ou NEG.

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

Ressources de l'API Route
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
Répartition du trafic en fonction d'une pondération (cliquez pour agrandir)

Ressource TLSRoute

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 avec le flux de configuration et les API existants.

Ressource Gateway

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
Entrée du maillage de services via une ressource Gateway (cliquez pour agrandir)
Ressource de passerelle
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. Traffic Director 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 à Traffic Director 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 la fusion des ressources de passerelle
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

Traffic Director permet d'ajouter des ressources Route définies dans d'autres projets à une ressource Mesh ou Gateway définie dans un projet d'administration centralisée. Les propriétaires de service autorisés peuvent ajouter directement leurs configurations de routage de services au fichier Mesh ou Gateway.

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

Dans un scénario multiprojet typique, vous choisissez un projet (projet hôte ou projet d'administration contrôlé de manière centralisée) comme projet d'administration du 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 maillage, qu'il s'agisse d'Envoy ou de gRPC, demande la configuration au projet d'administration et reçoit l'union de toutes les routes associées à Mesh. Pour un Gateway, les routes sont également fusionnées sur tous les Gateways utilisant le même champ d'application.

Le projet d'administration Mesh peut être n'importe quel projet de votre choix. La configuration fonctionne tant que les projets sous-jacents disposent d'une connectivité réseau VPC, via un VPC partagé ou l'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 autre rôle prédéfini 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.

Comparaison entre le routage des services et les anciens modèles d'API

Cette section compare sujet par sujet les anciens modèles de l'API Traffic Director et ceux de routage de services.

Anciennes API API de routage des services
Ressources de l'API Règle de transfert, proxy cible, mappage d'URL et service de backend Passerelle, maillage, route et service de backend
Adresses IP et numéros de port des services Vous devez provisionner les adresses IP et les numéros de port de vos services et configurer des règles de transfert, qui doivent correspondre aux paires IP:Port pour tous les cas d'utilisation.

Vous devez mapper manuellement les adresses IP sur les noms d'hôte, ou vous devez utiliser l'adresse IP collecteur 0.0.0.0.		 Vous n'avez pas besoin de configurer des adresses IP pour les cas d'utilisation Mesh ou Gateway. Gateway nécessite la configuration des numéros de port.
Champ d'application du maillage de services Traffic Director programme tous les proxys associés au réseau VPC. Le champ d'application du maillage est donc de type VPC. Traffic Director ne programme pas les proxys en fonction du réseau VPC.

Pour la communication de service à service est-ouest, les clients Envoy et gRPC sans proxy utilisent le nom de la ressource Mesh.

Pour les cas d'utilisation de passerelle d'entrée nord-sud, il existe un paramètre scope dans l'API Gateway qui permet de regrouper plusieurs Gateways avec la configuration fusionnée.
Référence multiprojet dans les environnements VPC partagés Le référencement interprojet n'est pas accepté. Toutes les ressources d'API doivent être configurées dans le même projet. Il est possible de créer des ressources Mesh ou Gateway dans un projet géré de manière centralisée (projet hôte), et les propriétaires de service peuvent créer les ressources Route dans les projets de service de l'environnement VPC partagé. Les ressources Route peuvent faire référence au Mesh ou à la Gateway situé dans les projets.
Port d'interconnexion Le paramètre d'amorçage TRAFFICDIRECTOR_INTERCEPTION_PORT doit être spécifié dans chaque Envoy qui se connecte à Traffic Director.

Avec le déploiement automatique d'Envoy sur l'API Compute Engine et avec l'injection side-car automatique sur GKE, cette valeur est définie par défaut sur 15001.		 Le port d'interception est configuré dans la ressource Mesh et s'applique automatiquement à tous les Envoy qui demandent la configuration de cette Mesh.

La valeur par défaut est toujours définie sur 15001 si elle n'est pas spécifiée.

Amorcer les clients Envoy et gRPC sur Compute Engine et GKE

Anciennes API API de routage des services
Utiliser le déploiement automatique d'Envoy sur Compute Engine Lorsque vous créez le modèle de VM, vous spécifiez un paramètre de ligne de commande, --service-proxy=enabled, qui amorce de manière dynamique le proxy Envoy avec les attributs requis. Lorsque vous créez le modèle de VM, vous spécifiez des paramètres supplémentaires. Par exemple, --service-proxy=enabled, mesh=[MESH_NAME] (pour les réseaux maillés) ou --service-proxy=enabled, scope=[SCOPE_NAME] (pour les passerelles). Les autres attributs requis sont amorcés de manière dynamique. Pour Envoy en tant que passerelle, assurez-vous que serving_ports n'est pas spécifié dans l'argument de ligne de commande --service-proxy. Pour plus d'informations, consultez la section Options de configuration d'une VM Compute Engine avec déploiement Envoy automatique.
Utiliser l'injection side-car automatique sur GKE Vous devez spécifier les attributs d'amorçage requis dans le fichier configMap de l'injecteur de side-car. Workflow identique avec les nouveaux attributs spécifiés dans le fichier configMap.
Utiliser l'injection manuelle de side-car sur GKE Comme expliqué ici, un conteneur side-car Envoy doit être amorcé avec les attributs requis au pod de l'application. Workflow identique avec les nouveaux attributs.
Déployez des clients gRPC à l'aide de Compute Engine ou de GKE. L'application cliente doit être amorcé avec les attributs requis. Workflow identique avec les nouveaux attributs.

Configurer des cas d'utilisation de la sécurité pour le maillage et la passerelle

Anciennes API API de routage des services
mTLS de service à service dans GKE Suivez ces instructions pour les déploiements side-car Envoy.

Suivez les instructions ici pour les déploiements basés sur gRPC sans proxy.		 Les mêmes instructions s'appliquent.

Les règles TLS client et TLS du serveur doivent être appliquées respectivement aux ressources du service de backend et des règles de point de terminaison. Étant donné que ces deux API sont indépendantes des API de routage de service, le flux de configuration reste le même qu'auparavant.
Sécuriser les déploiements de proxys intermédiaires (passerelle d'entrée ou de sortie) Suivez ces instructions détaillées.

Les ressources des règles d'autorisation et les règles TLS du serveur sont associées à la ressource de proxy HTTPS cible.		 Associez les ressources de la règle TLS du serveur et de la règle d'autorisation à la passerelle.

Remarques et limites

  • La console Google Cloud n'est pas compatible avec les API de routage de services.
  • Utilisez la version 3 de l'API xDS ou une version ultérieure.
    • Version minimale d'Envoy : 1.24.9.
    • 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 des services.
  • Terraform n'est pas compatible avec cette version.
  • 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.

Étapes suivantes