Panoramica del mesh di servizi GKE di Cloud Service Mesh

Questa configurazione è supportata per i clienti della versione di anteprima, ma non è consigliata per i nuovi utenti di Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Questo documento è destinato agli utenti di Google Kubernetes Engine che vogliono eseguire il deployment di un mesh di servizi Cloud Service Mesh utilizzando l'API Kubernetes Gateway.

Puoi configurare Cloud Service Mesh per GKE utilizzando le API Kubernetes Gateway, abilitando la comunicazione da servizio a servizio, la gestione del traffico, il bilanciamento del carico globale e l'applicazione dei criteri di sicurezza per i casi d'uso di service mesh.

API Kubernetes e API Google Cloud

Puoi configurare un mesh di servizi Cloud Service Mesh utilizzando due API diverse:

Questo documento e le guide alla configurazione associate forniscono istruzioni per l'utilizzo dell'API Kubernetes Gateway per configurare un mesh di servizi Cloud Service Mesh.

Ti consigliamo di utilizzare le API Kubernetes Gateway su Google Kubernetes Engine e sconsigliamo di utilizzare entrambe le API per configurare il routing nella stessa mesh di servizi su GKE.

L'API di routing dei servizi utilizza gli stessi nomi delle risorse delle risorse nelle API Kubernetes Gateway, il che semplifica l'utilizzo delle due API. Le risorse Kubernetes che configuri sono funzionalmente equivalenti alle risorse Google Cloud rappresentate dall'API di routing dei servizi per Cloud Service Mesh.

Le sezioni seguenti descrivono le risorse e l'architettura utilizzate dall'integrazione di Cloud Service Mesh con le API Kubernetes Gateway.

API Gateway

L'API Gateway è una raccolta di risorse che modellano il networking di servizi in Kubernetes. L'API Gateway di Kubernetes è un progetto open source incentrato sul supporto dei casi d'uso di Ingress e del bilanciamento del carico, fornendo un'API di routing generica. L'API di routing generica ha molte implementazioni. Le definizioni di risorse personalizzate (CRD) di Cloud Service Mesh vengono aggiunte come estensione dell'API Gateway open source. I CRD supportano i casi d'uso mesh di servizi e utilizzano la stessa API di routing generica introdotta dall'API Gateway.

L'API Gateway è organizzata in modo gerarchico, con una risorsa principale Gateway e GatewayClass associato, a cui colleghi le route. GKE include una risorsa TDMesh che è peer della risorsa Gateway. Puoi collegare gli stessi tipi di Route alla risorsa TDMesh. La risorsa TDMesh è dove collegare route e criteri per i service mesh.

API Gateway, risorsa Gateway, risorsa Mesh e route
API Gateway, risorsa Gateway, risorsa Mesh e route (fai clic per ingrandire)

Parco risorse

Un parco risorse è costituito da uno o più cluster GKE raggruppati in modo logico. Un parco risorse consente di gestire le funzionalità e applica i criteri in modo coerente su più cluster. Quando utilizzi un parco risorse, puoi gestire un mesh di servizi Cloud Service Mesh che si estende su più cluster.

Architettura

Cloud Service Mesh supporta l'API Gateway su GKE programmando i data plane dei cluster per implementare i comportamenti di rete specificati nelle risorse API Gateway. Cloud Service Mesh è un control plane gestito da Google che non elabora alcun traffico del piano dati. I proxy Envoy in esecuzione come sidecar dei tuoi carichi di lavoro o i client gRPC proxyless elaborano il traffico nel piano dati. Cloud Service Mesh configura sia i proxy Envoy sia i client gRPC senza proxy tramite l'API xDSv3.

Cloud Service Mesh offre una soluzione di control plane gestita e disponibile a livello globale, più solida e scalabile rispetto all'esecuzione di controller in-cluster. Poiché è una soluzione globale, Cloud Service Mesh può bilanciare il carico del traffico tra i carichi di lavoro distribuiti su più cluster GKE. Nell'illustrazione seguente, Cloud Service Mesh gestisce il traffico verso i servizi in tre cluster che si trovano in un'unica flotta, utilizzando le risorse dell'API Gateway.

Un service mesh di servizi multicluster Cloud Service Mesh configurato utilizzando l'API Gateway
Una mesh di servizi multicluster Cloud Service Mesh configurata utilizzando l'API Gateway (fai clic per ingrandire)

