Panoramica della gestione avanzata del traffico per le API di bilanciamento del carico

Questo documento è rivolto agli amministratori di mesh o piattaforme e agli sviluppatori di servizi che hanno un livello di conoscenza da intermedio a avanzato con i concetti di mesh di servizi e mesh di servizi e che determinano e configurano la modalità di gestione del traffico in un deployment di Cloud Service Mesh. Questo documento riguarda esclusivamente le API di bilanciamento del carico, non le API di routing dei servizi. Se il deployment di Cloud Service Mesh utilizza le API di routing dei servizi, consulta Panoramica della gestione avanzata del traffico.

Cloud Service Mesh offre funzionalità avanzate di gestione del traffico che ti offrono un controllo granulare sulla 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 copie a un altro
  • Distribuzione del traffico ottimizzata nei backend di un servizio per migliorare il bilanciamento del carico

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

  • Quando utilizzi il proxy HTTP di destinazione per configurare i proxy Envoy al fine di inviare le richieste HTTP, sono disponibili tutte le funzionalità in questo documento.

  • Quando utilizzi applicazioni o servizi gRPC senza proxy con Cloud Service Mesh, alcune funzionalità non sono disponibili.

  • Quando utilizzi il proxy TCP di destinazione per configurare i proxy Envoy per inviare richieste TCP, nessuna delle funzionalità è disponibile perché non esiste una mappa URL nelle configurazioni con un proxy TCP di destinazione.

Per ulteriori dettagli, consulta la pagina Funzionalità.

Per configurare la gestione avanzata del traffico, utilizza la stessa mappa di regole di routing e le stesse 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 le applicazioni gRPC senza proxy per applicare i criteri avanzati per la gestione del traffico che hai impostato.

A livello generale, svolgi le seguenti operazioni:

  1. Configura la mappa di regole di routing in modo da eseguire le seguenti operazioni, in base alle caratteristiche della richiesta in uscita:

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

    2. Se vuoi, puoi eseguire altre azioni.

  2. Configura il servizio di backend per controllare la distribuzione del traffico su backend ed endpoint dopo la selezione di un servizio di destinazione.

Configurazione filtri

Una delle responsabilità principali di Cloud Service Mesh è generare informazioni di configurazione da regola di forwarding, proxy di destinazione e mappa URL e quindi inviare queste informazioni ai client Cloud Service Mesh, ad esempio proxy Envoy e applicazioni gRPC. Cloud Service Mesh controlla il mesh di servizi inviando ai propri client informazioni di configurazione che indicano come comportarsi e come instradare il traffico. Cloud Service Mesh è il piano di controllo.

Quando crei o aggiorni le informazioni di configurazione in Cloud Service Mesh, Cloud Service Mesh traduce questa configurazione in un linguaggio comprensibile ai suoi client. Per impostazione predefinita, Cloud Service Mesh condivide questa configurazione con tutti i client. In alcuni casi, è possibile personalizzare quali client Cloud Service Mesh ricevono informazioni di configurazione specifiche, in altre parole filtrare la configurazione in base a client specifici.

Sebbene questa sia una funzionalità avanzata, i seguenti esempi illustrano quando la configurazione del filtro può aiutarti a:

  • La tua organizzazione utilizza il modello di networking VPC condiviso e più team utilizzano Cloud Service Mesh in diversi progetti di servizio. Se vuoi isolare la configurazione da altri progetti di servizio, puoi filtrare la configurazione in modo che client Cloud Service Mesh specifici ricevano solo un sottoinsieme della configurazione.
  • Hai un numero molto elevato di regole di route e servizi configurati in Cloud Service Mesh e vuoi evitare di inviare una quantità insolitamente grande di configurazione a ogni client Cloud Service Mesh. Tieni presente che un client che deve valutare una richiesta in uscita utilizzando una configurazione complessa e di grandi dimensioni potrebbe funzionare meno bene di un client che deve solo valutare una richiesta utilizzando una configurazione semplificata.

I filtri di configurazione si basano sul concetto di filtri dei metadati:

  1. Quando un client Cloud Service Mesh si connette, presenta le informazioni del suo file di bootstrap in Cloud Service Mesh.
  2. Queste informazioni contengono i contenuti dei campi dei metadati, sotto forma di coppie chiave-valore, specificate nel file di bootstrap quando esegui il deployment dei proxy Envoy e delle applicazioni gRPC.
  3. Puoi aggiungere filtri di metadati alla regola di forwarding. L'intera configurazione collegata alla regola di forwarding viene filtrata.
  4. Puoi aggiungere filtri di metadati sulla mappa URL. Il filtro di metadati viene applicato in base al routing per percorso.
  5. Cloud Service Mesh condivide la configurazione solo con i client che presentano metadati che corrispondono alle condizioni del filtro dei metadati.

