Présentation
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. Cette page décrit la configuration de Cloud Service Mesh avec les API Kubernetes Gateway. Ces API sont conçues pour simplifier et améliorer votre expérience de configuration globale du maillage.
Les API Kubernetes Gateway pour Mesh vous permettent de configurer Cloud Service Mesh pour les déploiements de gRPC sans proxy et de proxy Envoy. L'API Gateway pour le modèle Mesh offre plusieurs avantages clés :
- Les API Gateway fournissent une interface unique et cohérente pour gérer le trafic d'entrée (Nord-Sud) et le trafic de maillage de services (Est-Ouest) dans votre cluster Kubernetes.
- Les maillages de services permettent des modèles de routage du trafic avancés. Les API Gateway vous permettent de concevoir et de gérer des règles de routage complexes.
- Les API Gateway permettent aux développeurs de se concentrer sur la définition de règles et de stratégies de routage de haut niveau pour leur microservice, sans avoir besoin de connaissances approfondies sur l'implémentation du maillage de services sous-jacent.
- L'API est conçue pour être extensible, ce qui permet d'apporter des améliorations et de prendre en charge de nouveaux protocoles et cas d'utilisation à l'avenir.
- Les API Gateway bénéficient d'un fort soutien de la communauté et sont compatibles avec un écosystème croissant de fournisseurs et d'outils de maillage de services.
Le travail de l'initiative GAMMA pour la prise en charge des cas d'utilisation de service mesh fait partie du canal standard depuis la version 1.1.0 et est considéré comme disponible dans sa version finale.
La spécification propose qu'un propriétaire d'application configure des règles de trafic pour un service de maillage en configurant un Route resource (parfois appelé xRoute) avec une ressource Service Kubernetes en tant que parentRef. L'approche dépend des rôles "frontend" et "backend" de Kubernetes Service, tels que définis dans GEP-1324 : Service Mesh in Gateway API, où le rôle "frontend" est utilisé comme parentRef et le rôle "backend" de Service est utilisé comme backendRef. L'implémentation conforme utilise le nom Service pour faire correspondre le trafic et les points de terminaison backendRef pour les adresses IP canoniques.
API Gateway pour Mesh
L'API Gateway, un projet Kubernetes, est axée sur le routage de couche 4 et 7 dans Kubernetes. Elle succède aux API Ingress, Load Balancing et Service Mesh. Conçue pour être polyvalente, descriptive et axée sur les rôles, sa configuration se trouve principalement dans la couche de routage.
Les ressources spécifiques au protocole, telles que HTTPRoute et GRPCRoute, permettent un routage d'entrée et de maillage avancé.
L'initiative GAMMA (Gateway API for Service Mesh) définit comment l'API Gateway peut également être utilisée pour le trafic est/ouest ou entre services au sein d'un même cluster. GAMMA vise à établir comment utiliser l'API Gateway pour configurer un maillage de services avec un minimum de modifications apportées à l'API Gateway, tout en respectant sa nature axée sur les rôles. GAMMA souligne également l'importance de promouvoir la cohérence entre les différentes implémentations de maillage de services de l'API Gateway, indépendamment de leur technologie ou proxy sous-jacents.
GAMMA exploite les points d'extensibilité existants dans la spécification de l'API Gateway, sans nécessiter de modifications de l'API ni de nouvelles ressources. Pour ce faire, il faut étendre les définitions de ressources de route (GRPCRoute ou HTTPRoute dans l'API Gateway) pour signaler le cas d'utilisation du maillage de services, en associant plus précisément les ressources de route aux ressources de service, comme décrit dans API Gateway pour le maillage de services.
L'exemple suivant illustre le cas d'utilisation du maillage dans l'utilisation de HTTPRoute :
apiVersion: gateway.networking.k8s.io
kind: HTTPRoute
metadata:
name: echo-route
spec:
parentRefs:
- kind: Service
group: ""
name: echo-service
rules:
- backendRefs:
- name: echo-v1
port: 80
weight: 9
- backendRefs:
- name: echo-v2
port: 80
weight: 1
HTTPRoute fait référence à un Service en tant que parentRef, ce qui indique que la route HTTPRoute est configurée pour le cas d'utilisation du maillage de services. Dans l'exemple précédent, le service echo-service est spécifié comme parentRef, ce qui signifie que HTTPRoute est associé au frontend d'echo-service. Tout trafic envoyé à echo-service par un client est acheminé en fonction de la route HTTP echo-route.
GRPCRoute est une autre ressource de l'API Kubernetes Gateway, qui est utilisée pour router le trafic gRPC vers les services Kubernetes. Les utilisateurs choisissent d'utiliser GRPCRoute au lieu de HTTPRoute lorsqu'ils souhaitent acheminer spécifiquement le trafic gRPC et profiter de fonctionnalités adaptées à gRPC, telles que la mise en correspondance des méthodes et des services gRPC.
L'exemple suivant illustre l'utilisation de GRPCRoute :
apiVersion: gateway.networking.k8s.io
kind: GRPCRoute
metadata:
name: echo-route
spec:
parentRefs:
- kind: Service
group: ""
name: echo-service
rules:
- matches:
- method:
service:echo_basic.grpcecho.GrpcEcho
method: Echo
backendRefs:
- name: grpc-infra-backend-v1
port: 8080
- matches:
- method:
service:echo_basic.grpcecho.GrpcEcho
method: EchoTwo
backendRefs:
- name: grpc-infra-backend-v2
port: 8080
Comme l'exemple HTTPRoute, cette GRPCRoute est configurée pour les cas d'utilisation de maillage de services. Tout trafic envoyé à xds:///echo-service.default.svc.cluster.local:8080 par un client gRPC sans proxy est acheminé selon la route d'écho GRPCRoute. Dans cet exemple, les règles de routage correspondent à une méthode gRPC et acheminent le trafic vers un backendRef spécifique. Les GRPCRoutes peuvent également être utilisées pour acheminer les requêtes des clients proxy avec des injections side-car, comme Envoy, lorsque le préfixe xds:/// est supprimé.
