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

Esta página foi traduzida pela API Cloud Translation.

Configure o gerenciamento avançado de tráfego com o Envoy

A configuração tem suporte para clientes em fase de pré-lançamento, mas não é recomendada para novos usuários do Cloud Service Mesh. Para mais informações, consulte a Visão geral do roteamento de serviços do Cloud Service Mesh.

Este documento fornece informações sobre como configurar o gerenciamento de tráfego avançado para implantações do Cloud Service Mesh que usam o Envoy.

Antes de começar

Antes de configurar o gerenciamento avançado de tráfego, siga as instruções em Preparar-se para configurar o Cloud Service Mesh com o Envoy, incluindo a configuração do Cloud Service Mesh e de todos os hosts de máquina virtual (VM) ou Clusters do Google Kubernetes Engine (GKE) necessários. Crie os recursos necessários do Google Cloud.

A disponibilidade do recurso avançado de gerenciamento de tráfego é diferente de acordo com o protocolo de solicitação escolhido. Este protocolo é configurado quando você configura o roteamento usando os recursos de proxy HTTP ou HTTPS de destino, proxy gRPC de destino ou proxy TCP de destino:

Com os proxies HTTP e HTTPS de destino, todos os recursos descritos neste documento estão disponíveis.
Com o proxy gRPC de destino, alguns recursos estão disponíveis.
Com o proxy TCP de destino, nenhum recurso avançado de gerenciamento de tráfego está disponível.

Para mais informações, consulte Recursos do Cloud Service Mesh e Gerenciamento de tráfego avançado. Para um guia completo de configuração, consulte Configurar o gerenciamento avançado de tráfego com serviços gRPC sem proxy.

Configurar a divisão de tráfego

Os pressupostos destas instruções são os seguintes:

Sua implantação do Cloud Service Mesh tem um mapa de URLs chamado review-url-map.
O mapa de URLs envia todo o tráfego para um serviço de back-end, chamado review1, que serve como serviço de back-end padrão.
Você planeja rotear 5% do tráfego para uma nova versão de um serviço. Esse serviço está sendo executado em uma VM de back-end ou em um endpoint em um grupo de endpoints de rede (NEG, na sigla em inglês) associado ao serviço de back-end review2.
Nenhuma regra de host ou correspondência de caminho é usada.

Se você estiver dividindo o tráfego para um novo serviço que não foi referenciado pelo mapa de URL antes, primeiro adicione o novo serviço a weightedBackendServices e atribua um peso de 0 a ele. Em seguida, aumente gradualmente o peso atribuído a esse serviço.

Para configurar a divisão de tráfego, siga estas etapas:

Console

No console do Google Cloud, acesse a página Cloud Service Mesh.

Acessar o Cloud Service Mesh
Clique em Mapas de regra de roteamento.
Clique em Criar mapa de regras de roteamento.
Na página Criar um mapa de regras de roteamento, digite um Nome.
No menu Protocolo, selecione HTTP.
Selecione uma regra de encaminhamento atual.
Em Regras de roteamento, selecione Regra avançada para host, caminho e rota.
Em Correspondências de hosts e caminho, clique em Adicionar correspondência de hosts e caminho. Isso adiciona uma nova correspondência de caminhos que pode ser configurada para dividir o tráfego.

Adicione as configurações a seguir 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 Save.

Quando estiver satisfeito com a nova versão, será possível ajustar gradualmente os pesos dos dois serviços e, por fim, enviar todo o tráfego para review2.

gcloud

Use o comando gcloud export para ver a configuração do mapa de URLs:

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

Adicione a seção a seguir ao arquivo 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, será possível ajustar gradualmente os pesos dos dois serviços e, por fim, enviar todo o tráfego para review2.

Configurar uma versão parcial

Use um processo de implantação parcial, também chamado de canário, para liberar uma nova versão do software para uma pequena fração dos servidores antes de liberar a nova versão para o equilíbrio dos servidores de produção.

