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 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 à la fois le trafic d'entrée (Nord-Sud) et le trafic de maillage de services (Est-Ouest) dans votre cluster Kubernetes.
- Les réseaux maillés de services permettent d'utiliser des modèles de routage du trafic avancés. Les API de passerelle 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 service mesh sous-jacent.
- L'API est conçue pour être extensible, ce qui permet de l'améliorer et de prendre en charge de nouveaux protocoles et cas d'utilisation à l'avenir.
- Les API Gateway bénéficient d'un soutien important de la part de la communauté et d'un écosystème croissant de fournisseurs et d'outils de service mesh.
Le travail de l'initiative GAMMA visant à prendre en charge les cas d'utilisation de service mesh fait partie du canal standard depuis la version 1.1.0 et est considéré comme GA.
La spécification propose qu'un propriétaire d'application configure des règles de trafic pour un service de réseau maillé 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 aux adresses IP canoniques.
API Gateway pour Mesh
L'API Gateway, un projet Kubernetes, se concentre sur le routage de couche 4 et 7 dans Kubernetes. Il remplace les API Ingress, Load Balancing et Service Mesh. Conçu pour être polyvalent, descriptif et centré 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 avancé de l'entrée et du maillage.
L'initiative GAMMA (API Gateway pour le service mesh) définit comment l'API Gateway peut également être utilisée pour le trafic interservices 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 préservant sa nature orientée rôle. GAMMA met également l'accent sur l'importance de promouvoir la cohérence entre les différentes implémentations de maillage de services de l'API Gateway, quelle que soit leur technologie ou leur 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, vous devez étendre les définitions de ressources de route (GRPCRoute ou HTTPRoute dans l'API Gateway) pour signaler le cas d'utilisation du service mesh, en particulier en associant les ressources de route aux ressources de service, comme décrit dans la section API Gateway pour le service mesh.
L'exemple suivant illustre le cas d'utilisation de la mise en réseau 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 service mesh. Dans l'exemple précédent, le service echo-service est spécifié comme parentRef, ce qui signifie que le HTTPRoute est associé à l'interface de echo-service. Tout trafic envoyé à echo-service par un client est acheminé conformément à la route echo-route HTTPRoute.
GRPCRoute est une autre ressource de l'API Kubernetes Gateway, qui permet de router le trafic gRPC vers des services Kubernetes. Les utilisateurs choisissent d'utiliser GRPCRoute au lieu d'HTTPRoute lorsqu'ils souhaitent acheminer spécifiquement le trafic gRPC et profiter des fonctionnalités adaptées à gRPC, telles que la mise en correspondance de la méthode et du service 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, ce GRPCRoute est configuré pour les cas d'utilisation du service mesh. Tout trafic envoyé à xds:///echo-service.default.svc.cluster.local:8080 par un client gRPC sans proxy est acheminé conformément à la route d'écho GRPCRoute. Les règles de routage de cet exemple correspondent à une méthode gRPC et acheminent le trafic vers un backendRef spécifique. GRPCRoutes peut également être utilisé pour acheminer les requêtes de clients proxy avec des injections sidecar, comme Envoy, lorsque le préfixe xds:/// est supprimé.
