Panoramica delle API di routing dei servizi Cloud Service Mesh
Questo documento è destinato agli amministratori di mesh o piattaforme e agli sviluppatori di servizi che hanno una familiarità di livello intermedio o 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 istanze VM. Questo documento si applica alle implementazioni 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 del traffico, osservabilità e sicurezza avanzate. Tuttavia, la configurazione e il funzionamento di un mesh di servizi è un'attività complessa 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 l'esperienza complessiva di configurazione della 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 del service networking.
Questo documento introduce il seguente modello e le seguenti risorse dell'API di routing dei servizi.
Mesh
resource- Configurazione della gestione del traffico e della sicurezza da servizio a servizio (est-ovest) per i proxy sidecar Envoy e i client gRPC proxyless.
-
- Configurazione della gestione del traffico e della sicurezza per i proxy Envoy che fungono da gateway di ingresso, consentendo ai client esterni di connettersi al mesh di servizi (nord-sud).
Risorse
Route
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 sia per i deployment di gRPC proxyless sia per quelli del proxy Envoy. Il modello di API di routing del servizio consente di ottenere diversi vantaggi chiave.
Nel seguente diagramma, due servizi nel mesh di servizi sono connessi 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 del servizio creano la configurazione di routing per i loro servizi.
La progettazione di API orientata ai ruoli consente una chiara separazione delle responsabilità
Le API di routing del servizio ti consentono di separare le responsabilità di configurazione della mesh in base ai ruoli organizzativi:
- Gli amministratori del mesh possono definire il mesh logico e l'infrastruttura del gateway di ingresso.
- I proprietari del servizio (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 un gateway di ingresso per il traffico che entra nel mesh da un client che
non si trova nel mesh. L'amministratore del 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 di proprietà di proprietari di servizi indipendenti. Questo approccio presenta diversi vantaggi.
- I proprietari dei 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 gestiscono piccole configurazioni. - Il proprietario del servizio responsabile del servizio di destinazione o
del nome host è proprietario di ogni risorsa
Route
. - I proprietari dei servizi non devono dipendere dagli amministratori del mesh per aggiornare il routing.
Abilitare un mesh di servizi che si estende su 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 il VPC condiviso e altri mezzi di connettività, mantenendo il controllo indipendente sui propri servizi. Ad esempio, i proprietari del servizio
possono definire le risorse Route
nei propri progetti. Gli amministratori della piattaforma possono definire un Mesh
in un progetto host gestito centralmente, quindi concedere ai proprietari dei servizi le autorizzazioni IAM per collegare le proprie risorse Route
a un Mesh
o a un Gateway
condivisi. Il seguente diagramma mostra un esempio con VPC condiviso.
Le API di routing del servizio consentono inoltre di connettere i client di mesh di servizi a reti diverse utilizzando il peering di rete VPC.
Indirizza il traffico in base all'indicatore del nome del server
La risorsa TLSRoute
consente di instradare 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 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 sidecar o gateway.
Risorsa TLSRoute
allegata a una risorsa Mesh
Il deployment mostrato nel seguente diagramma instrada tutto il traffico mesh di servizi
in cui l'estensione SNI ha il valore service1
al servizio di backend
service1
. Inoltre, tutto il 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
e risorsa Mesh
(fai clic per ingrandire)Risorsa TLSRoute
allegata 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 nel proxy Envoy di Gateway
. La connessione TLS viene invece terminata nel servizio di backend corrispondente. Gateway
non può ispezionare alcuna informazione criptata nel
livello TLS, se non visualizzare ClientHello
, che contiene un'estensione SNI
in testo normale. Gateway
esegue il passthrough TLS in questa modalità. Tieni presente che
ClientHello
criptato non è supportato.
TLSRoute
e risorsa Gateway
(fai clic per ingrandire)Supporto di base di gRPC
Puoi configurare i client gRPC senza proxy utilizzando gli attributi gRPC di base, come la corrispondenza per metodo.
Suddivisione del traffico per il traffico TCP
Puoi implementare la suddivisione del traffico basata sul peso per il traffico TCP su più servizi di backend. Quando aggiorni il servizio, puoi configurare pattern come i rollout canary (blu/verde). La suddivisione del traffico ti consente anche di eseguire la migrazione del traffico in modo controllato senza tempi di inattività.
Intercettazione del traffico
Quando utilizzi l'API di routing dei servizi Mesh
e le risorse Gateway
,
tutto il traffico viene intercettato automaticamente. Per saperne di più, vedi
Opzioni per la configurazione delle VM di Compute Engine con deployment Envoy automatico.
Architettura e risorse
Questa sezione descrive il modello dell'API Service Routing e le relative risorse e ti aiuta a capire come funzionano insieme le risorse dell'API Service Routing.
Mesh
risorsa
La risorsa Mesh
rappresenta un'istanza di un mesh di servizi. Lo utilizzi per
creare unmesh di servizih logico nel tuo progetto. Ogni risorsa Mesh
deve avere un nome univoco nel progetto. Una volta creata una risorsa Mesh
, il nome non può essere modificato.
Mesh
La risorsa Mesh
viene utilizzata nella risorsa Route
per aggiungere route per i servizi che fanno parte del mesh.
Il proxy Envoy e i client gRPC proxyless ricevono la configurazione da
Cloud Service Mesh unendosi al mesh di servizi identificato dal nome della risorsa Mesh
. La risorsa Mesh
supporta i seguenti deployment del data plane:
- Envoy in esecuzione insieme all'applicazione come proxy sidecar
- Client gRPC senza proxy
- Combinazione di sidecar Envoy e client gRPC senza proxy
Route
risorsa
La risorsa Route
viene utilizzata per configurare il routing ai servizi. Esistono quattro
tipi diversi 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 un'API Route
letterale. 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 sia alle risorse Gateway
che a quelle Mesh
.
La risorsa Route
fa riferimento anche a una o più risorse
servizio di backend. I servizi vengono configurati utilizzando l'API del servizio di backend. Crea una risorsa di 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
e la risorsa servizio di backend e i relativi backend.
Route
(fai clic per ingrandire)Definisci altre funzionalità di gestione del traffico, come routing, modifiche
dell'intestazione, timeout e suddivisione del traffico in base al peso nelle risorse Route
.
Ad esempio, nel seguente diagramma, una risorsa HTTPRoute
definisce una suddivisione del traffico del 70% / 30% tra due servizi di backend.
Per semplificare l'amministrazione della mesh di servizi, puoi elencare tutte le risorse Route
collegate a una risorsa Mesh
o Gateway
.
TLSRoute
risorsa
Utilizza la risorsa TLSRoute
per indirizzare il traffico TLS ai servizi di backend in base ai nomi host SNI e al nome ALPN (Application-Layer Protocol Negotiation). 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 riferimento anche 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
di ingresso, consentendo ai client esterni di connettersi almesh di servizih (traffico
nord-sud). Questa risorsa ha porte di ascolto insieme a un parametro scope
. Il proxy Envoy che funge da gateway in entrata si associa 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 di ingresso e configurati dalla risorsa
Gateway
. In questo esempio specifico, i proxy Envoy sono configurati per
ascoltare sulla porta 80 le connessioni in entrata dai client.
La risorsa API Gateway
supporta solo il data plane 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
(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
per il traffico ricevuto su queste 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
siano in ascolto 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 la porta 443 per il traffico HTTPS. Assegna lo stesso valore al campo scope
in ciascun.
Cloud Service Mesh unisce dinamicamente le singole configurazioni di tutti i gateway con lo stesso ambito. Sul lato del piano dati, 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
devi specificare l'ambito quando crei la risorsa Gateway
e devi specificare
lo 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 nella risorsaGateway
e nella configurazione di bootstrap dei proxy Envoy anche quando esiste un soloGateway
. - La creazione di una risorsa
Gateway
non comporta 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 dell'ingresso. Questo campo è riservato per un 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 il proxy Envoy e gRPC senza proxy nello stesso mesh. Quando crei questi deployment, tieni presente 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 dalle implementazioni gRPC senza proxy.
Topologie supportate negli 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 centralizzata. I proprietari dei servizi autorizzati possono aggiungere direttamente le configurazioni di routing dei servizi a Mesh
o Gateway
.
Mesh
e Route
(fai clic per ingrandire)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 del mesh autorizza le risorse Route
di altri progetti a fare riferimento alla risorsa Mesh
, consentendo alla configurazione di routing di altri progetti di far parte del mesh. Un data plane mesh, Envoy o
gRPC, richiede la configurazione dal progetto di amministrazione e riceve un'unione di tutte
le route associate a Mesh
. Per un Gateway
, anche le rotte
vengono unite in tutti i Gateways
che utilizzano lo stesso ambito.
Il progetto di amministrazione Mesh
può essere qualsiasi progetto tu scelga e la configurazione funziona se i progetti sottostanti hanno 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 dei servizi devono disporre delle autorizzazioni
networkservices.grpcRoutes.*
,networkservices.httpRoutes.*
onetworkservices.tcpRoutes.*
.
Gli amministratori di Mesh devono concedere l'autorizzazione networkservices.mesh.use
ai proprietari dei servizi in modo che questi 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 delle autorizzazioni IAM
e cerca meshes
.
Non sono necessari altri ruoli predefiniti. Il ruolo predefinito esistente
Amministratore rete Compute
(roles/compute.networkAdmin
) dispone di networkservices.*
autorizzazioni per impostazione predefinita.
Potresti dover aggiungere le autorizzazioni descritte in precedenza ai tuoi ruoli personalizzati.
Considerazioni e limitazioni
- La console Google Cloud non supporta le API di routing dei servizi.
- Utilizza la
versione 3 dell'API xDS
o successive.
- Versione minima di Envoy 1.20.0 (poiché le API di routing del servizio sono supportate solo nella versione 3 di xDS)
- Versione minima del generatore di bootstrap gRPC v0.14.0
- La risorsa
TLSRoute
è supportata solo con i proxy Envoy distribuiti come proxy sidecar o gateway. - Sono supportate solo le VM di Compute Engine con deployment Envoy automatico e i 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 delle API.
- Quando una risorsa
TCPRoute
è collegata a una risorsaMesh
, la porta utilizzata per la corrispondenza del traffico TCP non può essere utilizzata per pubblicare altro traffico se non quello descritto da questoTCPRoute
.- Ad esempio, i tuoi 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 la precedenza prima alla route corrispondente 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 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 sull'elenco delle risorse di itinerario associate a una risorsa
Mesh
oGateway
, vedi Elenca le risorseRoute
. - Per informazioni sulle API di routing dei servizi, leggi la documentazione relativa alle API dei servizi di rete.