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

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 balanceadores de carga de aplicações externos globais. Os balanceadores de carga de aplicações externos globais usam o EXTERNAL_MANAGEDesquema de balanceamento de carga e os componentes de balanceamento de carga global, como a regra de encaminhamento, o mapa de URLs e o serviço de back-end.

Para ver informações sobre a gestão de tráfego com um balanceador de carga de aplicações clássico, consulte o artigo Vista geral da gestão de tráfego para um balanceador de carga de aplicações clássico.

Para mais informações sobre a gestão de tráfego com balanceadores de carga de aplicações externos regionais, consulte o artigo Vista geral da gestão de tráfego para balanceadores de carga de aplicações externos regionais.

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 a Vista geral da gestão de tráfego para balanceadores de carga de aplicações externos globais.

Configure e teste 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 escolhida, 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.

A consola Google Cloud não é suportada.

A documentação da API global de mapas de URLs e da API global de serviços de back-end fornece uma lista completa de campos, incluindo semântica relativa a relações, restrições e cardinalidade.

Pode adicionar testes de configuração a um mapa de URLs para garantir que o mapa de URLs encaminha os pedidos conforme previsto. Pode experimentar diferentes regras de mapeamento de URLs e executar tantos testes quanto necessário para garantir que o mapa encaminha o tráfego para o serviço de back-end ou o contentor de back-end adequado. Para ver detalhes, consulte o artigo Adicione testes a um mapa de URLs. Se quiser testar novas alterações a um mapa de URLs sem implementar realmente o mapa, consulte o artigo Valide a configuração do mapa de URLs.

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/global/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: /PREFIX
        priority: PRIORITY  # 0 is highest
        routeAction:
          weightedBackendServices:
          - backendService: projects/PROJECT_ID/global/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/global/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
           weight: 5

Configure um redirecionamento de URL

O exemplo seguinte devolve um código de resposta 301 MOVED_PERMANENTLY_DEFAULT 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.

Para criar um redirecionamento para um bucket de back-end, use projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET para o campo defaultService.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: <var>URL_MAP_NAME</var>
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/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/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

Se tiver vários serviços de back-end ponderados e quiser registar que serviço de back-end foi usado para publicar o pedido original, pode adicionar um cabeçalho personalizado que inclua estas informações a todos os pedidos. O exemplo seguinte adiciona um cabeçalho personalizado denominado x-weighted-picked-backend a todos os pedidos do cliente. Para o valor do cabeçalho, use o nome do serviço de back-end que processou o pedido original.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
              weight: 95
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_1
                  replace: True
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
              weight: 5
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_2
                  replace: True
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_3

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 ambos 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/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/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/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/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/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 0

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/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 0
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

Configure o CORS

Configure políticas de partilha de recursos de origem cruzada (CORS) para controlar a forma como o seu equilibrador de carga processa pedidos de origem cruzada.

Política de CORS aplicada ao nível do correspondente de caminhos

Nesta configuração, a política de CORS é definida no defaultRouteAction do correspondente de caminhos (pathMatchers[].defaultRouteAction.corsPolicy). Isto significa que a política é aplicada a todos os pedidos encaminhados através do correspondente de caminhos predefinido, independentemente do caminho ou da rota específicos.

Esta abordagem é adequada quando quer uma política de CORS única e consistente para todas as rotas geridas por um correspondente de caminho.

defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
  - '*'
  pathMatcher: path-matcher-1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
  name: path-matcher-1
- defaultRouteAction:
    corsPolicy:
      allowCredentials: true
      allowOrigins: [ "http://example.com" ]
      allowMethods: [ "GET", "POST" ]
      allowHeaders: [ "Authorization", "Content-Type" ]

Como funciona

  • O equilibrador de carga aplica a política CORS a todos os pedidos processados pelo correspondente de caminhos.
  • Apenas são permitidos pedidos do anfitrião example.com que usem os métodos GET ou POST e que tenham os cabeçalhos permitidos (Authorization, Content-Type).
  • As credenciais (como cookies ou cabeçalhos de autorização) são permitidas em pedidos de origem cruzada.
  • O serviço de back-end recebe apenas pedidos em conformidade com esta política de CORS.

Política CORS aplicada ao nível da regra de encaminhamento

