Em sistemas distribuídos modernos, o controle de tráfego evoluiu para além do simples Round Robin. Empresas que operam em escala exigem capacidades de fine-grained traffic shaping, como o roteamento preciso de porcentagens de requisições para backends distintos, essencial para estratégias robustas de canary deployments ou A/B testing.
Este artigo analisa a implementação de balanceamento de carga ponderado no Azure Kubernetes Service (AKS) utilizando o Istio. Esta abordagem é uma solução estratégica para contornar as limitações nativas dos serviços de balanceamento de carga da Azure, permitindo controle real sobre a distribuição de tráfego mesmo em arquiteturas híbridas.
Pré-requisitos
- Workloads no AKS (pods internos, sem Envoy sidecar).
- Istio instalado e configurado em um cluster AKS (foco em gerenciamento via Ingress Gateway).
Seção 1 — Visão Geral e por que o Istio é necessário
O controle de tráfego granular permite rotear uma fatia do tráfego (ex: 80:20) entre dois pools de backend com session affinity baseada em cookies, garantindo que o usuário mantenha a consistência de serviço. O Istio atua como um control plane de Layer 7, permitindo essa flexibilidade que infraestruturas L4 (como o Azure Standard Load Balancer) não conseguem entregar por design.
1.1 Cenário de uso
Requisito comum: Roteamento de tráfego do Client → AKS → Azure Backend Workloads com, por exemplo, 80% do tráfego vindo de um pool e 20% de outro. Isso é particularmente útil para:
- Canary ou blue-green deployments: Deslocamento gradual de tráfego para validar versões antes do roll-out total.
- A/B testing: Exposição controlada de grupos de usuários a variantes de aplicação.
- Capacidade desigual: Ajuste de tráfego proporcional à capacidade de processamento real dos backends.
1.2 Limitações do Azure Load Balancer Nativo
O Azure Standard Load Balancer opera na Layer 4, utilizando 5-tuple hashing. Isso significa:
- Sem roteamento ponderado.
- Sem consciência de conteúdo (HTTP awareness).
- Sem controle de sessão (session-level control).
O Azure Traffic Manager, embora suporte pesos, trabalha no nível de DNS, o que introduz latência por cache e é inadequado para tráfego interno (private endpoints) ou decisões de roteamento em tempo real.
1.3 Por que o Istio?
O Istio utiliza proxies Envoy para realizar o controle de tráfego na Layer 7, permitindo inspeção de headers/cookies e roteamento determinístico. A mudança fundamental aqui é passar o controle da infraestrutura para o seu intent de aplicação.
Seção 2 — Arquitetura e Fluxo de Tráfego
Independentemente de o backend ser um pod ou uma VM, o Istio atua como o ponto único de enforcement (Ingress Gateway). A localização dos workloads não altera a lógica de roteamento.
2.1 Istio com workloads apenas no AKS
Neste modelo, o tráfego entra, o Istio avalia cookies e, em caso de novos usuários, aplica o peso configurado.
Nota crítica: Containers Windows não rodam Envoy sidecar. Em malhas com mTLS rigoroso, é obrigatório desabilitar o TLS na DestinationRule entre o Gateway e o pod, mantendo a responsabilidade de enforcement centralizada no Gateway.
2.2 Istio para workloads em VMs Azure
Aqui, o AKS atua como um control plane puro para legados, utilizando ServiceEntry para registrar as VMs. Isso permite que infraestruturas legadas aproveitem as capacidades de gerenciamento de tráfego modernas sem necessidade de re-arquitetura imediata.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
