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 API Gateway. Queste API sono progettate per semplificare e migliorare l'esperienza complessiva di configurazione della maglia.

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 fondamentali:

  • 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.
  • I mesh di servizi abilitano pattern avanzati di routing del traffico. 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 di alto livello e i criteri al proprio microservizio senza il bisogno di una conoscenza approfondita del l'implementazione del mesh di servizi sottostante.
  • L'API è progettata per essere estensibile, consentendo miglioramenti e il supporto di 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.

L'iniziativa GAMMA lavora per i casi d'uso del mesh di servizi fanno parte del canale standard fin dal v1.1.0 ed è considerata 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 Nome Service per corrispondere al traffico e backendRef endpoint per l'IP canonico indirizzi IP esterni.

API Gateway per Mesh

L'API Gateway, un servizio incentrato sul routing di livello 4 e 7 all'interno di Kubernetes. Riuscita a Ingress, API di bilanciamento del carico e Service Mesh. Progettati per essere versatili, descrittivi e il ruolo, le sue configurazioni si trovano principalmente nel livello 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 tra i servizi o traffico 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 varie implementazioni di mesh di servizi dell'API Gateway, indipendentemente la tecnologia o il proxy sottostante.

GAMMA sfrutta i punti di estensione 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 del mesh nell'uso 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 Service come parentRef, che indica che La route HTTPRoute è configurata per il caso 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. Qualsiasi traffico inviato al servizio echo da un client viene instradato in base alla route echo di HTTPRoute.

GRPCRoute è un'altra risorsa API Gateway di Kubernetes, utilizzata per il routing Traffico gRPC verso i servizi Kubernetes. Gli utenti scelgono di utilizzare GRPCRoute anziché HTTPRoute quando vogliono instradare specificamente il traffico gRPC e sfruttare di funzionalità su misura per gRPC, ad esempio il metodo gRPC e la corrispondenza dei servizi.

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, questa GRPCRoute è configurata per il mesh di servizi e casi d'uso specifici. Qualsiasi 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. GRPCRoutes può essere utilizzato anche per instradare le richieste da client sottoposti a proxy con iniezioni di file collaterali, come Envoy, quando il prefisso xds:/// viene eliminato.

Diagramma del mesh a cluster singolo

Passaggi successivi