Por grande parte da história do Kubernetes, o gerenciamento de serviços de rede foi suportado pelo iptables. Era uma escolha pragmática, disponível em praticamente qualquer distribuição Linux e eficiente o suficiente para clusters de pequena escala com workloads previsíveis. No entanto, à medida que provedores de nuvem aumentam os limites de pods e as empresas adotam infraestruturas multi-regionais e de alta disponibilidade, esse modelo antigo tornou-se um gargalo arquitetural.
Clusters de produção modernos, impulsionados pela infraestrutura de nuvem, rodam milhares de serviços sujeitos a um endpoint churn constante e exigências rigorosas de performance, segurança e conformidade. O modelo de processamento linear do iptables simplesmente não foi projetado para esse nível de densidade e dinamismo.
É por isso que a comunidade Kubernetes iniciou a migração para o nftables, com o upstream oficializando o suporte ao kube-proxy em modo nftables como estável na versão v1.33, seguido pelo suporte no Project Calico v3.29+. A recente decisão da Microsoft de suportar o kube-proxy em modo nftables no AKS (Azure Kubernetes Service) reflete uma realidade de mercado: o modelo tradicional é um peso morto para a escalabilidade operacional.
O Custo Oculto do iptables
Equipes que rodam grandes clusters frequentemente questionam a necessidade da mudança se "tudo está funcionando". O problema do iptables não é uma falha catastrófica; é uma degradação gradual: consumo elevado de CPU, latência em updates de regras e dificuldades crescentes no debug.
Imagine dois seguranças controlando a entrada de um estádio:
- Segurança (iptables): Possui uma lista em papel. Para cada pessoa, ele começa a ler a lista do topo, varrendo nome por nome até encontrar uma correspondência. Quando uma nova pessoa chega, ele precisa reescrever parte da lista ou reiniciar o processo. Conforme a fila cresce, o tempo de busca torna-se exponencialmente mais lento.
- Segurança (nftables): Possui um banco de dados otimizado. Ele realiza uma busca instantânea e direta.
Ambos garantem a segurança, mas apenas um escala. O custo do iptables é o lookup time que cresce linearmente com o número de serviços, tornando as operações de rede cada vez mais custosas conforme o cluster expande.
Implementação no AKS
Atualmente no AKS, o suporte ao kube-proxy em modo nftables está em preview. Para testá-lo, você deve registrar a feature via Azure CLI:
az extension add --name aks-preview
az extension update --name aks-preview
az feature register --namespace "Microsoft.ContainerService" --name "KubeProxyConfigurationPreview"
Após o registro, você define a configuração do kube-proxy (kube-proxy.json) e inicia o cluster com o plugin de rede personalizado (--network-plugin none), delegando a rede ao Project Calico.
O Fim de uma Era
A migração para nftables não é um ajuste de versão qualquer; é um upgrade de arquitetura necessário para soluções cloud-native. O "imposto oculto" da avaliação linear de regras do iptables é incompatível com ambientes de milhares de microsserviços.
Para times de plataforma, a transição reduz o overhead e facilita a manutenibilidade, especialmente em ambientes onde as políticas de rede (NetworkPolicies) são complexas e frequentes.
Como nota de rodapé, o troubleshooting em nftables exige novas ferramentas de observability. Ferramentas como o Calico Whisker permitem visualizar fluxos de rede em tempo real, enquanto o Microsoft Retina provê insights profundos via eBPF sobre descartes de pacotes e métricas de DNS, essenciais para garantir a resiliência operacional que empresas brasileiras exigem ao escalar seus ambientes cloud.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
