Présentation

Cloud Service Mesh fournit des fonctionnalités de mise en réseau de services à vos y compris 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 l'API Kubernetes les API de passerelle. Ces API sont conçues pour simplifier et améliorer votre maillage global de configuration.

Les API Kubernetes Gateway pour le maillage vous permettent de configurer Cloud Service Mesh pour à la fois pour les déploiements de proxys gRPC et Envoy sans proxy. API Gateway pour le modèle de maillage présente 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 permettent pour concevoir et 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 de routage de haut niveau et des règles à leur microservice sans avoir besoin de connaissances approfondies l'implémentation sous-jacente du maillage de services.
  • L'API est conçue pour être extensible, permettant d'effectuer de futures améliorations et de nouveaux protocoles et cas d'utilisation.
  • Les API Gateway bénéficient d'un soutien important de la communauté et d'un écosystème croissant de fournisseurs et d'outils de service mesh.

L'initiative GAMMA s'applique la prise en charge des cas d'utilisation du maillage de services fait partie du canal standard depuis v1.1.0 et est considérée comme DG.

La spec propose qu'un propriétaire d'application configure des règles de trafic pour un réseau maillé 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 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 Nom de Service correspondant au trafic et aux points de terminaison backendRef de l'adresse IP canonique des adresses IP externes.

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 axé 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 de passerelle) pour Service Mesh) définit la manière dont l'API Gateway peut également être utilisée pour l'interservice ou trafic est/ouest au sein d'un même cluster. L'objectif de GAMMA est d'apprendre à utiliser l'API Gateway pour configurer un maillage de services avec un minimum de modifications à apporter à l'API Gateway, tout en en maintenant une approche axée sur les rôles de la nature. GAMMA met également en avant l'importance de favoriser la cohérence entre différentes implémentations de maillage de services de l'API Gateway, quelles que soient leurs la technologie ou le proxy sous-jacent.

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. Cela se fait en étendant la ressource de route (GRPCRoute ou HTTPRoute dans le API Gateway) pour signaler le cas d'utilisation du maillage de services, spécifiquement en associant les ressources de routage avec les ressources de service, comme décrit dans API Gateway pour le maillage de services

L'exemple suivant illustre le cas d'utilisation du réseau maillé dans le cadre de 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

Diagramme HTTPRoute

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 sert à acheminer Trafic gRPC vers les services Kubernetes. Les utilisateurs choisissent d'utiliser GRPCRoute au lieu de HTTPRouter lorsqu'ils souhaitent acheminer spécifiquement le trafic gRPC et profiter de fonctionnalités conçues pour gRPC, telles que la mise en correspondance des méthodes et 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

Schéma GRPCRoute

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ée selon la route echo-route de GRPCRoute. La les règles de routage de cet exemple correspondent à une méthode gRPC et acheminent le trafic des backendRef spécifiques. Les routes gRPC peuvent aussi être utilisées pour acheminer les requêtes les clients utilisant un proxy avec des injections side-car, comme Envoy, lorsque le préfixe xds:/// est supprimé.

Schéma de maillage à cluster unique

Étape suivante