Uma versão parcial usa weightedBackendServices. Para ativar uma versão parcial, designe um serviço de back-end como de teste, ou canário, e dê a ele um peso baixo, por exemplo, 2 ou 5. Implante a nova versão do software apenas nesses servidores. Quando você achar que a nova versão não tem problemas, implante-a no restante dos serviços.

Para ativar uma versão parcial, use o seguinte exemplo de código de 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 padrão do 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.

Configurar implantações azul-verde

As implantações azul-verde são modelos de versão que reduzem o tempo necessário para alternar o tráfego de produção para uma nova versão de um serviço ou para uma reversão de uma versão anterior do serviço. Essas implantações mantêm as duas versões do serviço disponíveis na produção e mudam o tráfego de uma para a outra.

Implantações azul-verde usam weightedBackendServices. No exemplo YAML a seguir, os back-ends para SERVICE_BLUE_URL estão totalmente implantados com a versão de produção atual. Os back-ends para SERVICE_GREEN_URL estão totalmente implantados com a nova versão. Na configuração do exemplo, a implantação GREEN recebe 100% do tráfego de produção. Se você encontrar problemas, é possível reverter os pesos das duas implantações, o que reverte de maneira eficaz a versão GREEN com defeito e restaura a versão BLUE conhecida. Nos dois casos, a alteração do tráfego pode ser feita rapidamente porque as duas versões estão disponíveis para receber tráfego.

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

Configure o espelhamento de tráfego

Use o espelhamento 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 a seguir, todas as solicitações são enviadas para SERVICE_URL e MIRROR_SERVICE_URL. Somente as respostas de SERVICE_URL são enviadas de volta ao cliente. MIRROR_SERVICE_URL não tem impacto sobre o cliente.

Para configurar o espelhamento, siga estas etapas:

Console

No console do Google Cloud, acesse a página Cloud Service Mesh.

Acessar o Cloud Service Mesh
Clique em Mapas de regra de roteamento.
Clique em Criar mapa de regras de roteamento.
Na página Criar um mapa de regras de roteamento, digite um Nome.
Na lista Protocolo, selecione HTTP.
Selecione uma regra de encaminhamento atual.
Em Regras de roteamento, selecione Regra avançada para host, caminho e rota.
Em Correspondências de hosts e caminho, clique em Adicionar correspondência de hosts e caminho. Isso adiciona uma nova correspondência de caminhos que pode ser configurada para espelhar o tráfego.

Adicione as configurações a seguir 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 padrão do serviço.
BACKEND_SERVICE_URL é o URL do back-end espelhado.
BACKEND_SERVICE_MIRROR_URL é o URL do serviço de back-end em que você espelha.

Clique em Concluído.
Clique em Salvar.

gcloud

Use o comando gcloud export para ver a configuração do mapa de URLs:

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

Adicione a seção a seguir ao arquivo 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 padrão do serviço.
BACKEND_SERVICE_URL é o URL do back-end espelhado.
BACKEND_SERVICE_MIRROR_URL é o URL do serviço de back-end em que você espelha.

Atualize o mapa de URLs:

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

Configurar a quebra de circuito

A quebra de circuito permite definir limites de falha para impedir que as solicitações do cliente sobrecarreguem os back-ends. Depois que as solicitações atingem um limite que você definiu, o cliente para de permitir novas conexões ou o envio de outras solicitações, proporcionando tempo para os back-ends se recuperarem.

Como resultado, a quebra de circuitos evita falhas em cascata retornando um erro ao cliente em vez de sobrecarregar um back-end. Isso permite que pouco tráfego seja veiculado enquanto fornece tempo para gerenciar a situação de sobrecarga, como lidar com um pico de tráfego aumentando a capacidade com escalonamento automático.

No exemplo a seguir, você define os disjuntores desta maneira:

Solicitações máximas por conexão: 100
Número máximo de conexões: 1.000
Máximo de solicitações pendentes: 200
Máximo de solicitações: 1.000
Máximo de novas tentativas: 3

Para configurar o disjuntor, siga estas etapas:

Console

No console do Google Cloud, acesse a página Cloud Service Mesh.

