Présentation du maillage de services GKE Cloud Service Mesh
Cette configuration est compatible avec les clients Preview, mais nous ne la recommandons pas aux nouveaux utilisateurs de Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.
Ce document est destiné aux utilisateurs de Google Kubernetes Engine qui souhaitent déployer un maillage de services Cloud Service Mesh à l'aide de l'API Kubernetes Gateway.
Vous pouvez configurer Cloud Service Mesh pour GKE à l'aide des API de passerelle Kubernetes, ce qui permet les communications de service à service, la gestion du trafic, l'équilibrage de charge global et l'application des règles de sécurité pour les cas d'utilisation du maillage de services.
API Kubernetes et API Google Cloud
Vous pouvez configurer un maillage de services Cloud Service Mesh à l'aide de deux API différentes:
- Les API Google Cloud, qui peuvent être les API de routage de services ou les anciennes API
- Les API de passerelle Kubernetes
Ce document et les guides de configuration associés fournissent des instructions d'utilisation de l'API Kubernetes Gateway afin de configurer un maillage de services Cloud Service Mesh.
Nous vous recommandons d'utiliser les API Kubernetes Gateway sur Google Kubernetes Engine et nous vous déconseillons d'utiliser les deux API pour configurer le routage dans le même maillage de services sur GKE.
L'API de routage de services utilise les mêmes noms de ressources que les ressources des API Kubernetes Gateway, ce qui vous facilite la tâche lorsque vous utilisez les deux API. Du point de vue fonctionnel, les ressources Kubernetes que vous configurez sont équivalentes aux ressources Google Cloud représentées par l'API de routage de services pour Cloud Service Mesh.
Les sections suivantes décrivent les ressources et l'architecture utilisées par l'intégration du service de maillage de services Cloud avec les API Kubernetes Gateway.
API Gateway
L'API Gateway est un ensemble de ressources modélisant la mise en réseau de services dans Kubernetes. L'API Gateway de Kubernetes est un projet Open Source axé sur la gestion des cas d'utilisation des entrées et de l'équilibreur de charge via une API de routage générique. L'API de routage générique dispose de nombreuses implémentations. Les définitions de ressources personnalisées (CRD) de Cloud Service Mesh sont ajoutées en tant qu'extension à l'API Gateway Open Source. Les CRD acceptent les cas d'utilisation du maillage de services et utilisent la même API de routage générique que celle introduite par l'API Gateway.
L'API Gateway est organisée de manière hiérarchique, avec une ressource parente Gateway et une classe GatewayClass
associée, à laquelle vous associez des routes. GKE inclut une ressource TDMesh
qui est un pair de la ressource Gateway
. Vous pouvez associer les mêmes types Route
à la ressource TDMesh
. La ressource TDMesh
vous permet d'associer des routes et des règles aux maillages de services.
Parc
Un parc est constitué d'un ou de plusieurs clusters GKE regroupés de manière logique. Un parc vous permet de gérer les fonctionnalités et d'appliquer des règles de manière cohérente sur plusieurs clusters. Lorsque vous utilisez un parc, vous pouvez gérer un maillage de services Cloud Service Mesh couvrant plusieurs clusters.
Architecture
Cloud Service Mesh est compatible avec l'API Gateway sur GKE en programmant les plans de données de vos clusters pour mettre en œuvre les comportements de mise en réseau spécifiés dans les ressources de l'API Gateway. Cloud Service Mesh est un plan de contrôle géré par Google qui ne traite aucun trafic de plan de données. Les proxys Envoy s'exécutant en tant que side-cars vers vos charges de travail ou les clients gRPC sans proxy traitent le trafic dans le plan de données. Cloud Service Mesh configure à la fois les proxys Envoy et les clients gRPC sans proxy via l'API xDSv3.
Cloud Service Mesh est une solution de plan de contrôle gérée et disponible dans le monde entier, plus robuste et évolutive que les contrôleurs de cluster. Comme il s'agit d'une solution globale, Cloud Service Mesh peut équilibrer la charge du trafic sur les charges de travail réparties sur plusieurs clusters GKE. Dans l'illustration suivante, Cloud Service Mesh gère le trafic vers des services dans trois clusters d'un même parc à l'aide de ressources de l'API Gateway.
Vous désignez un cluster de votre parc en tant que cluster de configuration. Le cluster de configuration est l'emplacement de stockage des ressources de l'API Gateway. Cloud Service Mesh surveille uniquement les ressources du cluster de configuration et ignore celles qui se trouvent dans les autres clusters du parc. Pour en savoir plus sur le cluster de configuration, consultez la section Conception du cluster de configuration dans la documentation GKE.
Avec les services multiclusters GKE, les ressources de l'API Gateway dans le cluster de configuration peuvent référencer les services Kubernetes de n'importe quel cluster d'un parc. Consultez la section Services multiclusters pour en savoir plus sur la détection de services multiclusters.
Ressources
Cloud Service Mesh est compatible avec les proxys Envoy et gRPC sans proxy dans le plan de données d'un maillage de services. Les deux clients reçoivent la configuration de Cloud Service Mesh pour un maillage de services particulier, en spécifiant le nom et le numéro de projet correspondant de la ressource TDMesh
dans leur configuration d'amorçage correspondante. Les guides de configuration de Cloud Service Mesh avec les API Kubernetes Gateway fournissent des configurations de plan de données de démonstration avec Envoy et gRPC sans proxy.
TDMesh
ressource
La ressource TDMesh
est une ressource personnalisée Cloud Service Mesh. Il s'agit d'une extension des API Gateway Open Source permettant de gérer les cas d'utilisation du maillage de services Cloud Service Mesh. À l'aide de la ressource TDMesh
, vous créez une instance de maillage de services dans votre parc. Les routes associées à la ressource TDMesh
spécifient les comportements de routage de service à service dans le maillage de services.
Route
ressources
Un sous-ensemble de ressources de routes de l'API Gateway peut être associé à une ressource TDMesh
pour spécifier le routage au niveau du service dans le maillage de services. Cloud Service Mesh est compatible avec les ressources Route
suivantes:
HTTPRoute
TCPRoute
TDGRPCRoute
(ressource personnalisée Cloud Service Mesh)
Par exemple, vous pouvez créer un objet HTTPRoute
pour spécifier que les requêtes HTTP destinées à l'hôte payments.svc.internal
sont acheminées vers le service Kubernetes service-payments
. Lorsque vous associez la ressource HTTPRoute
à une ressource TDMesh
à laquelle les instances de plan de données sont abonnées, les requêtes HTTP envoyées par les charges de travail au sein du maillage sont acheminées en conséquence.
Cette version étend les ressources génériques Route
dans l'API Gateway avec un nouveau type de route, TDGRPCRoute
. Le nouveau type de route offre une expérience de première classe pour le routage des requêtes gRPC, en fonction des primitives gRPC natives, telles que les définitions de méthodes et de services.
Limites
- Cloud Service Mesh configure les comportements par défaut suivants pour tous les services Kubernetes du maillage de services. Vous ne pouvez pas modifier ces comportements.
- Les vérifications d'état TCP sont configurées sur les ports de service référencés par les ressources
Route
de l'API Gateway. - Un délai avant expiration de 30 secondes est configuré par défaut pour toutes les requêtes entrantes adressées aux services.
- L'affinité de session est désactivée.
- Les vérifications d'état TCP sont configurées sur les ports de service référencés par les ressources
- L'injecteur automatique d'Envoy n'accepte qu'un seul maillage par parc.
- Les fonctionnalités de sécurité de Cloud Service Mesh ne peuvent pas être activées à l'aide de l'API Gateway.
- Vous devez configurer les ressources
TDMesh
etRoute
sur GKE à l'aide de l'API Gateway uniquement. Vous ne pouvez pas utiliser la console Google Cloud, gcloud CLI ou les API REST. - Tous les clusters doivent appartenir à un même projet. Il n'est pas possible de créer un maillage de services couvrant plusieurs clusters dans plusieurs projets.
- Vous ne pouvez pas configurer ou afficher un maillage de services GKE à l'aide de la console Google Cloud.
- L'observabilité du plan de contrôle avec Cloud Logging et Cloud Monitoring n'est pas possible.
Étape suivante
- Découvrez comment préparer la configuration d'un maillage de services avec l'API Gateway.