Panoramica della gestione avanzata del traffico

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 determinano e configurano la gestione del traffico in un deployment di Cloud Service Mesh.

Cloud Service Mesh offre funzionalità avanzate di gestione del traffico che ti consentono di controllare in modo granulare la gestione del traffico. Cloud Service Mesh supporta i seguenti casi d'uso:

• Routing del traffico granulare delle richieste a uno o più servizi.
• Suddivisione del traffico basata sul peso per distribuire il traffico tra più servizi.
• Criteri di mirroring del traffico che inviano richieste a un servizio di debug e copie a un altro. Il mirroring del traffico non è supportato con la risorsa TCPRoute o TLSRoute.
• Distribuzione del traffico ottimizzata tra i backend di un servizio per un migliore bilanciamento del carico.

Queste funzionalità avanzate di gestione del traffico ti consentono di raggiungere i tuoi obiettivi di disponibilità e rendimento. Uno dei vantaggi dell'utilizzo di Cloud Service Mesh per questi casi d'uso è che puoi aggiornare la modalità di gestione del traffico senza dover modificare il codice dell'applicazione.

La gestione del traffico in un mesh di servizi Cloud Service Mesh si basa sulle seguenti risorse:

• Risorsa Mesh, che identifica il mesh di servizi e rappresenta il componente responsabile dell'inoltro del traffico e dell'applicazione dei criteri. La risorsa Mesh identifica anche la porta di intercettazione del traffico.
• Gateway, che identifica i proxy intermedi e rappresenta il componente che ascolta un elenco di coppie indirizzo IP:porta, inoltra il traffico e applica i criteri.
• Risorsa Route, che può essere di diversi tipi e che contiene informazioni sul routing del traffico per la mesh. Le risorse Route identificano i nomi host e le porte che i client possono utilizzare per instradare il traffico ai servizi di backend. Di seguito sono riportati i tipi di risorse Route:
  • HTTPRoute, disponibile solo nei mesh che utilizzano proxy Envoy. Quando utilizzi la risorsa HTTPRoute per configurare i proxy Envoy per l'invio di richieste HTTP, sono disponibili tutte le funzionalità descritte in questo documento.
  • TCPRoute, disponibile solo nei mesh che utilizzano proxy Envoy.
  • TLSRoute, disponibile solo nei mesh che utilizzano proxy Envoy.
  • GRPCRoute, disponibile nelle mesh che utilizzano proxy sidecar Envoy e gRPC senza proxy. Quando utilizzi servizi o applicazioni gRPC senza proxy con Cloud Service Mesh, alcune delle funzionalità descritte in questo documento non sono disponibili.
• Servizio di backend a cui sono associate le risorse Route.

Configurazione

Per configurare la gestione avanzata del traffico, utilizzi le stesse risorse Route e servizi di backend che utilizzi durante la configurazione di Cloud Service Mesh. Cloud Service Mesh, a sua volta, configura i proxy Envoy e le applicazioni gRPC proxyless per applicare i criteri di gestione avanzata del traffico che hai configurato.

A livello generale, devi:

1. Configura una risorsa Mesh per identificare il mesh di servizi.

2. Configura le risorse Route per eseguire le seguenti operazioni in base alle caratteristiche della richiesta in uscita:

   1. Seleziona il servizio di backend a cui vengono indirizzate le richieste.

   2. (Facoltativo) Esegui altre azioni.

3. Configura il servizio di backend per controllare la modalità di distribuzione del traffico a backend ed endpoint dopo la selezione di un servizio di destinazione.

Routing e azioni del traffico

In Cloud Service Mesh, il traffico viene instradato in base ai valori della risorsa Mesh, della risorsa Route e della risorsa del servizio di backend. Tutte le funzionalità avanzate di gestione del traffico relative al routing e alle azioni vengono configurate utilizzando gli oggetti Route.

Le sezioni seguenti descrivono le funzionalità avanzate di gestione del traffico che puoi configurare negli oggetti Route.

Gestione delle richieste

Quando un cliente invia una richiesta, questa viene gestita come descritto nei passaggi seguenti:

