Gerenciamento de tráfego com regras de rota e políticas de tráfego

O balanceamento de carga HTTP(S) interno é alimentado pela mesma tecnologia do Traffic Director com o Envoy totalmente gerenciado. Assim, é possível usar regras de rota e tráfego para controlar o tráfego na implantação. No balanceamento de carga de HTTP(S) interno, estão disponíveis os recursos avançados de controle de tráfego da Envoy, com o uso dos componentes já conhecidos de balanceamento de carga do GCP: mapas de URLs e serviços de back-end.

Uma regra de rota corresponde às informações em uma solicitação recebida e toma uma decisão de roteamento com base na correspondência. O GCP procura a primeira regra de rota que tenha regras de correspondência que correspondam à solicitação. Depois disso, o GCP para de analisar qualquer outra regra. Em seguida, o GCP aplica as ações na regra de rota. A regra de rota é uma alternativa à correspondência de caminho e a uma regra de caminho.

Depois que o tráfego é roteado, as políticas de tráfego adotam outras medidas para gerenciar seu tráfego:

  • O algoritmo de balanceamento de carga é controlado pelas configurações do balanceador de carga.
  • O volume de conexões para um serviço de upstream é controlado pelas configurações do pool de conexão.
  • A remoção de hosts não íntegros do grupo de balanceamento de carga é controlada pela detecção de outlier.

Exemplos de casos de uso

As regras de rota e as políticas de tráfego permitem que você implemente divisão de tráfego, direcionamento de tráfego, injeção de falhas, disjuntor e espelhamento.

A divisão de tráfego permite que uma regra de rota tenha vários serviços de back-end, em que cada serviço de back-end recebe uma porcentagem especificada das solicitações correspondidas pela regra de rota. Por exemplo, é possível enviar 95% do tráfego para uma instância de serviço e 5% para outra. A divisão de tráfego normalmente é usada para implantar novas versões, testes A/B, migração de serviço e processos semelhantes.

Divisão de tráfego do Google Cloud Load Balancing (clique para ampliar)
Divisão de tráfego do Google Cloud Load Balancing (clique para ampliar)

O direcionamento de tráfego direciona o tráfego para instâncias de serviço com base no conteúdo dos cabeçalhos de solicitação HTTP. Por exemplo, se o dispositivo do usuário for Android, com user-agent:Android no cabeçalho da solicitação, o tráfego será direcionado às instâncias de serviço designadas para receber tráfego Android. O tráfego que não tiver user-agent:Android no cabeçalho será direcionado às instâncias que lidam com outros dispositivos.

Direcionamento de tráfego do Google Cloud Load Balancing (clique para ampliar)
Direcionamento de tráfego do Google Cloud Load Balancing (clique para ampliar)

A injeção de falhas permite testar a resiliência dos serviços por meio da simulação de situações de falha de serviço, como atrasos e solicitações canceladas. O proxy é configurado, por meio da injeção de atraso a fim de introduzir atrasos para uma fração de solicitações antes de enviar a solicitação ao serviço de back-end selecionado. O proxy é configurado, por meio da Injeção de cancelamento, para responder diretamente a uma fração de solicitações com códigos de resposta a falhas, em vez de encaminhar essas solicitações ao serviço de back-end.

O disjuntor impõe um limite a todas as solicitações para um serviço específico, caso um serviço diferente não consiga alcançar o serviço por um número configurável de tentativas consecutivas.

O espelhamento permite que você envie uma cópia das solicitações correspondidas por uma regra de rota para um segundo serviço de back-end. Como o proxy não espera uma resposta do segundo serviço de back-end, elas são descartadas. O espelhamento é útil para testar uma nova versão de um serviço de back-end. Ele pode ser usado também para depurar erros de produção em uma versão de depuração do serviço de back-end, mas não na versão de produção.

Sobre as regras de rota

