O Cloud Service Mesh e o Traffic Director são agora o Cloud Service Mesh. Para mais informações, consulte a vista geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

Configure a gestão avançada de tráfego com o Envoy

A configuração é suportada para clientes de pré-visualização, mas não a recomendamos para novos utilizadores do Cloud Service Mesh. Para mais informações, consulte a vista geral do encaminhamento de serviços do Cloud Service Mesh.

Este documento fornece informações sobre como configurar a gestão de tráfego avançada para implementações do Cloud Service Mesh que usam o Envoy.

Antes de começar

Antes de configurar a gestão de tráfego avançada, siga as instruções em Prepare-se para configurar a Cloud Service Mesh com o Envoy, incluindo a configuração da Cloud Service Mesh e de quaisquer anfitriões de máquinas virtuais (VMs) ou clusters do Google Kubernetes Engine (GKE) de que precisa. Crie os recursos Google Cloud necessários.

A disponibilidade da funcionalidade de gestão de tráfego avançada difere consoante o protocolo de pedido que escolher. Este protocolo é configurado quando configura o encaminhamento através do proxy HTTP ou HTTPS de destino, do proxy gRPC de destino ou do recurso de proxy TCP de destino:

Com o proxy HTTP de destino e o proxy HTTPS de destino, todas as funcionalidades descritas neste documento estão disponíveis.
Com o proxy gRPC de destino, algumas funcionalidades estão disponíveis.
Com o proxy TCP de destino, não estão disponíveis funcionalidades avançadas de gestão de tráfego.

Para mais informações, consulte as funcionalidades da Cloud Service Mesh e a gestão avançada de tráfego. Para um guia de configuração ponto a ponto, consulte o artigo Configure a gestão avançada de tráfego com serviços gRPC sem proxy.

Configure a divisão de tráfego

Estas instruções pressupõem o seguinte:

A sua implementação do Cloud Service Mesh tem um mapa de URLs denominado review-url-map.
O mapa de URLs envia todo o tráfego para um serviço de back-end denominado review1, que funciona como o serviço de back-end predefinido.
Planeia encaminhar 5% do tráfego para uma nova versão de um serviço. Esse serviço está a ser executado numa VM ou num ponto final de back-end num grupo de pontos finais da rede (NEG) associado ao serviço de back-end review2.
Não são usadas regras de anfitrião nem correspondências de caminhos.

Se estiver a dividir o tráfego para um novo serviço que não tenha sido referenciado pelo mapa de URLs anteriormente, adicione primeiro o novo serviço a weightedBackendServices e atribua-lhe um peso de 0. Em seguida, aumente gradualmente o peso atribuído a esse serviço.

Para configurar a divisão de tráfego, siga estes passos:

Consola

Na Google Cloud consola, aceda à página Cloud Service Mesh.

Aceda ao Cloud Service Mesh
Clique em Mapeamentos de regras de encaminhamento.
Clique em Criar mapa de regras de encaminhamento.
Na página Criar um mapa de regras de encaminhamento, introduza um Nome.
No menu Protocolo, selecione HTTP.
Selecione uma regra de encaminhamento existente.
Em Regras de encaminhamento, selecione Regra avançada de anfitrião, caminho e rota.
Em Anfitriões e correspondências de caminhos, clique em Adicionar anfitriões e correspondência de caminhos. Isto adiciona um novo correspondente de caminhos que pode configurar para dividir o tráfego.

Adicione as seguintes definições ao campo Correspondência de caminhos:

    - 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

Clique em Concluído.
Clique em Guardar.

Quando estiver satisfeito com a nova versão, pode ajustar gradualmente as ponderações dos dois serviços e, eventualmente, enviar todo o tráfego para review2.

gcloud

Execute o comando gcloud export para obter a configuração do mapa de URLs:

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

Adicione a seguinte secção ao ficheiro 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

Atualize o mapa de URLs:

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

Quando estiver satisfeito com a nova versão, pode ajustar gradualmente as ponderações dos dois serviços e, eventualmente, enviar todo o tráfego para review2.

Configure um lançamento parcial

Use um processo de implementação parcial, por vezes denominado canarying, para lançar uma nova versão de software para uma pequena fração de servidores antes de lançar a nova versão para o resto dos seus servidores de produção.