1. La richiesta viene associata a una risorsa Route specifica nel seguente modo:

   • Se utilizzi Envoy:
     • L'intestazione host nella richiesta HTTP viene confrontata con il campo hostnames in ogni risorsa HTTPRoute o GRPCRoute per selezionare la risorsa Route corretta per la richiesta. Solo le risorse HTTPRoute e GRPCRoute hanno il campo hostnames.
     • L'indirizzo IP viene abbinato per il routing del traffico TCP utilizzando TCPPRoute.
     • SNI e ALPN vengono utilizzati per il passthrough TLS tramite TLSRoute.
     • Le risorse HTTPRoute e GRPCRoute associate a un Mesh o a un Gateway devono avere nomi host univoci. Se tenti di collegare più route con nomi host in conflitto, la configurazione viene rifiutata.
     • Analogamente, il campo IP:Port di TCPRoute deve essere univoco o la configurazione viene rifiutata.
     • Allo stesso modo, SNI e ALPN devono essere univoci per TLSRoute.
     • Se sono presenti nomi host sovrapposti, ad esempio a.example.com e *.example.com, la richiesta corrisponde alla route più specifica.
   • Se utilizzi gRPC senza proxy:
     • I client gRPC senza proxy utilizzano lo schema di risoluzione dei nomi xds. Risolvono hostname[:port] nell'URI di destinazione inviando una richiesta a Cloud Service Mesh.
     • Viene confrontata solo la porta di una risorsa GRPCRoute con la porta nell'URI di destinazione (ad esempio, xds:///example.hostname:8080). L'URI di destinazione deve corrispondere esattamente alla stringa nel campo hostnames di GRPCRoute.

2. La risorsa Route può contenere ulteriori informazioni e regole di routing.

3. Una volta selezionato il servizio di backend di destinazione, il traffico viene distribuito tra i backend o gli endpoint per quel servizio di backend di destinazione, in base alla configurazione nella risorsa del servizio di backend.

Il secondo passaggio è descritto nella sezione seguente, Routing semplice basato su host e percorso. Il terzo passaggio è descritto in Routing e azioni avanzate.

Routing semplice basato su host e percorso

Cloud Service Mesh supporta uno schema di routing semplificato e uno più avanzato. Nello schema semplice, specifichi un host e, facoltativamente, un percorso. L'host e il percorso della richiesta vengono valutati per determinare il servizio di backend a cui viene indirizzata la richiesta.

• L'host della richiesta è la parte del nome di dominio di un URL. Ad esempio, la parte host dell'URL http://example.com/video/ è example.com.
• Il percorso della richiesta è la parte dell'URL che segue il nome host. Ad esempio, il percorso dell'URL http://example.com/video/ è /video.

Nella mappa delle regole di routing, configuri il routing semplice in base all'host e al percorso, che consiste in quanto segue:

• Mesh globale
• Un HTTPRoute o un GRPCRoute

La maggior parte della configurazione viene eseguita in HTTPRoute. Dopo aver creato la mappa iniziale delle regole di routing, devi solo modificare la risorsa HTTPRoute.

La regola più semplice è una regola predefinita, in cui specifichi solo una regola host con carattere jolly (*) e un matcher percorso con un servizio predefinito. Dopo aver creato la regola predefinita, puoi aggiungere regole aggiuntive che specificano host e percorsi diversi. Le richieste in uscita vengono valutate in base a queste regole nel seguente modo:

• Se l'host di una richiesta (ad esempio example.com) corrisponde al nome host di HTTPRoute:

  1. Successivamente viene valutato il RouteRule. RouteRule specifica come abbinare il traffico e come instradarlo quando viene trovato un abbinamento.
  2. Ogni RouteRule contiene una o più corrispondenze di route che vengono valutate in base al percorso della richiesta.
  3. Se viene trovata una corrispondenza, la richiesta viene instradata al servizio specificato in RouteAction.

Per saperne di più sui campi delle risorse di HTTPRoute e sul loro funzionamento, consulta la documentazione dell'API Network Service.

Routing e azioni avanzati

Se vuoi fare di più che instradare una richiesta in base all'host e al percorso della richiesta, puoi configurare regole avanzate per instradare le richieste ed eseguire azioni.

A livello generale, il routing e le azioni avanzate funzionano nel seguente modo:

