Configurare la gestione avanzata del traffico con servizi gRPC proxyless

Questa configurazione è supportata per i clienti Preview, ma non è consigliata per i nuovi utenti di Cloud Service Mesh. Per saperne di più, consulta la panoramica del routing dei servizi Cloud Service Mesh.

Questo documento fornisce istruzioni per configurare Cloud Service Mesh con le seguenti funzionalità di gestione del traffico:

• Corrispondenza route
• Suddivisione del traffico
• Interruttore di sicurezza
• Fault injection
• Durata massima dello stream
• Riprova
• Affinità sessione
• Rilevamento outlier
• Bilanciamento del carico per località

Sebbene questo documento si concentri sulla configurazione della gestione avanzata del traffico con gRPC proxyless su Compute Engine, questa funzionalità è supportata anche quando utilizzi gRPC proxyless su Google Kubernetes Engine (GKE).

Prima di iniziare

Prima di configurare la gestione avanzata del traffico, esamina i requisiti in Preparazione della configurazione di Cloud Service Mesh con servizi gRPC proxyless. Non puoi configurare la gestione avanzata del traffico a meno che non siano 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 esistono tre servizi gRPC, grpc.examples.wallet.Wallet, grpc.examples.wallet.stats.Stats e grpc.examples.wallet.account.Account, che vengono di cui vengono eseguiti il deployment come tre applicazioni distinte.

Come mostrato nel diagramma seguente, crei un client gRPC che chiama il servizio Wallet per ottenere il saldo 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 le informazioni sull'utente.

Nell'esempio, esegui il deployment di due versioni delle implementazioni di Wallet e Stats per illustrare il routing delle richieste in base alle regole che configuri. Per simulare la compilazione ed il deployment di versioni diverse di un servizio, utilizzi i flag del server per modificare il comportamento dei binari che compili una sola volta.

• Il flag --port specifica la porta su cui il servizio su un'istanza VM è in ascolto.
• 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 metadato hostname nella risposta. In questo modo puoi identificare la istanza in un gruppo di istanze che ha risposto alla richiesta del client.
• Il flag --premium_only con il valore true specifica che il servizio è una versione premium del servizio stats.
• Il flag --v1_behavior con il valore true specifica che il file .bin del portafoglio si comporta come una versione 1.

La tabella seguente mostra i valori di questi flag per ogni istanza VM che esegue uno dei servizi gRPC, il numero di istanze in un gruppo di istanze e i servizi di backend a cui appartengono questi gruppi di istanze.

Dopo aver eseguito il deployment di questi servizi, configura Cloud Service Mesh per instradare le richieste a questi servizi di backend da un client di test, in base alle regole di routing riportate nella tabella seguente. Il client si connette al nome host virtuale di un servizio, come mostrato nella colonna Host.

Questo esempio utilizza una suddivisione del traffico 70/30 tra due servizi esistenti. Se stai suddividendo il traffico in un nuovo servizio a cui non è stato fatto riferimento in precedenza dalla mappa URL, aggiungi prima il nuovo servizio a weightedBackendServices e assegnagli un peso di 0. Poi, aumenta gradualmente il peso assegnato al servizio.

Il client di test dispone delle seguenti opzioni che ti consentono di generare richieste appropriate per dimostrare le funzionalità di gestione del traffico.

Prepara l'ambiente locale

Per configurare l'ambiente locale per questi esempi, esegui i seguenti comandi:

1. Aggiorna il file binario gcloud per assicurarti di avere la versione più recente:

   gcloud components update
   

2. Scarica il repository di esempi:

   sudo apt-get install git -y
   

3. 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 router Cloud

In questa sezione crei istanze di router Cloud in ogni regione e le configuri per Cloud NAT. Le VM create da 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.

Crea la regola firewall e il controllo di integrità gRPC

In questa sezione crei 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 controllare l'integrità delle istanze di backend di questi servizi.

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.

Crea il gruppo di istanze gestite

I gruppi di istanze gestite (MIG) utilizzano la scalabilità automatica per creare nuove istanze VM in base alle esigenze. In questa sezione, crei un gruppo di istanze gestite utilizzando il modello di istanza creato nella sezione precedente.

Configura la porta denominata

In questa sezione, configuri la porta denominata per il servizio gRPC. La porta denominata è la porta su cui il servizio gRPC rimane in ascolto per le richieste. In questo esempio, la porta denominata è la porta 50053.

Crea il servizio di backend

