- Indirizzamento del traffico. Instrada il traffico in modo intelligente in base ai parametri HTTP(S) (ad esempio host, percorso, intestazioni e altri parametri di richiesta).
- Azioni relative al traffico. Esegui azioni basate su richieste e risposte (ad esempio reindirizzamenti e trasformazioni di intestazioni).
- Norme sul traffico. Ottimizzare il comportamento del bilanciamento del carico (ad esempio, algoritmi di bilanciamento del carico avanzati).
Puoi configurare queste funzionalità utilizzando le mappe URL e i servizi di backend. Per ulteriori informazioni, consulta i seguenti argomenti:
Esempi di casi d'uso
La gestione del traffico risponde a molti casi d'uso. Questa sezione fornisce alcuni esempi di alto livello.
Indirizzamento del traffico: routing basato su intestazioni
L'indirizzamento del traffico ti consente di indirizzare il traffico alle istanze di servizio in base ai parametri HTTP, come le intestazioni di richiesta. Ad esempio, se il dispositivo di un utente è un dispositivo mobile con user-agent:Mobile nell'intestazione della richiesta, la gestione del traffico può inviare questo traffico alle istanze di servizio designate per gestire il traffico mobile e inviare il traffico che non ha user-agent:Mobile alle istanze designate per gestire il traffico da altri dispositivi.
Azioni sul traffico: suddivisione del traffico in base al peso
Il deployment di una nuova versione di un servizio di produzione esistente comporta generalmente qualche rischio. Anche se i test superano la fase di staging, probabilmente non vuoi sottoporre immediatamente il 100% dei tuoi utenti alla nuova versione. Con la gestione del traffico, puoi definire suddivisioni del traffico in base alla percentuale su più servizi di backend.
Ad esempio, puoi inviare il 95% del traffico alla versione precedente del servizio e il 5% alla nuova versione. Dopo aver verificato che la nuova versione di produzione funziona come previsto, puoi modificare gradualmente le percentuali fino a quando il 100% del traffico non raggiunge la nuova versione del servizio. La suddivisione del traffico viene in genere utilizzata per il deployment di nuove versioni, i test A/B, la migrazione dei servizi e processi simili.
Criteri di traffico: mirroring delle richieste
La tua organizzazione potrebbe avere requisiti di conformità specifici che richiedono che tutto il traffico venga sottoposto a mirroring in un servizio aggiuntivo che possa, ad esempio, registrare i dettagli della richiesta in un database per la riproduzione successiva.
Estensibilità con Service Extensions
L'integrazione con Service Extensions consente di inserire logica personalizzata nel percorso dati del bilanciamento del carico dei bilanciatori del carico delle applicazioni supportati.
Per ulteriori informazioni, consulta la panoramica delle Estensioni di servizio.
Componenti di gestione del traffico
A un livello generale, i bilanciatori del carico forniscono la gestione del traffico sfruttando le risorse di mappe URL regionali e di servizi di backend regionali.Per i bilanciatori del carico delle applicazioni interni tra regioni, la gestione del traffico utilizza le risorse mappe URL globali e servizi di backend globali.
Puoi configurare lo smistamento del traffico e le azioni di traffico utilizzando le mappe URL. Le risorse Google Cloud associate alle mappe di URL includono quanto segue:
- Regola di route
- Corrispondenza regola
- Azione della regola
Puoi configurare i criteri di traffico utilizzando i servizi di backend. Le risorse Google Cloud associate ai servizi di backend include:
- Interruttori di sicurezza
- Criterio del bilanciatore del carico per le località
- Impostazioni del bilanciatore del carico con hashing coerente
- Rilevamento outlier
Il seguente diagramma mostra le risorse utilizzate per implementare ogni funzionalità.
Routing delle richieste ai backend
Nei bilanciatori del carico delle applicazioni interni regionali, il backend per il traffico viene determinato utilizzando un approccio in due fasi:- Il bilanciatore del carico seleziona un servizio di backend con backend. I backend possono essere istanze di macchine virtuali (VM) Compute Engine in un gruppo di istanze non gestite, VM Compute Engine in un gruppo di istanze gestite (MIG) o container tramite un nodo Google Kubernetes Engine (GKE) in un gruppo di endpoint di rete (NEG). Il bilanciatore del carico sceglie un servizio di backend in base alle regole definite in una mappa URL a livello di regione.
- Il servizio di backend seleziona un'istanza di backend in base ai criteri definiti in un servizio di backend regionale.
Quando configuri il routing, puoi scegliere tra le seguenti modalità:
- Regola semplice per host e percorso
- Regola avanzata per host, percorso e route
Le due modalità si escludono a vicenda. Ogni sitemap può contenere una sola modalità o l'altra.
Regola semplice per host e percorso
In una regola host e percorso semplice, le mappe URL funzionano come descritto nella panoramica delle mappe URL.
Il seguente diagramma mostra il flusso logico di una regola semplice per host e percorso.
Una richiesta viene inizialmente valutata utilizzando le regole host. Un host è il dominio
specificato dalla richiesta. Se la richiesta host corrisponde a una delle voci nel
campo hosts, viene utilizzato il matcher del percorso associato.
Successivamente, viene valutato il corrispettivo del percorso. Le regole percorso vengono valutate in base al primo percorso più lungo che corrisponde e puoi specificarle in qualsiasi ordine. Una volta trovata la corrispondenza più specifica, la richiesta viene inoltrata al servizio di backend corrispondente. Se la richiesta non corrisponde, viene utilizzato il servizio di backend predefinito.
Una regola semplice per host e percorso potrebbe avere il seguente aspetto, dove il traffico video viene indirizzato a video-backend-service e tutto il resto a web-backend-service.
gcloud compute url-maps describe lb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
- '*'
pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
name: pathmap
pathRules:
- paths:
- /video
- /video/*
service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1
Regola avanzata per host, percorso e route
Le regole avanzate per host, percorso e route offrono opzioni di configurazione aggiuntive rispetto alle regole semplici per host e percorso. Queste opzioni consentono di attivare modelli di gestione del traffico più avanzati e di modificare anche parte della semantica. Ad esempio, le regole di route hanno un valore di priorità associato e vengono interpretate in ordine di priorità (anziché utilizzando la semantica della corrispondenza del percorso più lungo in primo luogo).
Come nell'esempio precedente di regola semplice per host e percorso, puoi configurare la gestione avanzata del traffico utilizzando una mappa URL. Ad esempio, la mappa URL riportata di seguito configura il routing in cui il 95% del traffico viene indirizzato a un servizio di backend e il 5% del traffico a un altro servizio di backend.
gcloud compute url-maps describe lb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
name: matcher1
routeRules:
- matchRules:
- prefixMatch: ''
routeAction:
weightedBackendServices:
- backendService: regions/us-west1/backendServices/service-a
weight: 95
- backendService: regions/us-west1/backendServices/service-b
weight: 5
region: regions/us-west1
Regole host
Quando una richiesta raggiunge il bilanciatore del carico, il campo host della richiesta viene valutato in base a hostRules definito nella mappa URL. Ogni regola host è costituita da un elenco di uno o più host e da un singolo corrispondenze dei percorsi (pathMatcher). Se non sono definiti hostRules, la richiesta viene indirizzata a defaultService.
hostRules[] e defaultService nella
documentazione dell'API mappa degli URL regionali.
Matcher percorso
Dopo che una richiesta corrisponde a una regola host, il bilanciatore del carico valuta il corrispondente matcher dei percorsi per l'host.
Un'associazione di percorsi è costituita da:
- Una o più regole percorso (
pathRules) o regole di route (routeRules). - Un servizio predefinito (
defaultService), ovvero il servizio di backend predefinito utilizzato quando non sono presenti corrispondenze con altri servizi di backend.
pathMatchers[], pathMatchers[].pathRules[] e
pathMatchers[].routeRules[] nella documentazione dell'API mappa URL a livello di regione.
Regole percorso
Le regole dei percorsi (pathRules) specificano uno o più percorsi dell'URL, ad esempio / o /video.
Le regole percorso sono in genere destinate al tipo di routing semplice basato su host e percorso descritto in precedenza.
pathRules[] nella documentazione dell'API mappa degli URL regionali.
Regole di route
Una regola di routing (routeRules) associa le informazioni di una richiesta in entrata e prende una decisione di routing in base alla corrispondenza.
Le regole di routing possono contenere una serie di regole di corrispondenza (matchRules) e di azioni di routing (routeAction) diverse.
Una regola di corrispondenza valuta la richiesta in arrivo in base al percorso, alle intestazioni e parametri di ricerca della richiesta HTTP(S). Le regole di corrispondenza supportano vari tipi di corrispondenze (ad es. corrispondenza con prefisso) e modificatori (ad es. la sensibilità alle maiuscole). In questo modo, ad esempio, puoi inviare richieste HTTP(S) a un insieme di backend in base alla presenza di un'intestazione HTTP definita in modo personalizzato.
Nota: le opzioni e la semantica delle corrispondenze variano a seconda della parte della richiesta con cui effettui la corrispondenza. Per ulteriori informazioni, consultamatchRules[] nella documentazione dell'API mappa degli URL regionali.
Se hai più regole di route, il bilanciatore del carico le esegue in ordine di priorità (in base al campo priority), il che ti consente di specificare una logica personalizzata per la corrispondenza, il routing e altre azioni.
All'interno di una determinata regola di route, quando viene eseguita la prima corrispondenza, il bilanciatore del carico interrompe la valutazione delle regole di corrispondenza e le eventuali regole di corrispondenza rimanenti vengono ignorate.
Google Cloud esegue le seguenti azioni:
- Cerca la prima regola di corrispondenza che corrisponde alla richiesta.
- Interrompe la ricerca di altre regole di corrispondenza.
- Applica le azioni nelle azioni route corrispondenti.
Le regole di routing hanno diversi componenti, come descritto nella tabella seguente.
Componente regola percorso (API field name) |
Descrizione |
|---|---|
Priorità (priority) |
Un numero compreso tra 0 e 2147483647 (ovvero (2^31)-1) assegnato a una
regola di route all'interno di un determinato matcher percorso. La priorità determina l'ordine di valutazione delle regole di route. La priorità di una regola diminuisce con l'aumentare del numero, pertanto una regola con priorità 4 viene valutata prima di una regola con prioritaria25. Viene applicata la prima regola corrispondente alla richiesta.
I numeri di priorità possono avere spazi. Non puoi creare più di una regola con la stessa priorità. |
Descrizione (description) |
Una descrizione facoltativa di massimo 1024 caratteri. |
Servizio (service) |
L'URL completo o parziale della risorsa del servizio di backend a cui viene indirizzato il traffico se viene trovata una corrispondenza per questa regola. |
Regole di corrispondenza (matchRules) |
Una o più regole che vengono valutate in base alla richiesta. Questi
matchRules possono corrispondere a tutti o a un sottoinsieme degli attributi HTTP
della richiesta, ad esempio il percorso, le intestazioni HTTP e i parametri di query (GET).All'interno di un matchRule, tutti i criteri di corrispondenza devono essere soddisfatti affinché il routeActions del routeRule venga applicato. Se un routeRule ha più
matchRules, i routeActions del
routeRule vengono applicati quando una richiesta corrisponde a uno dei
matchRules del routeRule.
|
Azione route (routeAction) |
Ti consente di specificare quali azioni eseguire quando i criteri della regola di corrispondenza sono soddisfatti. Queste azioni includono la suddivisione del traffico, la riscrittura degli URL, il retry e il mirroring, l'iniezione di errori e i criteri CORS. |
Azione di reindirizzamento (urlRedirect) |
Puoi configurare un'azione per rispondere con un reindirizzamento HTTP quando i criteri della regola di corrispondenza sono soddisfatti. Questo campo non può essere utilizzato insieme a un'azione di percorso. |
Azione intestazione (headerAction) |
Puoi configurare le regole di trasformazione dell'intestazione della richiesta e della risposta quando vengono soddisfatti i criteri in matchRules.
|
routeRules[]routeRules[].priorityrouteRules[].descriptionrouteRules[].servicerouteRules[].matchRules[]routeRules[].routeActionrouteRules[].urlRedirectrouteRules[].headerAction
Regole delle corrispondenze
Le regole di corrispondenza (matchRules) corrispondono a uno o più attributi di una richiesta ed eseguono le azioni specificate nella regola di route. Il seguente elenco fornisce alcuni esempi di attributi delle richieste che possono essere abbinati utilizzando le regole di corrispondenza:
Host: un nome host è la parte del nome di dominio di un URL. Ad esempio, la parte del nome host dell'URL
http://example.net/video/hdèexample.net. Nella richiesta, il nome host proviene dall'intestazioneHost, come mostrato in questo esempio di comando curl, dove10.1.2.9è l'indirizzo IP bilanciato in base al carico:curl -v http://10.1.2.9/video/hd --header 'Host: example.com'I percorsi seguono il nome host, ad esempio
/images. La regola può specificare se deve corrispondere l'intero percorso o solo la parte iniziale.Altri parametri di richiesta HTTP, come le intestazioni HTTP, che consentono la corrispondenza dei cookie, nonché la corrispondenza in base ai parametri di ricerca (variabili GET).
pathMatchers[].routeRules[].matchRules[] nella documentazione dell'API mappa degli URL regionali.
Azioni di routing
Le azioni di routing sono azioni specifiche da eseguire quando una regola di routing corrisponde agli attributi di una richiesta.
Azione route (API field name) |
Descrizione |
|---|---|
Reindirizzamenti (urlRedirect) |
Restituisce un codice di risposta 3xx configurabile. Imposta inoltre l'intestazione di risposta Location
con l'URI appropriato, sostituendo l'host e il percorso come specificato nell'azione di reindirizzamento.
|
Riscrivi 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 dell'intestazione (headerAction) |
Aggiunge o rimuove le intestazioni delle richieste prima di inviare una richiesta al servizio di backend. Può anche aggiungere o rimuovere le intestazioni di risposta dopo aver ricevuto una risposta dal servizio di backend. |
Mirroring del traffico (requestMirrorPolicy) |
Oltre a inoltrare la richiesta al servizio di backend selezionato, invia una richiesta identica al servizio di backend mirror configurato su una base fire and forget. Il bilanciatore del carico non attende una risposta
dal backend a cui invia la richiesta sottoposta a mirroring. Tieni presenti le seguenti limitazioni quando utilizzi il mirroring del traffico:
|
Suddivisione del traffico ponderata (weightedBackendServices) |
Consente di distribuire il traffico per una regola con corrispondenza a più servizi di backend, proporzionalmente a un peso definito dall'utente assegnato al singolo servizio di backend. Questa funzionalità è utile per configurare implementazioni pianificate 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 viene 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 tentativi di ripetizione. |
Iniezione di errori (faultInjectionPolicy) |
Introduce errori durante l'elaborazione delle richieste per simulare errori, tra cui latenza elevata, sovraccarico del servizio, errori di servizio e partizione della rete. Questa funzionalità è utile per testare la resilienza di un servizio ai guasti simulati. |
Iniezione ritardata (faultInjectionPolicy) |
Introduce ritardi per una parte di richieste definita dall'utente prima di inviare la richiesta al servizio di backend selezionato. |
Interrompi inserimento (faultInjectionPolicy) |
Risponde direttamente a una frazione di richieste con codici di stato HTTP definiti dall'utente anziché inoltrarle al servizio di backend. |
Criteri di sicurezza (corsPolicy) |
I criteri di condivisione delle risorse tra origini (CORS) gestiscono le impostazioni per l'applicazione delle richieste CORS. |
Puoi specificare una delle seguenti azioni di percorso:
- Instrada il traffico a un singolo servizio (
service). - Suddividi il traffico tra più servizi (
weightedBackendServices weight:x, dove x deve essere compreso tra 0 e 1000). - URL di reindirizzamento (
urlRedirect).
Inoltre, puoi combinare una delle azioni di route menzionate in precedenza con una o più delle seguenti azioni di route:
- Esegui il mirroring del traffico (
requestMirrorPolicy). - Riscrivi host e percorso dell'URL (
urlRewrite). - Riprova le richieste non riuscite (
retryPolicy). - Imposta il timeout (
timeout). - Introduci errori in una percentuale del traffico (
faultInjectionPolicy). - Aggiungi il criterio CORS (
corsPolicy). - Manipola le intestazioni delle richieste o delle risposte (
headerAction).
urlRedirecturlRewriteheaderActionrequestMirrorPolicyweightedBackendServicesretryPolicytimeoutfaultInjectionPolicycorsPolicy
Reindirizzamenti da HTTP a HTTPS
Se devi reindirizzare il traffico HTTP a HTTPS, puoi creare due regole di inoltro con un indirizzo IP comune.
Affinché due regole di inoltro condividano un indirizzo IP interno comune, devi prenotare l'indirizzo IP e includere il flag--purpose=SHARED_LOADBALANCER_VIP:
gcloud compute addresses create NAME \
--region=us-west1 \
--subnet=backend-subnet \
--purpose=SHARED_LOADBALANCER_VIP
Per un esempio completo, consulta Configurare il reindirizzamento da HTTP ad HTTPS per i bilanciatori del carico delle applicazioni interni.
Criteri di traffico
Utilizzando le risorse di servizio di backend, puoi configurare i criteri di traffico per perfezionare il bilanciamento del carico all'interno di un gruppo di istanze o di un gruppo di endpoint di rete (NEG). Questi criteri vengono applicati solo dopo che è stato selezionato un servizio di backend utilizzando la mappa URL (come descritto in precedenza).
I criteri di traffico ti consentono di:
- Controlla l'algoritmo di bilanciamento del carico tra le istanze all'interno del servizio di backend.
- Controlla il volume di connessioni a un servizio a monte.
- Controlla l'eliminazione di host non integri da un servizio di backend.
Criterio di traffico (API field name) |
Descrizione |
|---|---|
Criterio di bilanciamento del carico per le località (LocalityLbPolicy) |
Per un servizio di backend, la distribuzione del traffico si basa su una modalità di bilanciamento del carico e su un criterio di bilanciamento del carico per le località. La modalità di bilanciamento determina il peso/la frazione di traffico che deve essere inviata a ciascun backend (gruppo di istanze o Per le modalità di bilanciamento supportate, consulta Modalità di bilanciamento. Per gli algoritmi dei criteri di bilanciamento del carico supportati, consulta
|
Affinità sessione (consistentHash) |
Sono incluse l'affinità basata sui cookie HTTP, l'affinità basata sulle intestazioni HTTP, l'affinità dell'indirizzo IP del client, l'affinità sessione basata sui cookie stateful e l'affinità cookie generato. L'affinità sessione 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à. Per ulteriori informazioni sull'affinità sessione, consulta
|
Rilevamento outlier (outlierDetection) |
Un insieme di criteri che specificano gli endpoint o le VM di backend non integri da estrarre nei NEG, insieme ai criteri che definiscono quando un backend o un endpoint è considerato sufficientemente integro per ricevere nuovamente il traffico. Per ulteriori informazioni sul rilevamento degli outlier, consulta
|
Interruttore di sicurezza (circuitBreakers) |
Imposta limiti superiori per il volume di connessioni e richieste per connessione a un servizio di backend. Per ulteriori informazioni sulla interruzione del circuito, consulta |
Passaggi successivi
- Per configurare la gestione del traffico per i bilanciatori del carico delle applicazioni interni, consulta Configurare la gestione del traffico per i bilanciatori del carico delle applicazioni interni.