1. Come nel routing semplice, l'host della richiesta viene confrontato con le regole host configurate in HTTPRoute o GRPCRoute. Se l'host di una richiesta corrisponde al nome host, viene valutato HTTPRoute o GRPCRoute.
2. Dopo aver selezionato un percorso, puoi applicare le azioni.

Routing avanzato

Il routing avanzato è simile al routing semplice descritto in precedenza, tranne per il fatto che puoi specificare condizioni di corrispondenza aggiuntive. Ad esempio, puoi specificare che una regola corrisponda all'intestazione di una richiesta se il nome dell'intestazione corrisponde esattamente o solo parzialmente, ad esempio in base al prefisso o al suffisso. Una regola può corrispondere in base alla valutazione del nome dell'intestazione rispetto a un'espressione regolare o ad altri criteri, ad esempio il controllo della presenza di un'intestazione.

Per ulteriori condizioni di corrispondenza e dettagli per headerMatches e queryParameterMatches, consulta la pagina API REST di network services.

Combinando host, percorso, intestazione e parametri di ricerca con le condizioni di corrispondenza, puoi creare regole molto espressive che si adattano ai tuoi requisiti esatti di gestione del traffico. Per maggiori dettagli consulta la tabella seguente.

	Applicazione basata su HTTP	Applicazione basata su gRPC
Host HTTP e host gRPC	L'host è la parte del nome di dominio dell'URL a cui l'applicazione fa riferimento. Ad esempio, la parte host dell'URL http://example.com/video/ è example.com.	L'host è il nome che un client utilizza nell'URI del canale per connettersi a un servizio specifico. Ad esempio, la parte host dell'URI del canale xds:///example.com è example.com.
Percorsi HTTP e percorsi gRPC	Il percorso è la parte dell'URL che segue il nome host. Ad esempio, la parte del percorso dell'URL http://example.com/video è /video.	Il percorso si trova nell'intestazione :path della richiesta HTTP/2 e ha un aspetto simile a /SERVICE_NAME/METHOD_NAME. Ad esempio, se chiami il metodo Download sul servizio gRPC Example, i contenuti dell'intestazione :path avranno il seguente aspetto: /Example/Download.
Altre intestazioni gRPC (metadati)		gRPC supporta l'invio di metadati tra il client gRPC e il server gRPC per fornire informazioni aggiuntive su una chiamata RPC. Questi metadati sono sotto forma di coppie chiave-valore che vengono trasportate come intestazioni nella richiesta HTTP/2.

Azioni

Cloud Service Mesh ti consente di specificare le azioni che i proxy Envoy o le applicazioni gRPC proxyless eseguono durante la gestione di una richiesta. Le seguenti azioni possono essere configurate utilizzando Cloud Service Mesh.

Azione	Nome campo API	Descrizione
Reindirizzamenti	redirect [pathredirect?]	Restituisce un codice di risposta 3xx configurabile. Imposta anche l'intestazione della risposta Location con l'URI appropriato, sostituendo l'host e il percorso come specificato nell'azione di reindirizzamento.
Riscritture degli URL	urlRewrite	Riscrive la parte del nome host dell'URL, la parte del percorso dell'URL o entrambe, prima di inviare una richiesta al servizio di backend selezionato.
Trasformazioni dell'intestazione	requestHeaderModifier/responseHeaderModifier?	Aggiunge o rimuove le intestazioni delle richieste prima di inviare una richiesta al servizio di backend. Può anche aggiungere o rimuovere le intestazioni di risposta dopo aver ricevuto una risposta dal servizio di backend.
Mirroring del traffico	requestMirrorPolicy	Oltre a inoltrare la richiesta al servizio di backend selezionato, invia una richiesta identica al servizio di backend mirror configurato in base al principio fire and forget. Il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta duplicata. Il mirroring è utile per testare una nuova versione di un servizio di backend. Puoi anche utilizzarlo per eseguire il debug degli errori di produzione in una versione di debug del tuo servizio di backend anziché nella versione di produzione.
Suddivisione del traffico basata sul peso	weightDestination.serviceName	Consente di distribuire il traffico per una regola corrispondente a più servizi di backend, in proporzione a un peso definito dall'utente assegnato al singolo servizio di backend. Questa funzionalità è utile per configurare implementazioni scaglionate o test A/B. Ad esempio, l'azione di routing potrebbe essere configurata in modo che il 99% del traffico venga inviato a un servizio che esegue una versione stabile di un'applicazione, mentre l'1% del traffico venga inviato a un servizio separato che esegue una versione più recente di quell'applicazione.
Nuovi tentativi	retryPolicy	Configura le condizioni in base alle quali il bilanciatore del carico riprova le richieste non riuscite, per quanto tempo il bilanciatore del carico attende prima di riprovare e il numero massimo di tentativi consentiti.
Timeout	timeout	Specifica il timeout per la route selezionata. Il timeout viene calcolato dal momento in cui la richiesta viene elaborata completamente fino al momento in cui la risposta viene elaborata completamente. Il timeout include tutti i tentativi.
Fault injection	faultInjectionPolicy	Introduce errori durante l'elaborazione delle richieste per simulare errori, tra cui latenza elevata, sovraccarico del servizio, errori del servizio e partizionamento della rete. Questa funzionalità è utile per testare la resilienza di un servizio a errori simulati.
Criteri di sicurezza	corsPolicy	I criteri di condivisione delle risorse tra origini (CORS) gestiscono le impostazioni per l'applicazione delle richieste CORS.

