Panoramica delle API di routing del servizio Cloud Service Mesh
Questo documento è rivolto agli amministratori di mesh o piattaforme e servizi sviluppatori che hanno un livello di familiarità con queste Concetti di Cloud Service Mesh e mesh di servizi e chi esegue il deployment Cloud Service Mesh su Compute Engine con istanze VM. Questo documento si applica a i deployment utilizzando Envoy e client 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, configurare e gestire un mesh di servizi è un'attività complessa per amministratori della rete mesh e sviluppatori di servizi.
Questo documento descrive le API di routing del servizio per la configurazione Cloud Service Mesh. Queste API sono progettate per semplificare e migliorare di configurazione mesh di Google.
Il modello di routing dei servizi utilizza risorse API chiamate Mesh
, Gateway
e Route
.
Queste risorse forniscono una configurazione pertinente dal punto di vista contestuale
durante la definizione del piano di controllo
del networking di servizi.
Questo documento introduce il seguente modello di API di routing dei servizi Google Cloud.
Mesh
risorsa- Gestione e sicurezza del traffico service-to-service (est-ovest) per proxy sidecar Envoy e 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).
Route
di risorse con i seguenti tipi:
La console Google Cloud non fornisce assistenza per il routing dei servizi su quelle di livello inferiore. 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 deployment di proxy Envoy e gRPC senza proxy. Il modello di API di routing dei servizi offre diversi vantaggi chiave.
Nel diagramma seguente, due servizi nel mesh di servizi sono collegati da un
Mesh
risorsa. 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 delle API orientata ai ruoli consente una chiara separazione 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 dei servizi (sviluppatori di applicazioni) possono definire in modo indipendente l'accesso modelli per i loro servizi. Possono anche definire e applicare il traffico e gestire i criteri di gestione per i loro servizi.
Nel diagramma seguente, Cloud Load Balancing e una risorsa Gateway
fornisce un gateway in entrata per il traffico che entra nel mesh da un client
non nella 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 routing dei servizi utilizzano risorse per protocollo e per route che possono essere configurati e di proprietà di proprietari di servizi indipendenti. Questo approccio prevede diverse e i vantaggi che offre.
- I proprietari dei servizi hanno autonomia nella configurazione i criteri e la gestione del traffico per i servizi di cui sono proprietari.
- L'aggiornamento di una risorsa
Route
non influisce sulle altre risorseRoute
nella 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
ogni nome host è proprietario di ogni risorsa
Route
. - I proprietari dei servizi non devono dipendere dagli amministratori del mesh per l'aggiornamento 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 mesh condiviso
dell'infrastruttura utilizzando un VPC condiviso e altri mezzi di connettività
mantenendo il controllo indipendente sui loro servizi. Ad esempio, i proprietari del servizio
può definire le risorse Route
nei propri progetti. Amministratori di 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 di VPC condiviso.
Le API di routing dei servizi consentono anche di avere client mesh di servizi connessi a diversi 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 con crittografia TLS in base al server
Name Indication (SNI) nell'handshake TLS. Puoi configurare il traffico TLS in modo che
instradato ai servizi di backend appropriati configurando la corrispondenza SNI
TLSRoute
risorsa. 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 è stato eseguito il deployment
come proxy collaterali o gateway.
TLSRoute
risorsa 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 mesh di servizi in cui l'estensione SNI ha
il valore service2
viene instradato al servizio di backend service2
. L'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 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
dove l'estensione SNI ha il valore serviceB
viene instradata al
servizio di backend serviceB
. Valore dell'estensione SNI e nome del servizio di backend
sono indipendenti l'uno dall'altro. Valore dell'estensione SNI e intestazione in HTTP
sono indipendenti.
La risorsa Gateway
non termina la connessione TLS all'indirizzoGateway
Proxy Envoy. La connessione TLS viene invece terminata al
di servizio di backend. Il Gateway
non può esaminare le informazioni criptate nel
Livello TLS, ad eccezione del ClientHello
, che contiene un SNI di testo normale
. Gateway
esegue il passthrough TLS in questa modalità. Tieni presente che
ClientHello
criptato non supportato.
TLSRoute
risorsa e Gateway
risorsa (fai clic per ingrandire)Supporto gRPC principale
Puoi configurare client gRPC senza proxy utilizzando gli 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 canary (i viene implementata quando aggiorni il servizio. La suddivisione del traffico ti consente inoltre eseguire la migrazione del traffico in modo controllato senza tempi di inattività.
Intercettazione del traffico
Quando utilizzi le risorse Mesh
e Gateway
dell'API Service routing,
tutto il traffico viene intercettato automaticamente. Per ulteriori informazioni, vedi
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 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.
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 cui aggiungere le 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 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 risorsa 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. 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 anche riferimento a uno o più
servizio di backend
Google Cloud. 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 Mesh
, Gateway
,
e Route
, oltre alla risorsa del servizio di backend e ai relativi backend.
Route
Risorse dell'API (fai clic per ingrandire)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 percentuale pari a 70% / 30%
suddiviso 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
implica il passthrough TLS, in cui il proxy Envoy non
e terminare il traffico TLS.
La risorsa TLSRoute
fa riferimento a una o più risorse Mesh
e Gateway
a
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 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 instradato dal proxy Envoy, che agisce come proxy centrale.
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 specifiche per la configurazione
al traffico ricevuto su quelle porte. La risorsa API Gateway
ha un parametro,
scope
, utilizzato per raggruppare e unire logicamente la configurazione di due o
altre Gateway
risorse.
Ad esempio, se vuoi che i proxy Gateway
rimangano in ascolto sulle porte 80 e 443,
ricevono rispettivamente traffico HTTP e HTTPS, crei 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
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.
Gateway
(fai clic per ingrandire)Di seguito sono riportate le considerazioni chiave per la risorsa Gateway
:
- Il parametro di ambito
Gateway
è obbligatorio. Specifica l'ambito nelGateway
risorsa e nella configurazione bootstrap dei proxy Envoy anche quando esiste un soloGateway
. - La creazione di una risorsa
Gateway
non esegue il deployment di un servizio con un Envoy proxy. Il deployment del proxy Envoy è un passaggio separato. - La risorsa
Gateway
ha un valoretype
che rappresenta il tipo di traffico in entrata e deployment continuo. Questo campo è riservato per uso futuro. L'unico il valore attualmente supportato èOPEN_MESH
, che è il valore predefinito 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 da gRPC proxyless deployment di machine learning.
Topologie supportate in ambienti VPC condiviso multiprogetto
Cloud Service Mesh supporta l'aggiunta di risorse Route
definite in altri
progetti in una risorsa Mesh
o Gateway
definita in un'amministrazione centralizzata
progetto. I proprietari dei servizi autorizzati possono aggiungere direttamente il proprio routing dei servizi
configurazioni in Mesh
o Gateway
.
Mesh
e Route
risorse (fai clic per ingrandire)In un tipico scenario multiprogetto, scegli un progetto (progetto host o
controllato a livello centrale) come progetto di amministrazione mesh in cui crei
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
, le route
vengono inoltre uniti in tutti i Gateways
che utilizzano lo stesso ambito.
Il progetto di amministrazione Mesh
può essere qualsiasi progetto a tua scelta e il
funziona purché i progetti sottostanti abbiano un VPC
connettività di rete tramite VPC condiviso
peering di rete VPC.
Autorizzazioni e ruoli 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
al servizio
in modo che i proprietari del servizio possano collegare le proprie risorse Route
Mesh
risorsa. Lo stesso modello si applica a Gateway
risorse.
Per visualizzare tutte le autorizzazioni IAM per Mesh
risorse, vai a
Pagina di riferimento delle autorizzazioni IAM
e cerca meshes
.
Non sono necessari altri ruoli predefiniti. Il ruolo predefinito esistente
Amministratore rete Compute
(roles/compute.networkAdmin
) ha networkservices.*
autorizzazioni 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 automatico Envoy 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 versioni 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 deployment potrebbero includere una risorsa
TCPRoute
che corrisponde alla porta "8000" e una risorsa HttpRoute. Quando entrambi sono collegato alla stessa risorsaMesh
, traffico instradato dalla risorsaHTTPRoute
non può utilizzare la porta 8000 anche se gli indirizzi IP sottostanti sono diverso. Questa limitazione deriva dall'implementazione del proxy Envoy, che assegna prima la precedenza alla route corrispondente alle porte.
- Ad esempio, i deployment potrebbero includere una risorsa
- La risorsa
Gateway
non esegue il provisioning di un bilanciatore del carico gestito, non crea dinamicamente un servizio Envoy. - Gli Envoy di cui è stato eseguito il deployment automatico che fungono da gateway in entrata non devono avere
Argomento
serving_ports
al flag--service-proxy
. - Envoy di cui è stato eseguito il deployment automatico non supporta la specifica di un numero di progetto diverso dal progetto 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 relativa alle API dei servizi di rete.