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

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. Questo documento si applica solo alle API di bilanciamento del carico, non alle API di routing dei servizi. Se le tue 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 e 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 le copiano in un altro
  • Distribuzione ottimizzata del traffico tra i backend di un servizio per un migliore 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.

  • Quando utilizzi il proxy HTTP target per configurare i proxy Envoy in modo che inviino richieste HTTP, sono disponibili tutte le funzionalità descritte in questo documento.

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

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

Per maggiori dettagli, consulta la pagina Funzionalità.

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

A livello generale, svolgi le seguenti operazioni:

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

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

    2. Se vuoi, puoi eseguire altre azioni.

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

Configurazione dei filtri

Una delle responsabilità principali di Cloud Service Mesh è generare informazioni di configurazione dalla regola di inoltro, dal proxy di destinazione e dalla mappa URL, per poi inviarle ai client Cloud Service Mesh, ad esempio i proxy Envoy e le applicazioni gRPC. Cloud Service Mesh controlla il tuo mesh di servizi inviando ai suoi client informazioni di configurazione che indicano loro come comportarsi e come indirizzare 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 che i suoi clienti possano comprendere. Per impostazione predefinita, Cloud Service Mesh condivide questa configurazione con tutti i suoi clienti. In alcuni casi, potresti voler adattare quali client Cloud Service Mesh ricevono specifiche informazioni di configurazione, altre parole, filtrano la configurazione in base a client specifici.

Sebbene si tratti di una funzionalità avanzata, i seguenti esempi mostrano quando la configurazione dei filtri può essere utile:

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

Il filtro delle configurazioni si basa sul concetto di filtri dei metadati:

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

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

Routing del traffico e azioni

In Cloud Service Mesh, la mappa di regole di routing si riferisce alla combinazione delle risorse della regola di inoltro, del proxy di destinazione e della mappa URL. Tutte le funzionalità avanzate di gestione del traffico relative a routing e le azioni vengono configurate usando la mappa URL.

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

Gestione delle richieste

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

  1. La richiesta viene associata a una mappa delle regole di routing specifica come segue:

    • Se utilizzi Envoy:

      • L'indirizzo IP e la porta di destinazione della richiesta vengono confrontati Indirizzo IP e porta delle regole di forwarding in tutte le mappe di regole di routing. Vengono prese in considerazione solo le mappe di regole di routing con regole di inoltro che hanno schema di bilanciamento del carico INTERNAL_SELF_MANAGED.
      • La regola di forwarding che corrisponde alla richiesta fa riferimento a un HTTP di destinazione o gRPC, 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 la ricerca DNS per risolvere il nome host nell'URI del canale. Questo client risolve invece hostname[:port] nella destinazione URI inviando un oggetto LDS a Cloud Service Mesh.
      • Solo la porta di un forwarding viene confrontata con lo schema di bilanciamento del carico INTERNAL_SELF_MANAGED alla porta nell'URI di destinazione (ad esempio, xds:///example.hostname:8080). L'IP dell'indirizzo della regola di forwarding. Il valore predefinito La porta è 80 se non è specificata nessuna porta nell'URI di destinazione.
      • La regola di forwarding che corrisponde ai riferimenti alla richiesta un proxy gRPC di destinazione, che fa riferimento a una mappa URL. Questa mappa di URL contiene informazioni utilizzate per il routing e le azioni.
      • Se più regole di inoltro corrispondono alla richiesta, per il routing e le azioni viene utilizzata la mappa URL che contiene la regola host corrispondente a hostname[:port] nell'URI di destinazione.

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

  3. 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 percorso. L'host e il percorso della richiesta vengono valutati per determinare il servizio verso a cui indirizzare una 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 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, consiste di 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 URL della mappa di regole di routing. Nel diagramma seguente, le regole del percorso hanno azioni in modo simile alle azioni nel prossimo diagramma.

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

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 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 corrispondenza di percorso contiene una o più regole di percorso che vengono valutate rispetto al percorso della richiesta.
    3. Se viene trovata una corrispondenza, la richiesta viene indirizzata al servizio specificato la regola del percorso.
    4. Se la regola host corrisponde, ma nessuna regola di percorso corrisponde, le richieste vengono instradate a un predefinito contenuto in ogni matcher percorso.

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

Per ulteriori informazioni sui campi delle risorse della mappa URL e sul loro funzionamento, consulta la pagina dell'API REST urlMaps.

Routing e azioni avanzati

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

