Anthos Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per ulteriori informazioni, consulta la panoramica di Cloud Service Mesh.

Questa pagina è stata tradotta dall'API Cloud Translation.

Configura la gestione avanzata del traffico con Envoy

La configurazione è supportata per i clienti del servizio Anteprima, ma non è consigliata per i nuovi utenti di Cloud Service Mesh. Per ulteriori informazioni, consulta Panoramica del routing del servizio Cloud Service Mesh.

Questo documento fornisce informazioni su come configurare il traffico avanzato per i deployment di Cloud Service Mesh che utilizzano Envoy.

Prima di iniziare

Prima di configurare la gestione avanzata del traffico, segui le istruzioni in Preparati a configurare Cloud Service Mesh con Envoy, inclusa la configurazione di Cloud Service Mesh e di qualsiasi host di macchine virtuali (VM) i cluster Google Kubernetes Engine (GKE) di cui hai bisogno. Crea l'oggetto dell'accesso a specifiche risorse Google Cloud.

La disponibilità delle funzionalità di gestione avanzata del traffico varia a seconda del di richiesta di accesso al protocollo scelto. Questo protocollo viene configurato quando configuri il routing utilizzando il proxy HTTP o HTTPS di destinazione, il proxy gRPC di destinazione o il proxy di destinazione Risorsa proxy TCP:

Con il proxy HTTP di destinazione e il proxy HTTPS di destinazione, tutte le funzionalità descritti in questo documento.
Con il proxy gRPC di destinazione, sono disponibili alcune funzionalità.
Con il proxy TCP di destinazione, non sono disponibili funzionalità avanzate di gestione del traffico disponibili.

Per ulteriori informazioni, vedi funzionalità di Cloud Service Mesh e Gestione avanzata del traffico. Per una guida alla configurazione end-to-end, vedi Configura la gestione avanzata del traffico con i servizi gRPC senza proxy.

Configurare la suddivisione del traffico

Queste istruzioni presuppongono quanto segue:

Il deployment di Cloud Service Mesh ha una mappa URL denominata review-url-map.
La mappa URL invia tutto il traffico a un solo servizio di backend chiamato review1, che funge da servizio di backend predefinito.
Prevedi di instradare il 5% del traffico a una nuova versione di un servizio. Quel servizio sia in esecuzione su una VM backend o su un endpoint in un gruppo di endpoint di rete (NEG) associati al servizio di backend review2.
Non vengono utilizzate regole host o matcher di percorso.

Se stai dividendo il traffico verso un nuovo servizio a cui non è stato fatto riferimento la mappa URL prima, aggiungi prima il nuovo servizio a weightedBackendServices e assegnagli un peso di 0. Poi aumenta gradualmente la ponderazione completamente gestito di Google Cloud.

Per impostare la suddivisione del traffico:

Console

Nella console Google Cloud, vai alla pagina Cloud Service Mesh.

Vai a Cloud Service Mesh
Fai clic su Mappe di regole di routing.
Fai clic su Crea mappa di regole di routing.
Nella pagina Crea una mappa di regole di routing, inserisci un Nome.
Nel menu Protocollo, seleziona HTTP.
Seleziona una regola di forwarding esistente.
In Regole di routing, seleziona Regola host, percorso e route avanzata.
In Corrispondenza host e percorso, fai clic su Aggiungi host e matcher percorso. Viene aggiunto un nuovo matcher percorso che puoi configurare per suddividere il traffico.

Aggiungi le seguenti impostazioni al campo Matcher percorso:

    - defaultService: global/backendServices/review1
      name: matcher1
      routeRules:
      - priority: 2
        matchRules:
        - prefixMatch: ''
        routeAction:
         weightedBackendServices:
         - backendService: global/backendServices/review1
           weight: 95
         - backendService: global/backendServices/review2
           weight: 5

Fai clic su Fine.
Fai clic su Salva.

Quando la nuova versione ti soddisfa, puoi modificare gradualmente il valore dei due servizi e alla fine invierà tutto il traffico a review2.

gcloud

