Panoramica

Cloud Service Mesh fornisce funzionalità di networking di servizi al tuo applicazioni, tra cui gestione avanzata del traffico, osservabilità e sicurezza. Tuttavia, la configurazione e il funzionamento di un mesh di servizi sono 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 il mesh complessivo durante la configurazione.

Le API gateway di Kubernetes per Mesh ti consentono di configurare Cloud Service Mesh per su deployment di proxy sia gRPC che proxy Envoy. L'API Gateway per il modello Mesh offre diversi vantaggi fondamentali:

  • Le API gateway forniscono un'unica interfaccia coerente per la gestione sia del traffico in entrata del traffico (nord-sud) e del mesh di servizi (est-ovest) all'interno di Kubernetes in un cluster Kubernetes.
  • I mesh di servizi abilitano pattern avanzati di routing del traffico. Le API del gateway consentono di progettare e gestire complesse regole di routing.
  • 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 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.

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.

Le spec propone al proprietario di un'applicazione di configurare le regole di traffico per un mesh servizio configurando un Route resource (a volte denominato 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 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. Risorse specifiche del protocollo come HTTPRoute e GRPCRoute abilitano in entrata e nel routing 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. GAMMA mira a stabilire come utilizzare l'API Gateway per configurare un mesh di servizi con modifiche minime all'API Gateway il proprio ruolo orientato natura. 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, richiedendo senza modifiche all'API o nuove risorse. Questo viene fatto estendendo la risorsa di route Definizioni (GRPCRoute o HTTPRoute nel Gateway) per segnalare il caso d'uso del mesh di servizi, in particolare associando eseguire il routing delle risorse con le risorse di servizio, come descritto 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 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 è associato al frontend di echo-service. Tutto il traffico inviato a echo-service da un client viene instradato in base alla route echo-route HTTP.

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, 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 senza proxy 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 mesh a cluster singolo

Passaggi successivi