Como configurar o gerenciamento de tráfego avançado

Neste documento, fornecemos informações sobre como configurar o gerenciamento avançado de tráfego para a implantação do Traffic Director.

Antes de configurar o gerenciamento avançado de tráfego

Siga as instruções em Como configurar o Traffic Director, incluindo a configuração do Traffic Director e de todos os hosts de VM ou clusters do GKE necessários. Crie os recursos necessários do Google Cloud.

Como configurar a divisão de tráfego

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

  • Sua implantação do Traffic Director 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 também 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 endpoint em um NEG associado ao serviço de back-end review2.
  • Nenhuma regra de host ou correspondência de caminho é usada.

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

Console

  1. Acesse a página do Traffic Director no Console do Cloud.

    Acessar a página do Traffic Director

  2. Clique em Criar mapas de regras de roteamento.

  3. Digite o Nome do mapa de regras de roteamento.

  4. Selecione HTTP no menu Protocolo.

  5. Selecione uma regra de encaminhamento atual.

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

  7. Em Correspondência de caminho, selecione Dividir tráfego entre serviços.

  8. Clique no botão de Visualização de YAML.

  9. Adicione as configurações a seguir à caixa Correspondência de caminho:

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

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.

Como configurar o disjuntor

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.

Assim, a quebra de circuito evita falhas em cascata retornando um erro ao cliente em vez de sobrecarregar um back-end. Isso permite que pouco tráfego seja vinculado 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 Cloud, acesse a página "Traffic Director".

    Acessar a página do Traffic Director

  2. Clique no nome do serviço de back-end que você quer atualizar.
  3. Clique em Edit.
  4. Clique em Configurações avançadas.
  5. Em Disjuntores, marque a caixa de seleção Ativar.
  6. Clique em Editar .
  7. Em Número máximo de solicitações por conexão, insira 100.
  8. Em Máximo de conexões, insira 1000.
  9. Em Máximo de solicitações pendentes, insira 200.
  10. Em Número máximo de solicitações, insira 1000.
  11. Em Máximo de tentativas, insira 3.
  12. Clique em Save.
  13. Clique em Save.

gcloud

  1. Use o comando gcloud export para conseguir a configuração do serviço de back-end, em que BACKEND_SERVICE_NAME é o 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/<var>PROJECT_ID</var>/zones/<var>ZONE</var>/instanceGroups/<var>INSTANCE_GROUP_NAME</var>
       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/<var>PROJECT_ID</var>/global/healthChecks/<var>HEALTH_CHECK_NAME</var>
     loadBalancingScheme: INTERNAL_SELF_MANAGED
     localityLbPolicy: ROUND_ROBIN
     name: <var>BACKEND_SERVICE_NAME</var>
     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 exemplo de disjuntor a seguir refere-se a um caso de uso em que um serviço de carrinho de compras tem um grupo de instâncias como back-end. As configurações do disjuntor indicam os limites no seguinte:

  • Número máximo de solicitações paralelas por conexão
  • Número máximo de conexões paralelas
  • Número máximo de solicitações pendentes
  • Número máximo de solicitações paralelas
  • Número máximo de novas tentativas paralelas

Para configurar esse exemplo de circuito, siga estas etapas:

Console

  1. No Console do Cloud, acesse a página "Traffic Director".

    Acessar a página do Traffic Director

  2. Clique no nome do serviço de back-end que você quer atualizar.
  3. Clique em Edit.
  4. Clique em Configurações avançadas.
  5. Em Disjuntores, marque a caixa de seleção Ativar.
  6. Clique em Editar .
  7. Em Número máximo de solicitações por conexão, insira 100.
  8. Em Máximo de conexões, insira 1000.
  9. Em Máximo de solicitações pendentes, insira 200.
  10. Em Número máximo de solicitações, insira 20000.
  11. Em Máximo de tentativas, insira 3.
  12. Clique em Save.
  13. Clique em Save.

gcloud

  1. Use o comando gcloud export para exportar a configuração do serviço de back-end, em que BACKEND_SERVICE_NAME é o nome do serviço de back-end.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
        --destination=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 baseada em HTTP_COOKIE, siga estas instruções.

Para configurar a afinidade de sessão usando HTTP_COOKIE:

Console

  1. No Console do Cloud, acesse a página "Traffic Director".

    Acessar a página do Traffic Director

  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.

  7. No campo Nome do cookie HTTP, insira http_cookie.

  8. No campo Caminho do cookie HTTP, insira /cookie_path.

  9. No campo TTL do cookie HTTP, digite 100.

  10. No campo Tamanho mínimo do anel, insira 10000.

  11. Clique em SALVAR.