As regras de rota fornecem várias maneiras de corresponder às solicitações HTTP e realizar várias ações, como divisão de tráfego em vários serviços de back-end, respondendo com redirecionamentos e alterando solicitações ou respostas. As regras de roteamento são executadas em ordem, oferecendo flexibilidade para vincular as ações de acordo com as regras nos mapas de URLs. Observe que, quando a primeira correspondência é feita, o balanceamento de carga de HTTP(S) interno para de avaliar as regras e todas as regras restantes são ignoradas.

  • As regras de correspondência ativam o balanceamento de carga de HTTP(S) interno para corresponder a um ou mais atributos de uma solicitação e executar ações especificadas na regra de rota. Os seguintes atributos de uma solicitação podem ser usados para especificar os critérios de correspondência:

    • Host: um nome de host é a parte do nome de domínio de um URL, por exemplo, a parte do nome do host do URL http://example.net/video/hd é example.net. Na solicitação, o nome do host vem do cabeçalho Host, mostrado neste exemplo de comando curl:
    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    

    em que 10.1.2.9 é o endereço IP com balanceamento de carga.

    • Os caminhos seguem o nome do host, por exemplo, /images. A regra pode especificar se a correspondência deve ser feita com todo o caminho ou apenas com a parte inicial dele.

    • Outros parâmetros de solicitação HTTP, como cabeçalhos HTTP, que permitem a correspondência de cookies e a correspondência com base em parâmetros de consulta (variáveis GET).

  • As ações de rota configuram o balanceamento de carga HTTP(S) interno com ações específicas a serem executadas quando uma regra de rota corresponde aos atributos de uma solicitação. Use as seguintes ações de rota avançadas:

    • Redirecionamentos: o balanceamento de carga de HTTP(S) interno retorna um código de resposta 3xx configurável. Ele também define o cabeçalho de resposta de Location com o URI apropriado, substituindo o host e o caminho, conforme especificado na ação de redirecionamento.

    • Regravações de URL: o balanceamento de carga de HTTP(S) interno pode reescrever a parte do nome do host do URL, a parte do caminho do URL ou ambas, antes de enviar uma solicitação ao serviço de back-end selecionado.

    • Transformações de cabeçalho: o balanceamento de carga HTTP(S) interno pode adicionar ou remover cabeçalhos de solicitação, antes de enviar uma solicitação ao serviço de back-end. Ele também pode adicionar ou remover cabeçalhos de resposta depois de receber uma resposta do serviço de back-end.

    • Espelhamento de tráfego: além de encaminhar a solicitação ao serviço de back-end selecionado, o balanceamento de carga HTTP(S) interno envia uma solicitação idêntica ao serviço de back-end espelho, configurado como autônomo ("fire and forget"). O espelhamento é útil para testar uma nova versão de um serviço de back-end. Ele pode ser usado também para depurar erros de produção em uma versão de depuração do serviço de back-end, mas não na versão de produção.

    • Divisão de tráfego ponderada é uma configuração que permite a distribuição do tráfego de uma regra correspondida para vários serviços de back-end, de maneira proporcional a uma ponderação definida pelo usuário e atribuída ao serviço de back-end individual. Esse recurso é útil para configurar implantações em estágios ou testes A/B. Por exemplo, a ação de rota pode ser configurada de forma que 99% do tráfego seja enviado a um serviço que executa uma versão estável de um aplicativo, enquanto 1% do tráfego é enviado a um serviço separado, em está sendo executada uma versão mais recente desse aplicativo.

  • As novas tentativas configuram as condições em que o balanceador de carga faz novas tentativas das solicitações com falha, quanto tempo o balanceador de carga aguarda antes de tentar novamente e o número máximo de novas tentativas permitidas.

  • Injeção de falha: o balanceamento de carga de HTTP(S) interno pode intencionalmente introduzir erros ao atender solicitações de serviço para simular falhas, incluindo alta latência, sobrecarga de serviço, falhas de serviço e particionamento de rede. Esse recurso é útil para testar a resiliência de um serviço a falhas simuladas.

  • A injeção de atraso configura o proxy para introduzir atrasos em uma parte das solicitações definida pelo usuário, antes de enviar a solicitação ao serviço de back-end selecionado.

  • O proxy é configurado, por meio da "Injeção de cancelamento", para responder diretamente a uma fração de solicitações com códigos de status HTTP definidos pelo usuário, em vez de encaminhar essas solicitações ao serviço de back-end.

  • Políticas de segurança: as políticas de Compartilhamento de recursos entre origens (CORS, na sigla em inglês), gerenciam as configurações de balanceamento de carga HTTP(S) interno para impor solicitações de CORS.

