Panoramica delle API di routing dei servizi 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 ai 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 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 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 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.

  • Meshrisorsa
    • Gestione del traffico e configurazione della sicurezza tra servizi (est-ovest) per i proxy sidecar Envoy e i client gRPC proxyless.

  • Gatewayresource

    • Gestione del traffico e configurazione 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 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 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 diagramma seguente, due servizi nel mesh di servizi sono collegati da un Mesh risorsa. Le due risorse HTTPRoute configurano il routing. L'amministratore della mesh o della piattaforma gestisce la risorsa Mesh e i due proprietari dei servizi creano la configurazione del routing per i loro servizi.

Traffico da est a ovest da servizi a servizio in un mesh di servizi
Traffico da servizio a servizio est-ovest in un mesh di servizi (fai clic per ingrandire)

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 mesh possono definire la mesh logica e l'infrastruttura del gateway di ingresso.
  • 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 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 del mesh configura e gestisce la risorsa Gateway, mentre i proprietari dei servizi configurano e gestiscono i propri servizi e il routing del traffico.

Traffico nord-sud nel mesh attraverso un gateway
Traffico nord-sud nel mesh attraverso un gateway (fai clic per ingrandire)

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 risorse Route nel mesh. Il processo di aggiornamento è più affidabile perché i proprietari dei servizi gestiscono configurazioni di piccole dimensioni.
  • 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 l'aggiornamento i percorsi dei carichi di lavoro.

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 può 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.

Riferimento tra progetti con il VPC condiviso
Riferimento tra progetti con il VPC condiviso (fai clic per ingrandire)

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 instradato ai servizi di backend appropriati configurando la corrispondenza SNI TLSRoute risorsa. 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.

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 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.

Risorsa TLSRoute e risorsa Mesh
TLSRoute risorsa e Mesh risorsa (fai clic per ingrandire)

TLSRoute risorsa collegata a una risorsa Gateway

Il deployment mostrato nel seguente diagramma instrada qualsiasi traffico in entrata alla risorsa Gateway in cui l'estensione SNI ha il valore serviceA al servizio serviceA di backend. Inoltre, qualsiasi traffico in entrata verso Gateway in cui 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 tra loro. Valore dell'estensione SNI e intestazione in HTTP sono indipendenti.

La risorsa Gateway non termina la connessione TLS nel proxy Envoy di Gateway. La connessione TLS viene invece terminata al di servizio di backend. Gateway non può ispezionare le informazioni criptate nel livello TLS, a parte il valore ClientHello, che contiene un'estensione SNI in testo normale. Gateway esegue il passthrough TLS in questa modalità. Tieni presente cheClientHello criptato non è supportato.

Risorsa TLSRoute e risorsa gateway
Risorsa TLSRoute e risorsa Gateway (fai clic per ingrandire)

Supporto di gRPC di base

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 i pattern canary (blu- viene implementata quando aggiorni il servizio. La suddivisione del traffico ti consente inoltre migrare il 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, consulta Opzioni per la configurazione delle VM di Compute Engine con deployment Envoy automatico.

Architettura e risorse

Questa sezione descrive il modello dell'API di routing dei servizi e le relative risorse e ti aiuta a comprendere come le risorse dell'API di routing dei servizi interagiscono tra loro.

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. Una volta creata una risorsa Mesh, il nome non può essere modificato.

Risorsa API Mesh con deployment di sidecar Envoy e gRPC senza proxy
MeshRisorsa API con sidecar Envoy e implementazioni gRPC senza proxy (fai clic per ingrandire)

La risorsa Mesh viene richiamata nella risorsa Route per aggiungere route per i servizi che fanno parte della mesh.

I client gRPC proxyless e Envoy proxy ricevono la configurazione da Cloud Service Mesh partecipando al 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 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. Le uniche risorse API configurabili 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 Mesh, Gateway, e Route, oltre alla risorsa del servizio di backend e ai relativi backend.

Risorse API Route
Route Risorse 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.

Suddivisione del traffico in base alla ponderazione
Suddivisione del traffico in base al peso (fai clic per ingrandire)

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 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 agiscono come gateway di ingresso, consentendo ai client esterni di connettersi al service mesh (traffico nord-sud). Questa risorsa ha porte di ascolto e un parametro scope. Il proxy Envoy che funge da gateway di ingresso 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 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.

Mesh di servizi in entrata attraverso una risorsa "Gateway"
Ingresso del mesh di servizi tramite una risorsa Gateway (fai clic per ingrandire)
Risorsa gateway
Risorsa Gateway (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, 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 in ogni riga. Cloud Service Mesh unisce dinamicamente le singole configurazioni di tutti i gateway che hanno lo stesso ambito. Sul lato del piano dati, i proxy Envoy che vengono eseguiti in modalità gateway di ingresso 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.

Comportamento di unione risorse gateway
Comportamento di unione risorse 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 nel Gateway risorsa e nella configurazione bootstrap dei proxy Envoy anche quando esiste un solo Gateway.
  • 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 un type che rappresenta il tipo di deployment di ingress. Questo campo è riservato per un uso futuro. L'unico valore attualmente supportato è OPEN_MESH, che è il valore predefinito e non può essere modificato.

Deployment di reti 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 e TLSRoute).
  • I deployment gRPC senza proxy supportano solo GRPCRoute.
  • GRPCRoute è limitato alle funzionalità supportate solo dalle implementazioni gRPC senza proxy.

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.

Riferimento tra progetti tra risorse mesh e route
Riferimento tra progetti tra risorse 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 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 disporre delle autorizzazioni networkservices.grpcRoutes.*, networkservices.httpRoutes.* o networkservices.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 versione 3 dell'API xDS o successive.
    • 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 0.14.0
  • La risorsa TLSRoute è supportata solo con i proxy Envoy di cui è stato eseguito il deployment come proxy o gateway sidecar.
  • Sono supportate solo le VM Compute Engine con deployment di Envoy automatico e 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 risorsa Mesh, la porta utilizzata per abbinare il traffico TCP non può essere utilizzata per pubblicare altro che il traffico descritto da questa TCPRoute.
    • Ad esempio, i deployment potrebbero includere una risorsa TCPRoute che corrisponde alla porta "8000" e una risorsa HttpRoute. Quando entrambi sono collegati alla stessa risorsa Mesh, il traffico instradato dalla risorsa Mesh 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.
  • 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 una risorsa Mesh o Gateway, consulta Elenca le risorse Route. Questa funzionalità è in anteprima.
  • Per informazioni sulle API di routing dei servizi, leggi la documentazione relativa alle API dei servizi di rete.