Um lançamento parcial usa o weightedBackendServices. Para ativar uma versão parcial, designe um serviço de back-end como o serviço de teste ou canary e atribua-lhe um peso baixo, por exemplo, 2 ou 5. Implemente a nova versão do software apenas nesses servidores. Quando tiver a certeza de que a nova versão não tem problemas, implemente-a nos restantes serviços.

Para ativar uma versão parcial, use o seguinte exemplo de código 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 é o URL predefinido do seu serviço.
BACKEND_SERVICE_PARTIAL_URL é o URL do serviço de back-end que recebe 2% do tráfego.
BACKEND_SERVICE_URL é o URL do serviço de back-end que recebe 98% do tráfego.

Configure implementações azul-verde

As implementações azul-verde são modelos de lançamento que reduzem o tempo necessário para mudar o tráfego de produção para um novo lançamento de um serviço ou para uma reversão de um lançamento anterior do serviço. Estas implementações mantêm ambas as versões do serviço disponíveis em produção e transferem o tráfego de uma para a outra.

As implementações azul-verde usam weightedBackendServices. No exemplo de YAML que se segue, os back-ends para SERVICE_BLUE_URL estão totalmente implementados com o lançamento de produção atual e os back-ends para SERVICE_GREEN_URL estão totalmente implementados com o novo lançamento. Na configuração do exemplo, a implementação GREEN recebe 100% do tráfego de produção. Se encontrar problemas, pode inverter as ponderações para as duas implementações, o que reverte eficazmente a versão GREEN com defeito e repõe a versão BLUE conhecida como boa. Em qualquer dos casos, o tráfego pode ser alterado rapidamente porque ambas as versões estão disponíveis para receber tráfego.

Para ativar uma implementação azul-verde, use o seguinte exemplo de código 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 é o URL predefinido do seu serviço.
BACKEND_SERVICE_BLUE_URL é o URL do serviço de back-end que não recebe nenhum do seu tráfego.
BACKEND_SERVICE_GREEN_URL é o URL do serviço de back-end que recebe 100% do seu tráfego.

Configure o espelhamento de tráfego

Use a replicação de tráfego quando quiser que o tráfego seja direcionado para dois serviços de back-end diferentes para fins de depuração ou teste de novos serviços.

No exemplo seguinte, todos os pedidos são enviados para SERVICE_URL e para MIRROR_SERVICE_URL. Apenas as respostas de SERVICE_URL são enviadas de volta ao cliente. MIRROR_SERVICE_URL não tem impacto no cliente.

Para configurar a replicação de tráfego, siga estes passos:

Consola

Na Google Cloud consola, aceda à página Cloud Service Mesh.

Aceda ao Cloud Service Mesh
Clique em Mapeamentos de regras de encaminhamento.
Clique em Criar mapa de regras de encaminhamento.
Na página Criar um mapa de regras de encaminhamento, introduza um Nome.
Na lista Protocolo, selecione HTTP.
Selecione uma regra de encaminhamento existente.
Em Regras de encaminhamento, selecione Regra avançada de anfitrião, caminho e rota.
Em Anfitriões e correspondências de caminhos, clique em Adicionar anfitriões e correspondência de caminhos. Isto adiciona um novo correspondente de caminho que pode configurar para duplicar o tráfego.

Adicione as seguintes definições ao campo Correspondência de caminhos:

    - 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 é o URL predefinido do seu serviço.
BACKEND_SERVICE_URL é o URL do back-end duplicado.
BACKEND_SERVICE_MIRROR_URL é o URL do serviço de back-end que espelha.

Clique em Concluído.
Clique em Guardar.

gcloud

Execute o comando gcloud export para obter a configuração do mapa de URLs:

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

Adicione a seguinte secção ao ficheiro 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 é o URL predefinido do seu serviço.
BACKEND_SERVICE_URL é o URL do back-end duplicado.
BACKEND_SERVICE_MIRROR_URL é o URL do serviço de back-end que espelha.

Atualize o mapa de URLs:

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

Configure a interrupção de circuito

