Configure a gestão de tráfego para balanceadores de carga de aplicações internos

Este documento mostra exemplos de utilização da gestão do tráfego para alguns exemplos de utilização específicos. São possíveis muitos outros exemplos de utilização.

O documento contém exemplos para os seguintes equilibradores de carga:

• Balanceador de carga de aplicações externo regional
• Balanceador de carga de aplicações interno regional
• Balanceador de carga de aplicações interno entre regiões

Balanceador de carga de aplicações externo regional versus balanceador de carga de aplicações interno regional. Para a configuração de gestão de tráfego dos balanceadores de carga regionais, a API de mapa de URLs regional e a documentação da API de serviço de back-end regional fornecem uma lista completa de campos, incluindo semântica relativa a relações, restrições e cardinalidade.

A única diferença entre estes dois balanceadores de carga é o esquema de balanceamento de carga, da seguinte forma:

• Os balanceadores de carga de aplicações externos regionais usam o EXTERNAL_MANAGED.
• Os balanceadores de carga de aplicações internos regionais usam INTERNAL_MANAGED.

Balanceador de carga de aplicações interno regional versus balanceador de carga de aplicações interno entre regiões. Para a configuração de gestão de tráfego:

• Os Application Load Balancers internos regionais usam a API de mapa de URLs regional e a documentação da API de serviço de back-end regional fornece uma lista completa de campos, incluindo semântica relativa a relações, restrições e cardinalidade.

• Os balanceadores de carga de aplicações internos entre regiões usam a API global de mapa de URLs , e a documentação da API global de serviço de back-end fornece uma lista completa de campos, incluindo semântica relativa a relações, restrições e cardinalidade.

Além das funcionalidades de encaminhamento avançadas descritas nesta página, os equilibradores de carga de aplicações suportados integram-se com as extensões de serviço para lhe permitir inserir lógica personalizada no caminho de dados do equilíbrio de carga.

Antes de começar

• Certifique-se de que compreende como funciona a gestão de tráfego. Para mais informações, leia o artigo Conceitos de gestão de tráfego.

• Siga as instruções em Configure um Application Load Balancer interno e configure todos os anfitriões de VMs ou clusters do GKE de que precisa.

• Crie a verificação de funcionamento necessária ou reutilize uma existente, conforme descrito em Configurar o balanceador de carga.

Configure a gestão de tráfego

No ambiente de configuração escolhido, configura a gestão de tráfego através de configurações YAML. Um mapa de URLs e um serviço de back-end têm cada um o seu próprio ficheiro YAML. Consoante a funcionalidade desejada, tem de escrever um ficheiro YAML de mapa de URLs, um ficheiro YAML de serviço de back-end ou ambos.

Para obter ajuda na escrita destes ficheiros YAML, pode usar os exemplos nesta página e a documentação da API Cloud Load Balancing.

Para equilibradores de carga de aplicações internos regionais e equilibradores de carga de aplicações externos regionais, a documentação da API de mapa de URLs regional e da API de serviço de back-end regional fornece uma lista completa de campos, incluindo semântica relativa a relações, restrições e cardinalidade.

Aceda aos exemplos de YAML na Trusted Cloud consola

Para aceder a exemplos de YAML na Trusted Cloud consola:

1. Na Trusted Cloud consola, aceda à página Equilíbrio de carga.

   Aceda a Balanceamento de carga

2. Clique em Criar equilibrador de carga.
3. Conclua os passos do assistente para criar um Application Load Balancer interno regional.
4. Na configuração Regras de encaminhamento, selecione Regra avançada de anfitrião, caminho e rota.
5. Clique em Adicionar anfitriões e correspondência de caminhos.
6. Clique no link Orientações sobre o código.

É apresentada a página Exemplos de YAML do Path matcher.

Mapeie o tráfego para um único serviço

Enviar todo o tráfego para um único serviço. Certifique-se de que substitui os marcadores de posição.

    defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
        - matchRules:
            - prefixMatch: /PREFIX
          priority: 1
          routeAction:
            weightedBackendServices:
              - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
                weight: 100

Divida o tráfego entre dois serviços

Dividir o tráfego entre dois ou vários serviços. Certifique-se de que substitui os marcadores de posição.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_2
           weight: 5