Esegui gcloud export. per ottenere la configurazione della mappa URL:

gcloud compute url-maps export review-url-map \
    --destination=review-url-map-config.yaml

Aggiungi la seguente sezione al file review-url-map-config.yaml:

     hostRules:
     - description: ''
      hosts:
       - '*'
     pathMatcher: matcher1
     pathMatchers:
     - defaultService: global/backendServices/review1
       name: matcher1
       routeRules:
       - priority: 2
         matchRules:
         - prefixMatch: ''
         routeAction:
          weightedBackendServices:
          - backendService: global/backendServices/review1
            weight: 95
          - backendService: global/backendServices/review2
            weight: 5

Aggiorna la mappa URL:

gcloud compute url-maps import review-url-map \
    --source=review-url-map-config.yaml

Quando la nuova versione ti soddisfa, puoi modificare gradualmente il valore dei due servizi e alla fine invierà tutto il traffico a review2.

Configura una release parziale

Utilizza un processo di deployment parziale, a volte chiamato canarying, per rilasciare un nuovo della versione software su una piccola parte dei server prima di rilasciare la nuova la versione precedente al saldo dei tuoi server di produzione.

Una release parziale utilizza weightedBackendServices. Per abilitare una release parziale: designare un servizio di backend come servizio di test, o canary, e assegnargli un peso, ad esempio 2 o 5. Esegui il deployment della nuova versione del software su questi server . Quando ritieni che la nuova versione sia priva di problemi, esegui il deployment ai restanti servizi.

Per abilitare una release parziale, utilizza il seguente esempio di codice YAML:

pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_PARTIAL_URL
            weight: 2
          - backendService: BACKEND_SERVICE_URL
            weight: 98

DEFAULT_SERVICE_URL è l'URL predefinito per completamente gestito di Google Cloud.
BACKEND_SERVICE_PARTIAL_URL è l'URL per di servizio di backend che riceve il 2% del traffico.
BACKEND_SERVICE_URL è l'URL del backend che riceve il 98% del traffico.

Configura i deployment blu/verde

I deployment blu/verde sono modelli di release che riducono il tempo necessario il passaggio del traffico di produzione a una nuova release di un servizio o a un rollback una release precedente del servizio. Questi deployment mantengono entrambe le versioni disponibile in produzione e di spostare il traffico da un servizio all'altro.

I deployment blu/verde utilizzano weightedBackendServices. Nell'esempio YAML che segue, il deployment dei backend verso SERVICE_BLUE_URL è stato completato con la di produzione e il deployment completo dei backend in SERVICE_GREEN_URL è stato completato con la nuova uscita. Nella configurazione dell'esempio, il deployment GREEN riceve il 100% del traffico di produzione. Se riscontri problemi, puoi annullare le i pesi per i due deployment, il che ripristina in modo efficace GREEN e reintegra la release BLUE non valida. In entrambi i casi, il traffico può essere spostato rapidamente perché entrambe le versioni sono disponibili per via del traffico.

Per abilitare un deployment blu/verde, utilizza il seguente esempio di codice YAML:

pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_BLUE_URL
            weight: 0
          - backendService: BACKEND_SERVICE_GREEN_URL
            weight: 100

DEFAULT_SERVICE_URL è l'URL predefinito per completamente gestito di Google Cloud.
BACKEND_SERVICE_BLUE_URL è l'URL per di servizio di backend che non riceve nessuno del tuo traffico.
BACKEND_SERVICE_GREEN_URL è l'URL del backend che riceve il 100% del traffico.

Configura il mirroring del traffico

Utilizza il mirroring del traffico quando vuoi che il traffico sia indirizzato a due diversi per eseguire il debug o il test di nuovi servizi.

Nell'esempio seguente, tutte le richieste vengono inviate a SERVICE_URL e a MIRROR_SERVICE_URL. Solo le risposte da SERVICE_URL vengono rinviate a il cliente. MIRROR_SERVICE_URL non ha alcun impatto sul cliente.

Per configurare il mirroring del traffico:

Console

Nella console Google Cloud, vai alla pagina Cloud Service Mesh.

