- Strumentazione del traffico. Instrada il traffico in modo intelligente in base a parametri HTTP(S) (ad esempio host, percorso, intestazioni e altri parametri di richiesta).
- Azioni relative al traffico. Eseguire azioni basate sulle richieste e sulle risposte (ad esempio, reindirizzamenti e trasformazioni delle intestazioni).
- Criteri relativi al traffico. Ottimizzare il comportamento del bilanciamento del carico (ad esempio, algoritmi avanzati di bilanciamento del carico).
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 è adatta a molti casi d'uso. Questa sezione fornisce alcuni esempi generali.
Indirizzamento del traffico: routing basato su intestazioni
L'indirizzamento del traffico consente di indirizzare il traffico alle istanze di servizio in base a parametri HTTP come le intestazioni delle richieste. Ad esempio, se il dispositivo di un utente è
un dispositivo mobile con user-agent:Mobile nell'intestazione della richiesta, il reindirizzamento del traffico
può inviare questo traffico alle istanze di servizio designate per la gestione del traffico
mobile e il traffico che non ha user-agent:Mobile alle istanze designate
per la gestione del traffico proveniente da altri dispositivi.
Azioni di traffico: suddivisione del traffico in base al peso
Il deployment di una nuova versione di un servizio di produzione esistente generalmente comporta dei rischi. Anche se i test superano la gestione temporanea, probabilmente non vorrai sottoporre immediatamente il 100% degli utenti alla nuova versione. Con la gestione del traffico, puoi definire suddivisioni del traffico su base percentuale tra più servizi di backend.
Ad esempio, puoi inviare il 95% del traffico alla versione precedente e il 5% alla nuova versione del servizio. Dopo aver verificato che la nuova versione di produzione funziona come previsto, puoi spostare 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: richiesta di mirroring
La tua organizzazione potrebbe avere requisiti di conformità specifici che impongono che tutto il traffico venga sottoposto a mirroring a un servizio aggiuntivo in grado, ad esempio, di registrare i dettagli della richiesta in un database per la riproduzione in un secondo momento.
Estensibilità con le estensioni di servizio
I callout delle estensioni di servizio consentono di inserire una logica personalizzata nel percorso dei dati del bilanciamento del carico. Queste estensioni consentono di indicare ai bilanciatori del carico delle applicazioni supportati di effettuare chiamate gRPC ad applicazioni o servizi gestiti dall'utente durante l'elaborazione dei dati.
Per saperne di più, consulta la panoramica delle estensioni di servizio.
Componenti della gestione del traffico
A livello generale, i bilanciatori del carico forniscono la gestione del traffico sfruttando le mappe URL a livello di regione e le risorse dei servizi di backend regionali.Per gli Application Load Balancer interni tra regioni, la gestione del traffico utilizza le risorse delle mappe URL globali e dei servizi di backend globali.
Puoi impostare l'indirizzamento del traffico e le azioni relative al traffico utilizzando le mappe URL. Le risorse Google Cloud associate alle mappe URL includono quanto segue:
- Regola di route
- Corrispondenza regola
- Azione della regola
Puoi configurare i criteri relativi al traffico utilizzando i servizi di backend. Le risorse Google Cloud associate ai servizi di backend includono quanto segue:
- Interruttori di sicurezza
- Criterio del bilanciatore del carico per località
- Impostazioni del bilanciatore del carico hash coerenti
- Rilevamento outlier
Il seguente diagramma mostra le risorse utilizzate per implementare ciascuna funzionalità.
Routing delle richieste ai backend
Negli Application Load Balancer 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 di Compute Engine in un gruppo di istanze gestite o container in base a 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 a livello di regione.
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à sono reciprocamente esclusive. Ogni mappa URL può contenere solo una modalità o l'altra.
Regola semplice per host e percorso
In una semplice regola host e percorso, le mappe URL funzionano come descritto nella panoramica della mappa URL.
Il seguente diagramma mostra il flusso logico di una regola host e percorso semplice.
Una richiesta viene inizialmente valutata utilizzando le regole dell'host. Un host è il dominio
specificato dalla richiesta. Se la richiesta host corrisponde a una delle voci nel campo hosts, viene utilizzato il matcher percorso associato.
Viene quindi valutato il matcher del percorso. Le regole per i percorsi vengono valutate in base al percorso più lungo e possono essere specificate in qualsiasi ordine. Dopo aver trovato la corrispondenza più specifica, la richiesta viene instradata al servizio di backend corrispondente. Se la richiesta non corrisponde, viene utilizzato il servizio di backend predefinito.
Una tipica regola host e percorso semplice potrebbe avere il seguente aspetto, in cui il traffico video va a video-backend-service e tutto il resto del traffico va 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 semplici regole relative a host e percorso. Queste opzioni consentono modelli di gestione del traffico più avanzati e modificano anche la semantica. Ad esempio, le regole di route hanno un valore di priorità associato e vengono interpretate in ordine di priorità (anziché utilizzare la semantica del percorso più lungo corrispondente a prima).
Come nel precedente esempio semplice di regole relative a host e percorso, puoi configurare la gestione avanzata del traffico utilizzando una mappa URL. Ad esempio, la seguente mappa URL configura il routing, dove il 95% del traffico viene instradato a un servizio di backend e il 5% del traffico viene instradato 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 al valore hostRules definito nella mappa URL. Ogni regola host è composta da un elenco di uno o più host e da un matcher percorso singolo (pathMatcher). Se non viene definito alcun valore hostRules, la richiesta viene instradata a defaultService.
hostRules[] e defaultService nella
documentazione relativa all'API per le mappe URL a livello di regione.
Corrispondenze percorso
Quando una richiesta corrisponde a una regola host, il bilanciatore del carico valuta il matcher percorso corrispondente all'host.
Un matcher percorso è costituito da:
- Una o più regole di percorso (
pathRules) o regole di route (routeRules). - Un servizio predefinito (
defaultService), che è il servizio di backend predefinito utilizzato quando non esistono altri servizi di backend corrispondenti.
pathMatchers[], pathMatchers[].pathRules[] e
pathMatchers[].routeRules[] nella documentazione relativa all'API
delle mappe URL a livello di regione.
Regole percorso
Le regole percorso (pathRules) specificano uno o più percorsi dell'URL, come / o /video.
Le regole percorso sono generalmente destinate al tipo di routing semplice basato su host e su percorsi descritto in precedenza.
pathRules[] nella documentazione relativa all'API
delle mappe URL a livello di regione.
Regole di route
Una regola di route (routeRules) abbina le informazioni in una richiesta in arrivo e prende una decisione di routing in base alla corrispondenza.
Le regole di route possono contenere una serie di regole di corrispondenza diverse (matchRules) e una serie di azioni di route diverse (routeAction).
Una regola di corrispondenza valuta la richiesta in entrata in base al percorso, alle intestazioni e parametri di ricerca della richiesta HTTP(S). Le regole di corrispondenza supportano vari tipi di corrispondenze (ad esempio corrispondenza con prefisso) e modificatori (ad esempio, insensibilità alle maiuscole). Questo ti permette, ad esempio, di inviare richieste HTTP(S) a un insieme di backend in base alla presenza di un'intestazione HTTP personalizzata.
Nota: le opzioni di corrispondenza e la semantica variano a seconda della parte della richiesta a cui corrisponde. Per ulteriori informazioni, consultamatchRules[] nella documentazione relativa all'API
delle mappe URL a livello di regione.
Se sono presenti più regole di route, il bilanciatore del carico le esegue in ordine di priorità (in base al campo priority), in modo da poter specificare una logica personalizzata per la corrispondenza, il routing e altre azioni.
All'interno di una determinata regola di route, quando viene effettuata la prima corrispondenza, il bilanciatore del carico smette di valutare le regole di corrispondenza ed eventuali regole di corrispondenza rimanenti vengono ignorate.
Google Cloud esegue le seguenti azioni:
- Cerca la prima regola di corrispondenza che corrisponde alla richiesta.
- Non esamina più le altre regole di corrispondenza.
- Applica le azioni nelle azioni di route corrispondenti.
Le regole di route hanno diversi componenti, come descritto nella tabella seguente.
Componente regola di route (API field name) |
Descrizione |
|---|---|
Priorità (priority) |
Un numero compreso tra 0 e 2.147.483.647 (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 all'aumentare del suo numero, al punto che una regola con priorità 4 viene valutata prima di una regola con priorità 25. Viene applicata la prima regola che corrisponde alla richiesta.
I numeri di priorità possono presentare lacune. 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 in caso di corrispondenza a questa regola. |
Regole di corrispondenza (matchRules) |
Una o più regole valutate in base alla richiesta. Questi
matchRules possono corrispondere a tutti o a un sottoinsieme degli attributi HTTP della
richiesta, come percorso, intestazioni HTTP e parametri
di query (GET).All'interno di un matchRule, devono essere soddisfatti tutti i criteri di corrispondenza affinché il valore routeActions di routeRule abbia effetto. Se un routeRule ha più
matchRules, i routeActions di
routeRule hanno effetto quando una richiesta corrisponde a uno qualsiasi dei
matchRules di routeRule.
|
Azione route (routeAction) |
Consente di specificare quali azioni intraprendere quando vengono soddisfatti i criteri della regola di corrispondenza. Queste azioni includono la suddivisione del traffico, le riscritture degli URL, i tentativi e il mirroring, l'inserimento di errori e i criteri CORS. |
Azione di reindirizzamento (urlRedirect) |
Puoi configurare un'azione in modo che risponda con un reindirizzamento HTTP quando vengono soddisfatti i criteri della regola di corrispondenza. Questo campo non può essere utilizzato insieme a un'azione di route. |
Azione intestazione (headerAction) |
Puoi configurare le regole di trasformazione dell'intestazione di richiesta e
risposta quando vengono soddisfatti i criteri all'interno di
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 e eseguono
le azioni specificate nella regola di route. Il seguente elenco fornisce alcuni esempi di attributi di richiesta 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 comando curl di esempio, dove10.1.2.9è l'indirizzo IP con bilanciamento del 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 basata su parametri di ricerca (variabili GET).
pathMatchers[].routeRules[].matchRules[] nella documentazione relativa all'API
delle mappe URL a livello di regione.
Azioni percorso
Le azioni di route sono azioni specifiche da intraprendere quando una regola di route corrisponde agli attributi di una richiesta.
Azione route (API field name) |
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 specificati nell'azione di reindirizzamento.
|
Riscritture di URL (urlRewrite) |
Riscrive la parte del nome host dell'URL, la parte del percorso dell'URL o entrambi prima di inviare una richiesta al servizio di backend selezionato. |
Trasformazioni 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 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 in base
fire and delete. Il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta di mirroring. |
Suddivisione del traffico ponderata (weightedBackendServices) |
Consente la distribuzione del traffico per una regola corrispondente a più servizi di backend, in proporzione alla ponderazione definita dall'utente assegnata al singolo servizio di backend. Questa funzionalità è utile per configurare deployment 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 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 a eseguire le richieste non riuscite, il tempo di attesa del 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 elaborata completamente 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 errori, tra cui alta latenza, sovraccarico dei servizi, errori dei servizi e partizionamento della rete. Questa funzionalità è utile per testare la resilienza di un servizio a errori simulati. |
Posticipa l'inserimento (faultInjectionPolicy) |
Introduce ritardi per una parte definita dall'utente delle richieste prima di inviare la richiesta al servizio di backend selezionato. |
Interrompi l'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 route:
- 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 qualsiasi delle azioni di route menzionate in precedenza con una o più delle seguenti azioni di route:
- Esegui il mirroring del traffico (
requestMirrorPolicy). - Riscrivi l'host e il percorso dell'URL (
urlRewrite). - Riprova le richieste non riuscite (
retryPolicy). - Imposta timeout (
timeout). - Introduci errori in una percentuale di traffico (
faultInjectionPolicy). - Aggiungi criterio CORS (
corsPolicy). - Manipolare le intestazioni della richiesta o della risposta (
headerAction).
urlRedirecturlRewriteheaderActionrequestMirrorPolicyweightedBackendServicesretryPolicytimeoutfaultInjectionPolicycorsPolicy
Reindirizzamenti da HTTP a HTTPS
Se devi reindirizzare il traffico HTTP a HTTPS, puoi creare due regole di forwarding con un indirizzo IP comune.
Affinché due regole di forwarding condividano lo stesso indirizzo IP interno, 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 a HTTPS per i bilanciatori del carico delle applicazioni interni.
Criteri di traffico
Utilizzando le risorse del servizio di backend, puoi configurare criteri di traffico per ottimizzare il bilanciamento del carico all'interno di un gruppo di istanze o di un gruppo di endpoint di rete (NEG). Questi criteri hanno effetto solo dopo che un servizio di backend è stato selezionato utilizzando la mappa URL (come descritto in precedenza).
I criteri di traffico consentono di:
- Controlla l'algoritmo di bilanciamento del carico tra istanze all'interno del servizio di backend.
- Controlla il volume delle connessioni a un servizio upstream.
- Controlla l'eliminazione di host in stato non integro da un servizio di backend.
Criterio di traffico (API field name) |
Descrizione |
|---|---|
Criterio di località del bilanciamento del carico (LocalityLbPolicy) |
Per un servizio di backend, la distribuzione del traffico si basa su una modalità di bilanciamento del carico e un criterio di località del bilanciamento del carico. La modalità di bilanciamento determina la ponderazione/frazione del traffico che deve essere inviata a ciascun backend (gruppo di istanze o NEG Per le modalità di bilanciamento supportate, consulta Modalità di bilanciamento. Per gli algoritmi dei criteri di bilanciamento del carico supportati, consulta |
Affinità sessione (consistentHash) |
Include affinità basata su cookie HTTP, affinità basata su intestazioni HTTP, affinità indirizzo IP client e affinità cookie generato. L'affinità sessione offre il tentativo del miglior tentativo di inviare richieste da un determinato client allo stesso backend purché il back sia integro e abbia capacità. Per maggiori informazioni sull'affinità sessione, consulta
|
Rilevamento outlier (outlierDetection) |
Un insieme di criteri che specifica i criteri per l'eliminazione di VM o endpoint del backend in stato non integro dai NEG, insieme a criteri che definiscono quando un backend o un endpoint viene considerato integro per ricevere di nuovo il traffico. Per maggiori informazioni sul rilevamento di outlier, consulta
|
Interruzione di circuito (circuitBreakers) |
Imposta limiti superiori per il volume di connessioni e richieste per connessione a un servizio di backend. Per maggiori informazioni sull'interruzione di circuito, consulta |
Passaggi successivi
- Per configurare la gestione del traffico per gli Application Load Balancer interni, consulta Configurare la gestione del traffico per gli Application Load Balancer interni.