Panoramica delle API di routing del servizio Cloud Service Mesh
Questo documento è rivolto agli amministratori di mesh o piattaforme e agli sviluppatori di servizi che hanno un livello di familiarità da intermedio a avanzato con Cloud Service Mesh e i concetti di mesh di servizi e che eseguono il deployment di Cloud Service Mesh su Compute Engine con le istanze VM. Questo documento riguarda i deployment che utilizzano client Envoy e gRPC. Per ulteriori informazioni sui concetti di Cloud Service Mesh, consulta la panoramica generale.
Cloud Service Mesh fornisce funzionalità di networking dei servizi alle tue applicazioni, tra cui gestione avanzata del traffico, osservabilità e sicurezza. Tuttavia, configurare e gestire un mesh di servizi è un'attività complessa per amministratori e sviluppatori di servizi.
Questo documento descrive le API di routing dei servizi per la configurazione di Cloud Service Mesh. Queste API sono progettate per semplificare e migliorare l'esperienza complessiva di configurazione del mesh.
Il modello di routing dei servizi utilizza risorse API chiamate Mesh
, Gateway
e Route
.
Queste risorse offrono un'esperienza di configurazione
contestuale per la definizione del piano di controllo del networking di servizi.
Questo documento introduce il seguente modello di API e risorse di routing dei servizi.
Mesh
risorsa- Configurazione della sicurezza e della gestione del traffico service-to-service (east-west) per proxy sidecar Envoy e client gRPC senza proxy.
-
- Configurazione della sicurezza e della gestione del traffico per i proxy Envoy che fungono da gateway in entrata, consentendo ai client esterni di connettersi al mesh di servizi (nord-sud).
Route
di risorse con i seguenti tipi:
La console Google Cloud non fornisce supporto per le API di routing dei servizi. Devi implementare queste risorse API utilizzando Google Cloud CLI o le API REST.
Casi d'uso e vantaggi
Le API di routing dei servizi consentono di configurare Cloud Service Mesh per i deployment di proxy senza proxy gRPC e Envoy. Il modello API di routing dei servizi offre diversi vantaggi chiave.
Nel diagramma seguente, due servizi nel mesh di servizi sono collegati da una risorsa Mesh
. Le due risorse HTTPRoute
configurano il routing. L'amministratore del mesh o della piattaforma gestisce la risorsa Mesh
e i due proprietari dei servizi creano la configurazione di routing per i loro servizi.
La progettazione delle API orientata ai ruoli consente una chiara separazione delle responsabilità
Le API di routing dei servizi consentono di separare le responsabilità di configurazione mesh in base ai ruoli dell'organizzazione:
- Gli amministratori di mesh possono definire il mesh logico e l'infrastruttura del gateway in entrata.
- I proprietari dei servizi (sviluppatori di applicazioni) possono definire in modo indipendente i pattern di accesso ai propri servizi. Possono anche definire e applicare criteri di gestione del traffico per i propri servizi.
Nel diagramma seguente, Cloud Load Balancing e una risorsa Gateway
forniscono un gateway in entrata per il traffico che entra nel mesh da un client che non si trova nel mesh. L'amministratore della rete mesh configura e gestisce la risorsa Gateway
, mentre i proprietari dei servizi configurano e gestiscono i propri servizi e il routing del traffico.
Affidabilità migliorata con il modello self-service
Le API di routing dei servizi utilizzano risorse per protocollo e per route che possono essere configurate e possedute da proprietari di servizi indipendenti. Questo approccio presenta diversi vantaggi.
- I proprietari dei servizi hanno autonomia nella configurazione dei criteri e della gestione del traffico per i servizi di loro proprietà.
- L'aggiornamento di una risorsa
Route
non influisce sulle altre risorseRoute
nella mesh. Il processo di aggiornamento è più affidabile perché i proprietari dei servizi gestiscono configurazioni ridotte. - Il proprietario del servizio responsabile del servizio o host di destinazione è proprietario di ogni risorsa
Route
. - I proprietari dei servizi non devono dipendere dagli amministratori del mesh per aggiornare il routing.
Abilita un mesh di servizi che comprende più progetti in ambienti VPC condiviso
Il modello di API di routing dei servizi consente ai proprietari dei servizi di partecipare a un'infrastruttura mesh condivisa utilizzando un VPC condiviso e altri mezzi di connettività, mantenendo al contempo un controllo indipendente sui propri servizi. Ad esempio, i proprietari dei servizi possono definire le risorse Route
nei propri progetti. Gli amministratori della piattaforma
possono definire un Mesh
in un progetto host amministrato centralmente e poi concedere ai proprietari
dei servizi le autorizzazioni IAM per collegare le loro risorse Route
a un elemento Mesh
o
Gateway
condiviso. Il seguente diagramma mostra un esempio di VPC condiviso.
Le API di routing dei servizi consentono inoltre di avere client mesh di servizi connessi a reti diverse utilizzando il peering di rete VPC.
Instrada il traffico in base all'indicatore del nome del server
La risorsa TLSRoute
ti consente di instradare il traffico criptato con TLS in base alla SNI (Server Name Indication) nell'handshake TLS. Puoi configurare il traffico TLS da instradare ai servizi di backend appropriati configurando la corrispondenza SNI nella risorsa TLSRoute
. In questi deployment, i proxy instradano solo il traffico e la sessione TLS viene terminata nell'istanza di backend di destinazione.
La risorsa TLSRoute
è supportata solo con i proxy Envoy di cui viene eseguito il deployment
come proxy o gateway sidecar.
TLSRoute
risorsa collegata a una risorsa Mesh
Il deployment mostrato nel seguente diagramma instrada qualsiasi traffico del mesh di servizi in cui l'estensione SNI ha il valore service1
al servizio di backend service1
. Inoltre, qualsiasi traffico del mesh di servizi in cui l'estensione SNI ha il valore service2
viene instradato al servizio di backend service2
. Il valore dell'estensione SNI e il nome del servizio di backend sono indipendenti l'uno dall'altro.
TLSRoute
risorsa e Mesh
risorsa (fai clic per ingrandire)TLSRoute
risorsa collegata a una risorsa Gateway
Il deployment mostrato nel seguente diagramma instrada tutto il traffico in entrata alla risorsa Gateway
in cui l'estensione SNI ha il valore serviceA
al servizio di backend serviceA
. Inoltre, tutto il traffico in entrata verso Gateway
in cui l'estensione SNI ha il valore serviceB
viene instradato al servizio di backend serviceB
. Il valore dell'estensione SNI e il nome
del servizio di backend sono indipendenti l'uno dall'altro. Anche il valore dell'estensione SNI e l'intestazione
nelle richieste HTTP sono indipendenti.
La risorsa Gateway
non termina la connessione TLS al proxy Envoy
di Gateway
. La connessione TLS viene invece terminata al servizio di backend corrispondente. Gateway
non può controllare le informazioni criptate nel livello TLS, ad eccezione del ClientHello
, che contiene un'estensione SNI in testo normale. Gateway
esegue il passthrough TLS in questa modalità. Tieni presente che la crittografia ClientHello
criptata non è supportata.
TLSRoute
risorsa e Gateway
risorsa (fai clic per ingrandire)Supporto gRPC principale
Puoi configurare client gRPC senza proxy utilizzando attributi gRPC principali, ad esempio la corrispondenza per metodo.
Suddivisione del traffico per il traffico TCP
Puoi implementare la suddivisione del traffico basata sui pesi per il traffico TCP su più servizi di backend. Puoi configurare pattern come le implementazioni canary (blu-verde) quando aggiorni il servizio. La suddivisione del traffico consente inoltre di eseguire la migrazione del traffico in modo controllato senza tempi di inattività.
Intercettazione del traffico
Quando utilizzi le risorse Mesh
e Gateway
dell'API di routing del servizio, tutto il traffico viene intercettato automaticamente. Per ulteriori informazioni, consulta Opzioni per la configurazione delle VM di Compute Engine con deployment automatico di Envoy.
Architettura e risorse
Questa sezione descrive il modello di API di routing dei servizi e le relative risorse e ti aiuta a comprendere come interagiscono le risorse dell'API di routing dei servizi.
Mesh
risorsa
La risorsa Mesh
rappresenta un'istanza di un mesh di servizi. per creare un mesh di servizi logico nel progetto. Ogni risorsa Mesh
deve avere un
nome univoco nel progetto. Dopo aver creato una risorsa Mesh
, il suo nome non può essere modificato.
Mesh
Risorsa API con sidecar Envoy e deployment gRPC senza proxy (fai clic per ingrandire)Nella risorsa Route
viene fatto riferimento alla risorsa Mesh
per aggiungere route per
i servizi che fanno parte del mesh.
I client proxy Envoy e gRPC senza proxy ricevono la configurazione da Cloud Service Mesh unendo il mesh di servizi identificato dal nome della risorsa Mesh
. La risorsa Mesh
supporta i seguenti deployment del piano dati:
- Envoy in esecuzione insieme all'applicazione come proxy sidecar
- Client gRPC senza proxy
- Combinazione di client gRPC Envoy e client gRPC proxyless
Route
risorsa
La risorsa Route
viene utilizzata per configurare il routing ai servizi. Esistono quattro diversi tipi di risorse API Route
. Definiscono il protocollo utilizzato per
instradare il traffico a un servizio di backend.
HTTPRoute
GRPCRoute
TCPRoute
TLSRoute
L'API non contiene l'API Route
parola per parola. Le uniche risorse API configurabili sono HTTPRoute
, GRPCRoute
, TCPRoute
e TLSRoute
.
La risorsa Route
fa riferimento a una o più risorse Mesh
e Gateway
per aggiungere le route che fanno parte della configurazione Mesh
o Gateway
corrispondente. Una risorsa Route
può fare riferimento alle risorse Gateway
e
Mesh
.
La risorsa Route
fa anche riferimento a una o più risorse del servizio di backend. I servizi vengono configurati utilizzando l'API del servizio di backend. Crei una risorsa del servizio di backend che punta a uno o più backend MIG o NEG.
Il seguente diagramma mostra le relazioni tra le risorse Mesh
, Gateway
e Route
, nonché la risorsa del servizio di backend e i relativi backend.
Route
Risorse API (fai clic per ingrandire)Sei tu a definire altre funzionalità di gestione del traffico, come routing, modifiche delle intestazioni, timeout e suddivisione del traffico basata sui pesi nelle risorse Route
.
Ad esempio, nel diagramma seguente, una risorsa HTTPRoute
definisce una suddivisione del traffico del 70% / 30%
tra due servizi di backend.
Per semplificare l'amministrazione del mesh di servizi, puoi elencare tutte le risorse Route
collegate a una risorsa Mesh
o Gateway
.
TLSRoute
risorsa
Utilizza la risorsa TLSRoute
per instradare il traffico TLS ai servizi di backend in base ai
nomi host SNI e al nome ALPN (Application- Layer Protocol Negoziazione). TLSRoute
implica il passthrough TLS, in cui il proxy Envoy non termina il traffico TLS.
La risorsa TLSRoute
fa riferimento a una o più risorse Mesh
e Gateway
per
aggiungere le route che fanno parte della configurazione mesh o gateway corrispondente.
La risorsa TLSRoute
fa anche riferimento a una o più risorse del servizio di backend.
I servizi vengono configurati utilizzando la risorsa API del servizio di backend.
Gateway
risorsa
La risorsa Gateway
viene utilizzata per rappresentare i proxy Envoy che fungono da gateway in entrata, consentendo ai client esterni di connettersi al mesh di servizi (traffico nord-sud). Questa risorsa ha porte di ascolto e un parametro scope
. Il proxy Envoy che agisce come gateway in entrata si collega alle porte specificate e a 0.0.0.0
, che rappresenta tutti gli indirizzi IP sulla VM locale. Il seguente diagramma mostra i proxy Envoy di cui è stato eseguito il deployment come servizio in entrata e configurati dalla risorsa Gateway
. In questo esempio specifico, i proxy Envoy sono configurati per rimanere in ascolto sulla porta 80 per le connessioni in entrata dai client.
La risorsa API Gateway
supporta solo il piano dati del proxy Envoy. Non supporta gRPC senza proxy. gRPCRoutes
sono supportati nella risorsa Gateway
,
ma il traffico gRPC viene instradato dal proxy Envoy, che funge da proxy intermedio.
Gateway
(fai clic per ingrandire)Gateway
risorsa (fai clic per ingrandire)Che cosa sono un ambito Gateway
e una configurazione Gateway
unita?
Un'istanza di risorsa Gateway
rappresenta le porte e la configurazione specifiche del traffico ricevuto su quelle porte. La risorsa API Gateway
contiene il parametro scope
, utilizzato per raggruppare e unire logicamente la configurazione di due o più risorse Gateway
.
Ad esempio, se vuoi che i proxy Gateway
rimangano in ascolto sulle porte 80 e 443 per ricevere rispettivamente traffico HTTP e HTTPS, crea due risorse Gateway
.
Configura una risorsa Gateway
con la porta 80 per il traffico HTTP e l'altra
con 443 per il traffico HTTPS. Assegna lo stesso valore al campo scope
.
Cloud Service Mesh unisce dinamicamente le singole configurazioni di tutti i gateway che hanno lo stesso ambito. Sul lato del piano dati, anche i proxy Envoy che vengono eseguiti in modalità gateway in entrata devono presentare lo stesso parametro di ambito a Cloud Service Mesh per ricevere la configurazione Gateway
. Tieni presente che
specifica l'ambito quando crei la risorsa Gateway
e specifichi lo stesso
ambito del parametro di bootstrap per i proxy.
Gateway
Comportamento di unione risorse (fai clic per ingrandire)Di seguito sono riportate le considerazioni chiave per la risorsa Gateway
:
- Il parametro di ambito
Gateway
è obbligatorio. Specifica l'ambito nella risorsaGateway
e nella configurazione di bootstrap dei proxy Envoy anche quando esiste un soloGateway
. - La creazione di una risorsa
Gateway
non esegue il deployment di un servizio con un proxy Envoy. Il deployment del proxy Envoy è un passaggio separato. - La risorsa
Gateway
ha untype
che rappresenta il tipo di deployment in entrata. Questo campo è riservato per uso futuro. L'unico valore attualmente supportato èOPEN_MESH
, che è il valore predefinito e che non può essere modificato.
Deployment di mesh con protocolli e piani dati misti
Puoi avere un deployment del piano dati misto con proxy Envoy e gRPC senza proxy nello stesso mesh. Quando crei questi deployment, considera quanto segue.
- I deployment sidecar di Envoy supportano tutte le route (
HTTPRoute
,GRPCRoute
,TCPRoute
eTLSRoute
). - I deployment gRPC senza proxy supportano solo
GRPCRoute
. GRPCRoute
è limitato alle funzionalità supportate solo dai deployment senza proxy gRPC.
Topologie supportate in ambienti VPC condiviso multiprogetto
Cloud Service Mesh supporta l'aggiunta di risorse Route
definite in altri progetti a una risorsa Mesh
o Gateway
definita in un progetto di amministrazione centralizzato. I proprietari dei servizi autorizzati possono aggiungere direttamente le proprie configurazioni di routing dei servizi a Mesh
o Gateway
.
Mesh
e Route
risorse (fai clic per ingrandire)In un tipico scenario tra progetti, scegli un progetto (progetto host o progetto di amministrazione controllata centralmente) come progetto di amministrazione mesh in cui crei una risorsa Mesh
. Il proprietario del progetto di amministrazione mesh autorizza le risorse Route
di altri progetti a fare riferimento alla risorsa Mesh
, consentendo alla configurazione del routing di altri progetti di far parte della rete. Un piano dati mesh, sia Envoy che
gRPC, richiede la configurazione al progetto di amministrazione e riceve un'unione di tutte
le route collegate a Mesh
. Per un Gateway
, le route
vengono unite anche in tutte le Gateways
che utilizzano lo stesso ambito.
Il progetto di amministrazione Mesh
può essere qualsiasi progetto di tua scelta e la configurazione funziona purché i progetti sottostanti dispongano di connettività di rete VPC, tramite VPC condiviso o peering di rete VPC.
Autorizzazioni e ruoli IAM
Di seguito sono riportate le autorizzazioni IAM necessarie per ottenere, creare, aggiornare, eliminare, elencare e utilizzare in modo sicuro le risorse Mesh
e Route
.
- Gli amministratori di mesh devono disporre delle autorizzazioni
networkservices.mesh.*
. - Gli amministratori del gateway devono disporre delle autorizzazioni
networkservices.gateways.*
. - I proprietari del servizio devono disporre delle autorizzazioni
networkservices.grpcRoutes.*
,networkservices.httpRoutes.*
onetworkservices.tcpRoutes.*
.
Gli amministratori di mesh devono concedere l'autorizzazione networkservices.mesh.use
ai proprietari del servizio
in modo che i proprietari del servizio possano collegare le proprie risorse Route
alla
risorsa Mesh
. Lo stesso modello si applica a Gateway
risorse.
Per visualizzare tutte le autorizzazioni IAM per le risorse Mesh
, vai alla pagina di riferimento delle autorizzazioni IAM e cerca meshes
.
Non sono necessari altri ruoli predefiniti. Il ruolo esistente predefinito Amministratore rete Compute (roles/compute.networkAdmin
) ha autorizzazioni networkservices.*
per impostazione predefinita.
Potrebbe essere necessario aggiungere ai ruoli
personalizzati le autorizzazioni descritte in precedenza.
Considerazioni e limitazioni
- La console Google Cloud non supporta le API di routing dei servizi.
- Utilizza l'API xDS versione 3 o successiva.
- Versione minima di Envoy 1.20.0 (poiché le API di routing dei servizi sono supportate solo su xDS versione 3)
- Versione minima del generatore di bootstrap gRPC v0.14.0
- La risorsa
TLSRoute
è supportata solo con i proxy Envoy di cui viene eseguito il deployment come proxy o gateway sidecar. - Sono supportate solo le VM di Compute Engine con deployment Envoy automatico e pod GKE con inserimento Envoy automatico. Non puoi utilizzare il deployment manuale con le API di routing dei servizi.
- Le API di routing dei servizi non sono compatibili con le versioni precedenti.
- Quando una risorsa
TCPRoute
è collegata a una risorsaMesh
, la porta utilizzata per la corrispondenza del traffico TCP non può essere utilizzata per gestire nulla, ad eccezione del traffico descritto daTCPRoute
.- Ad esempio, i deployment potrebbero includere una risorsa
TCPRoute
che corrisponde alla porta "8000" e una risorsa HttpRoute. Quando entrambi sono collegati alla stessa risorsaMesh
, il traffico instradato dalla risorsaHTTPRoute
non può utilizzare la porta 8000 anche se gli indirizzi IP sottostanti sono diversi. Questa limitazione deriva dall'implementazione del proxy Envoy, che assegna prima la precedenza alla route corrispondente per porta.
- Ad esempio, i deployment potrebbero includere una risorsa
- La risorsa
Gateway
non esegue il provisioning di un bilanciatore del carico gestito e non crea in modo dinamico un servizio Envoy. - Gli Envoy di cui è stato eseguito il deployment automatico che fungono da gateway in entrata non devono avere l'argomento
serving_ports
nel flag--service-proxy
. - Envoy distribuito automaticamente non supporta la fornitura di un numero di progetto diverso da quello della VM.
Passaggi successivi
- Per informazioni su come elencare le risorse di route associate a una risorsa
Mesh
oGateway
, consulta Elencare le risorse diRoute
. Questa funzionalità è in anteprima. - Per informazioni sulle API di routing dei servizi, leggi la documentazione relativa alle API dei servizi di rete.