Panoramica
Cloud Service Mesh fornisce funzionalità di networking dei servizi alle 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 Kubernetes Gateway. Queste API sono progettate per semplificare e migliorare l'esperienza complessiva di configurazione del mesh.
Le API Kubernetes Gateway per Mesh consentono di configurare Cloud Service Mesh per i deployment dei proxy Envoy e di gRPC senza proxy. L'API Gateway per il modello Mesh offre molti vantaggi importanti:
- Le API Gateway forniscono un'interfaccia singola e coerente per la gestione del traffico in entrata (nord-sud) e del mesh di servizi (est-ovest) all'interno del cluster Kubernetes.
- I mesh di servizi consentono l'utilizzo di pattern avanzati per il routing del traffico. Le API Gateway permettono di progettare e gestire regole di routing complesse.
- Con le API Gateway, gli sviluppatori possono concentrarsi sulla definizione di regole e policy di routing generali per i microservizi senza dover conoscere a fondo l'implementazione del mesh di servizi sottostante.
- L'API è progettata per essere estensibile, in modo da favorire i 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 per i mesh di servizi.
Il lavoro dell'iniziativa GAMMA per supportare i casi d'uso dei mesh di servizi fa parte del canale standard dalla versione 1.1.0 ed è considerato GA.
La specifica propone che il proprietario di un'applicazione definisca le regole di traffico per un servizio mesh configurando una Route resource (a volte chiamata xRoute) con una risorsa Kubernetes Service come parentRef. L'approccio dipende dai ruoli "frontend" e "backend" del Service di Kubernetes, 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, Load Balancing e Service Mesh. Progettata per essere versatile, descrittive e incentrata sui ruoli, le sue configurazioni si trovano principalmente nel livello di routing.
Le risorse specifiche del protocollo, come HTTPRoute e GRPCRoute, consentono il routing avanzato per traffico in entrata e mesh.
L'iniziativa GAMMA (Gateway API for Service Mesh) definisce in che modo l'API Gateway può essere utilizzata anche per il traffico est/ovest o tra servizi 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 basata sui 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 del mesh di servizi, in particolare associando le risorse di route alle risorse di servizio, come descritto in API Gateway per Service Mesh.
L'esempio seguente illustra il caso d'uso del 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
HTTPRoute fa riferimento a un Service come parentRef, il 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. Il traffico inviato a echo-service da un client viene instradato in base a all'echo-route HTTPRoute.
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 mostra 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
Come nel caso dell'esempio di HTTPRoute, questo GRPCRoute è configurato per i casi d'uso del mesh di servizi. Il traffico inviato a xds:///echo-service.default.svc.cluster.local:8080 da un client gRPC senza proxy viene instradato in base all'echo-route GRPCRoute. Le regole di routing in questo esempio corrispondono a un metodo gRPC e indirizzano il traffico a un
backendRef specifico. Le GRPCRoute possono essere utilizzate anche per instradare le richieste dai client proxy con inserimenti sidecar (ad esempio Envoy) quando viene eliminato il prefisso xds:///.