Per informazioni su come configurare i filtri dei metadati per Envoy, consulta Configurare il filtro della configurazione in base alla corrispondenza di MetadataFilter.

Routing del traffico e azioni

In Cloud Service Mesh, la mappa di regole di routing si riferisce alla combinazione di regola di forwarding, proxy di destinazione e risorse di mappa URL. Tutte le funzionalità di gestione avanzata del traffico relative al routing e alle azioni vengono configurate tramite la mappa URL.

Le seguenti sezioni descrivono le funzionalità avanzate di gestione del traffico che puoi impostare nella mappa di regole di routing.

Gestione delle richieste

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

  1. La richiesta è abbinata a una mappa di regole di routing specifica come segue:

    • Se utilizzi Envoy:

      • L'indirizzo IP e la porta di destinazione della richiesta vengono confrontati con l'indirizzo IP e la porta delle regole di forwarding in tutte le mappe di regole di routing. Vengono considerate solo le mappe di regole di routing con regole di forwarding che hanno lo schema di bilanciamento del carico INTERNAL_SELF_MANAGED.
      • La regola di forwarding che corrisponde alla richiesta fa riferimento a un proxy HTTP o gRPC di destinazione, che fa riferimento a una mappa URL. Questa mappa URL contiene informazioni utilizzate per il routing e le azioni.

    • Se utilizzi gRPC senza proxy:

      • Un client gRPC che utilizza lo schema di risoluzione dei nomi xds non esegue una ricerca DNS per risolvere il nome host nell'URI del canale. Un client di questo tipo risolve invece hostname[:port] nell'URI di destinazione inviando una richiesta LDS a Cloud Service Mesh.
      • Solo la porta di una regola di forwarding con schema di bilanciamento del carico INTERNAL_SELF_MANAGED viene confrontata con la porta nell'URI di destinazione (ad esempio xds:///example.hostname:8080). L'indirizzo IP della regola di forwarding non viene utilizzato. Il valore predefinito della porta è 80 se non è specificata alcuna porta nell'URI di destinazione.
      • La regola di forwarding che corrisponde alla richiesta fa riferimento a un proxy gRPC di destinazione, che fa riferimento a una mappa URL. Questa mappa URL contiene informazioni utilizzate per il routing e le azioni.
      • Se più di una regola di forwarding soddisfa la richiesta, per il routing e le azioni viene utilizzata la mappa dell'URL contenente la regola dell'host che corrisponde a hostname[:port] nell'URI di destinazione.

  2. Una volta determinata la mappa URL appropriata, quest'ultima viene valutata per determinare il servizio di backend di destinazione e, facoltativamente, applicare azioni.

  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 è descritto in Routing e azioni avanzati.

Routing semplice basato su host e percorso

Cloud Service Mesh supporta uno schema di routing semplificato e uno schema 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 a cui deve essere instradata una richiesta:

  • L'host della richiesta è la parte del nome di dominio di un URL; ad esempio, la parte dell'URL http://example.com/video/ relativa all'host è example.com.
  • Il percorso della richiesta è la parte dell'URL che segue il nome host; ad esempio, la parte 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, che comprende quanto segue:

  • Una regola di forwarding globale
  • Un proxy HTTP di destinazione, un proxy HTTPS di destinazione o un proxy gRPC di destinazione
  • Una mappa URL

La maggior parte della configurazione viene eseguita nella mappa URL. Dopo aver creato la mappa di regole di routing iniziale, devi solo modificare la parte della mappa di URL della mappa di regole di routing. Nel diagramma seguente, le regole del percorso hanno azioni simili a quelle del diagramma successivo.

Routing basato sulle risorse host e del percorso.
Routing basato sulle risorse host e percorso (fai clic per ingrandire)