A interrupção de circuitos permite-lhe definir limites de falhas para evitar que os pedidos de clientes sobrecarreguem os seus back-ends. Depois de os pedidos atingirem um limite que definiu, o cliente deixa de permitir novas ligações ou enviar pedidos adicionais, dando aos seus back-ends tempo para recuperar.

Como resultado, a interrupção de circuitos impede falhas em cascata devolvendo um erro ao cliente em vez de sobrecarregar um back-end. Isto permite que algum tráfego seja apresentado, ao mesmo tempo que dá tempo para gerir a situação de sobrecarga, como lidar com um pico de tráfego aumentando a capacidade através do dimensionamento automático.

No exemplo seguinte, define os disjuntores da seguinte forma:

Máximo de pedidos por ligação: 100
Número máximo de associações: 1000
Máximo de pedidos pendentes: 200
Pedidos máximos: 1000
Máximo de novas tentativas: 3

Para configurar a interrupção de circuito, siga estes passos:

Consola

Na Google Cloud consola, aceda à página Cloud Service Mesh.

Aceda ao Cloud Service Mesh
Clique no nome do serviço de back-end que quer atualizar.
Clique em Editar.
Clique em Configurações avançadas.
Em Disjuntores, selecione a caixa de verificação Ativar.
Clique em Editar.
1. Em Máximo de pedidos por ligação, introduza 100.
2. Em Ligações máximas, introduza 1000.
3. Em Máximo de pedidos pendentes, introduza 200.
4. Em Pedidos máximos, introduza 1000.
5. Em Máximo de tentativas, introduza 3.
Clique em Guardar e, de seguida, clique novamente em Guardar.

gcloud