In questa sezione, crei un servizio di backend globale con uno schema di bilanciamento del carico di INTERNAL_SELF_MANAGED e il protocollo GRPC. Associa quindi il controllo di integrità e il gruppo di istanze al servizio di backend. In questo esempio utilizzi il gruppo di istanze gestite che hai creato in Creare il gruppo di istanze gestite. Questo gruppo di istanze gestite esegue il servizio gRPC account. La porta nel flag --port-name è la porta denominata che hai creato in Configurare la porta denominata.

I passaggi per creare i restanti servizi di backend utilizzati nell'esempio di Wallet gRPC sono simili ai passaggi 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 viene creata una mappa di URL utilizzata 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, consulta la sezione Mappe delle regole di routing.

Nella mappa URL, hostRules specifica i nomi host virtuali dei servizi nell'esempio. Si tratta dei nomi utilizzati da un client nell'URI del canale per connettersi a un servizio specifico. Ad esempio, per inviare una richiesta al servizioaccount, un client utilizza xds:///account.grpcwallet.io nell'URI del canale. In hostRules, configura una voce hosts con il valore account.grpcwallet.io.

Il pathMatcher associato a una voce hosts specifica il nome di un pathMatcher contenente tutte le regole di routing per l'host virtuale. Una configurazione pathMatcher è composta da regole di corrispondenza e regole di azioni corrispondenti, come descritto in Informazioni sull'esempio di gRPC Wallet.

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 regola di forwarding

In questa sezione, crei il proxy gRPC target e una regola di forwarding.

Il proxy gRPC di destinazione fa riferimento alla mappa URL creata nel passaggio precedente. Il flag --validate-for-proxyless attiva i controlli di configurazione in modo da non attivare accidentalmente una funzionalità non compatibile con i deployment gRPC senza proxy.

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 Cloud Service Mesh. Deve essere una regola di forwarding globale. L'indirizzo IP è impostato su 0.0.0.0 perché un client gRPC proxyless risolve hostname:port nell'URI di destinazione inviando una richiesta LDS a Cloud Service Mesh anziché eseguire una ricerca DNS. Per ulteriori informazioni, consulta Schema di risoluzione dei nomi.

Quando non viene specificata una porta nell'URI di destinazione, il valore predefinito è 80. Ad esempio, un URI target 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.

Verificare la configurazione

Al termine della procedura di configurazione, verifica che i servizi di backend che hai configurato siano disponibili controllando la pagina Cloud Service Mesh nella console Google Cloud. Verifica che i servizi di backend e i backend associati siano segnalati come saldi. L'operazione potrebbe richiedere alcuni minuti.

Verifica la configurazione del routing

In questa sezione verifichi che la configurazione del routing funzioni correttamente. Utilizza lo strumento grpcurl per testare la configurazione.

Per accedere ai servizi senza un proxy sidecar, il client gRPC deve utilizzare il 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. Per farlo, è necessaria una configurazione di 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 di TRAFFICDIRECTOR_GCP_PROJECT_NUMBER, TRAFFICDIRECTOR_NETWORK_NAME e zone nel file di bootstrap generato vengono obtidosi dal server metadati che conosce questi dettagli sulle tue istanze VM Compute Engine. Puoi fornire questi valori allo script di supporto manualmente utilizzando le opzioni -gcp-project-number e -vpc-network-name.

Verifica la configurazione utilizzando lo strumento grpcurl

Esegui i seguenti comandi 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 i clienti grpc-wallet

Utilizza le seguenti istruzioni 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 indirizzata la richiesta.

Configurare opzioni più avanzate

Puoi configurare ulteriori opzioni di routing del traffico avanzato utilizzando le istruzioni riportate nelle sezioni seguenti.

Interruttore di sicurezza

L'interruttore di sicurezza ti consente di impostare soglie di errore per impedire alle richieste dei client di sovraccaricare i tuoi servizi di backend. Quando il numero di richieste in sospeso raggiunge un limite impostato, il client smette di inviare richieste aggiuntive, dando ai servizi di backend il tempo di recuperare.

L'interruttore di sicurezza impedisce i guasti a cascata restituendo un errore al client anziché sovraccaricare un servizio di backend. In questo modo, è possibile gestire parte del traffico e allo stesso tempo avere tempo per gestire la situazione di sovraccarico, ad esempio gestire un picco di traffico aumentando la capacità tramite la scalabilità automatica.

Quando crei il servizio di backend per stats-service, lo script create_service.sh include le seguenti righe nella configurazione:

circuitBreakers:
  maxRequests: 1

Questa impostazione limita i client a una sola richiesta in attesa al stats-service alla volta. Poiché esiste un solo servizio wallet-v2, l'esecuzione di due operazioni WatchBalance client del portafoglio contemporaneamente presenta errori dalla seconda istanza.