Sobre as políticas de tráfego

Políticas de tráfego são grupos de configurações que definem como o balanceamento de carga se comporta, incluindo a resposta a falhas de serviços de back-end e como evitar que falhas localizadas afetem o resto da malha de serviços. Os seguintes recursos da política de tráfego são configurados no serviço de back-end.

  • Política de balanceamento de carga: o balanceamento de carga HTTP(S) interno faz o balanceamento de carga com base na capacidade disponível e, conforme declarado na documentação do Envoy, define as ponderações do balanceamento de carga no nível de localidade, por zona do Google Cloud Platform, para que o proxy escolha a zona do GCP para VMs ou endpoints de back-end em NEGs. As políticas de balanceamento de carga, especificadas no serviço de back-end, determinam o algoritmo usado para VMs de back-end ou endpoints em NEGs na localidade a ser escolhida após a escolha da localidade ponderada. Os algoritmos de balanceamento de carga incluem ordem aleatória, anel de hash e VMs ou endpoints de back-ends em NEGs com menos solicitações. No balanceamento de carga de HTTP(S) interno, o balanceamento de carga é executado usando mapas de URL e serviços de back-end.

  • Afinidade de sessão: o balanceamento de carga HTTP(S) interno oferece várias opções de afinidade de sessão: afinidade baseada em cookie HTTP, afinidade baseada em cabeçalho HTTP, afinidade de endereço IP do cliente e afinidade de cookie gerada. Observe que as configurações de afinidade não serão honradas se mais de um weightedBackendServices estiver incluído na routeAction. Para saber mais informações sobre a afinidade de sessão, leia Afinidade de sessão.

  • A detecção de outlier é um conjunto de políticas que especificam os critérios para despejo de VMs de back-ends não íntegros ou endpoints em NEGs, juntamente com os critérios que definem quando um back-end ou endpoint é considerado íntegro o suficiente para receber tráfego novamente.

  • O disjuntor estabelece limites superiores no volume de conexões e solicitações por conexão para um serviço de back-end.

Modelo de dados de controle de tráfego

Os recursos atuais do GCP são usados para implementar recursos, como rotas avançadas e políticas de tráfego. O diagrama a seguir mostra quais recursos são usados para implementar cada recurso:

Direcionamento de tráfego do Google Cloud Load Balancing (clique para ampliar)
Modelo de dados do Google Cloud Load Balancing (clique para ampliar)

Recurso de mapa de URLs

O componente de mapa de URLs é estendido para oferecer suporte a recursos de roteamento avançados na correspondência de caminhos. É possível fazer a correspondência de solicitações com base no prefixo do caminho, caminho completo, cabeçalho HTTP e parâmetro de consulta. O prefixo e o caminho completo são válidos para a parte do caminho da correspondência. Para saber mais informações, leia a documentação RouteMatch do proxy Envoy.

  • Correspondência de caminhos: o balanceamento de carga HTTP(S) interno estende o conceito de correspondência de caminho de mapa de URLs. É possível continuar usando regras de caminho simples, como você faria para um balanceador de carga HTTP(S) do GCP ou usar regras de rota. Use os dois tipos de regras exclusivamente. Um único mapa de URLs pode conter somente um dos dois tipos. As regras de caminho são avaliadas em termos de primeiro o caminho mais longo e podem ser especificadas em qualquer ordem. As regras de rota são interpretadas em ordem. Isso permite maior flexibilidade na definição de critérios de rota complexos.

    • Regras de roteamento (HttpRouteRule): o balanceamento de carga de HTTP(S) interno avalia regras de roteamento na ordem em que elas são especificadas. Isso permite que você defina critérios de rota complexos. A seguir, veja os componentes de uma regra de rota:

      • Correspondência de regra de rota (HttpRouteRuleMatch): permite determinar se a regra de rota é válida para uma solicitação ao corresponder a todos ou a um subconjunto de atributos da solicitação, como o caminho, cabeçalhos HTTP e parâmetros de consulta (GET).

        Em um HttpRouteRuleMatch, todos os critérios correspondentes precisam ser atendidos para que as ações de regra entrem em vigor. Se uma regra tiver vários HttpRouteRuleMatches, as ações dela terão efeito quando uma solicitação corresponder a qualquer um dos respectivos HttpRouteRuleMatches.

      • Ação de rota (HttpRouteAction): permite especificar as ações que o balanceamento de carga de HTTP(S) interno deve executar quando os critérios em HttpRouteRuleMatch forem atendidos. Essas ações incluem divisão de tráfego, regravações de URLs, repetição e espelhamento, nova tentativa e espelhamento, injeção de falhas e política de CORS.

      • Ação de redirecionamento (HttpRedirectAction): é possível configurar o balanceamento de carga HTTP(S) interno para responder com um redirecionamento HTTP quando os critérios em HttpRouteRuleMatch forem atendidos.

      • Ação de cabeçalho (HttpHeaderAction): é possível configurar regras de transformação de cabeçalho de solicitação e resposta quando os critérios em HttpRouteRuleMatch forem atendidos.

    • Regras de caminho (PathRule): o balanceamento de carga HTTP(S) interno oferece suporte a objetos de regra de caminho em correspondências de caminho para manter a compatibilidade com mapas de URLs atuais. As regras de caminho podem ser inseridas em qualquer ordem. O balanceamento de carga HTTP(S) interno tenta fazer a correspondência entre o caminho da solicitação e cada caminho de todas as regras de caminho dessa correspondência de caminho, na base de o caminho mais longo corresponde primeiro. Se ocorrer uma correspondência de caminho, o tráfego será roteado para o serviço de back-end da regra de caminho correspondente.

