Panoramica

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

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

  • Le API Gateway forniscono un'interfaccia singola e coerente per gestire il traffico in entrata (nord-sud) e del mesh di servizi (est-ovest) all'interno del cluster Kubernetes.
  • Le mesh di servizi 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 criteri di alto livello per il proprio microservizio senza dover conoscere in modo approfondito l'implementazione del mesh di servizi sottostante.
  • L'API è progettata per essere estensibile, consentendo miglioramenti futuri e supporta nuovi protocolli e casi d'uso.
  • Le API Gateway hanno un solido supporto della community e sono supportate da un crescente ecosistema di fornitori e strumenti di mesh di servizi.

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

La specifica propone che un proprietario dell'applicazione debba configurare le regole di traffico per un servizio di mesh configurando un Route resource (a volte indicato come xRoute) con una risorsa Service Kubernetes 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 abbinare 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, Load Balancing e Service Mesh. Progettato per essere versatile, descrittivo e incentrato sui ruoli, le sue configurazioni si trovano principalmente nel livello di routing. Le risorse specifiche per il protocollo, come HTTPRoute e GRPCRoute, consentono l'instradamento avanzato di ingressi e mesh.

L'iniziativa GAMMA (API Gateway per Service Mesh) definisce in che modo l'API Gateway può essere utilizzata anche per il traffico interservizio o Est/Ovest all'interno dello stesso cluster. L'obiettivo di GAMMA è stabilire come utilizzare l'API Gateway per configurare un'architettura a mesh di servizi con modifiche minime all'API Gateway, mantenendone al contempo la natura orientata ai ruoli. GAMMA sottolinea inoltre l'importanza di promuovere la coerenza tra le varie implementazioni di mesh di servizi dell'API Gateway, indipendentemente dalla tecnologia o dal proxy sottostanti.

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

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 il percorso HTTPRoute è configurato per il caso d'uso del mesh di servizi. Nell'esempio precedente, il servizio echo-service è specificato come parentRef, il che significa che HTTPRoute è associato al frontend di echo-service. Qualsiasi traffico inviato al servizio echo da un client viene instradato in base alla route echo di HTTPRoute.

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

L'esempio seguente 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

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

Diagramma del mesh a cluster singolo

Passaggi successivi