Vai a Cloud Service Mesh
Fai clic su Mappe di regole di routing.
Fai clic su Crea mappa di regole di routing.
Nella pagina Crea una mappa di regole di routing, inserisci un Nome.
Nell'elenco Protocollo, seleziona HTTP.
Seleziona una regola di forwarding esistente.
In Regole di routing, seleziona Regola host, percorso e route avanzata.
In Corrispondenza host e percorso, fai clic su Aggiungi host e matcher percorso. Verrà aggiunto un nuovo matcher di percorso che puoi configurare per eseguire il mirroring del traffico.

Aggiungi le seguenti impostazioni al campo Matcher percorso:

    - defaultService: DEFAULT_SERVICE_URL
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: '/'
        routeAction:
         weightedBackendServices:
         - backendService: BACKEND_SERVICE_URL
           weight: 100
         requestMirrorPolicy:
           backendService: BACKEND_SERVICE_MIRROR_URL

DEFAULT_SERVICE_URL è l'URL predefinito per completamente gestito di Google Cloud.
BACKEND_SERVICE_URL è l'URL del backend mirroring.
BACKEND_SERVICE_MIRROR_URL è l'URL per di servizio di backend a cui esegui il mirroring.

Fai clic su Fine.
Fai clic su Salva.

gcloud

Esegui gcloud export. per ottenere la configurazione della mappa URL:

gcloud compute url-maps export review-url-map \
    --destination=review-url-map-config.yaml

Aggiungi la seguente sezione al file review-url-map-config.yaml:

     hostRules:
     - description: ''
      hosts:
       - '*'
     pathMatcher: matcher1
     pathMatchers:
    - defaultService: DEFAULT_SERVICE_URL
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: '/'
        routeAction:
         weightedBackendServices:
         - backendService: BACKEND_SERVICE_URL
           weight: 100
         requestMirrorPolicy:
           backendService: BACKEND_SERVICE_MIRROR_URL

DEFAULT_SERVICE_URL è l'URL predefinito per completamente gestito di Google Cloud.
BACKEND_SERVICE_URL è l'URL del backend mirroring.
BACKEND_SERVICE_MIRROR_URL è l'URL per di servizio di backend a cui esegui il mirroring.

Aggiorna la mappa URL:

gcloud compute url-maps import review-url-map \
    --source=review-url-map-config.yaml

Configura interruttore di circuito

L'interruzione di circuiti consente di impostare soglie di errore per impedire le richieste del client di sovraccaricare i tuoi backend. Quando le richieste raggiungono il limite che hai impostato, il client smette di consentire nuove connessioni o di inviare richieste aggiuntive, dando ai tuoi backend il tempo di recuperare.

Di conseguenza, l'interruzione di un circuito impedisce gli errori a cascata restituendo un errore al client, invece di sovraccaricare un backend. In questo modo una parte del traffico offerta e il tempo necessario per gestire la situazione di sovraccarico, ad esempio gestire un picco di traffico aumentando la capacità tramite la scalabilità automatica.

Nell'esempio seguente, gli interruttori di sicurezza vengono impostati come segue:

Numero massimo di richieste per connessione: 100
Numero massimo di connessioni: 1000
Numero massimo di richieste in attesa: 200
Numero massimo di richieste: 1000
Numero massimo di nuovi tentativi: 3

Per configurare l'interruzione di circuito, procedi nel seguente modo:

Console

Nella console Google Cloud, vai alla pagina Cloud Service Mesh.

Vai a Cloud Service Mesh
Fai clic sul nome del servizio di backend che vuoi aggiornare.
Fai clic su Modifica.
Fai clic su Configurazioni avanzate.
In Interruttori di sicurezza, seleziona la casella di controllo Abilita.
Fai clic su Modifica.
1. In Numero massimo di richieste per connessione, inserisci 100.
2. In Numero massimo di connessioni, inserisci 1000.
3. In N. massimo di richieste in attesa, inserisci 200.
4. In Max richieste, inserisci 1000.
5. In Numero massimo di nuovi tentativi, inserisci 3.
Fai clic su Salva e poi di nuovo su Salva.

