Panoramica

Cloud Service Mesh fornisce funzionalità di networking dei servizi alle tue applicazioni, tra cui gestione del traffico, osservabilità e sicurezza avanzate. Tuttavia, configurare e gestire un mesh di servizi è un'attività complessa. Questa pagina descrive la configurazione di Cloud Service Mesh con le API Gateway di Kubernetes. Queste API sono progettate per semplificare e migliorare l'esperienza complessiva di configurazione della mesh.

Le API Kubernetes Gateway per Mesh consentono di configurare Cloud Service Mesh per i deployment di gRPC proxyless e del proxy Envoy. L'API Gateway per il modello Mesh offre diversi vantaggi chiave:

  • Le API Gateway forniscono un'interfaccia singola e coerente per la gestione del traffico in entrata (nord-sud) e mesh di servizi (est-ovest) all'interno del cluster Kubernetes.
  • I service mesh consentono pattern di routing del traffico avanzati. Le API gateway ti consentono di progettare e gestire regole di routing complesse.
  • Con le API Gateway, gli sviluppatori possono concentrarsi sulla definizione di regole di routing e policy di alto livello per il proprio microservizio senza dover conoscere a fondo l'implementazione di mesh di servizi sottostante.
  • L'API è progettata per essere estensibile, consentendo miglioramenti futuri e il supporto di nuovi protocolli e casi d'uso.
  • Le API Gateway hanno un forte sostegno della community e sono supportate da un ecosistema in crescita di fornitori e strumenti di mesh di servizi.

Il lavoro dell'iniziativa GAMMA per supportare i casi d'uso delmesh di servizih fa parte del canale standard dalla versione 1.1.0 ed è considerato GA.

La spec propone che il proprietario di un'applicazione configuri le regole di traffico per un servizio mesh configurando un Route resource (a volte chiamato xRoute) con una risorsa Kubernetes Service come parentRef. L'approccio dipende dai ruoli "frontend" e "backend" di Kubernetes Service, come definiti in GEP-1324: Service Mesh in Gateway API, dove il ruolo "frontend" viene utilizzato come parentRef e il ruolo "backend" di Service viene utilizzato come backendRef. L'implementazione conforme utilizza il nome Service per trovare la corrispondenza con il traffico e gli endpoint backendRef per gli indirizzi IP canonici.

API Gateway per Mesh

L'API Gateway, un progetto Kubernetes, si concentra sul routing di livello 4 e 7 all'interno di Kubernetes. Sostituisce le API Ingress, bilanciamento del carico e service mesh. Progettate per essere versatili, descrittive e incentrate sui ruoli, le sue configurazioni si trovano principalmente nel livello di routing. Le risorse specifiche del protocollo, come HTTPRoute e GRPCRoute, consentono l'instradamento avanzato di Ingress e mesh.

L'iniziativa GAMMA (Gateway API for Service Mesh) definisce come Gateway API può essere utilizzato anche per il traffico tra servizi o est/ovest all'interno dello stesso cluster. GAMMA mira a stabilire come utilizzare l'API Gateway per configurare un mesh di servizi con modifiche minime all'API Gateway, mantenendo la sua natura orientata ai ruoli. GAMMA sottolinea inoltre l'importanza di promuovere la coerenza tra le varie implementazioni del mesh di servizi dell'API Gateway, indipendentemente dalla tecnologia o dal proxy sottostanti.

GAMMA sfrutta i punti di estensione esistenti nella specifica dell'API Gateway, senza richiedere modifiche all'API o nuove risorse. Ciò avviene estendendo le definizioni delle risorse di route (GRPCRoute o HTTPRoute nell'API Gateway) per segnalare il caso d'uso mesh di servizi, in particolare associando le risorse di route alle risorse di servizio come descritto in API Gateway per il service mesh.

L'esempio seguente illustra il caso d'uso della mesh nell'utilizzo di 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

Diagramma HTTPRoute

HTTPRoute fa riferimento a un Service come parentRef, il che indica che la route HTTPRoute è configurata per lo scenario d'uso del mesh di servizi. Nell'esempio precedente, il servizio echo-service è specificato come parentRef, il che significa che HTTPRoute è collegato al frontend di echo-service. Il traffico inviato a echo-service da un client viene instradato in base a HTTPRoute echo-route.

GRPCRoute è un'altra risorsa dell'API Gateway di Kubernetes, utilizzata per instradare il traffico gRPC ai servizi Kubernetes. Gli utenti scelgono di utilizzare GRPCRoute anziché HTTPRoute quando vogliono instradare in modo specifico il traffico gRPC e sfruttare funzionalità personalizzate per gRPC, come la corrispondenza di metodi e servizi gRPC.

Il seguente esempio illustra l'utilizzo di 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

Diagramma GRPCRoute

Come l'esempio di HTTPRoute, questo GRPCRoute è configurato per i casi d'uso mesh di servizi. Il traffico inviato a xds:///echo-service.default.svc.cluster.local:8080 da un client gRPC proxyless viene instradato in base alla route di echo GRPCRoute. Le regole di routing in questo esempio corrispondono a un metodo gRPC e indirizzano il traffico a un backendRef specifico. Le GRPCRoutes possono essere utilizzate anche per instradare le richieste dai client proxy con iniezioni sidecar, come Envoy, quando viene eliminato il prefisso xds:///.

Diagramma della mesh a cluster singolo

Passaggi successivi