Implementar persistência de sessão em um gateway ASM - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Aplicações com estado, como carrinhos de compras, sessões de login e painéis personalizados, exigem que todas as requisições de um mesmo cliente cheguem ao mesmo pod de backend. A afinidade de sessão (sticky sessions) no ASM direciona as requisições para um backend consistente mediante a aplicação de hashing consistente em uma regra de destino do Istio.

O hashing consistente mapeia cada requisição para um backend com base em uma chave de hash: cookie, cabeçalho HTTP, IP de origem ou parâmetro de consulta. Esse mecanismo fornece afinidade de sessão suave: requisições do mesmo cliente geralmente chegam ao mesmo pod, mas a afinidade pode ser interrompida ao adicionar ou remover backends.

Como funciona

Algoritmos de hash

O Envoy oferece suporte a dois algoritmos de hashing consistente:

Algoritmo	Padrão	Quando usar
HashRing	Sim	Afinidade de sessão de uso geral com rotatividade moderada de backends
Maglev	Não	Cenários de alto throughput em que a velocidade de busca é importante. Requer ASM v1.16 ou posterior

Pré-requisitos

Antes de começar, verifique se você tem:

Um cluster Container Service for Kubernetes (ACK) adicionado à sua instância do Service Mesh (ASM). Para obter mais informações, consulte Adicionar um cluster a uma instância ASM
Um gateway de entrada com a porta 80 exposta. Para obter mais informações, consulte Criar um gateway de entrada
A aplicação HTTPBin implantada. Para obter mais informações, consulte Implantar a aplicação HTTPBin

Configure afinidade de sessão baseada em cookies

Este tutorial demonstra a afinidade de sessão baseada em cookies. A mesma estrutura DestinationRule se aplica a outros tipos de chave de hash; substitua o bloco httpCookie pelo campo correspondente.

Etapa 1: Dimensionar o deployment do HTTPBin para três réplicas

São necessárias três réplicas para observar a distribuição das requisições entre os pods. Conecte-se ao plano de dados do cluster ACK com kubectl e execute:

kubectl scale deployment/httpbin --replicas 3

Etapa 2: Verifique a distribuição de requisições sem afinidade de sessão

Abra http://<ingress-gateway-ip>/status/418 em um navegador e atualize a página várias vezes.

Para obter instruções sobre como obter o IP do gateway de entrada, consulte a subetapa 1 da Etapa 3 em Usar recursos do Istio para rotear tráfego para diferentes versões de um serviço.
Verifique nos logs do gateway se as requisições estão distribuídas entre todos os três pods:
1. Faça login no console ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
2. Na página Mesh Management, clique em nome da instância ASM. No painel de navegação à esquerda, escolha ASM Gateways > Ingress Gateway.
3. Na página Ingress Gateway, localize o gateway de entrada desejado e clique em Log Center. Na aba Gateway Logs, adicione and 418 à caixa de pesquisa e clique em Search & Analyze. Na aba Raw Logs no canto inferior esquerdo, expanda o índice upstream_addr.
Os logs mostram requisições distribuídas de forma aproximadamente uniforme entre os três pods do HTTPBin.

Etapa 3: Crie uma regra de destino para afinidade de sessão baseada em cookies

Aplique a seguinte DestinationRule. Para detalhes sobre gerenciamento de regras de destino, consulte Gerencie regras de destino.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: httpbin
  namespace: default
spec:
  host: httpbin.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: sticky-session-key
          ttl: 0s

Campo	Valor	Descrição
`host`	`httpbin.default.svc.cluster.local`	Nome de host totalmente qualificado do serviço ao qual esta regra se aplica
`consistentHash.httpCookie.name`	`sticky-session-key`	Nome do cookie usado como chave de hash
`consistentHash.httpCookie.ttl`	`0s`	Tempo de vida do cookie

Após aplicar esta regra:

Na primeira requisição (sem cookie presente), o gateway gera um hash a partir dos endereços IP e portas de source e destino, roteia a requisição para um backend e define o cookie sticky-session-key na resposta.
Nas requisições subsequentes, o cliente reenvia esse cookie. O gateway calcula o hash do valor do cookie para determinar o backend e roteia a requisição para o mesmo pod.

Este exemplo usa o algoritmo HashRing padrão. Para usar Maglev (requer ASM v1.16 ou posterior), adicione o campo hashAlgorithm à sua política de tráfego conforme seus requisitos.

Etapa 4: Verifique se a afinidade de sessão está funcionando

Abra http://<ingress-gateway-ip>/status/333 em um navegador e atualize a página várias vezes.

Para obter instruções sobre como obter o IP do gateway de entrada, consulte a subetapa 1 da Etapa 3 em Usar recursos do Istio para rotear tráfego para diferentes versões de um serviço.
Verifique nos logs do gateway se todas as requisições chegam ao mesmo pod:
1. Faça login no console ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
2. Na página Mesh Management, clique em nome da instância ASM. No painel de navegação à esquerda, escolha ASM Gateways > Ingress Gateway.
3. Na página Ingress Gateway, localize o gateway de entrada desejado e clique em Log Center. Na aba Gateway Logs, adicione and 333 à caixa de pesquisa e clique em Search & Analyze. Na aba Raw Logs no canto inferior esquerdo, expanda o índice upstream_addr.
Os logs mostram todas as requisições roteadas para o mesmo pod de backend.
Confirme o cookie no navegador: abra as ferramentas de desenvolvedor, clique em aba Network, atualize a página e inspecione uma requisição. A resposta inclui um cookie sticky-session-key correspondente ao nome na DestinationRule. O gateway usa esse cookie para manter a afinidade de sessão.