Acessar o Cloud Service Mesh
Clique no nome do serviço de back-end que você quer atualizar.
Clique em Editar.
Clique em Configurações avançadas.
Em Disjuntores, marque a caixa de seleção Ativar.
Clique em Editar.
1. Em Número máximo de solicitações por conexão, insira 100.
2. Em Máximo de conexões, insira 1000.
3. Em Máximo de solicitações pendentes, insira 200.
4. Em Número máximo de solicitações, insira 1000.
5. Em Máximo de tentativas, insira 3.
Clique em Salvar e, depois, em Salvar novamente.

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 arquivo BACKEND_SERVICE_NAME.yaml da seguinte maneira:

 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 arquivo de configuração do serviço de back-end:

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

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

O gerenciamento de tráfego avançado permite que você configure a afinidade de sessão com base em um cookie fornecido.

Para configurar a afinidade de sessão usando HTTP_COOKIE, siga estas etapas:

Console

No console do Google Cloud, acesse a página Cloud Service Mesh.

Acessar o Cloud Service Mesh
Clique no nome do serviço de back-end que você quer atualizar.
Clique em Editar.
Clique em Configurações avançadas.
Em Afinidade da sessão, selecione Cookie HTTP.
Em Política de balanceamento de carga local, selecione Anel de hash.
1. No campo Nome do cookie HTTP, insira http_cookie.
2. No campo Caminho do cookie HTTP, insira /cookie_path.
3. No campo TTL do cookie HTTP, digite 100.
4. No campo Tamanho mínimo do anel, insira 10000.
Clique em Save.

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 arquivo 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 arquivo de configuração do serviço de back-end:

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

Configurar a detecção de outliers

A detecção de outlier controla a remoção de hosts não íntegros do pool de balanceamento de carga. A Cloud Service Mesh faz isso usando um conjunto de políticas que especifica os critérios para a remoção de VMs ou endpoints de back-end não íntegros em NEGs, juntamente com os critérios que definem quando um back-end ou endpoint é considerado íntegro o suficiente para receber tráfego novamente.

No exemplo a seguir, o serviço de back-end tem um grupo de instâncias como back-end. A configuração de detecção de outliers especifica que a análise de detecção de outliers é executada a cada segundo. Se um endpoint retornar cinco erros 5xx consecutivos, ele será removido da consideração de balanceamento de carga por 30 segundos pela primeira vez. O tempo real de remoção do mesmo endpoint é de 30 segundos vezes o número de vezes que ele é removido.

Para configurar a detecção de outliers no recurso do serviço de back-end, siga estas etapas.

Console

No console do Google Cloud, acesse a página Cloud Service Mesh.

Acessar o Cloud Service Mesh
Clique no nome de um serviço.
Clique em Editar.
Clique em Configurações avançadas.
Marque a caixa de seleção Detecção de outliers.
Clique em Editar.
1. Defina Erros consecutivos como 5.
2. Defina Intervalo como 1000 milissegundos.
3. Defina o Tempo de expulsão base para 30000 milissegundos.
Clique em Salvar e, depois, em Salvar novamente.

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 arquivo YAML da seguinte maneira, 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 arquivo de configuração do serviço de back-end:

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

Definir a política de balanceamento 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 de localidade e na prioridade fornecida pela Cloud Service Mesh. Por exemplo, é possível executar um round-robin ponderado entre endpoints íntegros ou gerar hash consistente.

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

Para definir a política de balanceamento de carga de localidade, siga estas etapas:

Console

No console do Google Cloud, acesse a página Cloud Service Mesh.

Acessar o 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 balanceamento de carga de localidade, selecione Anel de hash.
Clique em Save.

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 arquivo BACKEND_SERVICE_NAME.yaml da seguinte maneira:

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 arquivo 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 balanceamento de carga de localidade, consulte a documentação do recurso backendService.

Configurar o redirecionamento de URL

Os pressupostos destas instruções são os seguintes:

Sua implantação do Cloud Service Mesh tem um mapa de URLs chamado review-url-map.
O mapa de URLs envia todo o tráfego para um serviço de back-end, chamado review1, que serve como serviço de back-end padrão.
Você quer redirecionar o tráfego de um host para outro.

