Configurare la gestione avanzata del traffico con Envoy

La 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 informazioni su come configurare la gestione avanzata del traffico per i deployment di Cloud Service Mesh che utilizzano Envoy.

Prima di iniziare

Prima di configurare la gestione avanzata del traffico, segui le istruzioni riportate in Prepararsi a configurare Cloud Service Mesh con Envoy, inclusa la configurazione di Cloud Service Mesh e di eventuali host di macchine virtuali (VM) o cluster Google Kubernetes Engine (GKE) di cui hai bisogno. Crea le risorse Google Cloud richieste.

La disponibilità delle funzionalità di gestione del traffico avanzate varia in base al protocollo di richiesta scelto. Questo protocollo viene configurato quando configuri il routing utilizzando il proxy HTTP o HTTPS di destinazione, il proxy gRPC di destinazione o la risorsa proxy TCP di destinazione:

  • Con il proxy HTTP di destinazione e il proxy HTTPS di destinazione, sono disponibili tutte le funzionalità descritte 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.

Per saperne di più, consulta Funzionalità di Cloud Service Mesh e Gestione avanzata del traffico. Per una guida alla configurazione end-to-end, consulta Configurare la gestione avanzata del traffico con i servizi gRPC proxyless.

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 servizio di backend denominato review1, che funge da servizio di backend predefinito.
  • Hai intenzione di indirizzare il 5% del traffico a una nuova versione di un servizio. Il servizio è in esecuzione su un endpoint o una VM di backend in un gruppo di endpoint di rete (NEG) associato al servizio di backend review2.
  • Non vengono utilizzate regole host o corrispondenze di percorso.

Se stai suddividendo il traffico in base a un nuovo servizio a cui non è stato fatto riferimento in precedenza dalla mappa degli URL, aggiungi prima il nuovo servizio a weightedBackendServices e assegnagli un peso di 0. Poi, aumenta gradualmente il peso assegnato al servizio.

Per configurare la suddivisione del traffico:

Console

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

    Vai a Cloud Service Mesh

  2. Fai clic su Mappe di regole di routing.

  3. Fai clic su Crea mappa di regole di routing.

  4. Nella pagina Crea una mappa di regole di routing, inserisci un Nome.

  5. Nel menu Protocollo, seleziona HTTP.

  6. Seleziona una regola di forwarding esistente.

  7. In Regole di routing, seleziona Regola avanzata per host, percorso e route.

  8. In Matcher host e percorso, fai clic su Aggiungi matcher host e percorso. Viene aggiunto un nuovo corrispondenze dei percorsi che puoi configurare per suddividere il traffico.

  9. Aggiungi le seguenti impostazioni al campo Corrispondenza 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

  10. Fai clic su Fine.

  11. Fai clic su Salva.

Quando la nuova versione ti soddisfa, puoi regolare gradualmente i pesi dei due servizi e inviare tutto il traffico a review2.

gcloud

  1. Esegui il comando gcloud export per ottenere la configurazione della mappa degli URL:

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

  2. 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

  3. 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 regolare gradualmente i pesi dei due servizi e inviare tutto il traffico a review2.

Configurare una release parziale

Utilizza una procedura di implementazione parziale, a volte chiamata release canary, per rilasciare una nuova versione del software su una piccola parte di server prima di rilasciarla sul resto dei server di produzione.

Una release parziale utilizza weightedBackendServices. Per attivare una release parziale, designa un servizio di backend come servizio di test o canary e assegnagli un peso ridotto, ad esempio 2 o 5. Esegui il deployment della nuova versione del software solo su questi server. Quando hai verificato che la nuova versione è priva di problemi, esegui il deployment nel resto dei servizi.

  • Per attivare 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 il servizio.
  • BACKEND_SERVICE_PARTIAL_URL è l'URL del servizio di backend che riceve il 2% del traffico.
  • BACKEND_SERVICE_URL è l'URL del servizio di backend che riceve il 98% del traffico.

Configurare i deployment blu/verde

I deployment blu-verdi sono modelli di release che riducono il tempo necessario per trasferire il traffico di produzione a una nuova release di un servizio o a un rollback di una release precedente del servizio. Questi deployment mantengono entrambe le versioni del servizio disponibili in produzione e spostano il traffico da una all'altra.

I deployment blu/verde utilizzano weightedBackendServices. Nell'esempio YAML riportato di seguito, il deployment completo dei backend per SERVICE_BLUE_URL è stato eseguito con la release di produzione attuale e il deployment completo dei backend per SERVICE_GREEN_URL è stato eseguito con la nuova release. Nella configurazione dell'esempio, il deployment GREEN riceve il 100% del traffico di produzione. Se riscontri problemi, puoi invertire i pesi per i due implementazioni, annullando in modo efficace la release GREEN difettosa e reintegrando la release BLUE nota come valida. In entrambi i casi, il traffico può essere spostato rapidamente poiché entrambe le versioni sono disponibili per ricevere il 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 il servizio.
  • BACKEND_SERVICE_BLUE_URL è l'URL del servizio di backend che non riceve alcun traffico.
  • BACKEND_SERVICE_GREEN_URL è l'URL del servizio di backend che riceve il 100% del traffico.

