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 il bilanciamento del carico globale, come la regola di forwarding, la mappa URL e
di 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 il 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 funzioni avanzate per la creazione di percorsi descritte in questa pagina, alcuni I bilanciatori del carico delle applicazioni si integrano con Service Extensions inserire una logica personalizzata nel percorso dei dati di bilanciamento del carico configurazione dei callout di Service Extensions.
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.
Configura e testa 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.
L'API globale mappa URL e la documentazione relativa all'API globale del servizio di backend fornisce un elenco completo dei campi, inclusa la semantica su relazioni, restrizioni e cardinalità.
Puoi aggiungere test di configurazione a una mappa URL per assicurarti che i percorsi della mappa degli URL 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 nuovi modifiche a una mappa URL senza implementare effettivamente la mappa, consulta la sezione Convalidare la mappa URL configurazione.
Mappa il traffico verso un singolo servizio
Invia tutto il traffico a un singolo servizio. Assicurati di sostituire i segnaposto.
defaultService: global/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
Suddividi il traffico tra due servizi
Suddividi il traffico tra due o tra più servizi. Assicurati di sostituire i segnaposto.
defaultService: global/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 2
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 95
- backendService: global/backendServices/BACKEND_SERVICE_2
weight: 5
Configurare un reindirizzamento URL
L'esempio seguente restituisce un codice di risposta 3xx configurabile. L'esempio
imposta l'intestazione della risposta Location
con l'URI appropriato, sostituendo l'host
e il percorso come specificato nell'azione di reindirizzamento.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
urlRedirect:
hostRedirect: "new-host-name.com" # Omit to keep the requested host
pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
redirectResponseCode: FOUND
stripQuery: True
Mirroring del traffico
Oltre a inoltrare la richiesta al servizio di backend selezionato, puoi invia una richiesta identica al servizio di backend Mirror configurato su un e tralasciare. Il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta specchiata. Il mirroring è utile per il test una nuova versione di un servizio di backend. Puoi utilizzarlo anche per eseguire il debug della produzione gli errori in una versione di debug del servizio di backend, anziché in completamente gestita.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
requestMirrorPolicy:
backendService: global/backendServices/BACKEND_SERVICE_2
Il mirroring del traffico è supportato quando entrambi i servizi di backend hanno gruppi di istanze gestite, NEG a livello di zona o NEG ibride come backend. Non è supportato per i NEG internet, i NEG serverless e i backend Private Service Connect.
Il mirroring non può essere configurato solo per una parte specifica delle richieste. Anche se
suddividi il traffico tra più servizi di backend ponderati, il mirroring
servizio di backend riceve tutte le richieste. Tuttavia, puoi usare intestazioni personalizzate
per registrare il servizio di backend utilizzato per gestire la richiesta originale. La
nell'esempio seguente viene aggiunta un'intestazione personalizzata denominata x-weighted-picked-backend
a tutti
richieste del client. Per il valore dell'intestazione, utilizza il nome del servizio di backend che ha gestito la richiesta originale.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 95
headerAction:
requestHeadersToAdd:
- headerName: x-weighted-picked-backend
headerValue: BACKEND_SERVICE_1
replace: True
- backendService: global/backendServices/BACKEND_SERVICE_2
weight: 5
headerAction:
requestHeadersToAdd:
- headerName: x-weighted-picked-backend
headerValue: BACKEND_SERVICE_2
replace: True
requestMirrorPolicy:
backendService: global/backendServices/BACKEND_SERVICE_3
Riscrivi l'URL richiesto
Riscrivi la parte dell'URL relativa al nome host, la parte del percorso dell'URL oppure prima di inviare una richiesta al servizio di backend selezionato. Assicurati di sostituire i segnaposto.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: 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 i nuovi tentativi del bilanciatore del carico non sono riusciti richieste, quanto tempo attende il bilanciatore del carico prima di riprovare il numero massimo di nuovi tentativi consentiti.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
retryPolicy:
retryConditions: 502, 504
numRetries: 3
perTryTimeout:
seconds: 1
nanos: 500000000
Specifica il timeout della route
Specifica il timeout per il percorso selezionato. Il timeout viene calcolato dal momento in cui la richiesta viene elaborata completamente fino al completamento dell'elaborazione della risposta. Il timeout include tutti i tentativi di ripetizione. Assicurati di sostituire i segnaposto.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: 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 per risolvere gli errori simulati.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
faultInjectionPolicy:
delay:
fixedDelay:
seconds: 10
nanos: 0
percentage: 25
abort:
httpStatus: 503
percentage: 50
Configura CORS
Configura i criteri di condivisione delle risorse tra origini (CORS) per gestire impostazioni per l'applicazione delle richieste CORS.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
corsPolicy:
allowOrigins: [ "http://my-domain.com" ]
allowMethods: [ "GET", "POST" ]
allowHeaders: [ "Authorization", "Content-Type" ]
maxAge: 1200
allowCredentials: true
Aggiungi e rimuovi 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: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: 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'eliminazione di endpoint o VM di backend in stato non integro in NEG, insieme ai criteri che definiscono quando un backend o un endpoint considerato sufficientemente integro da ricevere di nuovo il traffico. Assicurati di sostituire i segnaposto.
loadBalancingScheme: EXTERNAL_MANAGED
localityLbPolicy: RANDOM
name: 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: passaggi dettagliati
Questo esempio illustra i seguenti passaggi:
Crea modelli distinti per servizi diversi.
Crea gruppi di istanze per questi modelli.
Crea regole di routing che impostino la suddivisione del traffico del 95% / 5%.
Invia comandi curl che mostrano che le percentuali di suddivisione del traffico corrispondono approssimativamente la configurazione.
Queste istruzioni presuppongono quanto segue:
Sono stati creati un proxy di destinazione e una regola di forwarding, insieme a una mappa URL denominato
global-lb-map
.La mappa URL invia tutto il traffico a un solo servizio di backend, denominato
red-service
, che è il servizio di backend predefinito.Hai configurato un percorso alternativo che invia il 5% del traffico a
blue-service
e 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, che include modello di istanza e 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 Compute Engine di backend
- Configurazione di un bilanciatore del carico delle applicazioni esterno globale con un backend del bucket
- 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
Richiama 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 host, percorso e route avanzata.
- In Nuovi host e matcher percorso, crea l'azione predefinita
Imposta il Servizio su
red-service
. - Fai clic su Fine.
- Fai clic su Aggiungi matcher host e percorso.
- Nel campo Host, inserisci l'indirizzo IP della regola di inoltro del bilanciatore del carico.
Incolla i seguenti contenuti YAML nella casella Matcher percorso:
defaultService: global/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: global/backendServices/green-service weight: 95 - backendService: global/backendServices/blue-service weight: 5
Fai 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.yaml
aggiungendo quanto segue alla fine del file:hostRules: - hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: global/backendServices/green-service weight: 95 - backendService: global/backendServices/blue-service weight: 5
Aggiorna 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
gli indirizzi IP del bilanciatore del carico configurati in precedenza sono gestiti dall'impostazione predefinita red
configurazione.
Poi, assicurati che le richieste inviate a
FORWARDING_RULE_IP_ADDRESS/prefix
siano suddivise come previsto.
Configura l'affinità sessione in base a HTTP_COOKIE
Il controllo del traffico consente di configurare l'affinità sessione in base a un
cookie. Per configurare l'affinità sessione basata su HTTP_COOKIE per un servizio di backend
denominato red-service
, segui queste istruzioni.
Utilizza il comando
gcloud compute backend_services export
per ottenere la configurazione del servizio di backend.gcloud compute backend-services export red-service \ --destination=red-service-config.yaml \ --global
Aggiorna il file
red-service-config.yaml
come segue:sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 0 minimumRingSize: 10000
Nel 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 è instradato in base alle regole di route 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.
- Aumento imprevisto delle risposte HTTP 4xx e 5xx per una determinata regola di route.
Soluzione: controlla l'ordine delle regole di route. Le regole di route vengono interpretate nell'ordine in cui vengono specificati.
Le regole di route all'interno di una mappa URL vengono interpretate nell'ordine in cui vengono specificato. 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 regola di percorso. Tuttavia, quando utilizzi le regole di route, potrebbe essere applicata più di una regola.
Quando definisci le regole di routing, assicurati che quelle 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.