Per ulteriori informazioni sulle azioni e sul loro funzionamento, consulta la pagina API dei servizi di rete.

In ogni regola di routing, puoi specificare una delle seguenti azioni di routing:

• Instrada il traffico a un singolo servizio (destination.serviceName)
• Suddividi traffico fra più servizi (destination.weight)
• URL di reindirizzamento (redirect)

Inoltre, puoi combinare una qualsiasi delle azioni route menzionate in precedenza con una o più delle seguenti azioni route (denominate Azioni aggiuntive nella console Google Cloud ):

• Manipola le intestazioni delle richieste o delle risposte (requestHeaderModifier/responseHeaderModifier)
• Mirroring del traffico (requestMirrorPolicy)
• Riscrivi host, percorso o entrambi dell'URL (urlRewrite)
• Ritenta le richieste non riuscite (retryPolicy)
• Imposta timeout (timeout)
• Introduci errori in una percentuale del traffico (faultInjectionPolicy)
• Aggiungi policy CORS (corsPolicy)

Poiché le azioni sono associate a regole specifiche, il proxy Envoy o l'applicazione gRPC senza proxy può applicare azioni diverse in base alla richiesta che sta gestendo.

Distribuire il traffico tra i backend di un servizio

Come descritto in Gestione delle richieste, quando un client gestisce una richiesta in uscita, seleziona prima un servizio di destinazione. Dopo aver selezionato un servizio di destinazione, deve capire quale backend o endpoint deve ricevere la richiesta.

Nel diagramma precedente, la regola è stata semplificata. La regola è in genere una regola host, un matcher percorso e una o più regole di percorso o route. Il servizio di destinazione è il servizio(di backend). Backend 1, … e Backend n ricevono e gestiscono la richiesta. Questi backend potrebbero essere, ad esempio, istanze di macchine virtuali (VM) Compute Engine che ospitano il codice dell'applicazione lato server.

Per impostazione predefinita, il client che gestisce la richiesta invia le richieste al backend integro più vicino con capacità disponibile. Per evitare di sovraccaricare un backend specifico, utilizza l'algoritmo di bilanciamento del carico round robin per bilanciare il carico delle richieste successive tra gli altri backend del servizio di destinazione. In alcuni casi, tuttavia, potresti voler avere un controllo più granulare su questo comportamento.

Bilanciamento del carico, affinità sessione e protezione dei backend

Puoi impostare i seguenti criteri di distribuzione del traffico su ogni servizio.