A hierarquia do mapa de URLs para elementos de rota avançados é a seguinte:

  • Serviço de back-end padrão
  • Apenas balanceamento de carga de HTTP(S) interno: ação de rota padrão
  • Apenas balanceamento de carga de HTTP(S) interno: redirecionamento padrão
  • Apenas balanceamento de carga de HTTP(S) interno: ação de cabeçalho
  • Lista de regras de host
  • Lista de correspondências de caminho, cada uma contendo
    • apenas balanceamento de carga de HTTP(S) interno: ação de rota padrão;
    • apenas balanceamento de carga de HTTP(S) interno: redirecionamento padrão;
    • apenas balanceamento de carga de HTTP(S) interno: ação de cabeçalho;
    • serviço de back-end padrão para a correspondência de caminho;
    • lista de regras de caminho.
    • apenas balanceamento de carga de HTTP(S) interno: lista de regras de roteamento;
      • apenas balanceamento de carga de HTTP(S) interno: lista de regras de correspondência;
      • apenas balanceamento de carga de HTTP(S) interno: serviço de back-end;
      • apenas balanceamento de carga de HTTP(S) interno: ação de rota;
      • apenas balanceamento de carga de HTTP(S) interno: redirecionamento;
      • apenas balanceamento de carga de HTTP(S) interno: ação de cabeçalho;

Recurso de serviço de back-end

O balanceamento de carga de HTTP(S) interno usa um serviço de back-end com um esquema de balanceamento de carga INTERNAL_MANAGED. Um serviço de back-end com esse esquema é compatível com as configurações que implementam a maioria das políticas de tráfego. Os seguintes atributos podem ser especificados para um serviço de back-end gerenciado interno:

  • Política de balanceamento de carga (LocalityLoadBalancingPolicy): para um serviço de back-end gerenciado interno, a distribuição de tráfego usa um modo de balanceamento de carga e uma política de balanceamento de carga. O serviço de back-end primeiro direciona o tráfego para um grupo de back-end (grupo de instâncias, grupo de instâncias gerenciadas ou de endpoints da rede) de acordo com o modo de balanceamento. Em seguida, após a seleção de um grupo de back-ends, o balanceador de carga distribuirá o tráfego de acordo com a política de balanceamento de carga. O modo de balanceamento permite que o balanceamento de carga HTTP(S) interno primeiro selecione uma localidade, como uma zona do GCP. Em seguida, a política de balanceamento de carga é usada para selecionar uma VM ou um endpoint de back-end específico em um NEG.

  • Afinidade de sessão (SessionAffinity): os serviços de back-end gerenciados internos aceitam quatro afinidades de sessão: endereço IP do cliente, baseado em cookie HTTP, baseado em cabeçalho HTTP e afinidade de cookie gerado.

  • O hash consistente (ConsistentHashLoadBalancerSettings) define critérios para criar hashes consistentes de cookies e cabeçalhos de balanceamento de carga de HTTP(S) interno, para o reencaminhamento de novas solicitações às mesmas VMs de back-end ou aos mesmos endpoints em NEGs.

  • Os disjuntores (CircuitBreakers) definem parâmetros para limitar o volume de tráfego para qualquer VM de back-end específico ou endpoint do serviço de back-end. Isso evita a sobrecarga dos serviços com solicitações que eles não podem tratar de forma significativa.

  • A detecção de outlier (OutlierDetection) define critérios para determinar quando uma VM de back-end ou um endpoint em um NEG é considerado não íntegro e excluído de avaliações de balanceamento de carga, bem como as condições que precisam ser satisfeitas para reconsiderar a VM de back-end ou os endpoints para balanceamento de carga. Uma VM ou um endpoint de back-end é avaliado como não íntegro quando a verificação de integridade vinculada ao serviço de back-end marca a VM de back-end ou o endpoint em um NEG como não íntegro.

