Panoramica della gestione avanzata del traffico

Questo documento è rivolto ad amministratori di mesh o piattaforme e sviluppatori di servizi che hanno un livello di familiarità intermedio o avanzato con i concetti di Cloud Service Mesh e dei mesh di servizi e che determinano e configurano la modalità di gestione del traffico in un deployment di Cloud Service Mesh.

Nota: questa guida supporta solo Cloud Service Mesh con le API Google Cloud e non supporta le API Istio. Per ulteriori informazioni, consulta la panoramica di Cloud Service Mesh.

Cloud Service Mesh offre funzionalità avanzate di gestione del traffico che ti consentono di avere un controllo granulare sulle modalità di gestione del traffico. Cloud Service Mesh supporta i seguenti casi d'uso:

• Routing granulare del traffico delle richieste a uno o più servizi.
• Suddivisione del traffico in base alla ponderazione per distribuire il traffico tra più servizi.
• Criteri di mirroring del traffico che inviano richieste a un servizio di debug e le copiano in un altro. Il mirroring del traffico non è supportato con TCPRoute o la risorsa TLSRoute.
• Distribuzione del traffico ottimizzata nei backend di un servizio per migliorare il carico e del bilanciamento del carico.

Queste funzionalità avanzate di gestione del traffico consentono di in termini di disponibilità e prestazioni. Uno dei vantaggi dell'utilizzo Cloud Service Mesh per questi casi d'uso consente di aggiornare il modo in cui il traffico è gestito senza dover modificare il codice dell'applicazione.

La gestione del traffico in un mesh di servizi Cloud Service Mesh si basa su quanto segue di risorse:

• Mesh, che identifica il mesh di servizi e rappresenta la risorsa responsabile dell'inoltro del traffico e dell'applicazione criteri. La risorsa Mesh identifica anche la porta di intercettazione del traffico.
• La risorsa Gateway, che identifica i proxy intermedi e rappresenta il componente che ascolta un elenco di coppie di indirizzo IP:porta, inoltra il traffico e applica le norme.
• Risorsa Route, che può essere di diversi tipi e 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 utilizza la risorsa HTTPRoute per configurare i proxy Envoy per inviare HTTP richieste, tutte le funzionalità di questo documento sono disponibili.
  • TCPRoute, disponibile solo nei mesh che utilizzano proxy Envoy.
  • TLSRoute, disponibile solo nei mesh che utilizzano proxy Envoy.
  • GRPCRoute, disponibile nei mesh che utilizzano proxy sidecar di Envoy e gRPC senza proxy. Quando utilizzi servizi o applicazioni gRPC senza proxy con Cloud Service Mesh, alcune delle funzionalità descritte in documento non disponibile.
• Servizio di backend, a cui sono associate Route risorse.

Configurazione

Per configurare la gestione avanzata del traffico, utilizza gli stessi Route e le risorse dei servizi di backend che utilizzi durante la configurazione di Cloud Service Mesh. Cloud Service Mesh, a sua volta, configura i proxy Envoy e gRPC senza proxy per applicare i criteri avanzati di gestione del traffico impostati verso l'alto.

A livello generale, svolgi le seguenti operazioni:

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

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

Routing del traffico e azioni

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

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

Gestione delle richieste

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