Configure um redirecionamento de URL

O exemplo seguinte devolve um código de resposta 3xx configurável. O exemplo também define o cabeçalho de resposta Location com o URI adequado, substituindo o anfitrião e o caminho, conforme especificado na ação de redirecionamento.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: URL_MAP_NAME
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     defaultUrlRedirect:
       hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
       pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
       stripQuery: True

Tráfego de espelho

Além de encaminhar o pedido para o serviço de back-end selecionado, pode enviar um pedido idêntico para o serviço de back-end duplicado configurado com base no princípio fire and forget. Isto significa que o balanceador de carga não aguarda uma resposta do back-end para o qual envia o pedido espelhado. O pedido de replicação é útil para testar uma nova versão de um serviço de back-end. Também pode usá-lo para corrigir erros de produção numa versão de depuração do seu serviço de back-end, em vez de na versão de produção.

Por predefinição, o serviço de back-end espelhado recebe todos os pedidos, mesmo que o tráfego original esteja a ser dividido entre vários serviços de back-end ponderados. Pode configurar o serviço de back-end espelhado para receber apenas uma percentagem dos pedidos através da flag mirrorPercent opcional para especificar a percentagem de pedidos a espelhar, expressa como um valor entre 0 e 100,0. A replicação de pedidos baseada em percentagem está em pré-visualização.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: 1
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

Tenha em atenção as seguintes limitações quando usar a replicação de tráfego:

• A replicação de tráfego é suportada quando ambos os serviços de back-end têm grupos de instâncias geridos, NEGs zonais ou back-ends de NEGs híbridos. Não é suportado para NEGs de Internet, NEGs sem servidor e back-ends do Private Service Connect.
• Os pedidos ao serviço de back-end espelhado não geram registos nem métricas para o Cloud Logging e o Cloud Monitoring.

Reescrever o URL pedido

Reescrever a parte do URL referente ao nome do anfitrião, a parte do URL referente ao caminho ou ambas antes de enviar um pedido ao serviço de back-end selecionado. Certifique-se de que substitui os marcadores de posição.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           urlRewrite:
             hostRewrite: "new-host-name.com" # Omit to keep the requested host
             pathPrefixRewrite: "/new-path/" # Omit to keep the requested path

Voltar a tentar um pedido

Configure as condições em que o equilibrador de carga volta a tentar pedidos com falhas, o tempo que o equilibrador de carga espera antes de voltar a tentar e o número máximo de tentativas permitidas.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

Especifique o limite de tempo do trajeto

Especifique o limite de tempo para o trajeto selecionado. O tempo limite é calculado a partir do momento em que o pedido é totalmente processado até que a resposta seja totalmente processada. O tempo limite inclui todas as novas tentativas. Certifique-se de que substitui os marcadores de posição.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 500000000

Configure a injeção de falhas

Introduzir erros ao processar pedidos para simular falhas, incluindo: latência elevada, sobrecarga do serviço, falhas do serviço e partição da rede. Esta funcionalidade é útil para testar a resiliência de um serviço a falhas simuladas.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 500000000
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

Configure o CORS

Configure políticas de partilha de recursos de origem cruzada (CORS) para processar definições para a aplicação de pedidos CORS.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: my-domain.com
               allowMethods: GET, POST
               allowHeaders: Authorization, Content-Type
               maxAge: 1200
               allowCredentials: True

Adicione e remova cabeçalhos de pedidos e respostas

Adicionar e remover cabeçalhos de pedidos antes de enviar um pedido ao serviço de back-end. Adicionar e remover também cabeçalhos de respostas após receber uma resposta do serviço de back-end.

Os balanceadores de carga de aplicações externos regionais e os balanceadores de carga de aplicações internos também suportam a utilização de variáveis em cabeçalhos personalizados. Pode especificar uma ou mais variáveis nos campos de valor do cabeçalho personalizado (headerValue) que são, em seguida, traduzidas para os respetivos valores por pedido. Para ver uma lista de valores de cabeçalho suportados, consulte o artigo Crie cabeçalhos personalizados em mapas de URLs.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
               headerAction:
                 requestHeadersToAdd:
                 - headerName: header-1-name
                   headerValue: header-1-value
                   replace: True
                 requestHeadersToRemove:
                 - header-2-name
                 - header-3-name
                 responseHeadersToAdd:
                 - headerName: header-4-name
                   headerValue: header-4-value
                   replace: True
                responseHeadersToRemove:
                - header-5-name
                - header-6-name

