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

A configuração é compatível com clientes de pré-lançamento, mas não recomendamos para novos usuários do Cloud Service Mesh. Para mais informações, consulte a Visão geral do roteamento de serviço 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 de tráfego avançado, siga as instruções em Prepare-se para configurar o Cloud Service Mesh com o Envoy, incluindo a configuração do Cloud Service Mesh e de qualquer host de máquina virtual (VM) ou clusters do Google Kubernetes Engine (GKE) de que você precisa. 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

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

    Acessar o Cloud Service Mesh

  2. Clique em Mapas de regra de roteamento.

  3. Clique em Criar mapa de regras de roteamento.

  4. Na página Criar um mapa de regras de roteamento, digite um Nome.

  5. No menu Protocolo, selecione HTTP.

  6. Selecione uma regra de encaminhamento atual.

  7. Em Regras de roteamento, selecione Regra avançada para host, caminho e rota.

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

  9. 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
    
  10. Clique em Concluído.

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

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

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

    Acessar o Cloud Service Mesh

  2. Clique em Mapas de regra de roteamento.

  3. Clique em Criar mapa de regras de roteamento.

  4. Na página Criar um mapa de regras de roteamento, digite um Nome.

  5. Na lista Protocolo, selecione HTTP.

  6. Selecione uma regra de encaminhamento atual.

  7. Em Regras de roteamento, selecione Regra avançada para host, caminho e rota.

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

  9. 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.
  10. Clique em Concluído.

  11. Clique em Salvar.

gcloud

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

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

    Acessar o Cloud Service Mesh

  2. Clique no nome do serviço de back-end que você quer atualizar.

  3. Clique em Editar.

  4. Clique em Configurações avançadas.

  5. Em Disjuntores, marque a caixa de seleção Ativar.

  6. 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.
  7. Clique em Salvar e, depois, em Salvar novamente.

gcloud

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

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

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

    Acessar o Cloud Service Mesh

  2. Clique no nome do serviço de back-end que você quer atualizar.

  3. Clique em Editar.

  4. Clique em Configurações avançadas.

  5. Em Afinidade da sessão, selecione Cookie HTTP.

  6. 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.
  7. Clique em Save.

gcloud

  1. 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
    
  2. 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
    
  3. 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. O Cloud Service Mesh faz isso usando um conjunto de políticas que especificar os critérios para a remoção de VMs ou endpoints de back-end não íntegros em NEGs, junto com os critérios que definem quando um back-end ou endpoint é considerado saudável o suficiente para receber o 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

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

    Acessar o Cloud Service Mesh

  2. Clique no nome de um serviço.

  3. Clique em Editar.

  4. Clique em Configurações avançadas.

  5. Marque a caixa de seleção Detecção de outliers.

  6. 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.
  7. Clique em Salvar e, depois, em Salvar novamente.

gcloud

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

Usar a política de balanceamento de carga de localidade para escolher um algoritmo de balanceamento de carga com base no peso da localidade e na prioridade fornecida pelo 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

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

    Acessar o Cloud Service Mesh

  2. Clique no nome de um serviço.

  3. Clique em Editar.

  4. Clique em Configurações avançadas.

  5. Em Política de tráfego, no menu Política de balanceamento de carga de localidade, selecione Anel de hash.

  6. Clique em Save.

gcloud

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

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

    Acessar o Cloud Service Mesh

  2. Clique em Mapas de regra de roteamento.

  3. Clique em Criar mapa de regras de roteamento.

  4. Na página Criar um mapa de regras de roteamento, digite um Nome.

  5. No menu Protocolo, selecione HTTP.

  6. Selecione uma regra de encaminhamento atual.

  7. Em Regras de roteamento, selecione Regra avançada para host, caminho e rota.

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

  9. 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
    
  10. Clique em Concluído.

  11. Clique em Salvar.

gcloud

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

  1. 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
    
  2. Exclua a regra de encaminhamento:

    gcloud compute forwarding-rules delete forwarding-rule1 \
        --global
    
  3. 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'
    
  4. 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.

  5. 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
    
  6. 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 o serviço Os recursos do Cloud Service Mesh ficam 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

  1. 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'
    
  2. 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'
    
  3. 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 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

  1. 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'
    
  2. 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'
    
  3. 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.

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