gcloud

Esegui il comando gcloud export per esportare il servizio di backend configurazione. Sostituisci BACKEND_SERVICE_NAME con il nome del servizio di backend.
```
 gcloud compute backend-services export BACKEND_SERVICE_NAME \
     --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

Aggiorna il file BACKEND_SERVICE_NAME.yaml come segue:

 affinityCookieTtlSec: 0
 backends:
 - balancingMode: UTILIZATION
   capacityScaler: 1.0
    group:https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME
   maxUtilization: 0.8
 circuitBreakers:
   maxConnections: 1000
   maxPendingRequests: 200
   maxRequests: 1000
   maxRequestsPerConnection: 100
   maxRetries: 3
 connectionDraining:
   drainingTimeoutSec: 300
 healthChecks:
   - https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME
 loadBalancingScheme: INTERNAL_SELF_MANAGED
 localityLbPolicy: ROUND_ROBIN
 name: BACKEND_SERVICE_NAME
 port: 80
 portName: http
 protocol: HTTP
 sessionAffinity: NONE
 timeoutSec: 30

Aggiorna il file di configurazione del servizio di backend:

gcloud compute backend-services import BACKEND_SERVICE_NAME \
    --source=BACKEND_SERVICE_NAME-config.yaml --global

Configura l'affinità sessione in base a `HTTP_COOKIE`

La gestione avanzata del traffico consente di configurare l'affinità sessione in base un cookie fornito.

Per impostare l'affinità sessione utilizzando HTTP_COOKIE:

Console

Nella console Google Cloud, vai alla pagina Cloud Service Mesh.

Vai a Cloud Service Mesh
Fai clic sul nome del servizio di backend che vuoi aggiornare.
Fai clic su Modifica.
Fai clic su Configurazioni avanzate.
In Affinità sessione, seleziona Cookie HTTP.
In Criterio di bilanciamento del carico delle località, seleziona Hash di posta.
1. Nel campo Nome cookie HTTP, inserisci http_cookie.
2. Nel campo Percorso cookie HTTP, inserisci /cookie_path.
3. Nel campo TTL cookie HTTP, inserisci 100.
4. Nel campo Dimensione minima anello, inserisci 10000.
Fai clic su Salva.

gcloud

Esegui il comando gcloud export per esportare il servizio di backend configurazione. Sostituisci BACKEND_SERVICE_NAME con il nome del servizio di backend.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

Aggiorna il file YAML come segue:

sessionAffinity: 'HTTP_COOKIE'
localityLbPolicy: 'RING_HASH'
consistentHash:
httpCookie:
  name: 'http_cookie'
  path: '/cookie_path'
  ttl:
    seconds: 100
    nanos: 30
minimumRingSize: 10000

Importa il file di configurazione del servizio di backend:

gcloud compute backend-services import BACKEND_SERVICE_NAME \
    --source=BACKEND_SERVICE_NAME-config.yaml --global

Configura il rilevamento outlier

Il rilevamento outlier controlla l'eliminazione di host in stato non integro di bilanciamento del carico. Per farlo, Cloud Service Mesh utilizza un insieme di criteri che specificare i criteri per l'eliminazione di endpoint o VM di backend in stato non integro NEG, insieme ai criteri che definiscono quando viene preso in considerazione un backend o un endpoint abbastanza integro da ricevere di nuovo il traffico.

Nell'esempio seguente, il servizio di backend ha un gruppo di istanze come proprio backend. L'impostazione di rilevamento outlier specifica che il rilevamento outlier viene eseguita ogni secondo. Se un endpoint restituisce cinque elementi 5xx consecutivi errori, viene escluso dalla considerazione del bilanciamento del carico per 30 secondi per per la prima volta. Il tempo di espulsione reale per lo stesso endpoint è di 30 secondi moltiplicati per il numero di volte in cui viene espulso.

Per configurare il rilevamento outlier nella risorsa del servizio di backend, segui questi passaggi:

Console

Nella console Google Cloud, vai alla pagina Cloud Service Mesh.

Vai a Cloud Service Mesh
Fai clic sul nome di un servizio.
Fai clic su Modifica.
Fai clic su Configurazioni avanzate.
Seleziona la casella di controllo Rilevamento outlier.
Fai clic su Modifica.
1. Imposta Errori consecutivi su 5.
2. Imposta Intervallo su 1000 millisecondi.
3. Imposta Tempo di espulsione di base su 30000 millisecondi.
Fai clic su Salva e poi di nuovo su Salva.

gcloud

Esegui il comando gcloud export per esportare il servizio di backend configurazione. Sostituisci BACKEND_SERVICE_NAME con il nome del servizio di backend.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

Aggiorna il file YAML come segue, sostituendo il nome del servizio di backend per BACKEND_SERVICE_NAME:

name: BACKEND_SERVICE_NAME
loadBalancingScheme: INTERNAL_SELF_MANAGED
backends:
- balancingMode: UTILIZATION
 capacityScaler: 1.0
 group: $INSTANCE_GROUP_URL
healthChecks:
- $HEALTH_CHECK_URL
port: 80
portName: http
protocol: HTTP
outlierDetection:
 consecutiveErrors: 5,
 interval:
     seconds: 1,
     nanos: 0
 baseEjectionTime:
     seconds: 30,
     nanos: 0

Importa il file di configurazione del servizio di backend:

gcloud compute backend-services import BACKEND_SERVICE_NAME \
    --source=BACKEND_SERVICE_NAME-config.yaml --global

Impostare il criterio di bilanciamento del carico per le località

Utilizza il criterio di bilanciamento del carico per le località per scegliere un algoritmo di bilanciamento del carico in base al peso e alla priorità della località forniti da Cloud Service Mesh. Ad esempio, puoi eseguire il round robin ponderato tra endpoint integri o e l'hashing coerente.

Nell'esempio seguente, il servizio di backend ha un gruppo di istanze come e il suo backend. Il criterio di bilanciamento del carico per le località è impostato su RING_HASH.

Per impostare il criterio di bilanciamento del carico per le località:

Console

Nella console Google Cloud, vai alla pagina Cloud Service Mesh.

Vai a Cloud Service Mesh
Fai clic sul nome di un servizio.
Fai clic su Modifica.
Fai clic su Configurazioni avanzate.
In Criterio di traffico, nel Criterio di bilanciamento del carico delle località seleziona Hash circolare.
Fai clic su Salva.

gcloud

Esegui il comando gcloud export per esportare il servizio di backend configurazione. Sostituisci BACKEND_SERVICE_NAME con il nome del servizio di backend.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

Aggiorna il file BACKEND_SERVICE_NAME.yaml come segue:

name: shopping-cart-service
loadBalancingScheme: INTERNAL_SELF_MANAGED
backends:
- balancingMode: UTILIZATION
 capacityScaler: 1.0
 group: $INSTANCE_GROUP_URL
healthChecks:
- $HEALTH_CHECK_URL
port: 80
portName: http
protocol: HTTP
localityLbPolicy: RING_HASH

Importa il file di configurazione del servizio di backend:

gcloud compute backend-services import BACKEND_SERVICE_NAME \
    --source=BACKEND_SERVICE_NAME-config.yaml --global

Per saperne di più sul funzionamento del criterio di bilanciamento del carico per le località, consulta la documentazione per la risorsa backendService.

Configurazione del reindirizzamento URL

Queste istruzioni presuppongono quanto segue:

Il deployment di Cloud Service Mesh ha una mappa URL denominata review-url-map.
La mappa URL invia tutto il traffico a un solo servizio di backend chiamato review1, che funge da servizio di backend predefinito.
Vuoi reindirizzare il traffico da un host all'altro.

Per impostare il reindirizzamento di URL:

Console

Nella console Google Cloud, vai alla pagina Cloud Service Mesh.

Vai a Cloud Service Mesh
Fai clic su Mappe di regole di routing.
Fai clic su Crea mappa di regole di routing.
Nella pagina Crea una mappa di regole di routing, inserisci un Nome.
Nel menu Protocollo, seleziona HTTP.
Seleziona una regola di forwarding esistente.
In Regole di routing, seleziona Regola host, percorso e route avanzata.
In Corrispondenza host e percorso, fai clic su Aggiungi host e matcher percorso. Viene aggiunto un nuovo matcher di percorso che reindirizza il traffico.

Aggiungi le seguenti impostazioni al campo Matcher percorso:

    - defaultService: global/backendServices/review1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: ''
        urlRedirect:
         hostRedirect: '[REDIRECT_HOST]'
         pathRedirect: '[REDIRECT_URL]'
         redirectResponseCode: 'FOUND',
        stripQuery: True

Fai clic su Fine.
Fai clic su Salva.

gcloud

Esegui gcloud export. per ottenere la configurazione della mappa URL:

gcloud compute url-maps export review-url-map \
    --destination=review-url-map-config.yaml

Aggiungi la seguente sezione al file review-url-map-config.yaml:

     hostRules:
     - description: ''
      hosts:
       - '*'
     pathMatcher: matcher1
     pathMatchers:
    - defaultService: global/backendServices/review1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: ''
        urlRedirect:
         hostRedirect: '[REDIRECT_HOST]'
         pathRedirect: '[REDIRECT_URL]'
         redirectResponseCode: 'FOUND',
        stripQuery: True

Aggiorna la mappa URL:

gcloud compute url-maps import review-url-map \
    --source=review-url-map-config.yaml

Configura il reindirizzamento del traffico con la riscrittura dell'URL

L'indirizzamento del traffico ti consente di indirizzare il traffico a diversi servizi di backend in base agli attributi della richiesta, come i valori dell'intestazione. Inoltre, puoi configurare azioni come la riscrittura dell'URL nella richiesta prima che venga indirizzato al servizio di backend.

Nell'esempio seguente, la richiesta viene indirizzata a SERVICE_ANDROID_URL se il percorso della richiesta con prefisso /mobile/ e User-Agent della richiesta contengono Android. Prima di inviare la richiesta al servizio di backend, l'URL può essere cambiato in REWRITE_PATH_ANDROID, ad esempio /android/. Tuttavia, se il percorso ha il prefisso /mobile/ e ha un User-Agent contenente iPhone, il traffico viene indirizzato verso SERVICE_IPHONE_URL e il prefisso dell'URL è modificato in REWRITE_PATH_IPHONE. Tutte le altre richieste con prefisso /mobile/ e User-Agent con un valore diverso da Android o iPhone sono indirizzato a SERVICE_GENERIC_DEVICE_URL.

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*Android.*
         service: $[SERVICE_ANDROID_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_ANDROID]
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*iPhone.*
         service: [SERVICE_IPHONE_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_IPHONE]
       - matchRules:
         - prefixMatch: /mobile/
         service: [SERVICE_GENERIC_DEVICE_URL]

Configura fault injection

Fault injection ti consente di inserire una o entrambe le opzioni con un ritardo fisso o interruzione, chiamata interruzione, verso un particolare percorso per testare la resilienza di un un'applicazione.

Nell'esempio che segue, tutte le richieste vengono inviate a SERVICE_URL, con un un ritardo fisso di 10 secondi aggiunto al 100% delle richieste. Il client che invia richieste vede che tutte le risposte sono ritardate di 10 secondi. Inoltre, una fermata un errore con una risposta 503 Service Unavailable viene applicato al 50% richieste. Il cliente vede che il 50% delle sue richieste riceve una risposta 503. Queste richieste non raggiungono affatto il servizio di backend.

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: [SERVICE_URL]
            weight: 100
          faultInjectionPolicy:
            delay:
              fixedDelay:
                seconds: 10
                nanos: 0
              percentage: 100
            abort:
              httpStatus: 503
              percentage: 50

Imposta il filtro della configurazione in base alla corrispondenza di `MetadataFilters`

MetadataFilters sono abilitati con le regole di forwarding e HttpRouteRuleMatch. Utilizza questa funzione per controllare una particolare regola di forwarding o di route in modo che il piano di controllo invia la regola di forwarding o la regola di route solo ai proxy i metadati del nodo corrispondano all'impostazione del filtro dei metadati. Se non specifichi alcuna MetadataFilters, la regola viene inviata a tutti i proxy Envoy.

Questa funzionalità semplifica l'esecuzione del deployment graduale di una configurazione. Ad esempio, crea una regola di forwarding denominata forwarding-rule1, che vuoi il push viene eseguito solo verso Envoy i cui metadati dei nodi contengono app: review e version: canary.

Per aggiungere MetadataFilters a una regola di forwarding:

gcloud

Esegui il comando gcloud export per ottenere la configurazione delle regola di forwarding:

gcloud compute forwarding-rules export forwarding-rule1 \
    --destination=forwarding-rule1-config.yaml \
    --global

Elimina la regola di forwarding:

gcloud compute forwarding-rules delete forwarding-rule1 \
    --global

Aggiorna il file forwarding-rule1-config.yaml.

Nell'esempio seguente viene creato un filtro di metadati MATCH_ALL:

 metadataFilters:
 - filterMatchCriteria: 'MATCH_ALL'
   filterLabels:
   - name: 'app'
     value: 'review'
   - name: 'version'
     value: 'canary'

Nell'esempio seguente viene creato un filtro di metadati MATCH_ANY:

 metadataFilters:
 - filterMatchCriteria: 'MATCH_ANY'
   filterLabels:
   - name: 'app'
     value: 'review'
   - name: 'version'
     value: 'production'

Rimuovi tutti i campi di solo output da forwarding-rule1-config.yaml . Per ulteriori informazioni, consulta la documentazione su gcloud compute forwarding-rules import.

Esegui il comando gcloud import per aggiornare forwarding-rule1-config.yaml file:

gcloud compute forwarding-rules import forwarding-rule1 \
    --source=forwarding-rule1-config.yaml \
    --global

Utilizza queste istruzioni per aggiungere metadati dei nodi a Envoy prima di avviare Envoy. È supportato solo un valore di stringa.

a. Per un deployment basato su VM, in bootstrap_template.yaml, aggiungi nella sezione metadata:
```
   app: 'review'
   version: 'canary'