La regola più semplice è una regola predefinita, in cui devi specificare solo una regola host con caratteri jolly (*) e un matcher di percorso con un servizio predefinito. Dopo aver creato la regola predefinita, puoi aggiungere altre regole che specificano host e percorsi diversi. 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 a una regola host:

    1. Successivamente viene valutato il matcher percorso.
    2. Ogni matcher di percorso contiene una o più regole di percorso che vengono valutate in base al percorso della richiesta.
    3. Se viene trovata una corrispondenza, la richiesta viene instradata al servizio specificato nella regola del percorso.
    4. Se la regola host corrisponde, ma nessuna regola di percorso corrisponde, le richieste vengono instradate a un servizio predefinito contenuto in ogni matcher di percorso.

  • Se la richiesta non corrisponde a nessuna delle regole host specificate, viene instradata al servizio specificato nella regola predefinita.

Per saperne di più sui campi delle risorse della mappa URL e sul loro funzionamento, consulta la pagina relativa all'API REST urlMaps.

Routing e azioni avanzate

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

Routing avanzato.
Routing avanzato (fai clic per ingrandire)

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

  1. Come nel caso del routing semplice, l'host della richiesta viene confrontato con le regole host che configuri nella mappa URL. Se l'host di una richiesta corrisponde a una regola dell'host, viene valutato il matcher percorso della regola host.
  2. Il matcher di percorso contiene una o più regole di route valutate in base alla richiesta. Queste regole di route vengono valutate in ordine di priorità mediante la corrispondenza degli attributi della richiesta (host, percorso, intestazione e parametri di query) in base a condizioni di corrispondenza specifiche, ad esempio la corrispondenza del prefisso.
  3. Dopo aver selezionato una regola di route, puoi applicare azioni. L'azione predefinita è instradare la richiesta a un singolo servizio di destinazione, ma puoi configurare anche altre azioni.

Routing avanzato

Il routing avanzato è simile al routing semplice descritto in precedenza, ma consente di specificare la priorità delle regole e condizioni di corrispondenza aggiuntive.

Con il routing avanzato, devi specificare una priorità unica per ogni regola. Questa priorità determina l'ordine in cui vengono valutate le regole di route. I valori con priorità più bassa hanno la precedenza sui valori con priorità più alta. Quando una richiesta corrisponde a una regola, quest'ultima viene applicata e le altre vengono ignorate.

Il routing avanzato supporta anche condizioni di corrispondenza aggiuntive. Ad esempio, puoi specificare che una regola corrisponde 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ò avere una corrispondenza in base alla valutazione del nome dell'intestazione rispetto a un'espressione regolare o ad altri criteri, come il controllo della presenza di un'intestazione.

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

Combinando i parametri di host, percorso, intestazione e query con priorità e condizioni di corrispondenza, puoi creare regole altamente 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 a cui l'applicazione chiama.

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 porzione 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 saranno simili a /Example/Download.
Altre intestazioni gRPC (metadati) gRPC supporta l'invio di metadati tra il client gRPC e il server gRPC per fornire ulteriori informazioni su una chiamata RPC. Questi metadati sono sotto forma di coppie chiave-valore trasportate come intestazioni nella richiesta HTTP/2.

Azioni

Cloud Service Mesh consente di specificare le azioni eseguite dai proxy Envoy o dalle applicazioni gRPC senza proxy quando gestiscono una richiesta. Le seguenti azioni possono essere configurate utilizzando Cloud Service Mesh.

Azione Nome campo API Descrizione
Reindirizzamenti urlRedirect Restituisce un codice di risposta 3xx configurabile. Inoltre, imposta l'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 o entrambe le cose prima di inviare una richiesta al servizio di backend selezionato.
Trasformazioni intestazione headerAction Aggiunge o rimuove le intestazioni della richiesta prima di inviare una richiesta al servizio di backend. Consente anche di aggiungere o rimuovere le intestazioni delle risposte 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 di mirroring configurato attivando e cancellando. 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 utilizzarlo anche 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 in base alla ponderazione weightedBackendServices

Consente di distribuire il traffico di una regola corrispondente a più servizi di backend, in modo proporzionale a una ponderazione definita dall'utente assegnata al singolo servizio di backend.

Questa funzionalità è utile per configurare deployment a fasi o test A/B. Ad esempio, l'azione di route potrebbe essere configurata in modo che il 99% del traffico venga inviato a un servizio che esegue una versione stabile di un'applicazione e che l'1% del traffico venga inviato a un servizio separato che esegue una versione più recente dell'applicazione.
Nuovi tentativi retryPolicy Configura le condizioni in base alle quali il bilanciatore del carico tenta di nuovo le richieste non riuscite, quanto tempo attende il bilanciatore del carico prima di riprovare e 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 nuovi tentativi.
Fault injection faultInjectionPolicy Introduce gli errori durante la gestione delle richieste per simulare gli errori, tra cui alta latenza, sovraccarico del servizio, errori dei servizi e partizionamento della rete. Questa funzionalità è utile per testare la resilienza di un servizio rispetto agli 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 REST urlMaps.