Routing avanzato.
Routing avanzato (fai clic per ingrandire)

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 nella mappa URL. Se l'host di una richiesta corrisponde a una regola host, viene valutato il matcher percorso della regola host.
  2. Il matcher di percorso contiene una o più regole di route valutate rispetto 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 routing, puoi applicare le azioni. Il valore predefinito è indirizzare la richiesta a un singolo servizio di destinazione, ma può configurare anche altre azioni.

Routing avanzato

Il routing avanzato è simile al routing semplice descritto in precedenza, tranne per il fatto che puoi specificare la priorità della regola e condizioni di corrispondenza aggiuntive.

Con il routing avanzato, devi specificare una priorità unica per ogni regola. Questo la priorità determina l'ordine in cui vengono valutate le regole di route, con valori valori di priorità che hanno la precedenza sui valori di priorità più alti. Una volta che una richiesta corrisponde a una regola, questa viene applicata e le altre regole 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 di quest'ultima 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 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 urlMaps.

Combinando i parametri host, percorso, intestazione e query con priorità e corrispondenze di traffico, puoi creare regole altamente espressive che si adattano i tuoi requisiti di gestione. 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 fa riferimento l'applicazione.

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 assomiglia a /SERVICE_NAME/METHOD_NAME.

Ad esempio, se chiami il metodo Download sul servizio gRPC Example, i contenuti dell'intestazione :path sono simili a /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 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 del campo dell'API Descrizione
Reindirizzamenti urlRedirect 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 Riscrivi 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 intestazioni headerAction Aggiunge o rimuove le intestazioni delle richieste prima di inviare una richiesta al 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 servizio di backend selezionato, invia una richiesta identica al servizio di backend mirror configurato su una base fire and forget. 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 anche utilizzarlo per eseguire il debug degli errori di produzione su una versione di debug del servizio di backend anziché sulla versione di produzione.
Suddivisione del traffico in base alla ponderazione weightedBackendServices

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 implementazioni graduali 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, mentre l'1% del traffico venga inviato a un servizio separato che esegue una versione più recente dell'applicazione.
Nuovi tentativi retryPolicy Consente di configurare le condizioni in base alle quali il bilanciatore del carico riprova le richieste non riuscite, il tempo di attesa prima del nuovo tentativo e il numero massimo di tentativi consentiti.
Timeout timeout Specifica il timeout per il percorso selezionato. 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 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 servizio ai guasti 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 su come funzionano, vedi urlMaps API REST.

In ogni regola di routing, puoi specificare una delle seguenti azioni di routing (chiamate 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 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/risposta (headerAction)
  • Mirroring del traffico (requestMirrorPolicy)
  • Riscrivi l'host dell'URL, il percorso o entrambi (urlRewrite)
  • Riprova le richieste non riuscite (retryPolicy)
  • Imposta timeout (timeout)
  • Introduci errori in una percentuale del traffico (faultInjectionPolicy)
  • Aggiungi criterio CORS (corsPolicy)

Poiché le azioni sono associate a regole di route specifiche, il proxy Envoy o un'applicazione gRPC senza proxy può applicare azioni diverse in base alla 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 deve ricevere la richiesta dal backend o dall'endpoint.

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, uno strumento di abbinamento del percorso e una o più regole di percorso o route. La di destinazione è il servizio(backend). Backend 1, … e Backend n ricevono e gestiscono 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 un backend specifico, utilizza l'algoritmo di bilanciamento del carico round robin per bilanciare le 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 del campo dell'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 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 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 al volume di connessioni e richieste per connessione 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 le backendServices API REST.

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, nella Configurare la gestione avanzata del traffico e Configurazione di servizi gRPC proxyless con gestione avanzata del traffico guide.

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 utenti Android. Nel seguente diagramma, Cloud Service Mesh configura il tuo service mesh in modo da inviare richieste con l'intestazione user-agent:Android al servizio Android anziché al servizio generico.

Routing in base all'intestazione user-agent impostata su Android.
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. Anche se i test superano un ambiente di test, potrebbe non essere consigliabile inoltrare tutti gli utenti alla nuova versione immediatamente.

Cloud Service Mesh ti consente di definire suddivisioni del traffico in base al peso per distribuire 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.

Suddivisione del traffico in base al peso in Cloud Service Mesh.
Suddivisione del traffico in base al peso in 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 dei dati 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 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 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 per soddisfare le tue esigenze.

Il seguente diagramma, a differenza dei precedenti, mostra sia un servizio di backend di destinazione (Servizio di produzione) sia 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.

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

Passaggi successivi