1. La richiesta è abbinata a una risorsa Route specifica come segue:

   • Se utilizzi Envoy:
     • L'intestazione host nella richiesta HTTP viene associata al campo hostnames in ogni risorsa HTTPRoute o GRPCRoute per selezionare la risorsa Route corretta per la richiesta. Solo le risorse HTTPRoute e GRPCRoute possiedono il campo hostnames.
     • L'indirizzo IP corrisponde al routing del traffico TCP utilizzando TCPPRoute.
     • SNI e ALPN vengono utilizzati per il passthrough TLS utilizzando TLSRoute.
     • Le risorse HTTPRoute e GRPCRoute sono associate a un Mesh o Un Gateway deve avere nomi host univoci. Se provi ad allegare più route con nomi host in conflitto, la configurazione viene rifiutata.
     • Analogamente, il campo IP:Port di TCPRoute deve essere univoco, altrimenti la configurazione viene rifiutata.
     • Analogamente, SNI e ALPN devono essere univoci per il TLSRoute.
     • Se sono presenti nomi host sovrapposti, ad esempio a.example.com e *.example.com, la richiesta corrisponde al percorso più specifico.
   • Se utilizzi gRPC senza proxy:
     • I client gRPC senza proxy utilizzano lo schema di risoluzione dei nomi xds. Risolvono il valore hostname[:port] nell'URI di destinazione inviando una richiesta a Cloud Service Mesh.
     • Solo la porta di una risorsa GRPCRoute viene confrontata 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. Dopo aver selezionato il servizio di backend di destinazione, il traffico viene distribuito tra i backend o gli endpoint del 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 è discusso in Routing e azioni avanzati.

Routing semplice basato su host e percorso

Cloud Service Mesh supporta uno schema di routing semplificato e una schema 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 instradata 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, la porzione del percorso dell'URL http://example.com/video/ è /video.

Puoi configurare un routing semplice in base all'host e al percorso nella mappa di regole di routing, consiste di quanto segue:

• Un Mesh globale
• Un HTTPRoute o un GRPCRoute

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

La regola più semplice è una regola predefinita, in cui specifichi solo una regola host con caratteri jolly (*) e un matcher percorso con un servizio predefinito. Dopo la creazione la regola predefinita, puoi aggiungere altre regole che specificano host percorsi di addestramento. Le richieste in uscita vengono valutate in base a queste regole come segue:

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

  1. Viene valutato successivamente il RouteRule. Il RouteRule specifica come trovare una corrispondenza e come instradare il traffico quando il traffico corrisponde.
  2. Ogni RouteRule contiene una o più corrispondenze di route che vengono valutate rispetto al percorso della richiesta.
  3. Se viene trovata una corrispondenza, la richiesta viene indirizzata al servizio specificato RouteAction.

Per ulteriori informazioni sui campi delle risorse di HTTPRoute e sul loro funzionamento, consulta la documentazione dell'API di servizio di rete.

Routing e azioni avanzati

Se vuoi fare qualcosa di più che eseguire il routing di una richiesta in base all'host e puoi impostare regole avanzate per instradare le richieste ed eseguire azioni.

A livello generale, il routing e le azioni avanzate funzionano come segue:

1. Come nel caso del routing semplice, l'host della richiesta viene confrontato con l'host che configuri 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 azioni.

Routing avanzato

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

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

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

	Applicazione basata su HTTP	Applicazione basata su gRPC
Confronto tra host HTTP e host gRPC	L'host è la parte del nome di dominio dell'URL che l'applicazione che ti chiama. Ad esempio, la parte dell'URL relativa all'host http://example.com/video/ è example.com.	L'host è il nome utilizzato da un client nell'URI del canale per collegarsi 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 il seguente aspetto: /SERVICE_NAME/METHOD_NAME. Ad esempio, se chiami il metodo Download nella Example servizio gRPC, i contenuti L'intestazione :path assomiglia a /Example/Download.
Altre intestazioni gRPC (metadati)		gRPC supporta l'invio metadati tra il client gRPC e il server gRPC per fornire informazioni su una chiamata RPC. Questi metadati si presentano in formato coppie chiave-valore trasportate come intestazioni nella richiesta HTTP/2.

Azioni

Cloud Service Mesh ti consente di specificare le azioni che il tuo Envoy le applicazioni gRPC senza proxy prendono in considerazione la gestione delle richieste. Le seguenti azioni può essere configurato utilizzando Cloud Service Mesh.

Nota: tutte le seguenti funzionalità sono disponibili quando utilizzi Envoy con Cloud Service Mesh. Alcune funzionalità non sono disponibili quando utilizzi applicazioni gRPC senza proxy con Cloud Service Mesh. Per maggiori informazioni nel dettaglio, consulta la pagina Funzionalità e Limitazioni con gRPC senza proxy .

