Panoramica di Cloud Service Mesh con servizi gRPC senza proxy
Questa guida fornisce una panoramica dell'architettura di Cloud Service Mesh con servizi gRPC senza proxy, inclusi casi d'uso e pattern di architettura.
Il control plane gestito di Cloud Service Mesh consente il routing globale, il bilanciamento del carico e il failover regionale per i casi d'uso di mesh di servizi e bilanciamento del carico. Ciò include i deployment che incorporano proxy sidecar e proxy gateway. Il supporto di Cloud Service Mesh per le applicazioni gRPC senza proxy offre un modello di deployment aggiuntivo in cui le applicazioni gRPC possono partecipare a un mesh di servizi senza bisogno di un proxy sidecar.
In un esempio tipico, un client gRPC stabilisce una connessione con un server gRPC che ospita la logica di backend. Cloud Service Mesh fornisce ai client gRPC informazioni su quali server contattare, come bilanciare il carico delle richieste a più istanze di un server e cosa fare con le richieste se un server non è in esecuzione.
Per una panoramica completa del funzionamento di Cloud Service Mesh, consulta la panoramica di Cloud Service Mesh.
Come funziona Cloud Service Mesh con le applicazioni gRPC
Cloud Service Mesh configura i client gRPC con una versione gRPC supportata, in modo simile alla configurazione dei proxy sidecar come Envoy. Tuttavia, le applicazioni gRPC senza proxy connesse direttamente a Cloud Service Mesh non richiedono proxy sidecar. Cloud Service Mesh utilizza invece le API xDS open source per configurare direttamente le applicazioni gRPC. Queste applicazioni gRPC fungono da client xDS e si connettono al control plane globale di Cloud Service Mesh. Una volta connesse, le applicazioni gRPC ricevono la configurazione dinamica dal control plane, consentendo l'individuazione degli endpoint, il bilanciamento del carico, il failover regionale e i controlli di integrità. Questo approccio consente ulteriori pattern di deployment di Cloud Service Mesh.
Nella prima illustrazione, un mesh di servizi è abilitato utilizzando un proxy sidecar.
Per configurare un proxy sidecar, Cloud Service Mesh utilizza le API xDS. I client comunicano con il server tramite il proxy sidecar.
Nella seconda illustrazione, un mesh di servizi è abilitato senza un proxy sidecar utilizzando un client gRPC senza proxy.
Se esegui il deployment solo di servizi gRPC configurati da Cloud Service Mesh, puoi creare un mesh di servizi senza eseguire il deployment di nessun proxy. In questo modo, è più facile integrare le funzionalità di mesh di servizi nelle applicazioni gRPC.
Risoluzione del nome
Ecco come funziona la risoluzione del nome per i deployment senza proxy:
- Quando ti connetti a un servizio, imposti
xdscome schema di risoluzione del nome nel canale client gRPC. L'URI di destinazione è formattato comexds:///hostname:port. Se la porta non è specificata, il valore predefinito è 80, ad esempio nell'URI di destinazionexds:///example.hostname. - Il client gRPC risolve
hostname:portnell'URI di destinazione inviando una richiesta del servizio di rilevamento dei listener (LDS) a Cloud Service Mesh. - Cloud Service Mesh cerca le regole di forwarding configurate con una porta corrispondente. Quindi, cerca la mappa URL corrispondente per una regola host
che corrisponda a
hostname:port. Restituisce la configurazione di routing associata al client gRPC.
Le regole host che configuri in Cloud Service Mesh devono essere univoche in tutte le mappe URL. Ad esempio, example.hostname, example.hostname:80 e example.hostname:8080 sono tutte regole diverse.
Risoluzione del nome con diversi tipi di deployment
Lo schema di risoluzione del nome è diverso per i deployment senza proxy e per i deployment che utilizzano proxy Envoy.
Il client gRPC utilizza lo schema di risoluzione del nome xds per connettersi a un servizio, in modo che il client possa ricevere la configurazione del servizio da Cloud Service Mesh. Il client gRPC comunica quindi direttamente con il server gRPC.
Puoi combinare i pattern di deployment proxy sidecar e senza proxy per una maggiore flessibilità. La combinazione di pattern è particolarmente utile quando se l'organizzazione e la rete supportano più team con requisiti diversi in termini di funzionalità, esigenze operative e versioni gRPC.
Nella seguente illustrazione, sia i client gRPC senza proxy sia i client gRPC con un proxy sidecar comunicano con un server gRPC. I client gRPC con proxy sidecar utilizzano lo schema di risoluzione del nome dns.
Casi d'uso
I seguenti casi d'uso ti aiutano a capire quando potresti voler utilizzare Cloud Service Mesh con applicazioni gRPC senza proxy. Il deployment può includere applicazioni gRPC senza proxy, applicazioni gRPC con proxy sidecar o un mix di entrambe.
Uso efficiente delle risorse in un mesh di servizi su larga scala
Se il mesh di servizi include centinaia o migliaia di client e backend, potresti notare che il consumo totale di risorse derivante dall'esecuzione di proxy sidecar inizia a sommarsi. Se utilizzi applicazioni gRPC senza proxy, non devi introdurre proxy sidecar nel deployment. Un approccio senza proxy può comportare un aumento dell'efficienza.
Applicazioni gRPC ad alte prestazioni
Per alcuni casi d'uso, ogni millisecondo di latenza di richiesta e risposta è importante. In questo caso, potresti riscontrare una latenza ridotta quando utilizzi un'applicazione gRPC senza proxy, anziché passare ogni richiesta tramite un proxy sidecar lato client e, potenzialmente, un proxy sidecar lato server.
Mesh di servizi per gli ambienti in cui non puoi eseguire il deployment dei proxy sidecar
In alcuni ambienti, potresti non essere in grado di eseguire un proxy sidecar come processo aggiuntivo insieme all'applicazione client o server. Potresti anche non essere in grado di configurare lo stack di rete di una macchina per l'intercettazione e il reindirizzamento delle richieste, ad esempio utilizzando
iptables.
In questo caso, puoi utilizzare Cloud Service Mesh con applicazioni gRPC senza proxy per introdurre funzionalità di mesh di servizi nelle applicazioni gRPC.
Mesh di servizi eterogeneo
Poiché sia le applicazioni gRPC senza proxy sia Envoy comunicano con Cloud Service Mesh, il mesh di servizi può includere entrambi i modelli di deployment. L'inclusione di entrambi i modelli consente di soddisfare le esigenze particolari di operatività, prestazioni e funzionalità di diverse applicazioni e diversi team di sviluppo.
Esegui la migrazione da un mesh di servizi con proxy a un mesh senza proxy
Se hai già un'applicazione gRPC con un proxy sidecar configurato da Cloud Service Mesh, puoi eseguire la transizione a un'applicazione gRPC senza proxy.
Quando un client gRPC viene implementato con un proxy sidecar, utilizza il DNS per risolvere il nome host a cui si connette. Il proxy sidecar intercetta il traffico per fornire funzionalità di mesh di servizi.
Puoi definire se un client gRPC utilizza la route senza proxy o la route proxy sidecar per comunicare con un server gRPC modificando lo schema di risoluzione del nome che utilizza. I client senza proxy utilizzano lo schema di risoluzione del nome xds, mentre i proxy sidecar utilizzano lo schema di risoluzione del nome dns. Alcuni client gRPC potrebbero utilizzare il percorso senza proxy quando comunicano con un server gRPC, ma utilizzare il percorso del proxy sidecar quando comunicano con un altro server gRPC. In questo modo puoi eseguire la migrazione graduale a un deployment senza proxy.
Per eseguire la migrazione da un mesh di servizi con proxy a un mesh senza proxy, devi creare un nuovo servizio Cloud Service Mesh utilizzato dal client gRPC senza proxy. Puoi utilizzare le stesse API per configurare Cloud Service Mesh per le versioni esistenti e nuove.
Architettura e risorse
Il modello dei dati di configurazione per i servizi gRPC senza proxy estende il modello di configurazione di Cloud Service Mesh, con alcune aggiunte e limitazioni descritte in questa guida. Alcune di queste limitazioni sono temporanee perché gRPC senza proxy non supporta tutte le funzionalità di Envoy, mentre altre sono inerenti all'utilizzo di RPC. Ad esempio, i reindirizzamenti HTTP che utilizzano gRPC non sono supportati. Per comprendere meglio il modello di configurazione in questa guida, ti consigliamo di imparare bene i concetti e la configurazione di Cloud Service Mesh.
Il seguente diagramma mostra le risorse che devi configurare per le applicazioni gRPC senza proxy.
Controlli di integrità
Un controllo di integrità gRPC può verificare lo stato di un servizio gRPC in esecuzione su un'istanza di macchina virtuale (VM) di backend o un gruppo di endpoint di rete (NEG).
Se non è possibile utilizzare un controllo di integrità gRPC perché il server gRPC non implementa il protocollo di controllo di integrità gRPC, utilizza un controllo di integrità TCP. Non utilizzare un controllo di integrità HTTP, HTTPS o HTTP/2.
Per ulteriori informazioni, consulta Controllo di integrità gRPC e Flag aggiuntivo per i controlli di integrità gRPC.
Servizio di backend
Il servizio di backend definisce il modo in cui un client gRPC comunica con un server gRPC.
Quando crei un servizio di backend per gRPC, imposta il campo del protocollo su GRPC.
È possibile accedere anche a un servizio di backend configurato con un protocollo impostato su
GRPCtramite un proxy sidecar. In questa situazione, il client gRPC non deve utilizzare lo schema di risoluzione del nomexds.In tutti i deployment di Cloud Service Mesh, lo schema di bilanciamento del carico per il servizio di backend deve essere
INTERNAL_SELF_MANAGED.
Backend
I backend ospitano le istanze del server gRPC. Puoi utilizzare gruppi di istanze gestite o non gestite in Compute Engine e NEG di zona in Google Kubernetes Engine come backend per ospitare le istanze del server gRPC.
Passaggi successivi
- Per scoprire di più sulle API di routing dei servizi e sul loro funzionamento, consulta la panoramica.
- Per prepararti a configurare Cloud Service Mesh con applicazioni gRPC senza proxy, consulta Preparati alla configurazione con Envoy e workload senza proxy.
- Per informazioni sulle limitazioni applicate ai deployment gRPC senza proxy, consulta Limiti e limitazioni con gRPC senza proxy.