Nesta configuração, a política de CORS é definida num routeAction para uma regra de rota específica (pathMatchers[].routeRules[].routeAction.corsPolicy). Isto permite-lhe aplicar políticas de CORS diferentes a diferentes rotas ou prefixos de caminhos.

Esta abordagem é adequada quando precisa de um controlo detalhado, como aplicar diferentes políticas de CORS a diferentes pontos finais ou caminhos da API.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: [ "http://example.com" ]
               allowMethods: [ "GET", "POST" ]
               allowHeaders: [ "Authorization", "Content-Type" ]
               maxAge: 1200
               allowCredentials: true

Como funciona

  • A política de CORS é aplicada apenas a pedidos que correspondam ao prefixo do caminho especificado (por exemplo, /PREFIX).
  • Apenas os pedidos do anfitrião example.com que usam métodos GET ou POST e que têm os cabeçalhos permitidos são permitidos para esta rota.
  • O campo maxAge especifica durante quanto tempo os resultados de um pedido de pré-voo podem ser colocados em cache pelo navegador (em segundos).
  • As credenciais são permitidas em pedidos de origem cruzada.
  • Outras rotas podem ter políticas de CORS diferentes ou nenhuma.

Também pode definir uma política CORS nos seguintes níveis de um mapa de URLs:

  • defaultRouteAction.corsPolicy
  • pathMatchers[].pathRules[].routeAction.corsPolicy

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.

Existem restrições nos valores válidos para headerName e headerValue. Para ver detalhes, consulte o artigo Como funcionam os cabeçalhos personalizados.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               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: EXTERNAL_MANAGED
    localityLbPolicy: RANDOM
    name: projects/PROJECT_ID/global/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

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:

  • Foi criado um proxy de destino e uma regra de encaminhamento, juntamente com um mapa de URLs denominado global-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.

Estas instruções pressupõem que foi criada uma verificação de funcionamento de HTTP (global-lb-basic-check). Para ver instruções, consulte uma das seguintes páginas:

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=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=global-lb-basic-check \
    --global \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --global)
}

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

Consola

  1. Aceda à página Equilíbrio de carga na Google Cloud consola.
    Aceda a Balanceamento de carga
  2. Clique no link global-lb-map.
  3. Clique em Editar .

Configure as novas regras de encaminhamento

  1. Em Regras de encaminhamento, selecione Regra avançada de anfitrião, caminho e rota.
  2. Em Novos anfitriões e correspondência de caminhos, crie a ação predefinida definindo o Serviço como red-service.
  3. Clique em Concluído.
  4. Clique em Adicionar anfitriões e correspondência de caminhos.
  5. No campo Anfitriões, introduza o endereço IP da regra de encaminhamento do balanceador de carga.

  6. Cole o seguinte conteúdo YAML na caixa Correspondência de caminhos:

    defaultService: projects/PROJECT_ID/global/backendServices/red-service
name: matcher1
routeRules:
- priority: 2
  matchRules:
    - prefixMatch: /PREFIX
  routeAction:
    weightedBackendServices:
      - backendService: projects/PROJECT_ID/global/backendServices/green-service
        weight: 95
      - backendService: projects/PROJECT_ID/global/backendServices/blue-service
        weight: 5

  7. Clique em Concluído.

  8. Clique em Atualizar.

gcloud

  1. Exporte o mapa de URLs existente através do comando gcloud compute url-maps export:

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

  2. Atualize o ficheiro de mapa de URLs global-lb-map-config.yaml adicionando o seguinte ao final do ficheiro:

    hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /PREFIX
    routeAction:
      weightedBackendServices:
        - backendService: projects/PROJECT_ID/global/backendServices/green-service
          weight: 95
        - backendService: projects/PROJECT_ID/global/backendServices/blue-service
          weight: 5

  3. Atualize o mapa de URLs com o comando gcloud compute url-maps import:

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

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.

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 \
    --global

  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: 0
 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 \
    --global

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.

Para obter informações sobre o registo e a monitorização, consulte o artigo Registo e monitorização de HTTP(S) externo.

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, o Application Load Balancer externo global seleciona apenas uma regra de caminho. No entanto, quando usa regras de encaminhamento, podem aplicar-se mais do que uma.

Quando define 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?