```
b. Per un deployment basato su Google Kubernetes Engine o Kubernetes, trafficdirector_istio_sidecar.yaml, aggiungi quanto segue nel campo Sezione env:
```
   - name: ISTIO_META_app
     value: 'review'
   - name: ISTIO_META_version
     value: 'canary'
```

Esempi di filtri dei metadati

Segui le istruzioni riportate di seguito per uno scenario in cui sono stati assegnati più progetti nella stessa rete VPC condiviso e vuoi che le risorse di Cloud Service Mesh siano visibili ai proxy nello stesso progetto.

La configurazione del VPC condiviso è la seguente:

Nome progetto host: vpc-host-project
Progetti di servizio: project1, project2
Servizi di backend con istanze di backend o endpoint che eseguono un'operazione conforme a xDS proxy in project1 e project2

Per configurare Cloud Service Mesh per isolare project1, segui questi passaggi:

gcloud

Crea tutte le regole di forwarding in project1 con i seguenti metadati filtro:

     metadataFilters:
     - filterMatchCriteria: 'MATCH_ALL'
       filterLabels
       - name: 'project_name'
         value: 'project1'
       - name: 'version'
         value: 'production'

Quando configuri i proxy di cui è stato eseguito il deployment in istanze o endpoint in project1, includi i seguenti metadati nella sezione dei metadati dei nodi del file di bootstrap:
```
   project_name: 'project1'
   version: 'production'
