Panoramica delle API di routing dei servizi Cloud Service Mesh
Questo documento è rivolto ad amministratori di mesh o piattaforme e sviluppatori di servizi che hanno un livello di familiarità intermedio o avanzato con i concetti di Cloud Service Mesh e service mesh e che eseguono il deployment di Cloud Service Mesh su Compute Engine con istanze VM. Questo documento si applica ai deployment che utilizzano client Envoy e gRPC. Per ulteriori informazioni Concetti di Cloud Service Mesh, consulta la panoramica generale.
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 è un compito complesso per gli amministratori del mesh e gli 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 durante la configurazione mesh.
Il modello di routing del servizio utilizza risorse API denominate Mesh
, Gateway
e Route
.
Queste risorse forniscono un'esperienza di configurazione pertinente al contesto quando definisci il piano di controllo della rete di servizi.
Questo documento illustra il seguente modello e le seguenti risorse dell'API di routing dei servizi.
Mesh
resource- Gestione e sicurezza del traffico service-to-service (est-ovest) per i proxy sidecar di Envoy e i client gRPC senza proxy.
-
- Configurazione della gestione del traffico e della sicurezza per i proxy Envoy che fungono da gateway in entrata, consentendo ai client esterni di connettersi dal mesh di servizi (nord-sud).
Risorse
Route
con i seguenti tipi:
La console Google Cloud non fornisce assistenza 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 ti consentono di configurare Cloud Service Mesh per deployment di proxy Envoy e gRPC senza proxy. Il modello di API di routing dei servizi offre diversi vantaggi fondamentali.
Nel seguente diagramma, due servizi nel mesh di servizi sono collegati da una risorsa Mesh
. Le due risorse HTTPRoute
configurano il routing. La rete mesh
amministratore di piattaforma gestisce la risorsa Mesh
e i due proprietari del servizio creano
e la configurazione del routing per i loro servizi.
La progettazione di API basate sui ruoli consente una separazione chiara delle responsabilità
Le API di routing dei servizi consentono di separare la configurazione mesh responsabilità basate sui ruoli organizzativi:
- Gli amministratori della rete mesh possono definire il mesh logico e il traffico in entrata dell'infrastruttura Gateway.
- I proprietari di servizi (sviluppatori di applicazioni) possono definire in modo indipendente i pattern di accesso per i propri servizi. Possono anche definire e applicare criteri di gestione del traffico per i propri servizi.
Nel seguente diagramma, Cloud Load Balancing e una risorsa Gateway
forniscono una gateway di ingresso per il traffico che entra nel mesh da un client che non fa parte del mesh. L'amministratore della rete mesh configura e gestisce Gateway
mentre i proprietari dei servizi configurano e gestiscono i propri servizi
routing del traffico.
Affidabilità migliorata con il modello self-service
Le API di instradamento dei servizi utilizzano risorse per protocollo e per percorso che possono essere configurate e di proprietà di proprietari di servizi indipendenti. Questo approccio presenta diversi vantaggi.
- I proprietari di servizi hanno autonomia su come configurare le norme e la gestione del traffico per i servizi di loro proprietà.
- L'aggiornamento di una risorsa
Route
non influisce sulle altre risorseRoute
nel mesh. Il processo di aggiornamento è più affidabile perché i proprietari dei servizi per gestire configurazioni di piccole dimensioni. - Il proprietario del servizio responsabile del servizio di destinazione o del nome host è proprietario di ogni risorsa
Route
. - I proprietari di servizi non devono fare affidamento sugli amministratori del mesh per aggiornare il routing.
Abilita un service mesh che si estende su più progetti in ambienti VPC condivisi
Il modello dell'API di routing dei servizi consente ai proprietari di servizi di partecipare a un'infrastruttura mesh condivisa utilizzando VPC condiviso e altri mezzi di connettività, mantenendo al contempo il controllo indipendente sui propri servizi. Ad esempio, i proprietari del servizio possono definire le risorse Route
nei propri progetti. Amministratori della piattaforma
può definire un Mesh
in un progetto host amministrato centralmente, quindi concedere il servizio
proprietari delle autorizzazioni IAM per collegare le proprie risorse Route
a un asset Mesh
condiviso oppure
Gateway
. Il seguente diagramma mostra un esempio con VPC condivisa.
Le API di routing dei servizi consentono anche di avere client mesh di servizi connessi a diversi utilizzando il peering di rete VPC.
Indirizza il traffico in base all'indicatore del nome del server
La risorsa TLSRoute
ti consente di indirizzare il traffico criptato con TLS in base all'indicazione nome server (SNI) nell'handshake TLS. Puoi configurare il traffico TLS in modo che venga instradato ai servizi di backend appropriati configurando la corrispondenza SNI nella risorsa TLSRoute
. In questi deployment, i proxy inoltrano 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 è stato eseguito il deployment
come proxy collaterali o gateway.
Risorsa TLSRoute
collegata a una risorsa Mesh
Il deployment mostrato nel seguente diagramma instrada il traffico del mesh di servizi
in cui l'estensione SNI ha il valore service1
per il servizio di backend
service1
. Inoltre, qualsiasi traffico del servizio mesh 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 collegata a una risorsa Gateway
Il deployment mostrato nel diagramma seguente instrada tutto il traffico in entrata verso
Risorsa Gateway
in cui l'estensione SNI ha il valore serviceA
per
servizio di backend serviceA
. Inoltre, qualsiasi 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 nel proxy Envoy di Gateway
. La connessione TLS viene invece terminata nel servizio di backend corrispondente. Gateway
non può ispezionare le informazioni criptate nel livello TLS, a parte il valore ClientHello
, che contiene un'estensione SNI in testo normale. In questa modalità, Gateway
esegue il passthrough TLS. Tieni presente cheClientHello
criptato non è supportato.
Supporto gRPC principale
Puoi configurare i client gRPC proxyless utilizzando gli attributi gRPC di base, come la corrispondenza per metodo.
Suddivisione del traffico per il traffico TCP
Puoi implementare la suddivisione del traffico in base al peso per il traffico TCP su più servizi di backend. Puoi configurare pattern come i pattern canary (blu- viene implementata quando aggiorni il servizio. La suddivisione del traffico ti consente inoltre di eseguire la migrazione del traffico in modo controllato senza tempi di inattività.
Intercettazione del traffico
Quando utilizzi l'API di routing del servizio Mesh
e le risorse Gateway
,
tutto il traffico viene intercettato automaticamente. Per ulteriori informazioni, consulta
Opzioni per la configurazione delle VM di Compute Engine con deployment Envoy automatico.
Architettura e risorse
Questa sezione descrive il modello di API di routing del servizio e le sue risorse e ti aiuta a: come funzionano insieme le risorse dell'API Service Routing.
Mesh
risorsa
La risorsa Mesh
rappresenta un'istanza di un mesh di servizi. Puoi utilizzarlo per
e creare una mesh di servizi logici nel tuo progetto. Ogni risorsa Mesh
deve avere un
un nome univoco nel progetto. Dopo aver creato una risorsa Mesh
, il suo nome non può
possono essere modificate.
Nella risorsa Route
viene fatto riferimento alla risorsa Mesh
per cui aggiungere route
dai servizi che fanno parte del mesh.
I client proxy Envoy e gRPC senza proxy ricevono la configurazione da
Cloud Service Mesh mediante l'unione del mesh di servizi identificato dal Mesh
il nome della risorsa. La risorsa Mesh
supporta i seguenti implementazioni del piano dati:
- Envoy in esecuzione insieme all'applicazione come proxy sidecar
- Client gRPC senza proxy
- Combinazione di client gRPC proxyless e sidecar Envoy
Route
risorsa
La risorsa Route
viene utilizzata per configurare il routing ai servizi. Esistono quattro tipi diversi di risorse dell'API Route
. Definiscono il protocollo utilizzato
per instradare il traffico a un servizio di backend.
HTTPRoute
GRPCRoute
TCPRoute
TLSRoute
L'API non contiene un'API Route
verbatim. L'unica API configurabile
risorse sono HTTPRoute
, GRPCRoute
, TCPRoute
e TLSRoute
.
La risorsa Route
fa riferimento a uno o più
Risorse di Mesh
e Gateway
per aggiungere le route che fanno parte del metodo Mesh
corrispondente
Configurazione Gateway
. Una risorsa Route
può fare riferimento sia a Gateway
che
Mesh
risorse.
La risorsa Route
fa riferimento anche a una o più risorse di servizio di backend. I servizi vengono configurati utilizzando l'API del servizio di backend. Tu
crea una risorsa del servizio di backend che punti a uno o più backend MIG o NEG.
Il seguente diagramma mostra le relazioni tra le risorse Mesh
, Gateway
e Route
e la risorsa del servizio di backend e i relativi backend.
Sei tu a definire altre funzionalità di gestione del traffico, come routing, intestazione
modifiche, timeout e suddivisione del traffico basata sui pesi in Route
risorse.
Ad esempio, nel diagramma seguente, una risorsa HTTPRoute
definisce una suddivisione del traffico in misura del 70%/30% tra due servizi di backend.
Per semplificare l'amministrazione del tuo mesh di servizi, puoi elencare tutti e Route
risorse collegate a una risorsa Mesh
o Gateway
.
TLSRoute
risorsa
Utilizza la risorsa TLSRoute
per instradare il traffico TLS ai servizi di backend in base a
Nomi host SNI e nome ALPN (Application-livello Protocol Negoziazione). TLSRoute
la configurazione 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 i route che fanno parte della configurazione di Mesh o Gateway corrispondente.
La risorsa TLSRoute
fa riferimento anche a una o più risorse di 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 proxy in entrata
, consentendo ai client esterni di connettersi al mesh di servizi (nord-sud
traffico). Questa risorsa ha porte di ascolto e un parametro scope
. La
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. Le seguenti
mostra i proxy Envoy di cui è stato eseguito il deployment come servizio in entrata e configurati
Gateway
risorsa. In questo esempio specifico, i proxy Envoy sono configurati
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
non supporta gRPC senza proxy. gRPCRoutes
sono supportati nella risorsa Gateway
, ma il traffico gRPC viene indirizzato dal proxy Envoy, che funge da proxy intermedio.
Che cosa sono un ambito Gateway
e una configurazione Gateway
unita?
Un'istanza di risorsa Gateway
rappresenta le porte specifiche per la configurazione
al traffico ricevuto su quelle porte. La risorsa API Gateway
ha un parametro,
scope
, che viene utilizzato per raggruppare e unire logicamente la configurazione di due o più risorse Gateway
.
Ad esempio, se vuoi che i proxy Gateway
ascoltino sulle porte 80 e 443 per ricevere rispettivamente il 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. Per quanto riguarda il piano dati, Envoy
eseguiti nella modalità gateway in entrata devono presentare anche lo stesso parametro di ambito
a Cloud Service Mesh per ricevere la configurazione Gateway
. Tieni presente che
specificare l'ambito quando crei la risorsa Gateway
e specificare
stesso ambito del parametro di bootstrap per i proxy.
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 se 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 di ingress. Questo campo è riservato per uso futuro. L'unico valore attualmente supportato èOPEN_MESH
, che è il valore predefinito e 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 implementazioni, tieni presente quanto segue.
- Gli implementazioni di Envoy sidecar supportano tutti i percorsi (
HTTPRoute
,GRPCRoute
,TCPRoute
eTLSRoute
). - I deployment gRPC senza proxy supportano solo
GRPCRoute
. GRPCRoute
è limitato alle funzionalità supportate solo da gRPC proxyless deployment di machine learning.
Topologie supportate negli ambienti VPC condivisi 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 centralizzata. I proprietari dei servizi autorizzati possono aggiungere direttamente il proprio routing dei servizi
configurazioni in Mesh
o Gateway
.
In uno scenario tipico tra progetti, scegli un progetto (progetto host o progetto di amministrazione controllato centralmente) come progetto di amministrazione del mesh in cui creare una risorsa Mesh
. Il proprietario del progetto di amministrazione mesh autorizza Route
risorse di altri
di fare riferimento alla risorsa Mesh
, consentendo la configurazione del routing
di altri progetti nel mesh. Un piano dati mesh, come Envoy o
gRPC, richiede la configurazione dal progetto di amministrazione e riceve un insieme di tutti
delle route collegate a Mesh
. Per un Gateway
, i percorsi vengono uniti anche in tutti i Gateways
che utilizzano lo stesso ambito.
Il progetto di amministrazione Mesh
può essere qualsiasi progetto scelto e la configurazione funziona a condizione che i progetti sottostanti dispongano di connettività di rete VPC tramite VPC condivisa o peering di rete VPC.
Ruoli e autorizzazioni IAM
Di seguito sono riportate le autorizzazioni IAM necessarie per ottenere,
creare, aggiornare, eliminare, elencare e utilizzare 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 dei servizi devono avere
networkservices.grpcRoutes.*
, Autorizzazioninetworkservices.httpRoutes.*
onetworkservices.tcpRoutes.*
.
Gli amministratori di Mesh devono concedere l'autorizzazione networkservices.mesh.use
ai proprietari di servizi in modo che possano collegare le proprie risorse Route
alla risorsa Mesh
. Lo stesso modello si applica alle risorse Gateway
.
Per visualizzare tutte le autorizzazioni IAM per le risorse Mesh
, vai alla pagina di riferimento sulle autorizzazioni IAM e cerca meshes
.
Non sono richiesti altri ruoli predefiniti. Il ruolo predefinito esistente Amministratore della rete Compute (roles/compute.networkAdmin
) dispone di autorizzazioni networkservices.*
per impostazione predefinita.
Potrebbe essere necessario aggiungere le autorizzazioni descritte in precedenza
ruoli.
Considerazioni e limitazioni
- La console Google Cloud non supporta le API di routing dei servizi.
- Utilizza la
API xDS versione 3
o in un secondo momento.
- Versione minima di Envoy 1.20.0 (poiché le API di routing del servizio sono supportata solo su xDS versione 3)
- Versione minima del generatore di bootstrap gRPC v0.14.0
- La risorsa
TLSRoute
è supportata solo con proxy Envoy che sono con deployment come proxy sidecar o gateway. - Solo VM di Compute Engine con deployment Envoy automatico e Sono supportati i pod GKE con inserimento di 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 API precedenti.
- Quando una risorsa
TCPRoute
è collegata a una risorsaMesh
, la porta utilizzata per la corrispondenza Il traffico TCP non può essere utilizzato per gestire nulla, ad eccezione del traffico descritto da questoTCPRoute
.- Ad esempio, i tuoi deployment potrebbero includere una risorsa
TCPRoute
corrispondente alla porta "8000" e una risorsa HttpRoute. Quando entrambi sono collegati alla stessa risorsaMesh
, il traffico instradato dalla risorsaMesh
non può utilizzare la porta 8000 anche se gli indirizzi IP sottostanti sono diversi. Questa limitazione deriva dall'implementazione del proxy Envoy, che assegna la precedenza alla route con corrispondenza alla porta.
- Ad esempio, i tuoi deployment potrebbero includere una risorsa
- La risorsa
Gateway
non esegue il provisioning di un bilanciatore del carico gestito e non crea dinamicamente un servizio Envoy. - Gli Envoy di cui è stato eseguito il deployment automatico e che fungono da gateway di ingresso non devono avere l'argomento
serving_ports
per il flag--service-proxy
. - Envoy di cui è stato eseguito il deployment automatico non supporta la fornitura di un numero di progetto diverso da quello della VM.
Passaggi successivi
- Per informazioni su come elencare le risorse di percorso associate a
Mesh
oGateway
risorsa, vedi Elenco di risorseRoute
. Questa funzionalità è in anteprima. - Per informazioni sulle API di routing dei servizi, leggi la documentazione delle API di servizi di rete.