Azione	Nome del campo dell'API	Descrizione
Reindirizzamenti	redirect [pathredirect?]	Restituisce un codice di risposta 3xx configurabile. Imposta inoltre l'Location intestazione di risposta con l'URI appropriato, sostituendo l'host e il percorso come specificato nell'azione di reindirizzamento.
Riscritture degli URL	urlRewrite	Riscrive la parte dell'URL relativa al nome host, la parte del percorso dell'URL, o entrambi, prima di inviare una richiesta al servizio di backend selezionato.
Trasformazioni intestazioni	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 backend selezionato invia una richiesta identica al backend di mirroring configurato su un incendio e dimenticarsi. Il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta sottoposta a mirroring. Il mirroring è utile per testare una nuova versione di un servizio di backend. Puoi utilizzarla anche per eseguire il debug degli errori di produzione in una versione di debug al servizio di backend anziché nella versione di produzione.
Suddivisione del traffico in base alla ponderazione	weiDestination.serviceNameght	Consente di distribuire il traffico per una regola con corrispondenza a più backend, in proporzione a un peso definito dall'utente assegnato al singolo servizio di backend. Questa funzionalità è utile per configurare deployment a fasi o A/B. test. Ad esempio, l'azione di route potrebbe essere configurata in modo che Il 99% del traffico viene inviato a un servizio che esegue una di un'applicazione, mentre l'1% del traffico viene inviato separato che esegue una versione più recente dell'applicazione.
Nuovi tentativi	retryPolicy	Configura le condizioni in cui i nuovi tentativi del bilanciatore del carico non sono riusciti richieste, quanto tempo attende il bilanciatore del carico prima di riprovare il numero massimo di nuovi tentativi consentiti.
Timeout	timeout	Specifica il timeout per la route selezionata. Il timeout viene calcolato dal momento in cui la richiesta viene completamente elaborata fino al momento in cui la risposta viene completamente elaborata. Il timeout include tutti i tentativi di ripetizione.
Fault injection	faultInjectionPolicy	Introduce errori durante l'elaborazione delle richieste per simulare errori, tra cui latenza elevata, sovraccarico del servizio, errori di servizio e suddivisione della rete. Questa funzionalità è utile per testare la resilienza di un per risolvere gli 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 relativa all'API Network Services.

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

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

Inoltre, puoi combinare una qualsiasi delle azioni di percorso menzionate in precedenza con una o più delle seguenti azioni di route (indicate come Azioni dei componenti aggiuntivi nella console Google Cloud):

• Manipolare le intestazioni di richiesta o risposta (requestHeaderModifier/responseHeaderModifier)
• Esegui il mirroring del traffico (requestMirrorPolicy)
• Riscrivere l'host, il percorso o entrambi gli elementi dell'URL (urlRewrite)
• Riprova le richieste non riuscite (retryPolicy)
• Imposta timeout (timeout)
• Introduci gli errori a una percentuale del traffico (faultInjectionPolicy)
• Aggiungi criterio CORS (corsPolicy)

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

Distribuisci il traffico tra i backend di un servizio

Come discusso 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 deve ricevere la richiesta dal backend o dall'endpoint.

Distribuzione del traffico tra i backend (fai clic per ingrandire)

Nel diagramma precedente, la Regola è stata semplificata. La Regola è tipicamente una regola host, un matcher percorso e una o più regole percorso o route. La di destinazione è il servizio(backend). Backend 1, ... e Il backend riceve e gestisce la richiesta. Questi backend possono 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 richieste con il backend integro più vicino con capacità. Per evitare di sovraccaricare utilizza l'algoritmo di bilanciamento del carico Round Robin per bilanciare richieste successive su altri backend del servizio di destinazione. In alcuni casi, però, potresti voler avere un controllo più granulare su questo comportamento.