Configure a deteção de valores atípicos

Especifique os critérios para a remoção de VMs ou pontos finais de back-end não íntegros em NEGs, juntamente com os critérios que definem quando um back-end ou um ponto final é considerado suficientemente íntegro para receber tráfego novamente. Certifique-se de que substitui os marcadores de posição.

    loadBalancingScheme: LOAD_BALANCING_SCHEME
    localityLbPolicy: RANDOM
    name: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
    outlierDetection:
      baseEjectionTime:
        nanos: 0
        seconds: '30'
      consecutiveErrors: 5
      consecutiveGatewayFailure: 3
      enforcingConsecutiveErrors: 2
      enforcingConsecutiveGatewayFailure: 100
      enforcingSuccessRate: 100
      interval:
        nanos: 0
        seconds: '1'
      maxEjectionPercent: 50
      successRateMinimumHosts: 5
      successRateRequestVolume: 100
      successRateStdevFactor: 1900
    region: region/REGION

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 balanceador de carga deixa de permitir novas ligações ou enviar pedidos adicionais, dando aos seus back-ends tempo para recuperar. Assim, a interrupção do circuito evita falhas em cascata devolvendo um erro ao cliente em vez de sobrecarregar um back-end. Isto permite o fornecimento de algum tráfego, ao mesmo tempo que dá tempo para gerir a situação de sobrecarga, como processar um pico de tráfego aumentando a capacidade através do dimensionamento automático.

Defina limites superiores para pedidos por ligação, bem como o volume de ligações a um serviço de back-end. Também deve limitar o número de pedidos pendentes e de novas tentativas.

    loadBalancingScheme: LOAD_BALANCING_SCHEME # EXTERNAL_MANAGED or INTERNAL_MANAGED
    localityLbPolicy: RANDOM
    affinityCookieTtlSec: 0
    backends:
    - balancingMode: UTILIZATION
      capacityScaler: 1.0
      group: region/REGION/instanceGroups/INSTANCE_GROUP
      maxUtilization: 0.8
    circuitBreakers:
      maxConnections: 1000
      maxPendingRequests: 200
      maxRequests: 1000
      maxRequestsPerConnection: 100
      maxRetries: 3
    connectionDraining:
      drainingTimeoutSec: 0
    healthChecks:
    - region/REGION/healthChecks/HEALTH_CHECK

Configure a divisão de tráfego: passos detalhados

Este exemplo demonstra os seguintes passos:

1. Crie modelos distintos para diferentes serviços.

2. Crie grupos de instâncias para esses modelos.

3. Crie regras de encaminhamento que configurem a divisão de tráfego de 95% / 5%.

4. Envie comandos curl que mostrem que as percentagens de divisão do tráfego correspondem aproximadamente à configuração.

Estas instruções pressupõem o seguinte:

• A região é us-west1.

• Foi criado um proxy de destino e uma regra de encaminhamento, juntamente com um mapa de URLs denominado regional-lb-map.

• O mapa de URLs envia todo o tráfego para um serviço de back-end, denominado red-service, que é o serviço de back-end predefinido.

• Configurou um caminho alternativo que envia 5% do tráfego para blue-service e 95% do tráfego para green-service.

• É usado um correspondente de caminhos.

• Está a usar o Cloud Shell ou outro ambiente com o bash instalado.

Defina os serviços

A seguinte função bash cria um serviço de back-end, incluindo o modelo de instância e o grupo de instâncias gerido.