Para configurar o redirecionamento de URL, siga estas etapas:

Console

No console do Google Cloud, acesse a página Cloud Service Mesh.

Acessar o Cloud Service Mesh
Clique em Mapas de regra de roteamento.
Clique em Criar mapa de regras de roteamento.
Na página Criar um mapa de regras de roteamento, digite um Nome.
No menu Protocolo, selecione HTTP.
Selecione uma regra de encaminhamento atual.
Em Regras de roteamento, selecione Regra avançada para host, caminho e rota.
Em Correspondências de hosts e caminho, clique em Adicionar correspondência de hosts e caminho. Isso adiciona uma nova correspondência de caminho que redireciona o tráfego.

Adicione as configurações a seguir 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 Salvar.

gcloud

Use o comando gcloud export para ver a configuração do mapa de URLs:

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

Adicione a seção a seguir ao arquivo 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

Configurar o direcionamento de tráfego com a substituição de URL

O direcionamento de tráfego possibilita direcionar o tráfego para diferentes serviços de back-end com base nos atributos da solicitação, como valores de cabeçalho. Além disso, é possível configurar ações como reescrever o URL na solicitação antes que ela seja direcionada para o serviço de back-end.

No exemplo a seguir, a solicitação será direcionada para SERVICE_ANDROID_URL se o caminho da solicitação estiver prefixado com /mobile/ e o User-Agent da solicitação contiver Android. Antes de enviar a solicitação ao serviço de back-end, o prefixo de URL pode ser alterado para REWRITE_PATH_ANDROID, por exemplo, /android/. No entanto, se o caminho for prefixado com /mobile/ e tiver uma User-Agent contendo iPhone, o tráfego será direcionado para SERVICE_IPHONE_URL e o prefixo do URL será alterado para REWRITE_PATH_IPHONE Todas as outras solicitações prefixadas com /mobile/ que tiverem um User-Agent com um valor diferente de Android ou iPhone serão direcionadas 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]

Configurar a injeção de falhas

A injeção da falha permite injetar um atraso fixo e/ou uma parada forçada, chamada de cancelamento, em uma rota específica para testar a resiliência de um aplicativo.

No exemplo a seguir, todas as solicitações são enviadas para SERVICE_URL, com um tempo de atraso fixo de 10 segundos adicionado a 100% das solicitações. O cliente que está enviando as solicitações vê que todas as respostas têm um atraso de 10 segundos. Além disso, uma falha de parada com uma resposta Service Unavailable 503 é aplicada a 50% das solicitações. O cliente vê que 50% das solicitações recebem uma resposta 503. Essas solicitações não atingem o 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

Como configurar a filtragem de configuração com base na correspondência de `MetadataFilters`

MetadataFilters estão ativados com regras de encaminhamento e HttpRouteRuleMatch. Use esse recurso para controlar uma regra de encaminhamento ou de rota específica para que o plano de controle envie a regra de encaminhamento ou de rota apenas para proxies em que os metadados do nó correspondem à configuração de filtro de metadados. Se você não especificar nenhum MetadataFilters, a regra será enviada para todos os proxies Envoy.

Esse recurso facilita a operação de uma implantação organizada de uma configuração. Por exemplo, crie uma regra de encaminhamento chamada forwarding-rule1, que você quer enviar somente para o Envoys cujos metadados de nó contenham app: review e version: canary.

Para adicionar MetadataFilters a uma regra de encaminhamento, siga estas etapas:

gcloud

Use o comando gcloud export para conseguir a configuração da regra de encaminhamento.

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

Exclua a regra de encaminhamento:

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

Atualize o arquivo forwarding-rule1-config.yaml.

No exemplo a seguir, criamos um filtro de metadados MATCH_ALL:

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

No exemplo a seguir, criamos um filtro de metadados MATCH_ANY:

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

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

Use o comando gcloud import para atualizar o arquivo 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ó ao Envoy antes de iniciar o Envoy. Apenas um valor de string é aceito.

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

Exemplos de filtragem de metadados