```
Verifica che i proxy di cui è già stato eseguito il deployment in project2 non abbiano ricevuto la regola di forwarding creata nel primo passaggio. Per farlo, prova ad accedere servizi in project1 da un sistema che esegue un proxy in project2. Per informazioni su come verificare che una configurazione di Cloud Service Mesh sia funzionano correttamente, vedi Verifica la configurazione.

Per testare una nuova configurazione su un sottoinsieme di proxy prima di renderla disponibile a tutti i proxy, segui questi passaggi:

gcloud

Avvia i proxy che stai utilizzando per i test con il seguente nodo metadati. Non includere questi metadati del nodo per i proxy che non sei per i test.
```
  version: 'test'
```

Per ogni nuova regola di forwarding che vuoi testare, includi quanto segue filtro dei metadati:

  metadataFilters:
  - filterMatchCriteria: 'MATCH_ALL'
    filterLabels:
    - name: 'version'
      value: 'test'

Testa la nuova configurazione inviando il traffico ai proxy di test e apporta le modifiche necessarie. Se la nuova configurazione funziona correttamente, i proxy testati ricevono la nuova configurazione. I restanti i proxy non ricevono la nuova configurazione e non possono utilizzarla.
Quando confermi che la nuova configurazione funziona correttamente, rimuovi l'elemento associato a un filtro di metadati. In questo modo tutti i proxy ricevono una nuova configurazione.

Risoluzione dei problemi

Utilizza queste informazioni per risolvere i problemi di traffico non instradato. in base alle regole di route e ai criteri di traffico che hai configurato.

Sintomi:

Aumento del traffico verso i servizi nelle regole sopra la regola in questione.
Aumento imprevisto delle risposte HTTP 4xx e 5xx per una determinata regola di route.

Soluzione: poiché le regole di route vengono interpretate in ordine di priorità, esamina la la priorità assegnata a ogni regola.

Quando definisci le regole di route, verifica che le regole con priorità più elevata (ovvero con i numeri con priorità più bassa) non instradare inavvertitamente il traffico che altrimenti verrebbero instradate da una regola di route successiva. Considera le nell'esempio seguente:

Prima regola di route
- Corrispondenza regola di route pathPrefix = /shopping/
- Azione di reindirizzamento: invia traffico al servizio di backend service-1
- Priorità regola: 4
Seconda regola di route
- Corrispondenza regola di route regexMatch = /shopping/cart/ordering/.*
- Azione di reindirizzamento: invia traffico al servizio di backend service-2
- Priorità regola: 8

In questo caso, una richiesta con percorso /shopping/cart/ordering/cart.html è indirizzato a service-1. Anche se la seconda regola avrebbe una corrispondenza, ignorato perché la prima regola aveva la priorità.

Blocca il traffico tra i servizi

Se vuoi bloccare il traffico tra il servizio A e il servizio B, e il tuo deployment è su GKE, configurare la sicurezza del servizio e utilizzare per bloccare il traffico tra i servizi. Per istruzioni complete, vedi Sicurezza del servizio Cloud Service Mesh e le istruzioni di configurazione con Envoy e gRPC senza proxy.

Passaggi successivi

Per risolvere i problemi di configurazione di Cloud Service Mesh, consulta Risoluzione dei problemi dei deployment che utilizzano Envoy.

Configura la gestione avanzata del traffico con Envoy

Prima di iniziare

Configurare la suddivisione del traffico

Console

gcloud

Configura una release parziale

Configura i deployment blu/verde

Configura il mirroring del traffico

Console

gcloud

Configura interruttore di circuito

Console

gcloud

Configura l'affinità sessione in base a HTTP_COOKIE

Console

gcloud

Configura il rilevamento outlier

Console

gcloud

Impostare il criterio di bilanciamento del carico per le località

Console

gcloud

Configurazione del reindirizzamento URL

Console

gcloud

Configura il reindirizzamento del traffico con la riscrittura dell'URL

Configura fault injection

Imposta il filtro della configurazione in base alla corrispondenza di MetadataFilters

gcloud

Esempi di filtri dei metadati

gcloud

gcloud

Risoluzione dei problemi

Blocca il traffico tra i servizi

Passaggi successivi

Configura l'affinità sessione in base a `HTTP_COOKIE`

Imposta il filtro della configurazione in base alla corrispondenza di `MetadataFilters`