function make_service() {
  local name="$1"
  local region="$2"
  local zone="$3"
  local network="$4"
  local subnet="$5"
  local subdir="$6"

  www_dir="/var/www/html/$subdir"

  (set -x; \
  gcloud compute instance-templates create "${name}-template" \
    --region="$region" \
    --network="$network" \
    --subnet="$subnet" \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee ${www_dir}index.html
  systemctl restart apache2"; \
  gcloud compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud compute backend-services create "${name}-service" \
    --load-balancing-scheme=LOAD_BALANCING_SCHEME\
    --protocol=HTTP \
    --health-checks=regional-lb-basic-check \
    --health-checks-region="$region" \
    --region="$region"; \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --region="$region")
}

Crie os serviços

Chame a função para criar três serviços: red, green e blue. O serviço red funciona como o serviço predefinido para pedidos a /. Os serviços green e blue estão ambos configurados em /PREFIX para processar 95% e 5% do tráfego, respetivamente.

make_service red us-west1 us-west1-a lb-network backend-subnet ""
make_service green us-west1 us-west1-a lb-network backend-subnet /PREFIX
make_service blue us-west1 us-west1-a lb-network backend-subnet /PREFIX

Crie o mapa de URLs

Teste a configuração

Para testar a configuração, primeiro, certifique-se de que os pedidos ao endereço IP do balanceador de carga configurado anteriormente são processados pela configuração red predefinida.

Em seguida, verifique se os pedidos enviados para FORWARDING_RULE_IP_ADDRESS/PREFIX são divididos conforme esperado.

Crie uma VM de cliente

Para ver instruções, consulte o artigo Criar uma instância de VM na zona para testar a conetividade.

Enviar pedidos para FORWARDING_RULE_IP_ADDRESS

1. Use ssh para estabelecer ligação ao cliente.

   gcloud compute ssh global-lb-client-us-west1-a \
      --zone=us-west1-a
   

2. Execute o seguinte comando:

   for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
      RESULTS=
      for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}`"; done >/dev/null 2>&1
      IFS=':'
      echo "***"
      echo "*** Results of load balancing to $LB_IP: "
      echo "***"
      for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
      echo
   done
   

Verifique os resultados

***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

Enviar pedidos para FORWARDING_RULE_IP_ADDRESS/PREFIX

Envie pedidos para FORWARDING_RULE_IP_ADDRESS/PREFIX e tenha em atenção a divisão de tráfego.

for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
    RESULTS=
    for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}/PREFIX/index.html`"; done >/dev/null 2>&1
    IFS=':'
    echo "***"
    echo "*** Results of load balancing to $LB_IP/PREFIX: "
    echo "***"
    for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
    echo
done

Verifique os resultados

***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS/PREFIX:
***
21 blue-instance-group-8n49
27 blue-instance-group-vlqc
476 green-instance-group-c0wv
476 green-instance-group-rmf4

A configuração de teste canary envia com êxito 95% dos pedidos /PREFIX para o serviço green e 5% para o serviço blue.

Configure a afinidade de sessão com base em HTTP_COOKIE

O controlo de tráfego permite-lhe configurar a afinidade de sessão com base num cookie fornecido. Para configurar a afinidade de sessão baseada em HTTP_COOKIE para um serviço de back-end denominado red-service, siga estas instruções.

1. Use o comando gcloud compute backend-services export para obter a configuração do serviço de back-end.

   gcloud compute backend-services export red-service \
       --destination=red-service-config.yaml \
       --region=us-west1
   

2. Atualize o ficheiro red-service-config.yaml da seguinte forma:

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

3. No ficheiro red-service-config.yaml, elimine a seguinte linha:

   sessionAffinity: NONE
   

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

   gcloud compute backend-services import red-service \
       --source=red-service-config.yaml \
       --region=us-west1
   

Resolução de problemas

Use estas informações para a resolução de 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: verifique a ordem das regras de encaminhamento. As regras de encaminhamento são interpretadas pela ordem em que são especificadas.

As regras de encaminhamento num mapa de URLs são interpretadas pela ordem em que são especificadas. Isto é diferente da forma como as regras de caminho são interpretadas pela correspondência do prefixo mais longo. Para uma regra de caminho, os equilibradores de carga de aplicações internos selecionam apenas uma regra de caminho. No entanto, quando usa regras de encaminhamento, podem aplicar-se mais do que uma.

Quando definir regras de encaminhamento, certifique-se de que as regras na parte superior da lista não encaminham inadvertidamente tráfego que, de outra forma, teria sido encaminhado por uma regra de encaminhamento subsequente. O serviço que recebe tráfego encaminhado incorretamente provavelmente rejeita pedidos, e o serviço nas suas regras de encaminhamento recebe tráfego reduzido ou nenhum tráfego.

O que se segue?

• Limpe a configuração do balanceador de carga.