Execute o comando gcloud export para exportar a configuração do serviço de back-end. Substitua BACKEND_SERVICE_NAME pelo nome do serviço de back-end.
```
 gcloud compute backend-services export BACKEND_SERVICE_NAME \
     --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

Atualize o ficheiro BACKEND_SERVICE_NAME.yaml da seguinte forma:

 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

Atualize o ficheiro de configuração do serviço de back-end:

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

Configure a afinidade de sessão com base em `HTTP_COOKIE`

A gestão avançada de tráfego permite-lhe configurar a afinidade de sessão com base num cookie fornecido.

Para configurar a afinidade de sessão através do HTTP_COOKIE, siga estes passos:

Consola

Na Google Cloud consola, aceda à página Cloud Service Mesh.

Aceda ao Cloud Service Mesh
Clique no nome do serviço de back-end que quer atualizar.
Clique em Editar.
Clique em Configurações avançadas.
Em Afinidade de sessão, selecione Cookie HTTP.
Em Política de equilíbrio de carga de localidade, selecione Ring hash.
1. No campo Nome do cookie HTTP, introduza http_cookie.
2. No campo Caminho do cookie HTTP, introduza /cookie_path.
3. No campo TTL de cookies HTTP, introduza 100.
4. No campo Tamanho mínimo do anel, introduza 10000.
Clique em Guardar.

gcloud

Execute o comando gcloud export para exportar a configuração do serviço de back-end. Substitua BACKEND_SERVICE_NAME pelo nome do serviço de back-end.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

Atualize o ficheiro YAML da seguinte forma:

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

Importe o ficheiro de configuração do serviço de back-end:

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

Configure a deteção de valores atípicos

A deteção de valores atípicos controla a remoção de anfitriões não saudáveis do conjunto de equilíbrio de carga. O Cloud Service Mesh faz isto através de um conjunto de políticas que especificam os critérios para a remoção de VMs ou pontos finais de back-end não íntegros em NEGs, juntamente com critérios que definem quando um back-end ou um ponto final é considerado suficientemente íntegro para receber tráfego novamente.

No exemplo seguinte, o serviço de back-end tem um grupo de instâncias como back-end. A definição de deteção de valores atípicos especifica que a análise de deteção de valores atípicos é executada a cada segundo. Se um ponto final devolver cinco erros 5xx consecutivos, é rejeitado da consideração do equilíbrio de carga durante 30 segundos pela primeira vez. O tempo de ejeção real para o mesmo ponto final é de 30 segundos multiplicado pelo número de vezes que é ejetado.

Para configurar a deteção de valores atípicos no recurso de serviço de back-end, siga estes passos:

Consola

Na Google Cloud consola, aceda à página Cloud Service Mesh.

Aceda ao Cloud Service Mesh
Clique no nome de um serviço.
Clique em Editar.
Clique em Configurações avançadas.
Selecione a caixa de verificação Deteção de valores atípicos.
Clique em Editar.
1. Defina Erros consecutivos como 5.
2. Defina o Intervalo para 1000 milissegundos.
3. Defina o Tempo de ejeção base para 30000 milissegundos.
Clique em Guardar e, de seguida, clique novamente em Guardar.

gcloud

Execute o comando gcloud export para exportar a configuração do serviço de back-end. Substitua BACKEND_SERVICE_NAME pelo nome do serviço de back-end.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

Atualize o ficheiro YAML da seguinte forma, substituindo o nome do serviço de back-end por 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

Importe o ficheiro de configuração do serviço de back-end:

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

Defina a política de equilíbrio de carga de localidade

Use a política de balanceamento de carga de localidade para escolher um algoritmo de balanceamento de carga com base no peso e na prioridade da localidade fornecidos pela Cloud Service Mesh. Por exemplo, pode fazer um round robin ponderado entre pontos finais saudáveis ou fazer uma hash consistente.

No exemplo seguinte, o serviço de back-end tem um grupo de instâncias como back-end. A política de equilíbrio de carga de localidade está definida como RING_HASH.

Para definir a política de equilíbrio de carga de localidade, siga estes passos:

Consola

Na Google Cloud consola, aceda à página Cloud Service Mesh.

Aceda ao Cloud Service Mesh
Clique no nome de um serviço.
Clique em Editar.
Clique em Configurações avançadas.
Em Política de tráfego, no menu Política de equilíbrio de carga de localidade, selecione Hash de anel.
Clique em Guardar.

gcloud

Execute o comando gcloud export para exportar a configuração do serviço de back-end. Substitua BACKEND_SERVICE_NAME pelo nome do serviço de back-end.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

Atualize o ficheiro BACKEND_SERVICE_NAME.yaml da seguinte forma:

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

Importe o ficheiro de configuração do serviço de back-end:

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

Para mais informações sobre como funciona a política de equilíbrio de carga de localidade, consulte a documentação do recurso backendService.

Configure o redirecionamento de URL

Estas instruções pressupõem o seguinte:

A sua implementação do Cloud Service Mesh tem um mapa de URLs denominado review-url-map.
O mapa de URLs envia todo o tráfego para um serviço de back-end denominado review1, que funciona como o serviço de back-end predefinido.
Quiser redirecionar o tráfego de um anfitrião para outro.

Para configurar o redirecionamento de URL, siga estes passos:

Consola

Na Google Cloud consola, aceda à página Cloud Service Mesh.

Aceda ao Cloud Service Mesh
Clique em Mapeamentos de regras de encaminhamento.
Clique em Criar mapa de regras de encaminhamento.
Na página Criar um mapa de regras de encaminhamento, introduza um Nome.
No menu Protocolo, selecione HTTP.
Selecione uma regra de encaminhamento existente.
Em Regras de encaminhamento, selecione Regra avançada de anfitrião, caminho e rota.
Em Anfitriões e correspondências de caminhos, clique em Adicionar anfitriões e correspondência de caminhos. Isto adiciona um novo correspondente de caminho que redireciona o tráfego.

Adicione as seguintes definições ao campo Correspondência de caminhos:

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

Clique em Concluído.
Clique em Guardar.

gcloud

Execute o comando gcloud export para obter a configuração do mapa de URLs:

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

Adicione a seguinte secção ao ficheiro 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

Atualize o mapa de URLs:

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

Configure o encaminhamento de tráfego com a reescrita de URLs

O encaminhamento de tráfego permite-lhe direcionar o tráfego para diferentes serviços de back-end com base em atributos de pedido, como valores de cabeçalho. Além disso, pode configurar ações como reescrever o URL no pedido antes de o pedido ser direcionado para o serviço de back-end.

No exemplo seguinte, o pedido é direcionado para SERVICE_ANDROID_URL se o caminho do pedido tiver o prefixo /mobile/ e o User-Agent do pedido contiver Android. Antes de enviar o pedido para o serviço de back-end, o prefixo do URL pode ser alterado para, por exemplo, REWRITE_PATH_ANDROID, /android/. No entanto, se o caminho tiver o prefixo /mobile/ e tiver um User-Agent que contenha iPhone, o tráfego é direcionado para SERVICE_IPHONE_URL e o prefixo do URL é alterado para REWRITE_PATH_IPHONE. Todos os outros pedidos com o prefixo /mobile/ e que tenham um User-Agent com um valor diferente de Android ou iPhone são direcionados para 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]

Configure a injeção de falhas

A injeção de falhas permite-lhe injetar um atraso fixo ou uma paragem forçada, denominada anulação, numa rota específica para testar a resiliência de uma aplicação.

No exemplo que se segue, todos os pedidos são enviados para SERVICE_URL, com um atraso fixo de 10 segundos adicionado a 100% dos pedidos. O cliente que envia os pedidos vê que todas as respostas estão atrasadas 10 segundos. Além disso, é aplicada uma falha com uma resposta Service Unavailable 503 a 50% dos pedidos. O cliente vê que 50% dos seus pedidos recebem uma resposta 503. Estes pedidos não chegam ao serviço de back-end.

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

Configure a filtragem de configurações com base na correspondência `MetadataFilters`

MetadataFilters estão ativadas com regras de encaminhamento e HttpRouteRuleMatch. Use esta funcionalidade para controlar uma regra de encaminhamento ou uma regra de trajeto específica, de modo que o plano de controlo envie a regra de encaminhamento ou a regra de trajeto apenas para proxies cujos metadados do nó correspondam à definição do filtro de metadados. Se não especificar nenhum MetadataFilters, a regra é enviada para todos os proxies Envoy.

Esta funcionalidade facilita a implementação faseada de uma configuração. Por exemplo, crie uma regra de encaminhamento denominada forwarding-rule1, que quer que seja enviada apenas para os Envoys cujos metadados de nós contenham app: review e version: canary.

Para adicionar MetadataFilters a uma regra de encaminhamento, siga estes passos:

gcloud

Execute o comando gcloud export para obter a configuração da regra de encaminhamento:

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

Elimine a regra de encaminhamento:

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

Atualize o ficheiro forwarding-rule1-config.yaml.

O exemplo seguinte cria um filtro de metadados MATCH_ALL:

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

O exemplo seguinte cria um filtro de metadados MATCH_ANY:

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

Remova todos os campos só de saída do ficheiro forwarding-rule1-config.yaml Para mais informações, consulte a documentação de gcloud compute forwarding-rules import.

Execute o comando gcloud import para atualizar o ficheiro:forwarding-rule1-config.yaml

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

Use estas instruções para adicionar metadados de nós ao Envoy antes de iniciar o Envoy. Apenas é suportado um valor de string.

a. Para uma implementação baseada em VMs, em bootstrap_template.yaml, adicione o seguinte na secção metadata:
```
   app: 'review'
   version: 'canary'