Fault injection

L'iniezione di errori introduce errori durante l'elaborazione delle richieste per simulare errori, tra cui latenza elevata, sovraccarico del servizio, errori del servizio e suddivisione della rete. Questa funzionalità è utile per testare la resilienza di un servizio ai guasti simulati.

Quando hai creato la mappa URL in precedenza, hai impostato il criterio di inserimento di errori in modo da far fallire il 50% delle chiamate RPC inviate a wallet.grpcwallet.io con l'intestazione route=fault.

Per dimostrare l'iniezione di errori, utilizza il codice nei seguenti linguaggi.

Durata massima dello stream

La durata massima dello stream consente di applicare un timeout massimo a tutte le chiamate RPC. In questo modo, i clienti che dimenticano di impostare una scadenza o che ne impostano una eccessiva non sprecano le risorse del server.

Quando hai creato la mappa URL in precedenza, hai impostato una durata massima dello stream di 5 secondi per le chiamate RPC inviate a wallet.grpcwallet.io con l'intestazione route=timeout.

Per dimostrare i timeout, interrompiamo prima il servizio wallet-v2.

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.

Tuttavia, il seguente comando che utilizza il percorso timeout non va a buon fine dopo 5 secondi a causa dell'impostazione maxStreamDuration.

Riavvia il servizio wallet-v2.

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 riprovare le richieste in uscita in base a un criterio di nuovo tentativo. In un criterio di ripetizione, puoi configurare le condizioni in base alle quali deve essere ripetuta una richiesta non riuscita e il numero massimo di tentativi di ripetizione, ad esempio quando una richiesta non riesce con un determinato codice di risposta.

Quando hai creato la mappa URL in precedenza, hai impostato un criterio di ripetizione per le RPC sul metodo FetchBalance con l'intestazione membership=premium. Questo criterio riprova le chiamate RPC che non vanno a buon fine con il codice stato unavailable fino a un massimo di 3 volte. Imposti inoltre un criterio di introduzione di errori per le RPC in account.grpcwallet.io con l'intestazione route=account-fault che causa l'errore del 30% delle RPC dal servizio Wallet al servizio Account. Di conseguenza, il 30% delle RPC del client di test con intestazionemembership=normal non va a buon fine, mentre il tasso di errore per le RPC con intestazionemembership=premium è inferiore all'1%.

Per dimostrare i tentativi di nuovo invio, utilizza il codice nei seguenti linguaggi.

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

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

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 fornisce un tentativo secondo il criterio del massimo impegno per inviare richieste con determinate caratteristiche (intestazioni HTTP) alla stessa istanza finché l'istanza è in stato di esecuzione e dispone di capacità. Questo è utile per i server di applicazioni stateful che beneficiano di un miglioramento delle prestazioni e dell'efficienza quando le richieste di un determinato client vengono inviate alla stessa istanza anziché, ad esempio, alla distribuzione round-robin in 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, applichi la seguente configurazione per cambiare localityLbPolicy in RING_HASH.

sessionAffinity: HEADER_FIELD
localityLbPolicy: RING_HASH
consistentHash:
  httpHeaderName: "session_id"

Per dimostrare l'affinità sessione, utilizza il codice nelle seguenti lingue. Con il flag --affinity=true, il client inserisce un'intestazione session-id con un valore univoco per ogni 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.

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

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

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 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 degli outlier. Questa funzionalità consente di identificare ed espellere temporaneamente gli host con problemi di integrità dal pool di bilanciamento del carico. Questi host non validi sono chiamati outlier.

gRPC valuta gli host in base alla percentuale di successo, ovvero alla frequenza con cui un host gestisce correttamente le richieste. Il tasso è influenzato da errori come errori gRPC, errori HTTP, timeout e altri problemi.

Quando configuri il rilevamento degli outlier tramite Cloud Service Mesh, puoi ottimizzare il modo in cui gRPC valuta gli host e gestisce gli outlier. Ad esempio, puoi specificare criteri come i seguenti:

• Il numero di richieste che un host deve ricevere prima che gRPC lo analizzi per verificare la presenza di un possibile stato di outlier.

• Il grado di deviazione di un host dalla percentuale di successo media prima che venga considerato un outlier.

• La percentuale massima di host che può essere espulsa contemporaneamente dal pool di bilanciamento del carico.

• Il periodo di tempo per cui un outlier viene escluso dal pool di bilanciamento del carico.

Per saperne di più sui parametri disponibili, consulta la documentazione di riferimento di 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

