Configurare la gestione avanzata del traffico con i servizi gRPC senza proxy
Questo documento fornisce istruzioni per configurare Traffic Director con le seguenti funzionalità di gestione del traffico:
- Corrispondenza route
- Suddivisione del traffico
- Interruzione di circuito
- Fault injection
- Durata massima dello stream
- Riprova
- Affinità sessione
- Rilevamento outlier
- Bilanciamento del carico delle località
Sebbene questo documento si concentri sulla configurazione della gestione avanzata del traffico con gRPC senza proxy su Compute Engine, la gestione avanzata del traffico è supportata anche se utilizzi gRPC proxyless su Google Kubernetes Engine (GKE).
Prima di iniziare
Prima di configurare la gestione avanzata del traffico, rivedi i requisiti in Prepararsi a configurare Traffic Director con servizi gRPC proxyless. Non puoi configurare la gestione avanzata del traffico a meno che non vengano soddisfatti tutti i requisiti.
Per informazioni concettuali su queste funzionalità, consulta Gestione avanzata del traffico.
Informazioni sull'esempio di Wallet gRPC
Per illustrare queste funzionalità, esegui il deployment di un esempio di Wallet gRPC. In questo esempio sono presenti tre servizi gRPC, grpc.examples.wallet.Wallet
, grpc.examples.wallet.stats.Stats
e grpc.examples.wallet.account.Account
, di cui viene eseguito il deployment come tre applicazioni separate.
Come mostrato nel seguente
diagramma, crei un client gRPC che chiama il servizio Wallet
per ottenere il
bilanciamento di un account e chiama il servizio Stats
per ottenere il prezzo di una moneta.
Il servizio Wallet
chiama i servizi Stats
e Account
per
calcolare il saldo. Il servizio Stats
chiama anche il servizio Account
per ottenere informazioni sugli utenti.
Nell'esempio, esegui il deployment di due versioni delle implementazioni Wallet
e Stats
per illustrare il routing delle richieste in base alle regole configurate. Per simulare la creazione e il deployment di versioni diverse di un servizio, utilizza i flag del server per modificare il comportamento dei programmi binari che crei una sola volta.
- Il flag
--port
specifica la porta su cui viene eseguito l'ascolto del servizio su un'istanza VM. - Il flag
--hostname_suffix
specifica un valore che viene aggiunto al nome host dell'istanza VM che risponde a una richiesta. Il valore risultante viene aggiunto come metadatihostname
nella risposta. Questo ti aiuta a identificare quale istanza in un gruppo di istanze ha risposto alla richiesta del client. - Il flag
--premium_only
con il valoretrue
specifica che il servizio è una versione premium del serviziostats
. - Il flag
--v1_behavior
con il valoretrue
specifica che il file binario del portafoglio si comporta come una versione v1.
La tabella seguente mostra i valori di questi flag per ogni istanza VM che esegue uno dei servizi gRPC, il numero di istanze presenti in un gruppo e i servizi di backend a cui appartengono questi gruppi.
Servizio di backend | Gruppo di istanze | Istanze | Flag server |
---|---|---|---|
account |
account |
2 | --port=50053 --hostname_suffix="account"
|
stats |
stats |
2 | --port=50052 --hostname_suffix="stats" --account_server="xds:///account.grpcwallet.io"
|
stats-premium |
stats-premium |
2 | --port=50052 --hostname_suffix="stats_premium" --account_server="xds:///account.grpcwallet.io" --premium_only=true
|
wallet-v1 wallet-v1-affinity
|
wallet-v1 |
2 | --port=50051 --hostname_suffix="wallet_v1" --v1_behavior=true --account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"
|
wallet-v2 |
wallet-v2 |
1 | --port=50051 --hostname_suffix "wallet_v2" --account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"
|
Dopo aver eseguito il deployment di questi servizi, configurerai Traffic Director in modo che instrada le richieste a questi servizi di backend da un client di test, in base alle regole di routing nella tabella seguente. Il client si connette al nome host virtuale di un servizio, come mostrato nella colonna Host.
Host | Regole delle corrispondenze | Azione route |
---|---|---|
wallet.grpcwallet.io |
Prefisso percorso: "/" Intestazione presente: "session_id"
|
Percorso per wallet-v1-affinity |
Prefisso percorso: "/" Intestazione: {"route": "timeout"}
|
Imposta un timeout di 5 secondi e instrada a wallet-v2
|
|
Prefisso percorso: "/" Intestazione: {"route": "fault"}
|
Non supera il 50% delle richieste e instrada le restanti a wallet-v2
|
|
Prefisso percorso: "/" Intestazione: {"membership": "premium"}
|
Instrada a wallet-v1 eriprova fino a 3 volte in caso di errore |
|
Percorso completo: /grpc.examples.wallet.Wallet/FetchBalance |
Instrada a:wallet-v1 : 70%wallet-v2 : 30%
|
|
Predefinito | Percorso per wallet-v1 |
|
stats.grpcwallet.io |
Prefisso percorso: "/" Intestazione: {"membership": "premium"}
|
Percorso per stats-premium |
Predefinito | Percorso per stats |
|
account.grpcwallet.io |
Prefisso percorso: "/" Intestazione: {"route": "account-fault"}
|
Non supera il 30% delle richieste e instrada le restanti a account
|
Predefinito | account |
Questo esempio utilizza una suddivisione del traffico di 70/30 tra due servizi esistenti. Se
suddividi il traffico verso un nuovo servizio a cui non è stato fatto riferimento
prima nella mappa URL, per prima cosa aggiungi il nuovo servizio a weightedBackendServices
e assegnagli una ponderazione pari a 0
. Quindi, aumenta gradualmente il peso assegnato al servizio.
Il client di prova ha le seguenti opzioni che ti consentono di generare richieste appropriate per dimostrare le funzionalità di gestione del traffico.
Opzione | Descrizione |
---|---|
--watch=true |
Chiama i metodi di streaming per il saldo/prezzo dell'orologio |
--unary_watch=true |
Chiamata ripetuta di metodi unari per saldo/prezzo dell'orologio |
--user=Alice |
Inserisci intestazione {"membership": "premium"} |
--user=Bob |
Inserisci intestazione {"membership": "normal"} |
--route=value |
Inserisci intestazione {"route": "value"} |
--affinity=true |
Inserisci intestazione {"session_id": "value"} |
Prepara l'ambiente locale
Per configurare l'ambiente locale per questi esempi, esegui questi comandi:
Aggiorna il programma binario
gcloud
per assicurarti di avere la versione più recente:gcloud components update
Scarica il repository di esempi:
sudo apt-get install git -y
Clona il repository corretto per l'esempio:
export EXAMPLES_VERSION=v1.1.x git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \ https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
Crea e configura le istanze del router Cloud
In questa sezione creerai istanze di router Cloud in ogni regione e le configurerai per Cloud NAT. Le VM create in questo esempio non hanno indirizzi IP esterni, ma devono avere accesso a internet. La configurazione del router Cloud con Cloud NAT fornisce l'accesso richiesto.
gcloud
Crea le istanze del router Cloud:
gcloud compute routers create nat-router-us-central1 \ --network=default \ --region=us-central1
Configura i router per Cloud NAT:
gcloud compute routers nats create nat-config \ --router-region=us-central1 \ --router=nat-router-us-central1 \ --nat-all-subnet-ip-ranges \ --auto-allocate-nat-external-ips
Crea il controllo di integrità gRPC e la regola firewall
In questa sezione creerai un controllo di integrità gRPC e una regola firewall per consentire alle richieste di controllo di integrità gRPC di raggiungere la tua rete. In seguito, il controllo di integrità gRPC viene associato ai servizi di backend, in modo da poter verificare l'integrità delle istanze di backend di tali servizi di backend.
gcloud
Crea il controllo di integrità:
gcloud compute health-checks create grpc grpcwallet-health-check \ --use-serving-port
Crea la regola firewall per il controllo di integrità:
gcloud compute firewall-rules create grpcwallet-allow-health-checks \ --network default --action allow --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tags allow-health-checks \ --rules tcp:50051-50053
Crea il modello di istanza
In questa sezione creerai un modello di istanza per eseguire il deployment del servizio gRPC account
esposto sulla porta 50053
.
gcloud
Crea il modello di istanza:
gcloud compute instance-templates create grpcwallet-account-template \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --tags=allow-health-checks \ --network-interface=no-address \ --image-family=debian-10 \ --image-project=debian-cloud \ --metadata-from-file=startup-script=<(echo "#! /bin/bash set -ex cd /root export HOME=/root sudo apt-get update -y pushd \$(mktemp -d) sudo apt-get install -y wget git wget https://dl.google.com/go/go1.16.5.linux-amd64.tar.gz sudo tar -C /usr/local -xvf go1.16.5.linux-amd64.tar.gz sudo cp /usr/local/go/bin/go /usr/bin/go popd git clone -b $EXAMPLES_VERSION --single-branch --depth=1 https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git cd traffic-director-grpc-examples/go/account_server/ go build . sudo systemd-run ./account_server --port 50053 --hostname_suffix account")
Crea il gruppo di istanze gestite
I gruppi di istanze gestite utilizzano la scalabilità automatica per creare nuove istanze VM in base alle esigenze. In questa sezione, creerai un gruppo di istanze gestite utilizzando il modello di istanza creato nella sezione precedente.
gcloud
Crea il gruppo di istanze:
gcloud compute instance-groups managed create grpcwallet-account-mig-us-central1 \ --zone=us-central1-a \ --size=2 \ --template=grpcwallet-account-template
Configura la porta denominata
In questa sezione configurerai la porta denominata per il servizio gRPC. La porta denominata è la porta su cui il servizio gRPC rimane in ascolto delle richieste. In questo esempio, la porta denominata è la porta 50053
.
gcloud
Crea la porta denominata:
gcloud compute instance-groups set-named-ports grpcwallet-account-mig-us-central1 \ --named-ports=grpcwallet-account-port:50053 \ --zone=us-central1-a
Crea il servizio di backend
In questa sezione creerai un servizio di backend globale con uno schema di bilanciamento del carico di INTERNAL_SELF_MANAGED
e protocollo GRPC
.
Successivamente, associ il controllo di integrità e il gruppo di istanze al servizio di backend.
In questo esempio, utilizzerai il gruppo di istanze gestite creato durante la procedura di creazione del gruppo di istanze gestite. Questo gruppo di istanze gestite esegue il servizio gRPC account
. La porta nel flag --port-name
è quella che hai
creato nella sezione
Configurare la porta denominata.
gcloud
Crea il servizio di backend, quindi associa il controllo di integrità al nuovo servizio di backend:
gcloud compute backend-services create grpcwallet-account-service \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --protocol=GRPC \ --port-name=grpcwallet-account-port \ --health-checks=grpcwallet-health-check
Aggiungi il gruppo di istanze gestite come backend:
gcloud compute backend-services add-backend grpcwallet-account-service \ --instance-group=grpcwallet-account-mig-us-central1 \ --instance-group-zone=us-central1-a \ --global
I passaggi per creare i servizi di backend rimanenti utilizzati nell'esempio di Wallet gRPC sono simili a quelli precedenti. Per creare i servizi rimanenti, esegui uno script shell. Lo script esegue il deployment dei seguenti servizi di backend:
stats
stats-premium
wallet-v1
wallet-v1-affinity
wallet-v2
Esegui lo script shell che crea i servizi di backend aggiuntivi:
traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats '--account_server="xds:///account.grpcwallet.io"' traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats-premium '--account_server="xds:///account.grpcwallet.io" --premium_only=true' # This command creates wallet-v1 and wallet-v1-affinity backend services. traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v1 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io" --v1_behavior=true' traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v2 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"'
Crea le regole di routing
In questa sezione creerai una mappa URL da utilizzare per dimostrare varie funzionalità di gestione del traffico. La mappa URL specifica i nomi host virtuali dei servizi in questo esempio e le regole di routing associate. Per ulteriori informazioni, vedi Mappe di regole di routing.
Nella mappa URL, hostRules
specifica i nomi host virtuali dei servizi nell'esempio. Questi sono i nomi che un client utilizza nell'URI del canale per connettersi a un servizio specifico. Ad esempio, per inviare una richiesta al servizio account
, un client utilizza xds:///account.grpcwallet.io
nell'URI del canale. In hostRules
, configura una voce hosts
con il valore
account.grpcwallet.io
.
L'elemento pathMatcher
associato a una voce hosts
specifica il nome di un elemento
pathMatcher
che contiene tutte le regole di routing per l'host virtuale in questione. Una configurazione di pathMatcher
è composta da regole di corrispondenza e regole di azione corrispondenti come descritto in Informazioni sull'esempio di Wallet gRPC.
gcloud
Crea la mappa URL:
export PROJECT_ID=$(gcloud config list --format 'value(core.project)') export BS_PREFIX=projects/$PROJECT_ID/global/backendServices/grpcwallet gcloud compute url-maps import grpcwallet-url-map << EOF name: grpcwallet-url-map defaultService: $BS_PREFIX-account-service hostRules: - hosts: - account.grpcwallet.io pathMatcher: grpcwallet-account-path-matcher - hosts: - stats.grpcwallet.io pathMatcher: grpcwallet-stats-path-matcher - hosts: - wallet.grpcwallet.io pathMatcher: grpcwallet-wallet-path-matcher pathMatchers: - name: grpcwallet-account-path-matcher defaultService: $BS_PREFIX-account-service routeRules: - matchRules: - prefixMatch: / headerMatches: - headerName: route exactMatch: account-fault priority: 0 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-account-service weight: 100 faultInjectionPolicy: abort: httpStatus: 503 percentage: 30 - name: grpcwallet-stats-path-matcher defaultService: $BS_PREFIX-stats-service routeRules: - matchRules: - prefixMatch: / headerMatches: - headerName: membership exactMatch: premium priority: 0 service: $BS_PREFIX-stats-premium-service - name: grpcwallet-wallet-path-matcher defaultService: $BS_PREFIX-wallet-v1-service routeRules: - matchRules: - prefixMatch: / headerMatches: - headerName: session_id presentMatch: true priority: 0 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v1-affinity-service weight: 100 - matchRules: - prefixMatch: / headerMatches: - headerName: route exactMatch: timeout priority: 1 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v2-service weight: 100 maxStreamDuration: seconds: 5 - matchRules: - prefixMatch: / headerMatches: - headerName: route exactMatch: fault priority: 2 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v2-service weight: 100 faultInjectionPolicy: abort: httpStatus: 503 percentage: 50 - matchRules: - prefixMatch: / headerMatches: - headerName: membership exactMatch: premium priority: 3 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v1-service weight: 100 retryPolicy: retryConditions: - unavailable numRetries: 3 - matchRules: - fullPathMatch: /grpc.examples.wallet.Wallet/FetchBalance priority: 4 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v1-service weight: 70 - backendService: $BS_PREFIX-wallet-v2-service weight: 30 - matchRules: - prefixMatch: /grpc.examples.wallet.Wallet/ priority: 5 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v2-service weight: 100 EOF
Crea il proxy di destinazione e la regola di forwarding
In questa sezione creerai il proxy gRPC di destinazione e una regola di forwarding.
Il proxy gRPC di destinazione fa riferimento alla mappa URL creata nel passaggio precedente.
Il flag --validate-for-proxyless
consente i controlli della configurazione in modo da non abilitare accidentalmente una funzionalità non compatibile con i deployment gRPC proxy.
gcloud
Crea il proxy gRPC di destinazione:
gcloud compute target-grpc-proxies create grpcwallet-proxy \ --url-map=grpcwallet-url-map \ --validate-for-proxyless
La regola di forwarding fa riferimento al proxy gRPC di destinazione che hai creato. Lo schema di bilanciamento del carico è impostato su INTERNAL_SELF_MANAGED
per indicare che questa regola di forwarding viene utilizzata da Traffic Director. Deve essere una regola di forwarding globale. L'indirizzo IP è impostato su 0.0.0.0
perché un client gRPC senza proxy risolve il problema hostname:port
nell'URI di destinazione inviando una richiesta LDS a Traffic Director anziché eseguire una ricerca DNS. Per ulteriori informazioni, consulta Schema di risoluzione dei nomi.
Quando non è specificata una porta nell'URI di destinazione, il valore predefinito è 80
. Ad esempio, un URI di destinazione xds:///foo.myservice:8080
corrisponde a una regola di forwarding configurata con la porta 8080
. In questo esempio, la regola di forwarding è
configurata con la porta 80
.
gcloud
Crea la regola di forwarding:
gcloud compute forwarding-rules create grpcwallet-forwarding-rule \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --address=0.0.0.0 \ --address-region=us-central1 \ --target-grpc-proxy=grpcwallet-proxy \ --ports=80 \ --network=default
Verificare la configurazione
Al termine del processo di configurazione, verifica che i servizi di backend che hai configurato siano disponibili controllando la pagina Traffic Director nella console Google Cloud. Conferma che i servizi di backend e i backend associati siano segnalati come integri. L'operazione potrebbe richiedere alcuni minuti.
Verifica la configurazione del routing
In questa sezione verificherai che la configurazione del routing funzioni correttamente.
Utilizza lo strumento grpcurl
per testare la configurazione.
gcloud
Crea una VM client su cui eseguire i client per testare il servizio. Se vuoi, puoi includere il flag
--network-interface=no-address
.gcloud compute instances create grpc-wallet-client \ --zone=us-central1-a \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --image-family=debian-10 \ --image-project=debian-cloud \ --metadata-from-file=startup-script=<(echo '#! /bin/bash set -e export GRPC_XDS_BOOTSTRAP=/run/td-grpc-bootstrap.json # Expose bootstrap variable to SSH connections echo export GRPC_XDS_BOOTSTRAP=$GRPC_XDS_BOOTSTRAP | sudo tee /etc/profile.d/grpc-xds-bootstrap.sh # Create the bootstrap file curl -L https://storage.googleapis.com/traffic-director/td-grpc-bootstrap-0.11.0.tar.gz | tar -xz ./td-grpc-bootstrap-0.11.0/td-grpc-bootstrap | sudo tee $GRPC_XDS_BOOTSTRAP')
Accedi alla VM tramite SSH ed esegui i comandi seguenti per preparare la VM:
export EXAMPLES_VERSION=v1.1.x sudo apt-get update sudo apt-get install git -y
Esegui questi comandi:
git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \ https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git curl -L https://github.com/fullstorydev/grpcurl/releases/download/v1.6.1/grpcurl_1.6.1_linux_x86_64.tar.gz | tar -xz chmod +x grpcurl
Per accedere ai servizi senza un proxy sidecar, il client gRPC deve utilizzare lo schema di risoluzione dei nomi xds
. Questo schema indica alla libreria gRPC utilizzata nel client di utilizzare un server xDS per risolvere il nome host. A questo scopo, è necessaria
una configurazione del bootstrap.
Lo script di avvio nella sezione precedente imposta la variabile di ambiente GRPC_XDS_BOOTSTRAP
e utilizza uno script di supporto per generare il file di bootstrap. I valori TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
, TRAFFICDIRECTOR_NETWORK_NAME
e zona nel file di bootstrap generato vengono ottenuti dal server dei metadati che conosce questi dettagli sulle istanze VM di Compute Engine. Puoi fornire questi valori allo script helper manualmente utilizzando le opzioni -gcp-project-number
e -vpc-network-name
.
Verifica la configurazione utilizzando lo strumento grpcurl
Esegui i comandi seguenti nella shell SSH per verificare che wallet-service
, stats-service
e account-service
siano in esecuzione:
./grpcurl -plaintext xds:///account.grpcwallet.io list ./grpcurl -plaintext -d '{"token": "2bd806c9"}' xds:///account.grpcwallet.io grpc.examples.wallet.account.Account/GetUserInfo ./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' xds:///stats.grpcwallet.io grpc.examples.wallet.stats.Stats/FetchPrice ./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' -d '{"include_balance_per_address": true}' xds:///wallet.grpcwallet.io grpc.examples.wallet.Wallet/FetchBalance
Vedrai i seguenti risultati:
grpc.examples.wallet.account.Account grpc.health.v1.Health grpc.reflection.v1alpha.ServerReflection { "name": "Alice", "membership": "PREMIUM" } { "price": "10295" } { "balance": "5089953" }
Verifica con grpc-wallet
client
Segui le istruzioni riportate di seguito specifiche per la lingua per verificare la configurazione. I comandi inviano più RPC, alcune con metadati aggiuntivi, per mostrare che le richieste vengono instradate ai servizi di backend in base alle regole di corrispondenza della mappa URL. Il comando stampa anche il nome host dell'istanza VM per ogni risposta per mostrare a quale istanza VM è stata instradata la richiesta.
Java
Per verificare il servizio con un client Java gRPC, esegui questo comando:
sudo apt-get install -y openjdk-11-jdk-headless
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java ./gradlew installDist # This command calls 'FetchBalance' from 'wallet-service' in a loop, # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%) # and 'wallet-v2' (30%). ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'. # The RPC path matches the service prefix, so all requests are # sent to 'wallet-v2'. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob # This command calls 'WatchPrice' from 'stats-service'. It sends the # user's membership (premium or not) in metadata. Premium requests are # all sent to 'stats-premium' and get faster responses. Alice's requests # always go to premium and Bob's go to regular. ./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob ./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice
Go
Per verificare il servizio con un client gRPC Go, installa golang o segui le istruzioni ufficiali:
sudo apt-get install -y wget wget https://dl.google.com/go/go1.16.5.linux-amd64.tar.gz sudo tar -C /usr/local -xvf go1.16.5.linux-amd64.tar.gz sudo ln -s /usr/local/go/bin/go /usr/bin/go
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client go build # This command calls 'FetchBalance' from 'wallet-service' in a loop, # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%) # and 'wallet-v2' (30%). ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch --user=Bob # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'. # The RPC path matches the service prefix, so all requests # are sent to 'wallet-v2'. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob # This command calls 'WatchPrice' from 'stats-service'. It sends the # user's membership (premium or not) in metadata. Premium requests are # all sent to 'stats-premium' and get faster responses. Alice's requests # always go to premium and Bob's go to regular. ./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Bob ./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Alice
C++
Per verificare il servizio con un client gRPC C++, esegui questo comando:
sudo apt-get install -y build-essential
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp ../tools/bazel build :client # This command calls 'FetchBalance' from 'wallet-service' in a loop, # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%) # and 'wallet-v2' (30%). ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'. # The RPC path matches the service prefix, so all requests are sent to 'wallet-v2'. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob # This command calls 'WatchPrice' from 'stats-service'. It sends the # user's membership (premium or not) in metadata. Premium requests are # all sent to 'stats-premium' and get faster responses. Alice's requests # always go to premium, and Bob's go to regular. ../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob ../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice
Configurare opzioni più avanzate
Puoi configurare opzioni avanzate di routing del traffico utilizzando le istruzioni riportate nelle sezioni seguenti.
Interruzione di circuito
L'interruzione di circuito consente di impostare soglie di errore per impedire alle richieste del client di sovraccaricare i servizi di backend. Una volta che il numero di richieste in sospeso ha raggiunto un limite che hai impostato, il client smette di inviare richieste aggiuntive, concedendo ai tuoi servizi di backend il tempo di recupero.
L'interruzione di circuito previene errori a cascata restituendo un errore al client anziché sovraccaricare un servizio di backend. Ciò consente di gestire una parte del traffico, fornendo al contempo il tempo necessario per gestire la situazione di sovraccarico, ad esempio per gestire un picco di traffico incrementando la capacità tramite la scalabilità automatica.
Quando crei il servizio di backend per stats-service
, lo script create_service.sh
include le seguenti righe di configurazione:
circuitBreakers: maxRequests: 1
Questa impostazione limita i client a una richiesta in attesa al stats-service
alla volta. Poiché esiste un solo servizio wallet-v2
, l'esecuzione
simultanea di due operazioni del client di portafoglio WatchBalance
determina errori nella seconda
istanza.
Java
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob 2>/dev/null 1>/dev/null & sleep 10 # Wait a few seconds to allow the watch to begin. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
L'output sarà simile al seguente:
io.grpc.examples.wallet.Client run INFO: Will try to run balance io.grpc.examples.wallet.Client run WARNING: RPC failed: Status{code=INTERNAL, description=RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded, cause=null}
Esegui il comando
kill
:kill %%
Go
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob 2> /dev/null 1> /dev/null & sleep 10 # Wait a few seconds to allow the watch to begin. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
L'output sarà simile al seguente:
server host: error: no hostname failed to fetch balance: rpc error: code = Internal desc = RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded
Esegui il comando
kill
:kill %%
C++
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob 2>/dev/null 1>/dev/null & sleep 10 # Wait a few seconds to allow the watch to begin. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
L'output sarà simile al seguente:
Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server: localhost:18882, user: Bob, watch: 1 ,unary_watch: 0, observability_project: , route: 13: RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded
Esegui il comando
kill
:kill %%
Fault injection
Fault injection introduce errori durante la gestione delle richieste per simulare guasti, tra cui latenza elevata, sovraccarico dei servizi, errori dei servizi e partizionamento della rete. Questa funzionalità è utile per testare la resilienza di un servizio in caso di errori simulati.
Quando hai creato la mappa URL in precedenza, imposti il criterio di fault injection in modo che il 50% delle RPC inviate a wallet.grpcwallet.io
con l'intestazione route=fault
non vada a buon fine.
Per dimostrare la fault injection, utilizza il codice nei seguenti linguaggi.
Java
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=fault
L'output sarà simile al seguente:
server host: grpcwallet-wallet-v2-mig-us-central1-zznc total balance: 10340491 - address: 148de9c5, balance: 2549839 - address: 2e7d2c03, balance: 7790652 io.grpc.examples.wallet.Client run WARNING: RPC failed: Status{code=UNAVAILABLE, description=RPC terminated due to fault injection: HTTP status code 503, cause=null}
Go
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch --user=Bob --route=fault
L'output sarà simile al seguente:
server host: grpcwallet-wallet-v1-mig-us-central1-bm1t_wallet-v1 user: Bob, total grpc-coin balance: 10452589. - address: 2e7d2c03, balance: 7875108. - address: 148de9c5, balance: 2577481. failed to fetch balance: rpc error: code = Unavailable desc = RPC terminated due to fault injection
C++
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=fault
L'output sarà simile al seguente:
Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server: localhost:18882, user: Bob, watch: 0 ,unary_watch: 1, observability_project: , route: fault server host: grpcwallet-wallet-v2-mig-us-central1-1lm6 user: Bob total grpc-coin balance: 10211908 - address: 148de9c5, balance: 2518132 - address: 2e7d2c03, balance: 7693776 14: Fault injected
Durata massima dello stream
La durata massima del flusso consente di applicare un timeout massimo a tutte le RPC. In questo modo, puoi impedire ai client che dimenticano di impostare una scadenza o che fissano una scadenza eccessiva di sprecare le risorse del server.
Quando hai creato la mappa URL in precedenza, hai impostato una durata massima dello stream di 5
secondi per le RPC inviate a wallet.grpcwallet.io
con l'intestazione route=timeout
.
Per dimostrare i timeout, prima interrompiamo il servizio wallet-v2
.
gcloud
gcloud compute instance-groups managed resize \ --size=0 grpcwallet-wallet-v2-mig-us-central1 \ --zone=us-central1-a
Il seguente comando rimarrebbe bloccato per sempre, perché non esiste un servizio di backend per gestirlo e l'applicazione non imposta una scadenza.
Java
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
Il comando non risponde più. Premi ^C per interrompere il comando.
Go
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
Il comando non risponde più. Premi ^C per interrompere il comando.
C++
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
Il comando non risponde più. Premi ^C per interrompere il comando.
Tuttavia, il seguente comando che utilizza la route timeout
non riesce dopo 5 secondi a causa dell'impostazione maxStreamDuration
.
Java
Esegui questo comando:
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob --route=timeout
L'output sarà simile al seguente:
io.grpc.examples.wallet.Client run WARNING: RPC failed: Status{code=DEADLINE_EXCEEDED, description=deadline exceeded after 4.999594070s. [wait_for_ready, buffered_nanos=5000553401, waiting_for_connection], cause=null}
Go
Esegui questo comando:
cd ~/traffic-director-grpc-examples/go/wallet_client ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob --route=timeout
L'output sarà simile al seguente:
failed to create stream: rpc error: code = DeadlineExceeded desc = context deadline exceeded.
C++
Esegui questo comando:
cd ~/traffic-director-grpc-examples/cpp ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob --route=timeout
L'output sarà simile al seguente:
Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server: localhost:18882, user: Bob, watch: 1 ,unary_watch: 0, observability_project: , route: timeout 4: Deadline Exceeded
Riavvia il servizio wallet-v2
.
gcloud
gcloud compute instance-groups managed resize \ --size=1 grpcwallet-wallet-v2-mig-us-central1 \ --zone=us-central1-a
Riprova
I nuovi tentativi ti aiutano a migliorare la disponibilità del servizio consentendo alle tue applicazioni gRPC di ritentare le richieste in uscita in base a un criterio di ripetizione. In un criterio per la ripetizione dei tentativi, puoi configurare le condizioni in base alle quali è necessario riprovare una richiesta non riuscita e il numero massimo di nuovi tentativi, ad esempio quando una richiesta non ha esito positivo con un determinato codice di risposta.
Quando hai creato la mappa URL in precedenza, imposti un criterio di nuovo tentativo per le RPC al metodo FetchBalance
con l'intestazione membership=premium
. Questo criterio consente di riprovare per un massimo di 3 volte le RPC con esito negativo con codice di stato unavailable
. Puoi anche impostare un criterio di fault injection per le RPC su account.grpcwallet.io
con l'intestazione route=account-fault
che non riesce per il 30% delle RPC dal servizio Wallet
al servizio Account
. Di conseguenza, il 30% delle RPC del client di prova con
l'intestazione membership=normal
ha esito negativo, mentre la percentuale di errori per le RPC con
l'intestazione membership=premium
è inferiore all'1%.
Per dimostrare i nuovi tentativi, utilizza il codice nelle lingue che seguono.
Java
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java # 30% of the requests fail because Bob is a normal user. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault # Less than 1% of the requests fail because Alice is a premium user. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault
Go
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client # 30% of the requests fail because Bob is a normal user. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault # Less than 1% of the requests fail because Alice is a premium user. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault
C++
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp # 30% of the requests fail because Bob is a normal user. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault # Less than 1% of the requests fail because Alice is a premium user. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault
Affinità sessione
L'affinità sessione offre il miglior tentativo di inviare richieste con caratteristiche specifiche (intestazioni HTTP) alla stessa istanza finché l'istanza è integro e ha capacità. Ciò è utile per i server di applicazioni stateful che traggono vantaggio da prestazioni ed efficienza migliorate quando le richieste di un determinato client vengono inviate alla stessa istanza anziché, ad esempio, la distribuzione round robin a istanze diverse.
Quando hai creato il servizio di backend grpcwallet-wallet-v1-affinity-service
,
nello script create_service.sh
, localityLbPolicy
è stato impostato su
ROUND_ROBIN
. In questo esempio, applicherai la seguente configurazione per
modificare localityLbPolicy
in RING_HASH
.
sessionAffinity: HEADER_FIELD localityLbPolicy: RING_HASH consistentHash: httpHeaderName: "session_id"
gcloud
Salva la configurazione del servizio di backend
grpcwallet-wallet-v1-affinity-service
:gcloud compute backend-services export grpcwallet-wallet-v1-affinity-service \ --destination=bs_config.yaml \ --global
Aggiorna il servizio di backend
grpcwallet-wallet-v1-affinity-service
:project_id="$(gcloud config list --format 'value(core.project)')" backend_config=" backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: projects/${project_id}/zones/us-central1-a/instanceGroups/grpcwallet-wallet-v1-mig-us-central1 connectionDraining: drainingTimeoutSec: 0 healthChecks: - projects/${project_id}/global/healthChecks/grpcwallet-health-check loadBalancingScheme: INTERNAL_SELF_MANAGED name: grpcwallet-wallet-v1-affinity-service portName: grpcwallet-wallet-port protocol: GRPC sessionAffinity: HEADER_FIELD localityLbPolicy: RING_HASH consistentHash: httpHeaderName: session_id" gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service --global <<< "${backend_config}"
Per dimostrare l'affinità sessione, utilizza il codice nei seguenti linguaggi. Con
il flag --affinity=true
, il client inserisce un'intestazione session-id
con
un valore univoco per ciascun utente. Un hash di questo valore viene utilizzato per inviare la richiesta a una determinata istanza nel gruppo di istanze del servizio di backend grpcwallet-wallet-v1-affinity-service
.
Java
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java # Without affinity, requests are sent to both instances. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice # With affinity, requests are sent to only one instance. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true
Go
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client # Without affinity, requests are sent to both instances. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice # With affinity, requests are sent to only one instance. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true
C++
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp # Without affinity, requests are sent to both instances. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice # With affinity, requests are sent to only one instance. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true
Ripristina la configurazione del servizio di backend grpcwallet-wallet-v1-affinity-service
.
gcloud
gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service \ --source=bs_config.yaml \ --global
Rilevamento outlier
Per migliorare la disponibilità del servizio, configura il rilevamento outlier. Questa funzionalità consente di identificare ed escludere temporaneamente gli host in stato non integro dal pool di bilanciamento del carico. Questi host in stato non integro sono chiamati outlier.
gRPC valuta gli host in base alla percentuale di successo, ovvero la frequenza con cui un host gestisce correttamente le richieste. La percentuale è influenzata da errori come errori gRPC, errori HTTP, timeout e altri problemi.
Quando configuri il rilevamento outlier tramite Traffic Director, puoi ottimizzare il modo in cui gRPC valuta gli host e come gestisce i valori anomali. Ad esempio, puoi specificare criteri come i seguenti:
Il numero di richieste che un host deve ricevere prima che gRPC lo analizzi per individuare un possibile stato outlier.
La misura in cui un host può discostarsi dal tasso di successo medio prima di essere considerato un outlier.
La percentuale massima di host che possono essere esclusi in qualsiasi momento dal pool di bilanciamento del carico.
Il periodo di tempo per cui un outlier viene escluso dal pool di bilanciamento del carico.
Per ulteriori informazioni sui parametri disponibili, consulta il riferimento a REST Resource: backendServices
. Tuttavia, esistono alcune limitazioni per gRPC, come descritto nella sezione seguente.
Limitazioni
I seguenti campi non sono supportati per i client gRPC:
outlierDetection.consecutiveErrors
outlierDetection.enforcingConsecutiveErrors
outlierDetection.consecutiveGatewayFailure
outlierDetection.enforcingConsecutiveGatewayFailure
Configura il rilevamento outlier
La procedura seguente mostra come configurare il rilevamento di outlier per un servizio che utilizza un gruppo di istanze come backend. Questa procedura stabilisce la seguente configurazione:
- L'analisi del rilevamento di outlier viene eseguita ogni secondo. Puoi configurare questo comportamento utilizzando il campo
interval
. - I valori anomali vengono espulsi dal pool di bilanciamento del carico per incrementi di 30
secondi, come segue:
- Se un host non è mai stato escluso in precedenza, viene espulso per soli 30 secondi.
- Se un host è stato precedentemente escluso, il tempo aumenta di 30 secondi per ogni espulsione precedente. Ad esempio, quando un host viene escluso per la terza volta, viene escluso per 90 secondi.
Puoi configurare questo comportamento utilizzando il campo
baseEjectionTime
.
- Un host è considerato non integro se la sua percentuale di successo è una deviazione standard sotto la media durante l'intervallo di tempo selezionato (in questo caso, 1 secondo). Puoi configurare la deviazione standard massima utilizzando il campo
successRateStdevFactor
.
Per configurare il rilevamento outlier in questo modo, segui i passaggi riportati di seguito.
gcloud
Esporta il file di configurazione del servizio di backend
grpcwallet-wallet-v2-service
utilizzando il comandogcloud compute backend-services export
:gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
Nel file
bs_config.yaml
, aggiorna la configurazionegrpcwallet-wallet-v2-service
in modo da includere i campi di rilevamento outlier:outlierDetection: interval: seconds: 1 nanos: 0 baseEjectionTime: seconds: 30 nanos: 0 successRateStdevFactor: 1000
Importa il file aggiornato utilizzando il comando
gcloud compute backend-services import
:gcloud compute backend-services import grpcwallet-wallet-v2-service \ --source=bs_config.yaml \ --global
Bilanciamento del carico delle località
Per utilizzare nel modo più efficiente le tue risorse, configura il bilanciamento del carico per le località. Questa funzionalità ti consente di risparmiare risorse distribuendo in modo uniforme le richieste client tra i tuoi backend.
Quando configuri il bilanciamento del carico delle località, puoi utilizzare le opzioni descritte nella tabella seguente. Tutte le opzioni richiedono la configurazione della risorsa backendServices
.
Opzione | Disponibile per | Campo di configurazione pertinente |
---|---|---|
Utilizzare un criterio integrato | Tutti i client gRPC | localityLbPolicy
|
Utilizzare una norma personalizzata | Client Java che utilizzano gRPC versione 1.47 o successive, in un mesh che include solo client gRPC | localityLbPolicies
|
Definire un elenco dei criteri preferiti | Client Java che utilizzano gRPC versione 1.47 o successive, in un mesh che include solo client gRPC | localityLbPolicies
|
Puoi utilizzare qualsiasi combinazione delle opzioni precedenti. Tuttavia, se configuri sia localityLbPolicy
sia localityLbPolicies
, gRPC tenta prima di utilizzare la configurazione localityLbPolicies
.
Se non configuri il bilanciamento del carico delle località, Traffic Director utilizza il criterio ROUND_ROBIN
.
Per informazioni su ROUND_ROBIN
e su altri criteri integrati, consulta la descrizione di localityLbPolicy
nella pagina backendServices
.
Utilizzare un criterio integrato
Se vuoi che tutti i tuoi client utilizzino un unico criterio integrato, puoi selezionarlo configurando il campo localityLbPolicy
.
Quando configuri questo campo, puoi scegliere tra i seguenti criteri:
LEAST_REQUEST
(solo client Java)RING_HASH
ROUND_ROBIN
Se non tutti i tuoi client possono utilizzare lo stesso criterio, consulta Definire un elenco dei criteri preferiti.
gcloud
-
Esporta il file di configurazione del servizio di backend
grpcwallet-wallet-v2-service
utilizzando il comandogcloud compute backend-services export
:gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
Aggiorna il file
bs_config.yaml
esportato in modo che includa le seguenti righe:localityLbPolicy: -- policy name: RING_HASH
-
Importa il file aggiornato utilizzando il comando
gcloud compute backend-services import
:gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
Utilizza una norma personalizzata
Se opportuno, puoi utilizzare un criterio di bilanciamento del carico personalizzato che hai creato e di cui hai eseguito il deployment con gRPC. Questa funzionalità è disponibile per i client Java che utilizzano gRPC 1.47 o versioni successive. Utilizzalo solo in un mesh che include tutti i client gRPC.
Quando crei un criterio personalizzato, potrebbe essere utile la seguente documentazione:
Per rendere il tuo criterio personalizzato più sofisticato, puoi utilizzare le API Open Request Cost Aggregation (ORCA). Queste API consentono di acquisire metriche sul costo delle query e sull'utilizzo dei server. L'utilizzo di queste API richiede gRPC versione 1.48.1 o successive. Per maggiori informazioni, consulta Esempio di gRPC ORCA.
Per informazioni su come le configurazioni di bilanciamento del carico personalizzate vengono consegnate a gRPC da xDS, consulta Configurazione del bilanciatore del carico personalizzato xDS gRPC.
Per configurare Traffic Director in modo da utilizzare il tuo criterio personalizzato, identifica il criterio utilizzando il campo localityLbPolicies
.
I passaggi seguenti spiegano questa procedura. In questa procedura,
aggiornerai la configurazione del servizio di backend grpcwallet-wallet-v2-service
in modo che i client che vi si connettono utilizzino un criterio personalizzato denominato
example.ExampleLoadBalancer
.
gcloud
-
Esporta il file di configurazione del servizio di backend
grpcwallet-wallet-v2-service
utilizzando il comandogcloud compute backend-services export
:gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
Aggiorna il file
bs_config.yaml
esportato in modo che faccia riferimento al criterioexample.ExampleLoadBalancer
. Includi le seguenti righe:localityLbPolicies: - customPolicy: name: example.ExampleLoadBalancer data: '{ "message": "Hello load-balancing world!" }'
-
Importa il file aggiornato utilizzando il comando
gcloud compute backend-services import
:gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
(Facoltativo) Testa la configurazione del bilanciamento del carico:
Java
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
Se hai configurato correttamente il criterio di bilanciamento del carico personalizzato, verrà visualizzato il messaggio che hai incluso nella configurazione ("Ciao mondo di bilanciamento del carico!").
Definisci un elenco dei criteri preferiti
Se hai più client che non supportano tutti un singolo criterio di bilanciamento del carico, crea un elenco di criteri utilizzabili dai client. Con questa opzione, se il primo criterio preferito non può essere utilizzato da un determinato client, gRPC utilizza di nuovo il criterio successivo nell'elenco.
Quando crei un elenco di criteri preferiti, le opzioni valide includono i criteri personalizzati, ROUND_ROBIN
e, per i client Java, LEAST_REQUEST
. Puoi
Elencare fino a 10 criteri.
Questa funzionalità è disponibile solo per i client Java che utilizzano gRPC versione 1.47 o successive. Utilizzalo solo in un mesh che include tutti i client gRPC.
gcloud
-
Esporta il file di configurazione del servizio di backend
grpcwallet-wallet-v2-service
utilizzando il comandogcloud compute backend-services export
:gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
Aggiorna il file
bs_config.yaml
esportato in modo da includere il campolocalityLbPolicies
. Compilalo con le voci che rappresentano le seguenti norme:- Una norma personalizzata non valida (
example.InvalidLoadBalancer
) - Una norma personalizzata valida (
example.ExampleLoadBalancer
) - Un criterio integrato supportato (
LEAST_REQUEST
)
localityLbPolicies: - customPolicy: name: example.InvalidLoadBalancer data: '{ "message": "This load-balancing policy doesn't work!" }' - customPolicy: name: example.ExampleLoadBalancer data: '{ "message": "Hello load-balancing world!" }' - policy: name: LEAST_REQUEST
- Una norma personalizzata non valida (
-
Importa il file aggiornato utilizzando il comando
gcloud compute backend-services import
:gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
(Facoltativo) Testa la configurazione del bilanciamento del carico:
Java
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
In risposta, gRPC tenta e non riesce a trovare
example.InvalidLoadBalancer
. Dopodiché, torna a utilizzareexample.ExampleLoadBalancer
e viene visualizzato il messaggio che hai incluso nella configurazione ("Ciao mondo di bilanciamento del carico!"). Il logging gRPC sul client include un messaggio che indica cheexample.InvalidLoadBalancer
non è stato trovato.
Esegui la pulizia delle risorse
Per eseguire la pulizia delle risorse, esegui questo comando dal tuo sistema locale:
traffic-director-grpc-examples/scripts/cleanup.sh
Blocca il traffico tra i servizi
Se vuoi bloccare il traffico tra il servizio A e il servizio B e il deployment è su GKE, configura la sicurezza dei servizi e utilizza un criterio di autorizzazione per bloccare il traffico tra i servizi. Per le istruzioni complete, consulta la pagina relativa alla sicurezza del servizio Traffic Director e le istruzioni di configurazione con Envoy e gRPC senza proxy.
Passaggi successivi
- Per aiutarti a risolvere i problemi di configurazione di Traffic Director, consulta Risoluzione dei problemi di deployment che utilizzano gRPC proxyless.