In ogni regola di route, puoi specificare una delle seguenti azioni di route (indicate come Azioni principali nella console Google Cloud):

  • Instrada il traffico a un singolo servizio (service)
  • Suddividi traffico tra più servizi (weightedBackendServices)
  • URL di reindirizzamento (urlRedirect)

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

  • Manipolare le intestazioni di richiesta/risposta (headerAction)
  • 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 di route specifiche, il proxy Envoy o l'applicazione gRPC senza proxy possono applicare azioni diverse a seconda della richiesta che gestisce.

Distribuzione del 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 backend o endpoint deve ricevere la richiesta.

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

Nel diagramma precedente, la regola è stata semplificata. La regola è in genere una regola host, un matcher di percorso e una o più regole di percorso o route. Il servizio di destinazione è il servizio(backend). I backend 1, ... e il 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 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 altri backend del servizio di destinazione. In alcuni casi, tuttavia, potresti volere 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.

Criterio Nome campo API Descrizione
Modalità di bilanciamento del carico balancingMode Controlla in che modo viene selezionato un gruppo di endpoint di rete (NEG) o un gruppo di istanze gestite (MIG) dopo che è stato selezionato un servizio di destinazione. Puoi configurare la modalità di bilanciamento per distribuire il carico in base alle connessioni simultanee e alla 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 le prestazioni, puoi scegliere tra vari algoritmi, ad esempio Round Robin o Mind Request.
Affinità sessione sessionAffinity

Fornisce un tentativo con il criterio del "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: indirizzo IP client, basato su cookie HTTP, basato su intestazioni HTTP e affinità cookie generato (che Cloud Service Mesh genera automaticamente).
Hash coerente consistentHash Fornisce un'affinità sessione soft basata su intestazioni HTTP, cookie o altre proprietà.
Interruttori di sicurezza circuitBreakers Imposta limiti massimi per il volume di connessioni e richieste per connessione a un servizio di backend.
Rilevamento outlier outlierDetection Specifica i criteri per (1) rimuovere i backend o gli endpoint in stato non integro dai gruppi di istanze gestite o dai NEG e (2) aggiungere di nuovo un backend o un endpoint quando viene considerato sufficientemente integro da ricevere nuovamente il traffico. Il controllo di integrità associato al servizio determina se un backend o un endpoint sono considerati integri.

Per saperne di più sulle diverse opzioni di distribuzione del traffico e sul loro funzionamento, consulta la pagina API REST backendServices.

Esempi di casi d'uso

La gestione avanzata del traffico è applicabile a molti casi d'uso. Questa sezione fornisce alcuni esempi generali.

Puoi trovare altri esempi, incluso il codice campione, nelle guide Configurazione della gestione avanzata del traffico e Configurazione di servizi gRPC senza proxy con la gestione avanzata del traffico.

Routing del traffico granulare per la personalizzazione

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

Routing basato sull'intestazione dello user agent impostata su Android.
Routing basato sull'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. Anche dopo aver superato i test in un ambiente di test, potrebbe essere utile non indirizzare subito tutti gli utenti alla nuova versione.

Cloud Service Mesh consente di definire le suddivisioni del traffico basate sulle ponderazioni per distribuire il traffico tra più servizi. Ad esempio, puoi inviare l'1% del traffico alla nuova versione del tuo servizio, monitorare che tutto funzioni e quindi aumentare gradualmente la proporzione di traffico verso il nuovo servizio.

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

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 delle richieste vengano inviate a un altro servizio.

Mirroring del traffico di Cloud Service Mesh.
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 è possibile migliorare le prestazioni e la disponibilità ottimizzando il modo in cui il traffico viene distribuito 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 un servizio di backend di destinazione (servizio di produzione) sia i relativi backend (macchina virtuale 1, macchina virtuale 2, macchina virtuale 3). Con la gestione avanzata del traffico, puoi configurare le modalità di selezione di un servizio di backend di destinazione e distribuzione del traffico tra i backend del servizio di destinazione in questione.

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

Passaggi successivi