Configurare il mirroring del traffico

Utilizza il mirroring del traffico quando vuoi che il traffico venga indirizzato a due diversi servizi di backend per eseguire il debug o testare 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 al client. MIRROR_SERVICE_URL non ha impatto sul client.

Per configurare il mirroring del traffico:

Console

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

    Vai a Cloud Service Mesh

  2. Fai clic su Mappe di regole di routing.

  3. Fai clic su Crea mappa di regole di routing.

  4. Nella pagina Crea una mappa di regole di routing, inserisci un Nome.

  5. Nell'elenco Protocollo, seleziona HTTP.

  6. Seleziona una regola di forwarding esistente.

  7. In Regole di routing, seleziona Regola avanzata per host, percorso e route.

  8. In Matcher host e percorso, fai clic su Aggiungi matcher host e percorso. Viene aggiunto un nuovo corrispettivo del percorso che puoi configurare per eseguire il mirroring del traffico.

  9. Aggiungi le seguenti impostazioni al campo Corrispondenza 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 il servizio.
    • BACKEND_SERVICE_URL è l'URL del backend sottoposto a mirroring.
    • BACKEND_SERVICE_MIRROR_URL è l'URL del servizio di backend di destinazione del mirroring.

  10. Fai clic su Fine.

  11. Fai clic su Salva.

gcloud

  1. Esegui il comando gcloud export per recuperare la configurazione della mappa degli URL:

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

  2. 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 il servizio.
    • BACKEND_SERVICE_URL è l'URL del backend sottoposto a mirroring.
    • BACKEND_SERVICE_MIRROR_URL è l'URL del servizio di backend di destinazione del mirroring.

  3. Aggiorna la mappa URL:

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

Configurare l'interruzione del circuito

L'interruttore di sicurezza ti consente di impostare soglie di errore per impedire alle richieste dei client di sovraccaricare i tuoi backend. Quando le richieste raggiungono un limite impostato, il client smette di consentire nuove connessioni o di inviare richieste aggiuntive, dando ai backend il tempo di recuperare.

Di conseguenza, l'interruttore di sicurezza impedisce gli errori a cascata restituendo un errore al client anziché sovraccaricare un backend. In questo modo, è possibile gestire parte del traffico, avendo al contempo il tempo di gestire la situazione di sovraccarico, ad esempio gestire un picco di traffico aumentando la capacità tramite la scalabilità automatica.

Nell'esempio seguente, imposti gli interruttori di sicurezza 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
  • Nuovi tentativi massimi: 3

Per configurare l'interruzione del circuito:

Console

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

    Vai a Cloud Service Mesh

  2. Fai clic sul nome del servizio di backend da aggiornare.

  3. Fai clic su Modifica.

  4. Fai clic su Configurazioni avanzate.

  5. In Dispositivi di sicurezza, seleziona la casella di controllo Attiva.

  6. Fai clic su Modifica.

    1. In Richieste massime per connessione, inserisci 100.
    2. In Connessioni massime, inserisci 1000.
    3. In Numero massimo di richieste in sospeso, inserisci 200.
    4. In Richieste massime, inserisci 1000.
    5. In Numero massimo di nuovi tentativi, inserisci 3.

  7. Fai clic su Salva e poi di nuovo su Salva.

gcloud

  1. Esegui il comando gcloud export per esportare la configurazione del servizio di backend. 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

  2. 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

  3. Aggiorna il file di configurazione del servizio di backend:

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

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

Per configurare l'affinità sessione utilizzando HTTP_COOKIE:

Console

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

    Vai a Cloud Service Mesh

  2. Fai clic sul nome del servizio di backend da aggiornare.

  3. Fai clic su Modifica.

  4. Fai clic su Configurazioni avanzate.

  5. In Affinità sessione, seleziona Cookie HTTP.

  6. In Criterio di bilanciamento del carico per le località, seleziona Hash ad anello.

    1. Nel campo Nome cookie HTTP, inserisci http_cookie.
    2. Nel campo Percorso cookie HTTP, inserisci /cookie_path.
    3. Nel campo TTL del cookie HTTP, inserisci 100.
    4. Nel campo Misura minima dell'anello, inserisci 10000.

  7. Fai clic su Salva.

gcloud

  1. Esegui il comando gcloud export per esportare la configurazione del servizio di backend. 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

  2. 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

  3. Importa il file di configurazione del servizio di backend:

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

Configurare il rilevamento degli outlier