gcloud

  1. Use o comando gcloud export para exportar a configuração do serviço de back-end, em que BACKEND_SERVICE_NAME é o 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 remoção de hosts não íntegros do grupo de balanceamento de carga é controlada pela detecção de outlier. O Traffic Director 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.

A detecção de outlier está configurada no recurso de serviço de back-end.

Console

  1. No Console do Cloud, acesse a página "Traffic Director".

    Acessar a página do Traffic Director

  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 .

  7. Defina Erros consecutivos como 5.

  8. Defina Intervalo como 1000 milissegundos.

  9. Defina o Tempo de expulsão base para 30000 milissegundos.

  10. Clique em Save.

  11. Clique em Save.

gcloud

  1. Use o comando gcloud export para exportar a configuração do serviço de back-end, em que BACKEND_SERVICE_NAME é o 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 your_service_name:

    name: your_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
    

Como 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 pelo Traffic Director. 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.

Console

  1. No Console do Cloud, acesse a página "Traffic Director".

    Acessar a página do Traffic Director

  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. Use o comando gcloud export para exportar a configuração do serviço de back-end, em que BACKEND_SERVICE_NAME é o 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.

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

MetadataFilters estão ativados com regras de encaminhamento e HttpRouteRuleMatch. Use esse recurso para controlar uma regra de encaminhamento ou regra 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 metadatafilter. 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 apenas para os Envoy com metadados de nó que contenham "app: review" e "version: canary".

Siga as etapas abaixo para adicionar MetadataFilters à regra de encaminhamento.

Para adicionar MetadataFilter 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. Atualize o arquivo forwarding-rule1-config.yaml.

    metadataFilters:
    - filterMatchCriteria: 'MATCH_ALL'
      filterLabels:
      - name: 'app'
        value: 'review'
      - name: 'version'
        value: 'canary'
    
  3. 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
    
  4. Use estas instruções para adicionar metadados de nó ao Envoy antes de iniciar o Envoy. Somente o valor da string é compatível.

    a. Para uma implantação baseada em VM, em bootstrap_template.yaml, adicione o seguinte na seção de metadados:

        app: 'review'
        version: 'canary'
    

    b. Para a 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 uso 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ê queira que os recursos do Traffic Director 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 Traffic Director para isolar project1:

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 Traffic Director 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:

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.

Como solucionar problemas

Use estas informações para solucionar problemas quando o tráfego não estiver sendo encaminhado 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 para uma determinada regra de rota.

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

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

    • A regra de rota corresponde ao 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 rota

    • A regra de rota corresponde a regexMatch = '/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' is routed to service-1. Mesmo que a segunda regra tenha correspondência, ela é ignorada porque a primeira regra tinha prioridade.

Limitações

  • Se o valor de BackendService.sessionAffinity não é NENHUM e BackendService.localityLbPolicy está definida como uma política de balanceamento de carga diferente de MAGLEV, RING_HASH, as configurações de afinidade da sessão não terão efeito.
  • UrlMap.headerAction, UrlMap.defaultRouteAction e UrlMap.defaultUrlRedirect não funcionam atualmente como pretendido. Você precisa especificar UrlMap.defaultService para processar o tráfego que não corresponde a nenhum dos hosts em UrlMap.hostRules[] nesse UrlMap. Da mesma forma, UrlMap.pathMatchers[].headerAction, UrlMap.pathMatchers[].defaultRouteAction e UrlMap.pathMatchers[].defaultUrlRedirect não funcionam no momento. Você precisa especificar UrlMap.pathMatchers[].defaultService para processar o tráfego que não corresponde a nenhuma das routeRules nessa pathMatcher.
  • O comando gcloud import não exclui os campos de nível superior do recurso, como o serviço de back-end e o mapa de URL. Por exemplo, se um serviço de back-end for criado com configurações para circuitBreakers, essas configurações poderão ser atualizadas por meio de um comando gcloud import subsequente. No entanto, essas configurações não podem ser excluídas do serviço de back-end. O recurso em si pode ser excluído e recriado sem as configurações do circuitBreakers.
  • A importação de regras de encaminhamento não funciona corretamente. Um arquivo YAML exportado não pode ser reimportado. A solução alternativa é exportar o arquivo de configuração, fazer alterações, excluir a regra de encaminhamento e importar o arquivo de configuração.