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é. Toutefois, la configuration et l'exploitation d'un maillage de services sont des tâches complexes. 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 globale de configuration du maillage.
Les API Kubernetes Gateway pour Mesh vous permettent de configurer Cloud Service Mesh pour les déploiements gRPC sans proxy et pour ceux utilisant un proxy Envoy. Le modèle d'API Gateway pour Mesh offre plusieurs avantages essentiels :
- Les API Gateway fournissent une interface unique et cohérente pour gérer le trafic entrant (nord-sud) et le trafic du 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.
- Avec les API Gateway, les développeurs peuvent 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'améliorer les fonctionnalités et de prendre en charge de nouveaux protocoles et cas d'utilisation.
- 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 du maillage de services fait partie du canal standard depuis la version 1.1.0 et est considéré comme disponible.
La spécification
propose qu'un propriétaire d'application configure les règles de trafic pour un service de maillage
en configurant une Route resource (parfois appelée xRoute)
avec une ressource Service Kubernetes en tant que parentRef. L'approche dépend des
rôles "frontend" et "backend" deService Kubernetes, 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, ses configurations se trouvent 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 inter-services ou est/ouest au sein du même cluster. GAMMA vise à établir comment utiliser l'API Gateway pour configurer un maillage de services avec un minimum de modifications de l'API Gateway tout en conservant 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 l'API Gateway dans le maillage de services, quelle que soit leur technologie ou leur proxy sous-jacent.
GAMMA exploite les points d'extensibilité existants dans la spécification de l'API Gateway, sans nécessiter de modifications d'API ni de nouvelles ressources. Pour ce faire, les définitions de ressources de routage (GRPCRoute ou HTTPRoute dans l' API Gateway) sont étendues pour signaler le cas d'utilisation du maillage de services, en particulier en associant les ressources de routage aux ressources de service, comme décrit dans API Gateway for Service Mesh.
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
La ressource HTTPRoute 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 la ressource HTTPRoute est associée au frontend de echo-service. Tout trafic envoyé à echo-service par un client est acheminé conformément à la route HTTPRoute echo-route.
GRPCRoute est une autre ressource de l'API Kubernetes Gateway, qui permet d'acheminer 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 méthode gRPC et la mise en correspondance des services.
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 ressource GRPCRoute est configurée pour les cas d'utilisation du maillage de services. Tout trafic envoyé à xds:///echo-service.default.svc.cluster.local:8080 par un client gRPC sans proxy est acheminé conformément à la route GRPCRoute echo-route. Les règles de routage de cet exemple correspondent à une méthode gRPC et acheminent le trafic vers un backendRef spécifique. Les ressources GRPCRoute peuvent également être utilisées pour acheminer les requêtes de clients proxy avec des injections side-car, comme Envoy, lorsque le préfixe xds:/// est supprimé.