Designi un cluster nel tuo parco risorse come cluster di configurazione. Il cluster di configurazione è il luogo in cui vengono archiviate le risorse API Gateway. Cloud Service Mesh osserva solo le risorse che si trovano nel cluster di configurazione e ignora le risorse che si trovano in altri cluster del parco progetti. Per informazioni più dettagliate sul cluster di configurazione, consulta Progettazione del cluster di configurazione nella documentazione di GKE.

Con i servizi multicluster di GKE, le risorse API Gateway nel cluster di configurazione possono fare riferimento ai servizi Kubernetes in qualsiasi cluster all'interno di un parco risorse. Per saperne di più su Multi-Cluster Service Discovery, consulta Servizi multi-cluster.

Risorse

Cloud Service Mesh supporta sia i proxy Envoy sia gRPC senza proxy nel piano dati di un mesh di servizi. Entrambi i client ricevono la configurazione da Cloud Service Mesh per una determinatamesh di servizih, specificando il nome e il numero di progetto corrispondente della risorsa TDMesh nella rispettiva configurazione di bootstrap. Le guide alla configurazione di Cloud Service Mesh con le API Kubernetes Gateway forniscono configurazioni del piano dati dimostrative con Envoy e gRPC proxyless.

TDMesh risorsa

La risorsa TDMesh è una risorsa personalizzata di Cloud Service Mesh. È un'estensione delle API Gateway open source per supportare i casi d'uso del mesh di servizi di Cloud Service Mesh. Utilizzando la risorsa TDMesh, crei un'istanza di mesh di servizi nel tuo parco risorse. Le route associate alla risorsa TDMesh specificano i comportamenti di routing da servizio a servizio nemesh di servizish.

Route risorse

Un sottoinsieme delle risorse Route API Gateway può essere collegato a una risorsa TDMesh per specificare il routing a livello di servizio all'interno del mesh di servizi. Cloud Service Mesh supporta le seguenti risorse Route:

  • HTTPRoute
  • TCPRoute
  • TDGRPCRoute (risorsa personalizzata Cloud Service Mesh)

Ad esempio, puoi creare un HTTPRoute per specificare che le richieste HTTP destinate all'host payments.svc.internal vengono indirizzate al servizio Kubernetes service-payments. Quando colleghi la risorsa HTTPRoute a una risorsa TDMesh a cui sono sottoscritte le istanze del data plane, le richieste HTTP inviate dai carichi di lavoro all'interno del mesh vengono indirizzate di conseguenza.

Questa release aumenta le risorse Route generiche nell'API Gateway con un nuovo tipo di route, TDGRPCRoute. Il nuovo tipo di route offre un'esperienza di prima classe per il routing delle richieste gRPC, tramite la corrispondenza con primitive gRPC native, come le definizioni di metodi e servizi.

Utilizzo delle risorse API Gateway in GKE per configurare Cloud Service Mesh
Utilizzo delle risorse dell'API Gateway in GKE per configurare Cloud Service Mesh (fai clic per ingrandire)

Limitazioni

  • Cloud Service Mesh configura i seguenti comportamenti predefiniti per tutti i servizi Kubernetes nel mesh di servizi. Non puoi modificare questi comportamenti.
    • I controlli di integrità TCP sono configurati sulle porte di servizio a cui fanno riferimento tutte le risorse Route dell'API Gateway.
    • Per tutte le richieste in entrata ai servizi è configurato un timeout predefinito di 30 secondi.
    • Affinità sessione è disattivata.
  • L'iniettore automatico Envoy supporta una sola mesh per flotta.
  • Le funzionalità di sicurezza di Cloud Service Mesh non possono essere abilitate utilizzando l'API Gateway.
  • Devi configurare le risorse TDMesh e Route su GKE utilizzando solo l'API Gateway. Non puoi utilizzare la consoleGoogle Cloud , gcloud CLI o le API REST.
  • Tutti i cluster devono trovarsi in un unico progetto. Una mesh di servizi che si estende su più cluster in più progetti non è supportata.
  • Non puoi configurare o visualizzare un mesh di servizi GKE utilizzando la console Google Cloud .
  • L'osservabilità del control plane con Cloud Logging e Cloud Monitoring non è supportata.

Passaggi successivi