Questo documento mostra esempi di utilizzo della gestione del traffico per alcuni casi d'uso specifici. Sono possibili molti altri casi d'uso.
Il documento contiene esempi per i bilanciatori del carico delle applicazioni esterni globali.
I bilanciatori del carico delle applicazioni esterni globali utilizzano lo schema di bilanciamento del carico EXTERNAL_MANAGED e i componenti di bilanciamento del carico globale, come la regola di forwarding, la mappa URL e il servizio di backend.
Per informazioni sulla gestione del traffico con un bilanciatore del carico delle applicazioni classico, consulta la Panoramica della gestione del traffico per un bilanciatore del carico delle applicazioni classico.
Per informazioni sulla gestione del traffico con i bilanciatori del carico delle applicazioni esterni regionali, consulta la Panoramica della gestione del traffico per i bilanciatori del carico delle applicazioni esterni regionali.
Oltre alle funzionalità di routing avanzate descritte in questa pagina, i bilanciatori del carico delle applicazioni supportati si integrano con le estensioni di servizio per consentirti di inserire logica personalizzata nel percorso dati del bilanciamento del carico.
Prima di iniziare
Assicurati di comprendere come funziona la gestione del traffico. Per ulteriori informazioni, consulta la panoramica della gestione del traffico per i bilanciatori del carico delle applicazioni esterni globali.
Configurare e testare la gestione del traffico
Nell'ambiente di configurazione scelto, puoi configurare la gestione del traffico utilizzando le configurazioni YAML. Una mappa URL e un servizio di backend hanno ciascuno il proprio file YAML. A seconda della funzionalità scelta, devi scrivere un file YAML mappa URL, un file YAML del servizio di backend o entrambi.
Per assistenza nella scrittura di questi file YAML, puoi utilizzare gli esempi in questa pagina e la documentazione dell'API Cloud Load Balancing.
La console Google Cloud non è supportata.
La documentazione dell'API mappa URL globale e dell' API servizio di backend globale fornisce un elenco completo dei campi, inclusa la semantica relativa a relazioni, restrizioni e cardinalità.
Puoi aggiungere test di configurazione a una mappa URL per assicurarti che indirizzi le richieste come previsto. Puoi fare esperimenti con diverse regole della mappa URL ed eseguire quanti test sono necessari per assicurarti che la mappa indirizzi il traffico al servizio o al bucket di backend appropriato. Per maggiori dettagli, vedi Aggiungere test a una mappa di URL. Se vuoi testare le nuove modifiche a una mappa di URL senza eseguire effettivamente il deployment della mappa, consulta Verificare la configurazione della mappa di URL.
Mappa il traffico a un singolo servizio
Invia tutto il traffico a un singolo servizio. Assicurati di sostituire i segnaposto.
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
weight: 100
Suddividi il traffico tra due servizi
Suddividi il traffico tra due o più servizi. Assicurati di sostituire i segnaposto.
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 2
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
weight: 95
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
weight: 5
Configurare un reindirizzamento URL
L'esempio seguente restituisce un codice di risposta 301 MOVED_PERMANENTLY_DEFAULT
configurabile. L'esempio imposta anche l'intestazione di risposta Location con l'URI appropriato, sostituendo l'host e il percorso come specificato nell'azione di reindirizzamento.
Per creare un reindirizzamento per un bucket di backend, utilizza
projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
per il campo defaultService.
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: <var>URL_MAP_NAME</var>
hostRules:
- hosts:
- "HOST TO REDIRECT FROM" # Use * for all hosts
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
defaultUrlRedirect:
hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
stripQuery: True
Mirroring del traffico
Oltre a inoltrare la richiesta al servizio di backend selezionato, puoi inviare una richiesta identica al servizio di backend mirror configurato in modalità fire and forget. Ciò significa che il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta specchiata. Il mirroring delle richieste è 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.
Per impostazione predefinita, il servizio di backend sottoposto a mirroring riceve tutte le richieste, anche se il traffico originale viene suddiviso tra più servizi di backend ponderati. Puoi configurare il servizio di backend sottoposto a mirroring in modo che riceva solo una percentuale delle richieste utilizzando il flag facoltativo mirrorPercent per specificare la percentuale di richieste da sottoporre a mirroring espressa come valore compreso tra 0 e 100,0.
Il mirroring delle richieste in base alla percentuale è in anteprima.
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
weight: 100
requestMirrorPolicy:
backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
mirrorPercent: 50.0
Se hai più servizi di backend ponderati e vuoi registrare il servizio di backend utilizzato per soddisfare la richiesta originale, puoi aggiungere un'intestazione personalizzata che includa queste informazioni a tutte le richieste. L'esempio seguente aggiunge un
intestazione personalizzata chiamata x-weighted-picked-backend a tutte le richieste del client. Per il valore dell'intestazione, utilizza il nome del servizio di backend che ha gestito la richiesta originale.
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
weight: 95
headerAction:
requestHeadersToAdd:
- headerName: x-weighted-picked-backend
headerValue: BACKEND_SERVICE_1
replace: True
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
weight: 5
headerAction:
requestHeadersToAdd:
- headerName: x-weighted-picked-backend
headerValue: BACKEND_SERVICE_2
replace: True
requestMirrorPolicy:
backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_3
Tieni presenti le seguenti limitazioni quando utilizzi il mirroring del traffico:
- Il mirroring del traffico è supportato quando entrambi i servizi di backend hanno backend di gruppi di istanze gestite, NEG a livello di zona o NEG ibridi. Non è supportato per i NEG internet, i NEG serverless e i backend Private Service Connect.
- Le richieste al servizio di backend sottoposto a mirroring non generano log o metriche per Cloud Logging e Cloud Monitoring.
Riscrivere l'URL richiesto
Riscrivere 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. Assicurati di sostituire i segnaposto.
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
weight: 100
urlRewrite:
hostRewrite: "new-host-name.com" # Omit to keep the requested host
pathPrefixRewrite: "/new-path/" # Omit to keep the requested path
Riprovare una richiesta
Configura le condizioni in cui il bilanciatore del carico riprova le richieste non riuscite, il tempo di attesa prima di riprovare e il numero massimo di tentativi consentiti.
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
weight: 100
retryPolicy:
retryConditions: 502, 504
numRetries: 3
perTryTimeout:
seconds: 1
nanos: 500000000
Specifica il timeout del percorso
Specifica il timeout per il percorso selezionato. 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 tentativi di ripetizione. Assicurati di sostituire i segnaposto.
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
weight: 100
timeout:
seconds: 30
nanos: 0
Configurare l'iniezione di errori
Inserisci errori durante l'elaborazione delle richieste per simulare errori, tra cui alta latenza, sovraccarico del servizio, errori del servizio e partizione della rete. Questa funzionalità è utile per testare la resilienza di un servizio in caso di guasti simulati.
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
weight: 100
faultInjectionPolicy:
delay:
fixedDelay:
seconds: 10
nanos: 0
percentage: 25
abort:
httpStatus: 503
percentage: 50
Configurare CORS
Configura i criteri di condivisione delle risorse tra origini (CORS) per gestire le impostazioni per l'applicazione delle richieste CORS.
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
weight: 100
corsPolicy:
allowOrigins: [ "http://my-domain.com" ]
allowMethods: [ "GET", "POST" ]
allowHeaders: [ "Authorization", "Content-Type" ]
maxAge: 1200
allowCredentials: true
Aggiungere e rimuovere intestazioni di richiesta e risposta
Aggiungi e rimuovi le intestazioni della richiesta prima di inviare una richiesta al servizio di backend. Inoltre, aggiungi e rimuovi le intestazioni di risposta dopo aver ricevuto una risposta dal servizio di backend.
Esistono limitazioni per i valori validi di headerName e headerValue.
Per maggiori dettagli, vedi Come funzionano le intestazioni personalizzate.
defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
headerAction:
requestHeadersToAdd:
- headerName: header-1-name
headerValue: header-1-value
replace: True
requestHeadersToRemove:
- header-2-name
- header-3-name
responseHeadersToAdd:
- headerName: header-4-name
headerValue: header-4-value
replace: True
responseHeadersToRemove:
- header-5-name
- header-6-name
Configurare il rilevamento degli outlier
Specifica i criteri per l'espulsione di VM o endpoint di backend non integri nei NEG, insieme ai criteri che definiscono quando un backend o un endpoint è considerato sufficientemente integro per ricevere nuovamente il traffico. Assicurati di sostituire i segnaposto.
loadBalancingScheme: EXTERNAL_MANAGED
localityLbPolicy: RANDOM
name: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
outlierDetection:
baseEjectionTime:
nanos: 0
seconds: 30
consecutiveErrors: 5
consecutiveGatewayFailure: 3
enforcingConsecutiveErrors: 2
enforcingConsecutiveGatewayFailure: 100
enforcingSuccessRate: 100
interval:
nanos: 0
seconds: 1
maxEjectionPercent: 50
successRateMinimumHosts: 5
successRateRequestVolume: 100
successRateStdevFactor: 1900
Configurare la suddivisione del traffico: procedura dettagliata
Questo esempio illustra i seguenti passaggi:
Crea modelli distinti per servizi diversi.
Crea gruppi di istanze per questi modelli.
Crea regole di routing che impostano la suddivisione del traffico in 95% / 5%.
Invia comandi curl che mostrano che le percentuali di suddivisione del traffico corrispondono approssimativamente alla configurazione.
Queste istruzioni presuppongono quanto segue:
Sono stati creati un proxy di destinazione e una regola di forwarding, insieme a una mappa URL chiamata
global-lb-map.La mappa URL invia tutto il traffico a un servizio di backend, chiamato
red-service, che è il servizio di backend predefinito.Hai configurato un percorso alternativo che invia il 5% del traffico a
blue-servicee il 95% del traffico agreen-service.Viene utilizzato un matcher percorso.
Stai utilizzando Cloud Shell o un altro ambiente con bash installato.
Definisci i servizi
La seguente funzione bash crea un servizio di backend, inclusi il modello di istanza e il gruppo di istanze gestite.
Queste istruzioni presuppongono che sia stato creato un controllo di integrità HTTP (global-lb-basic-check). Per le istruzioni, consulta una delle seguenti pagine:
- Configurazione di un bilanciatore del carico delle applicazioni esterno globale con un backend Compute Engine
- Configurazione di un bilanciatore del carico delle applicazioni esterno globale con un bucket di backend
- Configurazione di un bilanciatore del carico delle applicazioni esterno globale con connettività ibrida
- Configurazione di un bilanciatore del carico delle applicazioni esterno globale con Cloud Run, App Engine o funzioni Cloud Run
function make_service() {
local name="$1"
local region="$2"
local zone="$3"
local network="$4"
local subnet="$5"
local subdir="$6"
www_dir="/var/www/html/$subdir"
(set -x; \
gcloud compute instance-templates create "${name}-template" \
--region="$region" \
--network="$network" \
--subnet="$subnet" \
--tags=allow-ssh,load-balanced-backend \
--image-family=debian-12 \
--image-project=debian-cloud \
--metadata=startup-script="#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
sudo mkdir -p $www_dir
/bin/hostname | sudo tee ${www_dir}index.html
systemctl restart apache2"; \
gcloud compute instance-groups managed create \
"${name}-instance-group" \
--zone="$zone" \
--size=2 \
--template="${name}-template"; \
gcloud compute backend-services create "${name}-service" \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--health-checks=global-lb-basic-check \
--global \
gcloud compute backend-services add-backend "${name}-service" \
--balancing-mode='UTILIZATION' \
--instance-group="${name}-instance-group" \
--instance-group-zone="$zone" \
--global)
}
Crea i servizi
Chiama la funzione per creare tre servizi, red, green e blue. Il servizio red funge da servizio predefinito per le richieste a /. I servizi green e
blue sono entrambi configurati su /prefix per gestire rispettivamente il 95% e il 5% del traffico.
make_service red us-west1 us-west1-a lb-network backend-subnet "" make_service green us-west1 us-west1-a lb-network backend-subnet /prefix make_service blue us-west1 us-west1-a lb-network backend-subnet /prefix
Crea la mappa URL
Console
- Vai alla pagina Bilanciamento del carico nella console Google Cloud.
Vai a Bilanciamento del carico - Fai clic sul link global-lb-map.
- Fai clic su Modifica .
Configura le nuove regole di routing
- In Regole di routing, seleziona Regola avanzata per host, percorso e route.
- In Matcher nuovi host e percorsi, crea l'azione predefinita impostando Servizio su
red-service. - Fai clic su Fine.
- Fai clic su Aggiungi corrispondenze di host e percorso.
- Nel campo Host, inserisci l'indirizzo IP della regola di forwarding del bilanciatore del carico.
Incolla i seguenti contenuti YAML nella casella Matcher percorso:
defaultService: projects/PROJECT_ID/global/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: projects/PROJECT_ID/global/backendServices/green-service weight: 95 - backendService: projects/PROJECT_ID/global/backendServices/blue-service weight: 5Fai clic su Fine.
Fai clic su Aggiorna.
gcloud
Esporta la mappa degli URL esistente utilizzando il comando
gcloud compute url-maps export:gcloud compute url-maps export global-lb-map \ --destination=global-lb-map-config.yaml \ --global
Aggiorna il file della mappa URL
global-lb-map-config.yamlaggiungendo quanto segue alla fine del file:hostRules: - hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: projects/PROJECT_ID/global/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: projects/PROJECT_ID/global/backendServices/green-service weight: 95 - backendService: projects/PROJECT_ID/global/backendServices/blue-service weight: 5Aggiorna la mappa URL utilizzando il comando
gcloud compute url-maps import:gcloud compute url-maps import global-lb-map \ --global \ --source=global-lb-map-config.yaml
Testa la configurazione
Per testare la configurazione, assicurati innanzitutto che le richieste all'indirizzo IP del bilanciatore del carico configurato in precedenza siano gestite dalla configurazione predefinita red.
Poi, assicurati che le richieste inviate a
FORWARDING_RULE_IP_ADDRESS/prefix vengano suddivise come previsto.
Configurare l'affinità sessione in base a HTTP_COOKIE
Il controllo del traffico ti consente di configurare l'affinità sessione in base a un
cookie fornito. Per configurare l'affinità sessione basata su HTTP_COOKIE per un servizio di backend chiamato red-service, segui queste istruzioni.
Utilizza il comando
gcloud compute backend_services exportper recuperare la configurazione del servizio di backend.gcloud compute backend-services export red-service \ --destination=red-service-config.yaml \ --globalAggiorna il file
red-service-config.yamlcome segue:sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 0 minimumRingSize: 10000Nel file
red-service-config.yaml, elimina la seguente riga:sessionAffinity: NONE
Aggiorna il file di configurazione del servizio di backend:
gcloud compute backend-services import red-service \ --source=red-service-config.yaml \ --global
Risoluzione dei problemi
Utilizza queste informazioni per la risoluzione dei problemi quando il traffico non viene indirizzato in base alle regole di routing e ai criteri di traffico che hai configurato.
Per informazioni su logging e monitoraggio, consulta Logging e monitoraggio HTTP(S) esterno.
Sintomi:
- Aumento del traffico verso i servizi nelle regole precedenti a quella in questione.
- Un aumento imprevisto delle risposte HTTP 4xx e 5xx per una determinata regola di route.
Soluzione: controlla l'ordine delle regole di routing. Le regole di route vengono interpretate nell'ordine in cui sono specificate.
Le regole di routing all'interno di una mappa URL vengono interpretate nell'ordine in cui sono specificate. Questo è diverso dal modo in cui le regole dei percorsi vengono interpretate dalla corrispondenza del prefisso più lungo. Per una regola di percorso, il bilanciatore del carico delle applicazioni esterno globale seleziona solo una singola regola di percorso. Tuttavia, quando utilizzi le regole di route, potrebbe essere applicata più di una.
Quando definisci le regole di routing, assicurati che le regole nella parte superiore dell'elenco non indirizzino inavvertitamente il traffico che altrimenti sarebbe stato indirizzato da una regola di routing successiva. Il servizio che riceve traffico indirizzato in modo errato rifiuterà probabilmente le richieste e il servizio nelle regole di routing riceverà traffico ridotto o nessuno.