Configurare il rilevamento degli outlier

La procedura seguente mostra come configurare il rilevamento degli outlier per un servizio che utilizza un gruppo di istanze come backend. Questa procedura stabilisce la seguente configurazione:

• L'analisi di rilevamento degli outlier viene eseguita ogni secondo. Puoi configurare questo comportamento utilizzando il campo interval.
• Gli outlier vengono espulsi dal pool di bilanciamento del carico per incrementi di 30 secondi, come segue:
  • Se un host non è mai stato espulso in precedenza, viene espulso solo per 30 secondi.
  • Se un host è stato espulso in precedenza, il tempo aumenta di 30 secondi per ogni espulsione precedente. Ad esempio, quando un host viene espulso per la terza volta, viene espulso per 90 secondi. Puoi configurare questo comportamento utilizzando il campo baseEjectionTime.
• Un host è considerato non integro se il suo tasso di successo è inferiore alla media di una deviazione standard 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 degli outlier in questo modo, segui i passaggi che seguono.

Bilanciamento del carico per località

Per utilizzare le risorse in modo più efficiente, configura il bilanciamento del carico per località. Questa funzionalità ti aiuta a risparmiare risorse distribuendo uniformemente le richieste dei client tra i tuoi backend.

Quando configuri il bilanciamento del carico a livello di località, puoi utilizzare le opzioni descritte nella tabella seguente. Tutte le opzioni richiedono la configurazione della risorsa backendServices.

Puoi utilizzare qualsiasi combinazione delle opzioni precedenti. Tuttavia, se configurerai sia localityLbPolicy sia localityLbPolicies, gRPC tenterà prima di utilizzare la configurazione localityLbPolicies.

Se non configuri il bilanciamento del carico a livello di località, Cloud Service Mesh utilizza il criterioROUND_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 clienti 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 clienti possono utilizzare lo stesso criterio, consulta Definire un elenco di criteri preferiti.

Utilizzare una norma personalizzata

Se opportuno, puoi utilizzare un criterio di bilanciamento del carico personalizzato creato e disegnato con gRPC. Questa funzionalità è disponibile per i client Java che utilizzano gRPC versione 1.47 o successive. Utilizzalo solo in un mesh che includa tutti i client gRPC.

Quando crei una norma personalizzata, potrebbe essere utile la seguente documentazione:

• Per rendere più sofisticato il tuo criterio personalizzato, puoi utilizzare le API ORCA (Open Request Cost Aggregation). Queste API ti consentono di acquisire metriche sul costo delle query e sull'utilizzo del server. L'utilizzo di queste API richiede gRPC 1.48.1 o versioni successive. Per ulteriori informazioni, consulta Esempio di ORCA gRPC.

• Per informazioni su come le configurazioni di bilanciamento del carico personalizzate vengono comunicate a gRPC da xDS, consulta Configurazione del bilanciatore del carico personalizzato gRPC xDS.

Per configurare Cloud Service Mesh in modo che utilizzi il criterio personalizzato, identificalo utilizzando il campo localityLbPolicies.

I passaggi che seguono mostrano questa procedura. In questa procedura, aggiorni la configurazione del servizio di backend grpcwallet-wallet-v2-service in modo che i client che si connettono utilizzino un criterio personalizzato chiamato example.ExampleLoadBalancer.

Definire un elenco di norme preferite

Se hai più client che non supportano tutti un unico criterio di bilanciamento del carico, crea un elenco di criteri che i client possono utilizzare. Con questa opzione, se il primo criterio preferito non può essere utilizzato da un determinato client, gRPC ricorre al 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 1.47 o versioni successive. Utilizzalo solo in un mesh che includa tutti i client gRPC.

gcloud compute backend-services export grpcwallet-wallet-v2-service \
  --destination=bs_config.yaml \
  --global

Ripulire le risorse

Per ripulire le risorse, esegui il seguente comando dal tuo sistema locale:

traffic-director-grpc-examples/scripts/cleanup.sh

Bloccare il traffico tra i servizi

Se vuoi bloccare il traffico tra il servizio A e il servizio B e il tuo deployment è su GKE, configura la sicurezza del servizio e utilizza un criterio di autorizzazione per bloccare il traffico tra i servizi. Per istruzioni complete, consulta la sezione Sicurezza dei servizi Cloud Service Mesh e le istruzioni di configurazione con Envoy e gRPC proxyless.

Passaggi successivi

• Per aiutarti a risolvere i problemi di configurazione di Cloud Service Mesh, consulta Risoluzione dei problemi dei deployment che utilizzano gRPC senza proxy.