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 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 d'entrée (nord-sud) et le trafic du maillage de services (est-ouest) au sein de votre cluster Kubernetes.
- Les maillages de services permettent d'utiliser 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.
- Grâce aux API Gateway, les développeurs peuvent se concentrer sur la définition de règles de routage et de règles de haut niveau pour leur microservice, sans avoir besoin de connaître en détail 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 futures et de prendre en charge de nouveaux protocoles et cas d'utilisation.
- Les API Gateway bénéficient d'un soutien important de la communauté et sont prises en charge par 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 maillage de services fait partie du canal Standard depuis la version 1.1.0 et est considéré comme en disponibilité générale.
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 Kubernetes Service en tant que parentRef. L'approche dépend des rôles "frontend" et "backend" de Service de Kubernetes, tels que définis dans GEP-1324 : Maillage de services dans l'API Gateway, 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, se concentre sur le routage des couches 4 et 7 dans Kubernetes. Elle succède aux API Ingress, d'équilibrage de charge et de maillage de services. Conçues pour être polyvalentes, descriptives et axées 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 interservices ou Est/Ouest 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 de l'API Gateway, tout en respectant sa nature orientée rôle. 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 de leur proxy sous-jacents.
GAMMA exploite les points d'extensibilité existants dans la spécification de l'API Gateway, ce qui ne nécessite aucune modification de l'API ni aucune nouvelle ressource. Pour ce faire, étendez les définitions de ressources de routage (GRPCRoute ou HTTPRoute dans l'API Gateway) 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 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
La ressource 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é en tant que parentRef, ce qui signifie que la ressource HTTPRoute est associée à l'interface de echo-service. Tout trafic envoyé à echo-service par un client est acheminé selon la ressource 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 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
Tout comme l'exemple HTTPRoute, cette ressource 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 ressource 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 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é.