Use as instruções a seguir para um cenário em que vários projetos estão na mesma rede VPC compartilhada e você quer que os recursos da Cloud Service Mesh de cada projeto de serviço fiquem visíveis para os proxies no mesmo projeto.

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

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

Para configurar o Cloud Service Mesh para isolar project1, siga estas etapas:

gcloud

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

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

Ao configurar os proxies implantados em instâncias ou endpoints em project1, inclua os metadados a seguir na seção de metadados do nó do arquivo de inicialização:
```
   project_name: 'project1'
   version: 'production'
```
Verifique se os proxies já implantados em project2 não receberam a regra de encaminhamento criada na primeira etapa. Para fazer isso, tente acessar serviços em project1 de um sistema que executa um proxy em project2. Para informações sobre como verificar se uma configuração do Cloud Service Mesh está funcionando corretamente, consulte Como verificar a configuração.

Para testar uma nova configuração em um subconjunto de proxies antes de disponibilizá-la para todos os proxies, siga estas etapas:

gcloud

Inicie os proxies que você está usando para testar com os metadados de nó a seguir. Não inclua esses metadados de nó para proxies que você não está usando para teste.
```
  version: 'test'
```

Para cada nova regra de encaminhamento que você quer testar, inclua o filtro de metadados a seguir:

  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 funcionando corretamente, somente os proxies que você testar receberão a nova configuração. Os proxies restantes não recebem a nova configuração e não podem usá-la.
Quando você confirmar que a nova configuração funciona corretamente, remova o filtro de metadados associado a ela. Isso permite que todos os proxies recebam a nova configuração.

Solução de problemas

Use estas informações para solucionar problemas quando o tráfego não estiver sendo roteado de acordo com as regras de roteamento e as políticas de tráfego que você tiver configurado.

Sintomas:

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

Solução: como as regras de rota são interpretadas em ordem de prioridade, revise a prioridade atribuída a cada regra.

Ao definir regras de rota, verifique se as regras com maior prioridade (ou seja, com números de prioridade mais baixa) não encaminham inadvertidamente o tráfego que, de outra forma, seria roteado por outra regra de rota. Veja o exemplo a seguir.

Primeira regra de rota
- Caminho de correspondência da regra de rota = /shopping/
- Ação de redirecionamento: enviar tráfego para o serviço de back-end service-1
- Prioridade da regra: 4
Segunda regra de rota
- regexMatch da correspondência de regra de rota = /shopping/cart/ordering/.*
- Ação de redirecionamento: enviar tráfego para o serviço de back-end service-2
- Prioridade da regra: 8

Nesse caso, uma solicitação com o caminho /shopping/cart/ordering/cart.html é roteada para service-1. Mesmo que a segunda regra tenha correspondência, ela é ignorada porque a primeira regra tinha prioridade.

Bloquear tráfego entre os serviços

Caso você queira bloquear o tráfego entre os Serviços A e B, e a implantaçã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 eles. Para instruções completas, consulte Segurança do serviço do Cloud Service Mesh e as instruções de configuração com o Envoy e o gRPC sem proxy.

A seguir

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

Configure o gerenciamento avançado de tráfego com o Envoy

Antes de começar

Configurar a divisão de tráfego

Console

gcloud

Configurar uma versão parcial

Configurar implantações azul-verde

Configure o espelhamento de tráfego

Console

gcloud

Configurar a quebra de circuito

Console

gcloud

Configurar a afinidade de sessão com base em HTTP_COOKIE

Console

gcloud

Configurar a detecção de outliers

Console

gcloud

Definir a política de balanceamento de carga de localidade

Console

gcloud

Configurar o redirecionamento de URL

Console

gcloud

Configurar o direcionamento de tráfego com a substituição de URL

Configurar a injeção de falhas

Como configurar a filtragem de configuração com base na correspondência de MetadataFilters

gcloud

Exemplos de filtragem de metadados

gcloud

gcloud

Solução de problemas

Bloquear tráfego entre os serviços

A seguir

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

Como configurar a filtragem de configuração com base na correspondência de `MetadataFilters`