Persistência de sessão baseada em cookies agora disponível no OKE

Persistência de sessão baseada em cookies agora disponível no OKE

A atualização recente do OKE agora suporta persistência de sessão baseada em cookies para serviços de tipo LoadBalancer e OCI Native Ingress Controller. Para times de engenharia, isso simplifica o gerenciamento de 'sticky sessions' em aplicações que mantêm estado, eliminando a necessidade de complexas lógicas de camada de aplicação. A conclusão principal é que, ao escolher entre persistência via aplicação ou via load balancer, é possível melhorar a experiência do usuário em fluxos críticos de forma nativa e eficiente.

Embora o ecossistema Kubernetes incentive arquiteturas stateless, a realidade técnica de muitas empresas brasileiras envolve legados ou fluxos específicos — como carrinhos de compra ou autenticação — que dependem da continuidade da sessão. Com o suporte nativo no OCI, a necessidade de "gambiarra" na camada de aplicação diminui, garantindo que o cliente mantenha o contexto ao longo de suas requisições, sem que a infraestrutura se torne um gargalo de complexidade.

Quais são os dois modelos de persistência oferecidos?

Para versões do Kubernetes 1.32 ou superiores, o OKE introduz duas abordagens distintas para lidar com a afinidade de sessão:

1. Application Cookie Persistence: O controle reside na aplicação. O backend é responsável por emitir e gerenciar o cookie. O load balancer atua apenas respeitando o comportamento definido pelo seu código.
2. Load Balancer Cookie Persistence: O load balancer assume a responsabilidade, injetando e gerenciando o cookie de afinidade. É a escolha ideal para reduzir o débito técnico da aplicação, pois retira a responsabilidade de sessão do código fonte.

Como integrar persistência com Services e Ingress?

Independente da topologia de rede escolhida, o OKE agora oferece paridade. Se você opta por expor seus containers diretamente com um Service do tipo LoadBalancer, as anotações do OCI permitem configurar a persistência de forma declarativa:

CopiarapiVersion: v1
kind: Service
metadata:
  name: my-app-svc
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci-load-balancer.oraclecloud.com/lb-cookie-session-persistence-config: |
      {
        "cookieName": "X-Oracle-OCI-Route",
        "disableFallback": true,
        "path": "/",
        "isHttpOnly": true
      }      
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - name: http
      port: 80
      targetPort: 8080

Para cenários mais complexos, o OCI Native Ingress Controller (NIC) oferece a mesma flexibilidade, permitindo roteamento baseado em path ou host, com o adicional da persistência configurada diretamente nas anotações do recurso Ingress.

Pontos de atenção para a operação

Ao implementar essas configurações, tenha em mente as diretrizes de governança técnica:

• Validação de JSON: O suporte depende da sintaxe correta nas anotações. JSON malformado resultará em falhas silenciosas de configuração.
• Exclusividade: Não tente sobrepor modos. Se você definir ambas as configurações (Application e Load Balancer) para o mesmo backend, o processo de reconciliação falhará.
• Conformidade de Security: Ao usar isSecure: true, o tráfego deve ser obrigatoriamente sobre TLS. Cookies seguros são descartados por listeners HTTP padrão.

Perguntas Frequentes

• Quando devo usar persistência de aplicação vs. load balancer?
  Use a persistência de aplicação quando seu sistema já gerencia cookies de sessão próprios e você quer apenas garantir afinidade. Use a persistência de load balancer quando desejar gerenciar a afinidade na camada de infraestrutura, sem precisar alterar mudanças no código da aplicação.

• É possível configurar ambos os modos de persistência simultaneamente?
  Não. Configure apenas um modo de persistência por backend set. Tentar especificar ambos os tipos de anotações no mesmo caminho de configuração causará falha na reconciliação do recurso.

• A persistência via cookie funciona em qualquer listener?
  Se você habilitar o parâmetro 'isSecure' como verdadeiro, o listener deve obrigatoriamente utilizar HTTPS ou TLS. Cookies seguros são rejeitados em listeners que operam apenas em HTTP.

---

Artigo originalmente publicado por (autor não identificado) em cloud-infrastructure.