Entender as diferenças entre Azure CNI, CNI Overlay e Kubenet é essencial para definir a arquitetura de rede do AKS. As opções de rede determinam como seus pods se comunicam, como os endereços IP são alocados e quais recursos ficam disponíveis no seu cluster! Todas as soluções viabilizam a conectividade entre pods, mas se diferenciam na implementação, no desempenho e na escalabilidade. Esta visão técnica analisa as principais diferenças entre o Azure CNI (nos modos tradicional e overlay) e o Kubenet, com foco em gerenciamento de endereços IP, desempenho de rede e capacidade de integração, para ajudar a embasar sua estratégia de rede no AKS.
Gerenciamento de endereços IP
No Azure CNI tradicional, cada pod recebe um endereço IP diretamente da subnet da sua Azure Virtual Network. Ou seja, os pods são cidadãos de primeira classe na sua VNet, o que permite a comunicação direta com outros recursos do seu ambiente Azure. Os IPs dos pods são roteáveis e podem ser acessados por qualquer recurso com conectividade de rede até a subnet.
O Azure CNI agora também oferece um modo Overlay, em que apenas os nós do cluster são implantados em uma subnet. Os pods recebem endereços IP de um CIDR privado, logicamente separado da VNet que hospeda os nós. O tráfego entre pods e nós dentro do cluster passa por uma rede Overlay, enquanto o Network Address Translation (NAT) usa o IP do nó para alcançar recursos fora do cluster. Essa abordagem economiza muitos endereços IP e permite escalar o cluster bem mais.
O Kubenet também implementa uma rede overlay. Os pods recebem endereços IP de um espaço de endereçamento separado, fora da sua VNet. Quando precisam se comunicar com recursos fora do cluster, o Kubenet usa NAT para rotear o tráfego pelo IP do nó. Isso cria um salto de rede a mais, mas economiza IPs da VNet, já que apenas os nós precisam de IPs da sua subnet.
Necessidade de espaço na subnet
No Azure CNI tradicional, o planejamento da subnet exige cuidado, porque cada pod em potencial precisa de um IP dedicado da sua subnet. Por isso, é preciso alocar uma subnet grande o suficiente para acomodar todos os nós e o número máximo de pods que podem rodar neles. Por exemplo: se cada nó pode rodar 30 pods e você planeja escalar para 10 nós, vai precisar de pelo menos 300 IPs para os pods, além dos IPs dos próprios nós. Isso muitas vezes obriga você a optar por faixas CIDR maiores e pode impactar o design geral da rede.
O Azure CNI Overlay aproveita os endereços IP de forma mais eficiente, atribuindo um espaço /24 a cada nó a partir de um CIDR privado definido na criação do cluster. O bloco /24 é fixo e suporta até 250 pods por nó. Você pode reaproveitar o mesmo CIDR de pods em vários clusters AKS independentes na mesma VNet, ampliando significativamente o espaço de IPs disponível para aplicações em containers.
O Kubenet também aproveita bem os endereços IP, já que só exige IPs da VNet para os próprios nós. Os pods usam uma faixa CIDR interna para a rede overlay — geralmente 10.244.0.0/16 por padrão —, que não consome o espaço de endereçamento da sua VNet. Isso faz do Kubenet uma boa opção em ambientes com pouca disponibilidade de IPs ou com restrições rígidas de endereçamento. Por outro lado, essa eficiência tem um custo: a necessidade de configuração extra de roteamento via User Defined Routes (UDRs).
Desempenho de rede
O Azure CNI tradicional entrega desempenho de rede superior graças ao seu modelo de integração direta. Como os pods têm conectividade direta com a VNet, sem rede overlay, o overhead na pilha de rede é mínimo. Os pacotes fluem direto entre os pods e outros recursos da VNet, sem camadas adicionais de encapsulamento ou tradução, o que se traduz em menor latência e maior throughput para workloads que exigem rede intensiva.
O Azure CNI Overlay mantém um desempenho comparável ao de VMs em uma VNet. Não é preciso provisionar rotas customizadas nem usar encapsulamento para tunelar o tráfego entre pods, o que garante uma conectividade entre pods no mesmo nível das VMs em uma VNet.
Já o Kubenet adiciona overhead de rede, porque exige NAT e roteamento pela interface de rede do nó. Cada pacote precisa passar pela rede overlay e ter o IP interno do pod traduzido para o IP externo do nó. Para muitas aplicações, esse impacto é mínimo, mas pode ficar evidente em cenários com alto throughput de rede ou em workloads sensíveis à latência.
Controle por Network Security Group (NSG)
O Azure CNI funciona com NSGs no nível da subnet e da interface de rede, e as regras podem mirar os IPs dos pods, já que eles fazem parte da VNet. Os NSGs não podem ser anexados diretamente a pods individuais, mas é possível criar regras específicas que mirem pods individuais ou grupos de pods pelos seus IPs na VNet.
Com o Azure CNI Overlay, o tráfego pod a pod não é encapsulado, e as regras de NSG da subnet são aplicadas. Algumas regras específicas são necessárias para o cluster funcionar corretamente, incluindo o tráfego entre as faixas CIDR dos nós e dos pods. Para o controle do tráfego dos workloads, recomenda-se o uso de network policies.
Com o Kubenet, o controle de segurança de rede fica restrito ao nível do nó, já que os pods não têm IPs diretos da VNet. As regras de NSG só podem ser aplicadas à interface de rede do nó, então todos os pods de um mesmo nó compartilham as mesmas regras. Essa limitação dificulta a aplicação de políticas de rede específicas por pod e pode exigir alternativas, como Kubernetes Network Policies, para um controle mais granular do tráfego dentro do cluster.
Integração com a VNet
O Azure CNI tradicional oferece uma integração ampla com a VNet, permitindo que os pods se comuniquem diretamente com qualquer recurso conectado à VNet no seu ambiente Azure. Isso inclui serviços como SQL Managed Instances, Azure Cache for Redis ou recursos em VNets emparelhadas. Como os pods recebem IPs diretamente da subnet da VNet, eles estabelecem conexões diretas sem configuração extra — ideal para cenários que pedem integração transparente com outros serviços do Azure.
O Azure CNI Overlay faz a integração com a VNet via NAT, e o tráfego de saída dos pods usa o IP do nó. Os pods não podem ser acessados diretamente de fora do cluster, mas é possível publicar aplicações como serviços do tipo Kubernetes Load Balancer para torná-las acessíveis na VNet.
O Kubenet tem capacidades mais limitadas de integração com a VNet. Os pods continuam podendo se comunicar com recursos externos, mas isso exige UDRs para rotear corretamente o tráfego entre a rede overlay dos pods e a VNet. Essa complexidade extra de roteamento pode afetar a conectividade com determinados serviços do Azure e exigir configurações adicionais em cenários de peering de VNet ou redes híbridas. Os requisitos de roteamento também tendem a ficar mais complexos conforme a arquitetura de rede cresce.
Gerenciamento de tabelas de rotas e complexidade da configuração
O gerenciamento de tabelas de rotas varia bastante entre as opções. O Azure CNI tradicional simplifica esse gerenciamento, porque os pods se comunicam diretamente na VNet e não há necessidade de entradas adicionais na tabela de rotas para tratar o tráfego dos pods. A configuração de roteamento continua simples mesmo conforme o cluster cresce. A contrapartida está na complexidade inicial: é preciso planejar os endereços IP com cuidado.
O Azure CNI Overlay simplifica a rede dos pods ao não exigir UDRs para a conectividade básica, ao contrário do Kubenet. Embora exija a configuração de regras específicas de NSG para o cluster funcionar corretamente, a solução cuida automaticamente do roteamento pod a pod e mantém um desempenho comparável à comunicação tradicional na VNet. UDRs ainda podem ser necessárias em casos específicos, como tunelamento forçado ou requisitos de roteamento customizado.
O Kubenet usa UDRs e encaminhamento de IP para a conectividade dos pods, criados e mantidos automaticamente pelo serviço AKS por padrão. Você pode, opcionalmente, trazer a sua própria tabela de rotas para um gerenciamento customizado, mas a configuração padrão dispensa manutenção manual. A principal limitação é que o Azure suporta no máximo 400 rotas em uma UDR, o que, na prática, limita o cluster a 400 nós. A configuração inicial é mais simples do que a do Azure CNI tradicional, já que não exige um planejamento extenso de IPs — basta considerar os IPs dos nós na sua subnet. Por outro lado, a arquitetura com UDR acrescenta um salto de rede a mais, que introduz uma pequena latência na comunicação entre pods, e você não pode compartilhar subnets entre vários clusters Kubenet.
Recursos adicionais
Cada opção de rede dá suporte a diferentes recursos avançados. O Azure CNI tradicional tem o suporte mais amplo, incluindo containers Windows, Azure Network Policies e integração com Application Gateway. O Azure CNI Overlay suporta containers Windows e várias opções de network policy (Azure, Calico, Cilium), mas não pode usar o Application Gateway como Ingress Controller. Os dois modos CNI suportam rede dual-stack, embora o Overlay tenha algumas limitações. O Kubenet tem suporte mais restrito: funciona apenas com containers Linux e network policies do Calico. Além disso, o Kubenet é limitado a containers Linux, suporta até 400 nós com 250 pods por nó e só aceita Calico para network policies. Ele não suporta containers Windows nem recursos avançados de rede do Azure.
Qual escolher?
A escolha entre as opções de rede depende dos requisitos específicos dos seus workloads e das restrições da sua infraestrutura:
O Azure CNI tradicional é mais indicado para workloads corporativos que exigem integração direta de rede, alto desempenho ou integração avançada com serviços do Azure. Escolha esta opção quando:
- Você tem espaço de endereçamento IP disponível
- A maior parte da comunicação dos pods é com recursos fora do cluster
- Recursos fora do cluster precisam acessar os pods diretamente
- Você precisa de recursos avançados do AKS, como virtual nodes
- A integração com o Application Gateway é necessária
O Azure CNI Overlay é ideal para implantações em larga escala com pouco espaço de endereçamento IP. Escolha esta opção quando:
- Você precisa escalar para um grande número de pods, mas tem pouco espaço de endereçamento IP
- A maior parte da comunicação dos pods ocorre dentro do cluster
- Você quer uma configuração de rede mais simples
- Você precisa de suporte a containers Windows, mas não precisa do Application Gateway Ingress Controller.
- Você quer reaproveitar faixas CIDR de pods entre clusters
O Kubenet funciona bem para workloads Linux mais simples e ambientes com restrições de endereçamento IP. Escolha esta opção quando:
- Você tem workloads simples, somente Linux
- Você tem restrições de endereçamento IP, mas não precisa da escala do CNI Overlay
- Você não precisa de recursos avançados de rede
- Você está montando ambientes de desenvolvimento ou teste
A escolha do plugin de rede do seu cluster AKS tem impacto de longo prazo em escalabilidade, desempenho e complexidade operacional! Entender as características e limitações de cada opção é essencial para tomar uma decisão embasada e alinhada aos requisitos da sua infraestrutura e aos planos de crescimento futuro. Vale lembrar: trocar de opção de rede normalmente exige recriar o cluster, então essa decisão deve ser tomada cedo no planejamento do AKS.
Uma última observação: em 31/03/2028, a rede Kubenet do AKS será descontinuada. Considere migrar para o Azure CNI Overlay como substituto adequado, que resolve várias limitações do Kubenet sem abrir mão da utilização eficiente de endereços IP.
Fale com a DoiT hoje mesmo e descubra como podemos ajudar você a extrair o máximo em eficiência, custo-benefício e segurança do seu ambiente de nuvem. Com a DoiT, você tem acesso a expertise em nuvem exclusivamente sênior para consultoria, capacitação e suporte — e estamos por aqui sempre que você precisar de uma consultoria especializada, uma segunda opinião, ajuda para adotar novas tecnologias ou apoio para apagar incêndios em produção.
Se quiser se aprofundar em outros temas de segurança e arquitetura em nuvem, confira os posts do nosso blog de engenharia em nuvem.