Panoramica sulla gestione avanzata del traffico
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 determina e configura il modo il traffico viene gestito in un deployment Cloud Service Mesh.
Cloud Service Mesh offre funzionalità avanzate per la gestione del traffico che ti offrono un controllo granulare di come viene gestito il 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
in un'altra libreria. Il mirroring del traffico non è supportato con
TCPRoute
o la risorsaTLSRoute
. - 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 risorsaMesh
identifica anche la porta di intercettazione del traffico.Gateway
, che identifica i proxy intermedi e rappresenta la risorsa che rimane in ascolto su un elenco di coppie indirizzo:porta, inoltra traffico e applica i criteri.Route
, che può essere di diversi tipi e che contiene informazioni sul routing del traffico per la mesh. Identificazione diRoute
risorsa nomi host e porte utilizzabili dai client per instradare il traffico al backend i servizi di machine learning. Di seguito sono riportati i tipi di risorseRoute
:HTTPRoute
, disponibile solo nei mesh che utilizzano proxy Envoy. Quando utilizza la risorsaHTTPRoute
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:
- Configura una risorsa
Mesh
per identificare il mesh di servizi. Configura le risorse di
Route
per eseguire le seguenti operazioni, in base al caratteristiche della richiesta in uscita:Seleziona il servizio di backend a cui vengono instradate le richieste.
Se vuoi, puoi eseguire altre azioni.
Configura il servizio di backend per controllare la distribuzione del traffico a backend ed 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 nella risorsa Mesh
,
Route
risorsa e risorsa del servizio di backend. Gestione avanzata del traffico
le funzionalità relative al routing e alle azioni vengono configurate utilizzando l'Route
di oggetti strutturati.
Le seguenti sezioni descrivono le funzionalità avanzate di gestione del traffico che
che puoi configurare negli oggetti Route
.
Gestione delle richieste
Quando un client invia una richiesta, questa viene gestita come descritto seguenti passaggi:
La richiesta è abbinata a una risorsa
Route
specifica come segue:- Se utilizzi Envoy:
- L'intestazione host nella richiesta HTTP viene confrontata con
hostnames
in ogniHTTPRoute
oGRPCRoute
risorsa per selezionareRoute
risorsa per la richiesta. SoloHTTPRoute
eGRPCRoute
risorse hanno il campohostnames
. - 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
eGRPCRoute
sono associate a unMesh
oGateway
deve avere nomi host univoci. Se provi ad allegare più route con nomi host in conflitto, la configurazione viene rifiutata. - Allo stesso modo, il campo
IP:Port
diTCPRoute
deve essere univoco o il 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 al percorso più specifico.
- L'intestazione host nella richiesta HTTP viene confrontata con
- Se utilizzi gRPC senza proxy:
- I client gRPC senza proxy utilizzano lo schema di risoluzione dei nomi
xds
. Loro risolvihostname[:port]
nell'URI di destinazione inviando una richiesta in Cloud Service Mesh. - Viene confrontata solo la porta di una risorsa
GRPCRoute
alla porta nell'URI di destinazione (ad esempio,xds:///example.hostname:8080
). L'URI di destinazione deve corrispondere esattamente la stringa nel campohostnames
diGRPCRoute
.
- I client gRPC senza proxy utilizzano lo schema di risoluzione dei nomi
- Se utilizzi Envoy:
La risorsa
Route
può contenere ulteriori informazioni e regole di routing.Dopo aver 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 configurazione nella risorsa del servizio di backend.
Il secondo passaggio è descritto nella sezione seguente. Routing semplice basato su host e percorso. Il terzo passaggio prevede discussi 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 del tuo percorso di apprendimento. 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 unGRPCRoute
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 devi specificare solo un carattere jolly
(*
) e un matcher del 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 nel modo seguente:
Se l'host di una richiesta (ad esempio
example.com
) corrisponde al nome host diHTTPRoute
:- Viene valutato successivamente il
RouteRule
. IlRouteRule
specifica come trovare una corrispondenza e come instradare il traffico quando il traffico corrisponde. - Ogni
RouteRule
contiene una o più corrispondenze di route valutate rispetto al percorso della richiesta. - Se viene trovata una corrispondenza, la richiesta viene indirizzata al servizio specificato
RouteAction
.
- Viene valutato successivamente il
Per saperne di più sui campi delle risorse di HTTPRoute
e sul loro funzionamento,
consulta la documentazione relativa all'API del servizio di rete.
Routing e azioni avanzate
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 avanzati funzionano come segue:
- Come nel caso del routing semplice, l'host della richiesta viene confrontato con l'host
che configuri in
HTTPRoute
oGRPCRoute
. Se una richiesta host corrisponde al nome host, viene valutatoHTTPRoute
oGRPCRoute
. - 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 le
API REST network services
.
Combinando host, percorso, intestazione e parametri di ricerca con la corrispondenza di traffico, puoi creare regole altamente espressive che si adattano al traffico requisiti di gestione. 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
|
L'host è il nome utilizzato dal client nell'URI del canale connettersi a un servizio specifico. Ad esempio, la parte host dell'URI del canale
|
Percorsi HTTP e percorsi gRPC | Il percorso è la parte dell'URL che segue il nome host. Ad esempio, la parte del percorso dell'URL
|
Il percorso si trova nell'intestazione Ad esempio, se chiami il metodo |
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.
Azione | Nome campo API | Descrizione |
---|---|---|
Reindirizzamenti | redirect |
Restituisce un codice di risposta 3xx configurabile. Imposta anche
intestazione della risposta Location con l'URI appropriato,
sostituendo l'host e il percorso come specificato nell'azione di reindirizzamento.
|
Riscrittura 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 intestazione | requestHeaderModifier/responseHeaderModifier |
Aggiunge o rimuove le intestazioni della richiesta prima di inviare una richiesta al di servizio di backend. Può anche aggiungere o rimuovere le intestazioni delle risposte dopo o ricevere 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 di una regola con corrispondenza in più di backend, proporzionale a un peso definito dall'utente assegnato un 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 è stato calcolato dal momento dell'elaborazione completa della richiesta fino al momento in cui la risposta viene elaborata completamente. Il timeout include tutti i nuovi tentativi. |
Fault injection | faultInjectionPolicy |
Introduce errori durante la gestione delle richieste per simulare gli errori, tra cui alta latenza, sovraccarico del servizio, errori del servizio e rete il partizionamento orizzontale. 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 forzando l'applicazione delle richieste CORS. |
Per ulteriori informazioni sulle azioni e su come funzionano, vedi API Network Services.
In ogni regola di route, puoi specificare una delle seguenti azioni di route:
- Instrada il traffico a un singolo servizio (
destination.serviceName
) - Suddividi 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
) - Mirroring del traffico (
requestMirrorPolicy
) - Riscrivi l'host dell'URL, il percorso o entrambi (
urlRewrite
) - Riprova 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 descritto in Gestione delle richieste, Quando un client gestisce una richiesta in uscita, seleziona prima una destinazione completamente gestito di Google Cloud. Dopo aver selezionato un servizio di destinazione, deve capire quale deve ricevere la richiesta dal backend o dall'endpoint.
Nel diagramma precedente, la regola è stata semplificata. La regola è in genere una regola host, uno strumento di abbinamento del percorso e una o più regole di percorso o route. La di destinazione è il servizio(backend). Backend 1, ... e Il backend riceve e gestisce la richiesta. Questi backend potrebbero essere, ad esempio le 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, tuttavia, potresti volere un controllo più granulare comportamento degli utenti.
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 NEG o un gruppo di istanze gestite. Per ottimizzare il rendimento, puoi scegliere tra vari algoritmi (come round robin o minima richiesta). |
Affinità sessione | sessionAffinity |
Fornisce un tentativo di invio delle richieste basato sul criterio del "best effort" da un particolare client allo stesso backend per tutto il tempo per cui il backend è integro e ha capacità. Cloud Service Mesh supporta quattro opzioni di affinità sessione: indirizzo IP client, HTTP basato su cookie, HTTP basato su intestazioni e dell'affinità cookie generato (che Cloud Service Mesh genera automaticamente). |
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 sono considerati integri. |
Per ulteriori informazioni sulle varie opzioni di distribuzione del traffico e come funzionano, consulta i seguenti documenti:
Esempi di casi d'uso
La gestione avanzata del traffico è applicabile a molti casi d'uso. Questa sezione fornisce una alcuni esempi di alto livello.
Puoi trovare altri esempi, incluso il codice campione, in Configura la gestione avanzata del traffico con Envoy e Configurare la gestione avanzata del traffico con i servizi gRPC senza proxy.
Routing del traffico granulare per la personalizzazione
Puoi instradare 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 gli 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.
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, controlla che tutto funzioni e poi gradualmente aumentare la proporzione di traffico diretto al nuovo servizio.
Mirroring del traffico per il debug
Quando esegui il debug di un problema, potrebbe essere utile inviare copie dei dati 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.
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 le 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 gestione avanzata del traffico, puoi configurare il modo in cui un servizio di backend di destinazione e il modo in cui il traffico viene distribuito tra i backend per servizio di destinazione.
Per ulteriori informazioni sul bilanciamento del carico con Cloud Service Mesh, consulta Panoramica del bilanciamento del carico avanzato.
Passaggi successivi
- Per indirizzare il traffico dall'esterno del mesh al tuo mesh, consulta Traffico in entrata per il tuo mesh.