Présentation du maillage de services GKE Traffic Director

Ce document est destiné aux utilisateurs de Google Kubernetes Engine qui souhaitent déployer un maillage de services Traffic Director à l'aide de l'API Kubernetes Gateway.

Vous pouvez configurer Traffic Director 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 Traffic Director à l'aide de deux API différentes :

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 Traffic Director.

Nous vous recommandons d'utiliser les API Kubernetes Gateway sur Google Kubernetes Engine, ainsi que 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 Traffic Director.

Les sections suivantes décrivent les ressources et l'architecture utilisées par l'intégration de Traffic Director 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 Kubernetes est un projet Open Source qui fournit une API de routage générique pour répondre aux cas d'utilisation d'entrée et d'équilibreur de charge. L'API de routage générique dispose de nombreuses implémentations. Les définitions de ressources personnalisées (CRD) de Traffic Director 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.

API Gateway, ressource Gateway, ressource Mesh et routes
API Gateway, ressource Gateway, ressource Mesh et routes (cliquez pour agrandir)

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 Traffic Director couvrant plusieurs clusters.

Architecture

Traffic Director 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. Traffic Director 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. Traffic Director configure à la fois les proxys Envoy et les clients gRPC sans proxy via l'API xDSv3.

Traffic Director 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, Traffic Director peut équilibrer la charge du trafic sur les charges de travail réparties sur plusieurs clusters GKE. Dans l'illustration suivante, Traffic Director gère le trafic vers des services dans trois clusters d'un même parc à l'aide de ressources de l'API Gateway.

Maillage de services multicluster Traffic Director configuré à l'aide de l'API Gateway
Maillage de services multicluster Traffic Director configuré à l'aide de l'API Gateway (cliquez pour agrandir)

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. Traffic Director 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 multicluster GKE, les ressources de l'API Gateway dans le cluster de configuration peuvent référencer les services Kubernetes dans n'importe quel cluster d'un parc. Pour en savoir plus sur la détection de services multiclusters, consultez la page Services multiclusters.

Ressources

Traffic Director 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 Traffic Director 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 pour Traffic Director et les API Kubernetes Gateway fournissent des démonstrations de configurations de plan de données avec Envoy et gRPC sans proxy.

Ressource TDMesh

La ressource TDMesh est une ressource personnalisée Traffic Director. Il s'agit d'une extension des API Gateway Open Source permettant de gérer les cas d'utilisation du maillage de services Traffic Director. À 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 route d'API Gateway peut être associé à une ressource TDMesh pour spécifier le routage au niveau du service au sein du maillage de services. Traffic Director est compatible avec les ressources Route suivantes :

  • HTTPRoute
  • TCPRoute
  • TDGRPCRoute (ressource personnalisée Traffic Director)

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.

Utiliser les ressources de l'API Gateway dans GKE pour configurer Traffic Director
Utiliser les ressources de l'API Gateway dans GKE pour configurer Traffic Director (cliquez pour agrandir)

Limites

  • Traffic Director 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 par défaut de 30 secondes est configuré pour toutes les requêtes entrantes adressées aux services.
    • L'affinité de session est désactivée.
  • L'injecteur automatique Envoy n'accepte qu'un seul maillage par parc.
  • Les fonctionnalités de sécurité de Traffic Director ne peuvent pas être activées à l'aide de l'API Gateway.
  • Vous devez configurer les ressources TDMesh et Route 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.

Étapes suivantes