Il rilevamento degli outlier controlla l'eliminazione di host in stato non integro dal pool di bilanciamento del carico. Cloud Service Mesh lo fa utilizzando un insieme di criteri che specificano i criteri per l'espulsione di endpoint o VM di backend non integri nei NEG, insieme ai criteri che definiscono quando un backend o un endpoint è considerato sufficientemente integro per ricevere nuovamente il traffico.

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

Per configurare il rilevamento degli outlier nella risorsa del servizio di backend:

Console

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

    Vai a Cloud Service Mesh

  2. Fai clic sul nome di un servizio.

  3. Fai clic su Modifica.

  4. Fai clic su Configurazioni avanzate.

  5. Seleziona la casella di controllo Rilevamento delle anomalie.

  6. 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.

  7. Fai clic su Salva e poi di nuovo su Salva.

gcloud

  1. Esegui il comando gcloud export per esportare la configurazione del servizio di backend. 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

  2. Aggiorna il file YAML come segue, sostituendo il nome del servizio di backend con 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

  3. Importa il file di configurazione del servizio di backend:

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

Imposta 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 basato sul peso e sulla priorità della località forniti da Cloud Service Mesh. Ad esempio, puoi eseguire il round robin ponderato tra gli endpoint sani o eseguire hashing coerente.

Nell'esempio seguente, il servizio di backend ha un gruppo di istanze come 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

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

    Vai a Cloud Service Mesh

  2. Fai clic sul nome di un servizio.

  3. Fai clic su Modifica.

  4. Fai clic su Configurazioni avanzate.

  5. In Criterio di traffico, nel menu Criterio di bilanciamento del carico per le località, seleziona Hash anello.

  6. Fai clic su Salva.

gcloud

  1. Esegui il comando gcloud export per esportare la configurazione del servizio di backend. 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

  2. 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

  3. 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 ulteriori informazioni sul funzionamento del criterio di bilanciamento del carico per località, consulta la documentazione della 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 servizio di backend denominato review1, che funge da servizio di backend predefinito.
  • Vuoi reindirizzare il traffico da un host all'altro.

Per configurare il reindirizzamento dell'URL:

Console

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

    Vai a Cloud Service Mesh

  2. Fai clic su Mappe di regole di routing.

  3. Fai clic su Crea mappa di regole di routing.

  4. Nella pagina Crea una mappa di regole di routing, inserisci un Nome.

  5. Nel menu Protocollo, seleziona HTTP.

  6. Seleziona una regola di forwarding esistente.

  7. In Regole di routing, seleziona Regola avanzata per host, percorso e route.

  8. In Matcher host e percorso, fai clic su Aggiungi matcher host e percorso. Viene aggiunto un nuovo corrispondenze dei percorsi che reindirizza il traffico.

  9. Aggiungi le seguenti impostazioni al campo Corrispondenza percorso:

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

  10. Fai clic su Fine.

  11. Fai clic su Salva.

gcloud

  1. Esegui il comando gcloud export per recuperare la configurazione della mappa degli URL:

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

  2. 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

  3. Aggiorna la mappa URL:

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

Configurare l'indirizzamento del traffico con la riscrittura dell'URL

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

Nell'esempio seguente, la richiesta è indirizzata a SERVICE_ANDROID_URL se il percorso della richiesta contiene il prefisso /mobile/ e il User-Agent della richiesta contiene Android. Prima di inviare la richiesta al servizio di backend, il prefisso dell'URL può essere sostituito da REWRITE_PATH_ANDROID, ad esempio /android/. Tuttavia, se il percorso contiene il prefisso /mobile/ e ha un User-Agent contenente iPhone, il traffico viene indirizzato a SERVICE_IPHONE_URL e il prefisso dell'URL viene modificato in REWRITE_PATH_IPHONE. Tutte le altre richieste con prefisso /mobile/ e con User-Agent con un valore diverso da Android o iPhone vengono indirizzate 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]

Configurare l'iniezione di errori

La fault injection ti consente di iniettare uno o entrambi i ritardi fissi o un interruzione forzata, chiamata interruzione, in un determinato percorso per testare la resilienza di un'applicazione.

Nell'esempio che segue, tutte le richieste vengono inviate a SERVICE_URL, con un ritardo fisso di 10 secondi aggiunto al 100% delle richieste. Il client che invia le richieste vede che tutte le risposte sono in ritardo di 10 secondi. Inoltre, al 50% delle richieste viene applicato un errore di interruzione con una risposta Service Unavailable 503. Il client vede che il 50% delle 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

Configurare il filtro della configurazione in base alla corrispondenza di MetadataFilters