Bilanciamento del carico, affinità sessione e protezione dei backend

Per ogni servizio puoi impostare i seguenti criteri di distribuzione del traffico.

Norme	Nome campo API	Descrizione
Modalità di bilanciamento del carico	balancingMode	Controlla in che modo un gruppo di endpoint di rete (NEG) o un'istanza gestita gruppo (MIG) viene selezionato dopo che è stato eseguito un servizio di destinazione selezionato. Puoi configurare la modalità di bilanciamento per distribuire il carico in base alle connessioni simultanee e tasso di richieste.
Criterio di bilanciamento del carico	localityLbPolicy	Imposta l'algoritmo di bilanciamento del carico utilizzato per distribuire il traffico tra i backend all'interno di un gruppo NEG o MIG. Per ottimizzare il rendimento, puoi scegliere tra vari algoritmi (ad esempio round robin o least request).
Affinità sessione	sessionAffinity	Fornisce un tentativo secondo il criterio del "best effort" per inviare richieste da un determinato client allo stesso backend finché il backend è integro e dispone di capacità. Cloud Service Mesh supporta quattro opzioni di affinità di sessione: l'indirizzo IP del client, basata su cookie HTTP, basata su intestazione HTTP e affinità del cookie generata (generata da Cloud Service Mesh).
Hash coerente	consistentHash	Fornisce affinità sessione software basata su intestazioni HTTP, cookie o altre proprietà.
Interruttori di sicurezza	circuitBreakers	Imposta limiti superiori per il volume di connessioni e richieste per a un servizio di backend.
Rilevamento outlier	outlierDetection	Specifica i criteri per (1) rimuovere i backend in stato non integro da MIG o NEG e (2) aggiungere un backend quando è considerato sufficientemente integro da ricevere traffico di nuovo. 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 backendServices API REST
• Panoramica dei servizi di backend.

Esempi di casi d'uso

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

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

Routing del traffico granulare per la personalizzazione

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

Routing in base all'intestazione user-agent impostata su Android (fai clic per ingrandire)

Suddivisione del traffico in base alla ponderazione per deployment più sicuri

Il deployment di una nuova versione di un servizio di produzione esistente può essere rischioso. Uniforme una volta superati i test in un ambiente di test, potrebbe essere utile non eseguire il routing gli utenti alla nuova versione.

Cloud Service Mesh ti consente di definire le suddivisioni del traffico basate sui pesi da distribuire e il traffico su più servizi. Ad esempio, puoi inviare l'1% del traffico alla nuova versione del servizio, monitorare il funzionamento di tutto e poi aumentare gradualmente la proporzione di traffico che va al nuovo servizio.

Suddivisione del traffico basata sui pesi di Cloud Service Mesh (fai clic per ingrandire)

Mirroring del traffico per il debug

Quando stai eseguendo il debug di un problema, può essere utile inviare copie del traffico di produzione a un servizio di debug. Cloud Service Mesh ti consente di configurare la richiesta i criteri di mirroring in modo che le richieste vengano inviate a un servizio e a copie di questi vengono inviate a un altro servizio.

Mirroring del traffico di Cloud Service Mesh (fai clic per ingrandire)

Bilanciamento del carico ottimizzato per le prestazioni

A seconda delle caratteristiche della tua applicazione, potresti scoprire che migliorare le prestazioni e la disponibilità ottimizzando le modalità di distribuzione del traffico nei 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 di quelli precedenti, mostra sia una destinazione (servizio di produzione) e i backend per quel servizio di backend (Macchina virtuale 1, Macchina virtuale 2, Macchina virtuale 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.

Bilanciamento del carico di Cloud Service Mesh (fai clic per ingrandire)

Per ulteriori informazioni sul bilanciamento del carico con Cloud Service Mesh, consulta la Panoramica del bilanciamento del carico avanzato.

Passaggi successivi

• Per indirizzare il traffico dall'esterno della tua rete mesh al suo interno, consulta Traffico in entrata per il tuo mesh.