Como configurar o controle de tráfego

Nas seções a seguir, você encontra informações sobre como configurar o controle de tráfego.

Antes de configurar o controle de tráfego

Siga as instruções em Como configurar o balanceamento de carga HTTP(S) interno e configure todos os hosts de VM ou clusters do GKE que sejam necessários. Crie os recursos obrigatórios do GCP.

Como configurar a divisão de tráfego

Neste exemplo, demonstramos as seguintes etapas:

  1. Criar modelos distintos para diferentes serviços.

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

  3. Criar regras de roteamento que configurem 95% / 5% como canary.

  4. Enviar comandos curl, mostrando que as porcentagens de divisão de tráfego correspondem aproximadamente à configuração.

Como definir os serviços

A função bash a seguir cria um serviço de back-end, incluindo o modelo da instância e o grupo de instâncias gerenciadas.

Nestas instruções, presumimos que tenha sido criada uma verificação de integridade HTTP (l7-ilb-basic-check). Consulte as instruções em Como configurar o balanceamento de carga de HTTP interno para VMs do Compute Engine.

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=l7-ilb-tag,http-server \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  sudo apt-get update
  sudo apt-get install apache2 -y
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee $www_dir/index.html
  sudo service apache2 restart
  "; \
  gcloud beta compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud beta compute backend-services create "${name}-service" \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-basic-check \
    --health-checks-region="$region" \
    --region="$region"; \
  gcloud beta compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --region="$region")
}

Como criar 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 padrão para solicitações de /. Os serviços green e blue estão configurados com /prefix para processar 95% e 5% do tráfego, respectivamente.

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

Como criar o arquivo de mapa de URLs

Grave um arquivo de mapa de URLs canary.yaml com a configuração canary que você quiser.

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

  • A região é us-west1.
  • Sua implantação de balanceamento de carga HTTP(S) interno tem um mapa de URLs chamado l7-ilb-map.
  • Foram criados um proxy de destino e uma regra de encaminhamento.
  • O endereço da regra de encaminhamento é 10.1.2.9.

    Consulte as instruções em Como configurar o balanceamento de carga HTTP(S) interno para VMs do Compute Engine.

  • O mapa de URLs envia todo o tráfego para um serviço de back-end padrão, chamado red-service.

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

  • É usada uma correspondência de caminho.

  • Você está usando o Cloud Shell ou outro ambiente com o bash instalado.

Substitua ID do projeto com seu ID do projeto GCP.

defaultService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/red-service
hostRules:
- description: ''
  hosts:
  - '*'
  pathMatcher: matcher1
kind: compute#urlMap
name: l7-ilb-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/red-service
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /prefix
    routeAction:
      weightedBackendServices:
      - backendService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/green-service
        weight: 95
      - backendService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/blue-service
        weight: 5
region: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1
selfLink: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/urlMaps/l7-ilb-map

Como importar o mapa de URLs

gcloud beta compute url-maps import l7-ilb-map \
    --region=us-west1 \
    --source=canary.yaml

Como testar a configuração