```
b. Para uma implementação baseada no Google Kubernetes Engine ou no Kubernetes, em trafficdirector_istio_sidecar.yaml, adicione o seguinte na secção env:
```
   - name: ISTIO_META_app
     value: 'review'
   - name: ISTIO_META_version
     value: 'canary'
```

Exemplos de filtragem de metadados

Use as seguintes instruções para um cenário em que vários projetos estão na mesma rede VPC partilhada e quer que os recursos do Cloud Service Mesh de cada projeto de serviço sejam visíveis para proxies no mesmo projeto.

A configuração da VPC partilhada é a seguinte:

Nome do projeto anfitrião: vpc-host-project
Projetos de serviços: project1, project2
Serviços de back-end com instâncias ou pontos finais de back-end que executam um proxy compatível com xDS em project1 e project2

Para configurar a Cloud Service Mesh para isolar project1, siga estes passos:

gcloud

Crie todas as regras de encaminhamento em project1 com o seguinte filtro de metadados:

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

Quando configurar os proxies implementados em instâncias ou pontos finais no project1, inclua os seguintes metadados na secção de metadados do nó do ficheiro de arranque:
```
   project_name: 'project1'
   version: 'production'
```
Verifique se os proxies já implementados em project2 não receberam a regra de encaminhamento criada no primeiro passo. Para o fazer, tente aceder aos serviços em project1 a partir de um sistema que execute um proxy em project2. Para obter informações sobre como verificar se uma configuração da Cloud Service Mesh está a funcionar corretamente, consulte Verificar a configuração.

Para testar uma nova configuração num subconjunto de proxies antes de a disponibilizar a todos os proxies, siga estes passos:

gcloud

Inicie os proxies que está a usar para testes com os seguintes metadados do nó. Não inclua os metadados deste nó para proxies que não esteja a usar para testes.
```
  version: 'test'