MetadataFilters sono abilitati con le regole di inoltro e HttpRouteRuleMatch. Utilizza questa funzionalità per controllare una determinata regola di forwarding o route in modo che il control plane invii la regola di forwarding o route solo ai proxy i cui metadati del nodo corrispondono all'impostazione del filtro dei metadati. Se non specifichi alcun valore per MetadataFilters, la regola viene inviata a tutti i proxy Envoy.

Questa funzionalità semplifica l'esecuzione di un deployment graduale di una configurazione. Ad esempio, crea una regola di forwarding denominata forwarding-rule1, che vuoi spingere solo agli Envoy i cui metadati del nodo contengono app: review e version: canary.

Per aggiungere MetadataFilters a una regola di forwarding:

gcloud

  1. Esegui il comando gcloud export per ottenere la configurazione della regola di forwarding:

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

  2. Elimina la regola di forwarding:

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

  3. Aggiorna il file forwarding-rule1-config.yaml.

    L'esempio seguente crea un filtro dei metadati MATCH_ALL:

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

    L'esempio seguente crea un filtro dei metadati MATCH_ANY:

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

  4. Rimuovi tutti i campi di sola uscita dal forwarding-rule1-config.yaml file. Per ulteriori informazioni, consulta la documentazione di gcloud compute forwarding-rules import.

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

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

  6. Segui queste istruzioni per aggiungere i metadati del nodo a Envoy prima di avviarlo. È supportato solo un valore di stringa.

    a. Per un deployment basato su VM, in bootstrap_template.yaml, aggiungi quanto segue nella sezione metadata:

       app: 'review'
   version: 'canary'

    b. Per un deployment basato su Google Kubernetes Engine o Kubernetes, in trafficdirector_istio_sidecar.yaml, aggiungi quanto segue nella 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 più progetti si trovano nella stessa rete VPC condiviso e vuoi che le risorse Cloud Service Mesh di ogni progetto siano visibili ai proxy nello stesso progetto.

La configurazione della rete VPC condivisa è la seguente:

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

Per configurare Cloud Service Mesh in modo da isolare project1:

gcloud

  1. Crea tutte le regole di inoltro in project1 con il seguente filtro dei metadati:

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

  2. Quando configuri i proxy di cui è stato eseguito il deployment in istanze o endpoint in project1, includi i seguenti metadati nella sezione dei metadati del nodo del file di bootstrap:

       project_name: 'project1'
   version: 'production'

  3. Verifica che i proxy già di cui è stato eseguito il deployment in project2 non abbiano ricevuto la regola di forwarding creata nel primo passaggio. A questo scopo, prova ad accedere ai servizi in project1 da un sistema che esegue un proxy in project2. Per informazioni su come verificare che una configurazione di Cloud Service Mesh funzioni correttamente, consulta Verificare la configurazione.

Per testare una nuova configurazione su un sottoinsieme di proxy prima di renderla disponibile per tutti i proxy:

gcloud

  1. Avvia i proxy che utilizzi per i test con i seguenti metadati del nodo. Non includere questi metadati dei nodi per i proxy che non utilizzi per i test.

      version: 'test'

  2. Per ogni nuova regola di forwarding che vuoi testare, includi il seguente filtro dei metadati:

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

  3. Testa la nuova configurazione inviando traffico ai proxy di test e apporta le modifiche necessarie. Se la nuova configurazione funziona correttamente, solo i proxy che testi la ricevono. I proxy rimanenti non ricevono la nuova configurazione e non sono in grado di utilizzarla.

  4. Dopo aver verificato che la nuova configurazione funzioni correttamente, rimuovi il filtro dei metadati associato. In questo modo tutti i proxy riceveranno la nuova configurazione.

Risoluzione dei problemi

Utilizza queste informazioni per risolvere i problemi relativi al routing del traffico in base alle regole di routing e ai criteri di traffico che hai configurato.

Sintomi:

  • Aumento del traffico verso i servizi nelle regole precedenti a quella in questione.
  • Un aumento imprevisto delle risposte HTTP 4xx e 5xx per una determinata regola di route.

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

Quando definisci le regole di route, assicurati che le regole con priorità più elevata (ovvero con numeri di priorità più bassi) non indirizzino inavvertitamente il traffico che altrimenti sarebbe stato indirizzato da una regola di route successiva. Considera l'esempio seguente:

  • Prima regola di route

    • Corrispondenza regola route pathPrefix = /shopping/
    • Azione di reindirizzamento: invia il traffico al servizio di backend service-1
    • Priorità regola: 4

  • Seconda regola di route

    • Corrispondenza regola route regexMatch = /shopping/cart/ordering/.*
    • Azione di reindirizzamento: invia il traffico al servizio di backend service-2
    • Priorità regola: 8

In questo caso, una richiesta con il percorso /shopping/cart/ordering/cart.html viene indirizzata a service-1. Anche se la seconda regola avrebbe generato una corrispondenza, viene ignorata perché la prima regola aveva la priorità.

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