Para testar a configuração canary, primeiro verifique se as solicitações para 10.1.2.9/, que é o endereço IP do balanceador de carga configurado anteriormente, sejam tratadas pela configuração red padrão.

Em seguida, verifique se as solicitações enviadas para 10.1.2.9/prefix foram divididas conforme esperado.

Como criar uma VM cliente

Consulte Como criar uma instância de VM na zona para testar a conectividade.

Como enviar solicitações para 10.1.2.9

SSH no cliente e execute o seguinte comando:

for LB_IP in 10.1.2.9; 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
Como verificar os resultados
***
***Results of load balancing to 10.1.2.9:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

Como enviar solicitações para 10.1.2.9/prefix

Envie solicitações para 10.1.2.9/prefix e observe a divisão de tráfego.

for LB_IP in 10.1.2.9; 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
Como verificar os resultados
***
***Results of load balancing to 10.1.2.9/prefix:
***
21 blue-instance-group-8n49
27 blue-instance-group-vlqc
476 green-instance-group-c0wv
476 green-instance-group-rmf4

A configuração canary envia 95% de solicitações de /prefix para o serviço green e 5% para o serviço blue.

É possível usar o controle de tráfego para configurar a afinidade de sessão com base em um cookie. Para configurar a afinidade de sessão baseada em HTTP_COOKIE para um serviço de back-end chamado red-service, siga estas instruções.

Para configurar a afinidade de sessão usando HTTP_COOKIE:

  1. Use o comando gcloud export para conseguir a configuração do serviço de back-end.

    gcloud beta compute backend-services export red-service \
        --destination=red-service-config.yaml \
        --region=us-west1
    
  2. Atualize o arquivo red-service-config.yaml seguinte maneira:

    sessionAffinity: 'HTTP_COOKIE'
    localityLbPolicy: 'RING_HASH'
    consistentHash:
     httpCookie:
      name: 'http_cookie'
      path: '/cookie_path'
      ttl:
        seconds: 100
        nanos: 30
     minimumRingSize: 10000
    
  3. No arquivo red-service-config.yaml, exclua a linha que diz:

    sessionAffinity: NONE
    
  4. Atualize o arquivo de configuração do serviço de back-end:

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

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.

Para saber informações sobre geração de registros e monitoramento, consulte Geração de registro e monitoramento de HTTP(S) interno.

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: verifique a ordem das suas regras de rota. As regras de rota são interpretadas na ordem em que são especificadas.

As regras de rota em um mapa de URLs são interpretadas na ordem em que são especificadas. Isso é diferente de como as regras de caminho são interpretadas pela correspondência de prefixo mais longa. Para uma regra de caminho, o balanceamento de carga de HTTP(S) interno selecionará somente uma regra de caminho, no entanto, mais de uma opção pode ser aplicada quando você usa regras de rota.

Ao definir regras de rota, verifique se as regras na parte superior da lista não encaminham inadvertidamente o tráfego que, de outra forma, seria roteado por outra regra de rota. O serviço que recebe tráfego direcionado incorretamente provavelmente rejeitará as solicitações, e o serviço nas regras de rota receberá tráfego reduzido ou nenhum tráfego.

Limitações

  • UrlMap.defaultRouteAction e UrlMap.defaultUrlRedirect não funcionam atualmente como pretendido. Você precisa especificar UrlMap.defaultService para lidar com o tráfego que não corresponda a nenhum dos hosts em UrlMap.hostRules[] nesse UrlMap. Da mesma forma, UrlMap.pathMatchers[].defaultRouteAction e UrlMap.pathMatchers[].defaultUrlRedirect não funcionam atualmente. Você precisa especificar UrlMap.pathMatchers[].defaultService para lidar com o tráfego que não corresponda a nenhuma routeRules para esse pathMatcher.
  • RouteRule.service não funciona atualmente como pretendido. A solução é usar RouteRule.weightedBackendServices com um único WeightedBackendService.
  • O comando gcloud import não exclui campos de nível superior do recurso, como o serviço de back-end e o mapa de URLs. 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.
  • Os campos int64 são exportados com o comando gcloud export como strings, não como números inteiros, no arquivo exportado. Você precisa remover manualmente as aspas ao redor do campo para importar o arquivo exportado.