Configurare la gestione avanzata del traffico con Envoy
La configurazione è supportata per i clienti in anteprima, ma non è consigliata per i nuovi utenti di Cloud Service Mesh. Per maggiori informazioni, consulta la panoramica del routing del servizio Cloud Service Mesh.
Questo documento fornisce informazioni su come configurare la gestione avanzata del traffico per i deployment Cloud Service Mesh che utilizzano Envoy.
Prima di iniziare
Prima di configurare la gestione avanzata del traffico, segui le istruzioni in Prepararsi per la configurazione di 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. Creare le risorse Google Cloud richieste.
La disponibilità delle funzionalità di gestione avanzata del traffico varia a seconda del 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 maggiori informazioni, 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 servizi gRPC senza proxy.
Configura la suddivisione del traffico
Queste istruzioni presuppongono quanto segue:
- Il deployment del mesh di servizi Cloud ha una mappa URL chiamata
review-url-map
. - La mappa URL invia tutto il traffico a un servizio di backend denominato
review1
, che funge da servizio di backend predefinito. - Prevedi di indirizzare il 5% del traffico a una nuova versione di un servizio. Il servizio è in esecuzione su una VM o un endpoint di backend in un gruppo di endpoint di rete (NEG) associato al servizio di backend
review2
. - Non vengono utilizzati matcher percorso o regole host.
Se suddividi il traffico in un nuovo servizio a cui la mappa URL non fa riferimento in precedenza, aggiungi innanzitutto il nuovo servizio a weightedBackendServices
e assegnagli una ponderazione pari a 0
. Quindi, aumenta gradualmente il peso assegnato al servizio.
Per configurare la suddivisione del traffico:
Console
Nella console Google Cloud, vai alla pagina 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 Matcher host e percorso, fai clic su
Aggiungi matcher host e 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 le ponderazioni dei due servizi e alla fine inviare tutto il traffico a review2
.
gcloud
Esegui il comando
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 degli URL:
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
Quando la nuova versione ti soddisfa, puoi modificare gradualmente le ponderazioni dei due servizi e alla fine inviare tutto il traffico a review2
.
Configurare una release parziale
Utilizza un processo di deployment parziale, a volte chiamato canarying, per rilasciare una nuova versione del software su una piccola parte di server prima di rilasciare la nuova versione sul bilanciamento dei server di produzione.
Una release parziale utilizza weightedBackendServices
. Per abilitare una release parziale,
specifica un servizio di backend come servizio di test, o canary, e assegnagli una ponderazione ridotta, ad esempio 2 o 5. Esegui il deployment della nuova versione
del software solo su questi server. Quando hai la certezza che la nuova versione sia priva di problemi, esegui il deployment sul resto dei 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 del 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.
Configura i deployment blu/verde
I deployment blu/verde sono modelli di rilascio che riducono il tempo necessario per trasferire il traffico di produzione a una nuova release di un servizio o al rollback di una release precedente del servizio. Questi deployment mantengono entrambe le versioni del servizio disponibili in produzione e spostano il traffico dall'una all'altra.
I deployment blu/verde utilizzano weightedBackendServices
. Nell'esempio YAML che segue, il deployment completo dei backend in SERVICE_BLUE_URL
è stato eseguito con la release di produzione attuale e dei backend in SERVICE_GREEN_URL
con la nuova release. Nella configurazione dell'esempio, il deployment GREEN
riceve il 100% del traffico di produzione. Se riscontri problemi, puoi invertire le ponderazioni per i due deployment, in modo da ripristinare la release GREEN
con problemi e reintegrare la release BLUE
valida nota. In entrambi i casi, il traffico può essere spostato rapidamente perché entrambe le versioni sono disponibili per ricevere traffico.
- Per abilitare un deployment blu/verde, usa 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 del servizio.BACKEND_SERVICE_BLUE_URL
è l'URL del servizio di backend che non riceve il tuo traffico.BACKEND_SERVICE_GREEN_URL
è l'URL del servizio di backend che riceve il 100% del tuo traffico.
Configurare il mirroring del traffico
Utilizza il mirroring del traffico quando vuoi che il traffico sia indirizzato a due servizi di backend diversi allo scopo di 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 inviate al client. 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.
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 Matcher host e percorso, fai clic su
Aggiungi matcher host e percorso. Viene aggiunto un nuovo matcher 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 del servizio.BACKEND_SERVICE_URL
è l'URL per il backend di cui viene eseguito il mirroring.BACKEND_SERVICE_MIRROR_URL
è l'URL del servizio di backend a cui esegui il mirroring.
Fai clic su Fine.
Fai clic su Salva.
gcloud
Esegui il comando
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 del servizio.BACKEND_SERVICE_URL
è l'URL per il backend di cui viene eseguito il mirroring.BACKEND_SERVICE_MIRROR_URL
è l'URL del servizio di backend a cui esegui il mirroring.
Aggiorna la mappa degli URL:
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
Imposta interruzione di sicurezza
L'interruzione di circuito consente di impostare soglie di errore per evitare che le richieste del client sovraccarichino i backend. Quando le richieste raggiungono un limite 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 circuito previene gli errori a cascata restituendo un errore al client anziché sovraccaricare un backend. Ciò consente di pubblicare una parte del traffico fornendo al contempo il tempo necessario per gestire la situazione di sovraccarico, ad esempio per 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:
Console
Nella console Google Cloud, vai alla pagina 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.- In Numero massimo di richieste per connessione, inserisci
100
. - In Numero massimo di connessioni, inserisci
1000
. - In Numero massimo di richieste in attesa, inserisci
200
. - In Numero massimo di richieste, inserisci
1000
. - In Numero massimo di nuovi tentativi, inserisci
3
.
- In Numero massimo di richieste per connessione, inserisci
Fai clic su Salva e poi di nuovo su Salva.
gcloud
Esegui il comando
gcloud export
per esportare la configurazione del servizio di backend. SostituisciBACKEND_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 a un cookie fornito.
Per configurare l'affinità sessione utilizzando HTTP_COOKIE
:
Console
Nella console Google Cloud, vai alla pagina 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 ad anello.
- Nel campo Nome cookie HTTP, inserisci
http_cookie
. - Nel campo Percorso cookie HTTP, inserisci
/cookie_path
. - Nel campo TTL cookie HTTP, inserisci
100
. - Nel campo Dimensioni minime anello, inserisci
10000
.
- Nel campo Nome cookie HTTP, inserisci
Fai clic su Salva.
gcloud
Esegui il comando
gcloud export
per esportare la configurazione del servizio di backend. SostituisciBACKEND_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 degli host in stato non integro dal pool di bilanciamento del carico. Per farlo, Cloud Service Mesh utilizza un insieme di criteri che specificano i criteri per l'eliminazione di VM o endpoint del backend in stato non integro dai NEG, insieme ai criteri che definiscono quando un backend o un endpoint viene considerato integro per ricevere di nuovo il traffico.
Nell'esempio seguente, il servizio di backend ha un gruppo di istanze come backend. L'impostazione di rilevamento outlier specifica che
l'analisi di rilevamento outlier viene eseguita ogni secondo. Se un endpoint restituisce cinque errori 5xx
consecutivi, viene escluso dalla considerazione del bilanciamento del carico per 30 secondi per la prima volta. Il tempo di espulsione reale per lo stesso endpoint è pari a 30 secondi volte il numero di volte in cui viene espulso.
Per configurare il rilevamento di outlier nella risorsa del servizio di backend, segui questi passaggi:
Console
Nella console Google Cloud, vai alla pagina 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.- Imposta Errori consecutivi su
5
. - Imposta Intervallo su
1000
millisecondi. - Imposta il Tempo di espulsione di base su
30000
millisecondi.
- Imposta Errori consecutivi su
Fai clic su Salva e poi di nuovo su Salva.
gcloud
Esegui il comando
gcloud export
per esportare la configurazione del servizio di backend. SostituisciBACKEND_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 conBACKEND_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
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 in base al peso e alla priorità delle località forniti da Cloud Service Mesh. Ad esempio, puoi eseguire round robin ponderato tra endpoint integri o eseguire un 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à, segui questi passaggi:
Console
Nella console Google Cloud, vai alla pagina Cloud Service Mesh.
Fai clic sul nome di un servizio.
Fai clic su
Modifica.Fai clic su Configurazioni avanzate.
In Criterio di traffico, nel menu Criterio di bilanciamento del carico delle località, seleziona Hash circolare.
Fai clic su Salva.
gcloud
Esegui il comando
gcloud export
per esportare la configurazione del servizio di backend. SostituisciBACKEND_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 ulteriori informazioni su come funziona il 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 del mesh di servizi Cloud ha una mappa URL chiamata
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 a un altro.
Per impostare il reindirizzamento degli URL, procedi nel seguente modo:
Console
Nella console Google Cloud, vai alla pagina 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 Matcher host e percorso, fai clic su
Aggiungi matcher host e percorso. Viene aggiunto un nuovo matcher 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 il comando
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 degli 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 a 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 un prefisso /mobile/
e il User-Agent
della richiesta contiene Android
. Prima di inviare la richiesta al servizio di backend, il prefisso URL può essere modificato in REWRITE_PATH_ANDROID
, ad esempio /android/
. Tuttavia,
se il percorso ha un prefisso /mobile/
e ha un User-Agent
contenente
iPhone
, il traffico viene indirizzato a SERVICE_IPHONE_URL
e il prefisso dell'URL viene
cambiato in REWRITE_PATH_IPHONE
. Tutte le altre richieste che hanno un prefisso con /mobile/
e che presentano un valore 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]
Configura fault injection
La Fault injection consente di inserire uno o entrambi un ritardo fisso o un arresto forzato, chiamato interruzione, in una determinata route per testare la resilienza di un'applicazione.
Nell'esempio riportato di seguito, 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 ritardate di 10 secondi. Inoltre, al 50% delle richieste viene applicato un errore di arresto con una risposta Service Unavailable
503. Il client vede che il 50% delle richieste riceve una risposta 503.
Queste richieste non raggiungono in alcun modo 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
Configura il filtro della configurazione in base alla corrispondenza di MetadataFilters
MetadataFilters
sono attivate con le regole di forwarding e HttpRouteRuleMatch
.
Utilizza questa funzionalità per controllare una determinata regola di forwarding o di route in modo che il piano di controllo la invii solo ai proxy i cui metadati dei nodi corrispondono all'impostazione del filtro dei metadati. Se non specifichi un valore 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
, di cui vuoi eseguire il push solo agli 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 della 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 per i metadati
MATCH_ALL
:metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'canary'
Nell'esempio seguente viene creato un filtro per i metadati
MATCH_ANY
:metadataFilters: - filterMatchCriteria: 'MATCH_ANY' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'production'
Rimuovi tutti i campi solo di output dal file
forwarding-rule1-config.yaml
. Per saperne di più, consulta la documentazione relativa agcloud compute forwarding-rules import
.Esegui il comando
gcloud import
per aggiornare il fileforwarding-rule1-config.yaml
: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 stringa.
a. Per un deployment basato su VM, in
bootstrap_template.yaml
, aggiungi quanto segue nella sezionemetadata
:app: 'review' version: 'canary'
b. Per un deployment basato su Google Kubernetes Engine o Kubernetes, in
trafficdirector_istio_sidecar.yaml
aggiungi quanto segue nella sezioneenv
:- name: ISTIO_META_app value: 'review' - name: ISTIO_META_version value: 'canary'
Esempi di filtro dei metadati
Utilizza le seguenti istruzioni 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 di servizio siano visibili ai proxy dello 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 proxy compatibile con xDS in
project1
eproject2
Per configurare Cloud Service Mesh per isolare project1
, segui questi passaggi:
gcloud
Crea tutte le regole di forwarding in
project1
con il seguente filtro per metadati: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 ai servizi inproject1
da un sistema che esegue un proxy inproject2
. Per informazioni su come verificare il corretto funzionamento di una configurazione Cloud Service Mesh, consulta Verifica della configurazione.
Per testare una nuova configurazione su un sottoinsieme di proxy prima di renderla disponibile per tutti i proxy, segui questi passaggi:
gcloud
Avvia i proxy che utilizzi per i test con i seguenti metadati dei nodi. Non includere questi metadati dei nodi per i proxy che non utilizzi per i test.
version: 'test'
Per ogni nuova regola di forwarding che vuoi testare, includi il seguente filtro di 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, solo i proxy che testi ricevono la nuova configurazione. I proxy rimanenti non ricevono la nuova configurazione e non sono in grado di utilizzarla.
Quando confermi che la nuova configurazione funziona correttamente, rimuovi il filtro dei metadati associato. In questo modo tutti i proxy ricevono la nuova configurazione.
Risoluzione dei problemi
Utilizza queste informazioni per risolvere i problemi quando il traffico non viene 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.
- Un aumento imprevisto delle risposte HTTP
4xx
e5xx
per una determinata regola di route.
Soluzione: poiché le regole di route vengono interpretate in ordine di priorità, rivedi la priorità assegnata a ogni regola.
Quando definisci le regole di route, verifica che le regole con priorità più alta (ovvero con numeri di priorità inferiore) non instradano inavvertitamente il traffico che altrimenti sarebbe stato instradato da una regola di route successiva. Considera il seguente esempio:
Prima regola di route
- Prefisso percorso di corrispondenza della regola di route =
/shopping/
- Azione di reindirizzamento: invia il traffico al servizio di backend
service-1
- Priorità regola:
4
- Prefisso percorso di corrispondenza della regola di route =
Seconda regola di route
- Corrispondenza regola di route regexMatch =
/shopping/cart/ordering/.*
- Azione di reindirizzamento: invia il traffico al servizio di backend
service-2
- Priorità regola:
8
- Corrispondenza regola di route regexMatch =
In questo caso, una richiesta con il percorso /shopping/cart/ordering/cart.html
viene instradata a service-1
. Anche se verrebbe trovata una corrispondenza per la seconda regola, viene
ignorata 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 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 Sicurezza del servizio Traffic Director 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.