```

Para cada nova regra de encaminhamento que quer testar, inclua o seguinte filtro de metadados:

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

Teste a nova configuração enviando tráfego para os proxies de teste e faça as alterações necessárias. Se a nova configuração estiver a funcionar corretamente, apenas os proxies que testar recebem a nova configuração. Os restantes proxies não recebem a nova configuração e não a podem usar.
Quando confirmar que a nova configuração funciona corretamente, remova o filtro de metadados associado à mesma. Isto permite que todos os proxies recebam a nova configuração.

Resolução de problemas

Use estas informações para resolver problemas quando o tráfego não está a ser encaminhado de acordo com as regras de encaminhamento e as políticas de tráfego que configurou.

Sintomas:

Aumento do tráfego para serviços em regras acima da regra em questão.
Um aumento inesperado nas respostas HTTP 4xx e 5xx para uma determinada regra de encaminhamento.

Solução: uma vez que as regras de encaminhamento são interpretadas por ordem de prioridade, reveja a prioridade atribuída a cada regra.

Quando definir regras de percursos, certifique-se de que as regras com prioridade mais elevada (ou seja, com números de prioridade mais baixos) não encaminham inadvertidamente tráfego que, de outra forma, teria sido encaminhado por uma regra de percurso subsequente. Considere o seguinte exemplo:

Regra do primeiro trajeto
- Regra de encaminhamento com correspondência pathPrefix = /shopping/
- Ação de redirecionamento: enviar tráfego para o serviço de back-end service-1
- Prioridade da regra: 4
Segunda regra de trajeto
- Route rule match regexMatch = /shopping/cart/ordering/.*
- Ação de redirecionamento: enviar tráfego para o serviço de back-end service-2
- Prioridade da regra: 8

Neste caso, um pedido com o caminho /shopping/cart/ordering/cart.html é encaminhado para service-1. Embora a segunda regra tivesse sido correspondente, é ignorada porque a primeira regra tinha prioridade.

Bloqueie o tráfego entre serviços

Se quiser bloquear o tráfego entre o Serviço A e o Serviço B, e a sua implementação estiver no GKE, configure a segurança do serviço e use uma política de autorização para bloquear o tráfego entre serviços. Para ver instruções completas, consulte o artigo Segurança do serviço Cloud Service Mesh e as instruções de configuração com o Envoy e o gRPC sem proxy.

O que se segue?

Para ajudar a resolver problemas de configuração do Cloud Service Mesh, consulte o artigo Resolva problemas de implementações que usam o Envoy.

Configure a gestão avançada de tráfego com o Envoy

Antes de começar

Configure a divisão de tráfego

Consola

gcloud

Configure um lançamento parcial

Configure implementações azul-verde

Configure o espelhamento de tráfego

Consola

gcloud

Configure a interrupção de circuito

Consola

gcloud

Configure a afinidade de sessão com base em HTTP_COOKIE

Consola

gcloud

Configure a deteção de valores atípicos

Consola

gcloud

Defina a política de equilíbrio de carga de localidade

Consola

gcloud

Configure o redirecionamento de URL

Consola

gcloud

Configure o encaminhamento de tráfego com a reescrita de URLs

Configure a injeção de falhas

Configure a filtragem de configurações com base na correspondência MetadataFilters

gcloud

Exemplos de filtragem de metadados

gcloud

gcloud

Resolução de problemas

Bloqueie o tráfego entre serviços

O que se segue?

Configure a afinidade de sessão com base em `HTTP_COOKIE`

Configure a filtragem de configurações com base na correspondência `MetadataFilters`