Norme	Nome campo API	Descrizione
Modalità di bilanciamento del carico	balancingMode	Controlla la modalità di selezione di un gruppo di endpoint di rete (NEG) o di un gruppo di istanze gestite (MIG) dopo la selezione di un servizio di destinazione. Puoi configurare la modalità di bilanciamento per distribuire il carico in base alle connessioni simultanee e allatasso di richiestee.
Policy di bilanciamento del carico	localityLbPolicy	Imposta l'algoritmo di bilanciamento del carico utilizzato per distribuire il traffico tra i backend all'interno di un NEG o di un gruppo di istanze gestite. Per ottimizzare il rendimento, puoi scegliere tra vari algoritmi (ad esempio round robin o least request).
Affinità sessione	sessionAffinity	Fornisce un tentativo di best effort per inviare richieste da un determinato client allo stesso backend finché il backend è integro e ha capacità. Cloud Service Mesh supporta quattro opzioni di affinità sessione: basata su indirizzo IP client, cookie HTTP, intestazione HTTP e affinità cookie generato (che Cloud Service Mesh genera autonomamente).
Hash coerente	consistentHash	Fornisce l'affinità sessione temporanea in base alle intestazioni HTTP, ai cookie o ad altre proprietà.
Interruttori di sicurezza	circuitBreakers	Imposta limiti superiori sul volume di connessioni e richieste per connessione a un servizio di backend.
Rilevamento outlier	outlierDetection	Specifica i criteri per (1) rimuovere backend o endpoint non integri da MIG o NEG e (2) aggiungere di nuovo un backend o un endpoint quando è considerato sufficientemente integro da ricevere di nuovo traffico. Il controllo di integrità associato al servizio determina se un backend o un endpoint è considerato integro.

Per ulteriori informazioni sulle diverse opzioni di distribuzione del traffico e sul loro funzionamento, consulta i seguenti documenti:

• Pagina backendServicesAPI REST
• Panoramica dei servizi di backend.

Esempi di casi d'uso

La gestione avanzata del traffico copre molti casi d'uso. Questa sezione fornisce alcuni esempi di alto livello.

Puoi trovare altri esempi, incluso codice campione, in Configurare la gestione avanzata del traffico con Envoy e Configurare la gestione avanzata del traffico con i servizi gRPC proxyless.

Instradamento del traffico granulare per la personalizzazione

Puoi indirizzare il traffico a un servizio in base ai parametri della richiesta. Ad esempio, potresti utilizzare questo servizio per offrire un'esperienza più personalizzata agli utenti Android. Nel seguente diagramma, Cloud Service Mesh configura il mesh di servizi per inviare richieste con l'intestazione user-agent:Android al tuo servizio Android anziché al tuo servizio generico.

Suddivisione del traffico basata sul peso per deployment più sicuri

Il deployment di una nuova versione di un servizio di produzione esistente può essere rischioso. Anche dopo che i test sono stati superati in un ambiente di test, potresti non voler indirizzare subito tutti gli utenti alla nuova versione.

Cloud Service Mesh consente di definire suddivisioni del traffico basate sul peso per distribuire il traffico tra più servizi. Ad esempio, puoi inviare l'1% del traffico alla nuova versione del servizio, monitorare che tutto funzioni e poi aumentare gradualmente la percentuale di traffico che va al nuovo servizio.

Mirroring del traffico per il debug

Quando esegui il debug di un problema, potrebbe essere utile inviare copie del traffico di produzione a un servizio di debug. Cloud Service Mesh ti consente di configurare criteri di mirroring delle richieste in modo che le richieste vengano inviate a un servizio e le copie di queste richieste vengano inviate a un altro servizio.

Bilanciamento del carico ottimizzato per le prestazioni

A seconda delle caratteristiche dell'applicazione, potresti scoprire di poter migliorare le prestazioni e la disponibilità ottimizzando la distribuzione del traffico tra i backend di un servizio. Con Cloud Service Mesh, puoi applicare algoritmi di bilanciamento del carico avanzati in modo che il traffico venga distribuito in base alle tue esigenze.

Il seguente diagramma, a differenza dei precedenti, mostra sia un servizio di backend di destinazione (Production Service) sia i backend per quel servizio di backend (Virtual Machine 1, Virtual Machine 2, Virtual Machine 3). Con la gestione avanzata del traffico, puoi configurare la modalità di selezione di un servizio di backend di destinazione e la modalità di distribuzione del traffico tra i backend per quel servizio di destinazione.

Per saperne di più sul bilanciamento del carico con Cloud Service Mesh, consulta la Panoramica del bilanciamento del carico avanzato.

Passaggi successivi

• Per indirizzare il traffico dall'esterno del mesh al suo interno, consulta la sezione Traffico in entrata per il tuo mesh.