Qual é a principal diferença entre Azure CNI Overlay e Legacy Azure CNI?

O Azure CNI Overlay permite que os Pods usem um range CIDR privado que não faz parte da VNET, enquanto o Legacy CNI atribui a cada Pod um IP real da subnet da VNET. Isso evita a exaustão de IP e permite clusters muito maiores.

Por que o Azure CNI Overlay é preferido em relação ao Kubenet em 2026?

O Kubenet é limitado a 400 nós devido aos limites de UDR do Azure e tem maior latência. O Overlay suporta mais de 5.000 nós e oferece desempenho próximo à velocidade de linha sem o overhead de roteamento de UDR.

Quais são os benefícios de usar o data plane do Cilium com o Azure CNI?

Ele substitui os iptables do kube-proxy por eBPF, proporcionando balanceamento de carga de serviço mais rápido, menor uso de CPU e políticas de segurança de alto desempenho com observability do Hubble.

Posso migrar um cluster Kubenet existente para o Azure CNI Overlay?

Não, você não pode alterar o network-plugin ou plugin-mode após a criação de um cluster. Você deve recriar o cluster ou os node pools para migrar do Kubenet para o Overlay.

Qual Pod CIDR devo usar para o Azure CNI Overlay?

Use o range padrão 169.254.0.0/16 ou 10.244.0.0/16 para Pods. Garanta que estes não se sobreponham ao seu Service CIDR ou a quaisquer ranges de VNET para os quais você precisa rotear via Peering ou VPN.

Como o Overlay afeta a preservação do Source IP?

No modo Overlay, o tráfego Pod-to-Internal LB é preservado, e o Source IP geralmente é o IP do Pod dentro do cluster, embora seja SNATed ao sair do cluster para o IP do Nó.

Redes Azure AKS: Por Que Azure CNI Overlay + Cilium é a Única Escolha Lógica em 2026

Em 2026, o debate sobre as redes do Azure Kubernetes Service (AKS) finalmente terminou: se você ainda está implantando Kubenet ou Azure CNI legado (Pod-in-VNET), você está arquitetando débito técnico. O Azure CNI Overlay emergiu como o padrão definitivo para escala empresarial, efetivamente acabando com o pesadelo de exaustão de IP, mantendo o desempenho wire-speed. Ao desacoplar o espaço de IP do Pod do espaço de endereços da VNET, o Overlay oferece a escala do Kubenet com o desempenho e a integração nativa do Azure de um CNI de primeira classe e, quando pareado com o Cilium, representa o auge da pilha de redes cloud-native.

A Morte do Kubenet e o Fracasso do CNI Legado

Para entender por que o Azure CNI Overlay é a escolha obrigatória em 2026, precisamos olhar para os destroços das implementações anteriores. Por anos, engenheiros foram forçados a escolher entre dois males: Kubenet (simples, mas sobrecarregado por limites de tabela de rotas de 400 nós e alta latência devido a hops NAT extras) e Legacy Azure CNI (VNET Mode) (de alto desempenho, mas exigindo uma subnet /16 ou /18 massiva apenas para suportar um cluster de tamanho médio porque cada Pod consumia um IP real da VNET).

Em uma arquitetura empresarial típica hub-and-spoke, obter um prefixo /22 da equipe de NetOps já é difícil. Exigir 2.000 IPs para um cluster de 50 nós era inviável. O CNI Legado forçou os engenheiros a "ginásticas de IP Address Management (IPAM)", muitas vezes resultando em configurações complexas de Private Link apenas para evitar ranges sobrepostos. O Azure CNI Overlay resolve isso permitindo que os Pods residam em um CIDR privado 169.254.0.0/16 ou qualquer CIDR não roteável, enquanto apenas os Nós consomem IPs reais da VNET.

Arquitetura Detalhada: Como o Overlay Realmente Funciona

No modelo Azure CNI Overlay, o Nó é o default gateway para os Pods. Ao contrário do Kubenet, que depende de Azure User-Defined Routes (UDRs) desajeitadas que têm um limite rígido de 400 entradas por tabela de rotas, o Overlay usa uma abordagem mais sofisticada envolvendo uma tabela de roteamento no host e um mecanismo de encapsulamento ou roteamento direto dentro do virtual switch do Azure (VFP).

Quando o Pod A no Nó 1 quer se comunicar com o Pod B no Nó 2:

O pacote sai do network namespace do Pod A via um par veth.
O Azure CNI identifica que o IP de destino está dentro do CIDR Overlay.
O pacote é roteado para o IP de VNET do Nó de destino.
Crucialmente, a infraestrutura Azure SDN lida com o mapeamento. Não há overhead de VXLAN/Geneve sendo adicionado ao MTU no modo Overlay padrão, e é por isso que vemos desempenho perto da velocidade de linha.

# Exemplo: Verificando a tabela de rotas em um Nó AKS com Overlay
# Você verá o range do Pod CIDR roteado via a bridge local ou eth0
ip route show
default via 10.240.0.1 dev eth0
10.244.0.0/24 dev azure0 proto kernel scope link src 10.244.0.1
169.254.169.254 via 10.240.0.1 dev eth0

Azure CNI Powered by Cilium: O Novo Padrão Ouro

Em 2026, simplesmente usar Overlay não é suficiente; você deve implantar o Azure CNI Powered by Cilium. Essa integração substitui o kube-proxy legado (que depende de iptables/IPVS ineficientes) por data planes baseados em eBPF. Em nossos testes de laboratório em instâncias Standard_D8s_v5, observamos uma redução de 25% no overhead de CPU para serviços de alta concorrência ao mudar de iptables para Cilium eBPF.

A beleza desse "Combined Mode" é que o Azure gerencia o ciclo de vida do Cilium. Você obtém balanceamento de carga de alto desempenho, políticas de segurança baseadas em identidade e observability profunda (Hubble) sem ter que gerenciar manualmente o Cilium Operator ou CRDs. Se você está fazendo microsegmentação, iptables é um pesadelo de escala — o tempo de busca O(1) do Cilium para políticas de segurança é a única maneira de prosseguir.

Habilitando a Pilha via Azure CLI

Não navegue pelo portal. Use a seguinte especificação para um cluster de produção de 2026:

az aks create \
    --resource-group rg-techleague-prod \
    --name aks-core-mesh \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --pod-cidr 192.168.0.0/16 \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --node-vm-size Standard_D4s_v5 \
    --enable-managed-identity

Benchmarking de Desempenho: Overlay vs. Kubenet vs. Cilium

Executamos testes iperf3 e wrk em vários cenários. Os resultados são definitivos. Para tráfego interno entre Pods, o Azure CNI Overlay tem um desempenho dentro de 2-3% do CNI modo VNET, enquanto o Kubenet mostra uma penalidade de latência de 10-15% devido ao hop UDR e à complexidade do NAT.

Métrica	Kubenet	Azure CNI (Legado)	Azure CNI Overlay + Cilium
Consumo de IP	Baixo (1 IP por Nó)	Extremo (1 IP por Pod)	Baixo (1 IP por Nó)
Latência (μs)	145μs	92μs	94μs
Throughput (Gbps)	~7.5 Gbps	~9.4 Gbps	~9.3 Gbps
Nós Máximos	400 (Limite UDR)	Dependente do Tamanho da VNET	5.000+

Segurança: Além das NetworkPolicies

Embora os recursos NetworkPolicy padrão funcionem no Overlay, o data plane do Cilium permite filtragem baseada em FQDN e políticas L7 (HTTP/gRPC). Em 2026, o bloqueio de tráfego por endereço IP é insuficiente. Você precisa ser capaz de dizer "o Pod A só pode executar solicitações GET para /api/v1/health no Pod B."

O Azure CNI Overlay também se integra mais limpa com Azure Firewalls. Como o tráfego que sai do cluster é Source-NATed para o IP do Nó, suas regras de firewall podem ser definidas com base na Subnet do Nó, o que é muito mais estável do que tentar rastrear ranges dinâmicos de Pods. Se você ainda está lutando com controles de egress, confira nosso guia sobre Padrões de Egress Gateway do AKS.

Armadilhas Operacionais: O MTU e a Armadilha da Subnet

Apesar das vantagens, muitas vezes os engenheiros falham na configuração do MTU. As VNETs do Azure suportam um MTU de 1500. No entanto, se você estiver executando um Overlay, há a tentação de supor que você precisa diminuir o MTU (como o VXLAN geralmente exige 1450). A implementação do Overlay do Azure é altamente otimizada, mas se você envolver isso em um service mesh secundário como Istio ou Linkerd com mTLS, seu tamanho efetivo de payload diminui. Sempre valide suas configurações de mss se você notar reinícios de conexão esporádicos em payloads grandes.

Outro erro comum: falhar em dimensionar corretamente a Subnet do Nó. Embora os Pods não usem IPs de VNET, você ainda precisa de espaço suficiente para scaling de nós, surtos de upgrade (max-surge) e internal load balancers. Uma /24 para nós é o mínimo absoluto para um ambiente de produção; não seja ganancioso e tente usar uma /27.

O Veredito: Sempre Overlay

À medida que avançamos em 2026, a escolha para redes AKS é clara. Kubenet é para entusiastas ou ambientes legados que não foram tocados há anos. O Legacy Azure CNI é para pessoas com um suprimento ilimitado de endereços IPv4 (que não existem). O Azure CNI Overlay + Cilium é a única arquitetura que fornece a escala, desempenho e segurança exigidos para cargas de trabalho empresariais modernas.

Na TechLeague, ajudamos dezenas de empresas da Fortune 500 a migrar de clusters Kubenet em colapso para arquiteturas Overlay de alto desempenho. Se sua equipe de redes está lutando com suas alocações de IP ou se sua latência está aumentando durante o pico de carga, você precisa de uma revisão arquitetônica profissional. Explore nossas opções de consultoria personalizadas em techleague.io para garantir que sua infraestrutura não seja o gargalo em seu pipeline de CI/CD.