O Comitê de Direção do Kubernetes anunciou o fim do suporte para o NGINX Ingress controller a partir de março de 2026. Para times de engenharia e gestores de TI, isso não é apenas uma nota técnica, mas um alerta de risco operacional: após essa data, a ferramenta deixará de receber patches de segurança, expondo clusters a vulnerabilidades críticas.
O Cenário no Azure Kubernetes Service (AKS)
O Azure (AKS) oferece um managed add-on de roteamento que utiliza o NGINX como motor. A Microsoft garantiu suporte oficial a esta versão até novembro de 2026. Embora isso ofereça um fôlego extra, é crucial entender que a migração para o App Routing add-on não é o fim da jornada, mas um movimento tático. O plano de longo prazo da Microsoft envolve uma transição para uma solução baseada em Istio, exclusiva para Gateway API.
Para quem utiliza a Ingress API tradicional, o dever de casa envolve preparar a transição através de ferramentas como o Ingress2Gateway. Migrar agora para o App Routing add-on serve para ganhar tempo de manobra, permitindo que a equipe planeje uma arquitetura definitiva antes da expiração do suporte em novembro.
Como Funciona a Migração Zero-Downtime
Uma estratégia eficiente de migração requer que ambos os ingress controllers operem em paralelo. Como o Kubernetes permite a coexistência através de IngressClass distintas, é possível isolar o tráfego usando a referência correta nos objetos Ingress.
O seu BYO (Bring Your Own) Nginx opera no namespace ingress-nginx, enquanto o App Routing add-on roda no app-routing-system. Eles são entidades independentes, cada uma com seu próprio IP de load balancer.
Habilitando e Validando a Nova Infraestrutura
O processo começa habilitando o add-on sem interferir na instalação existente:
az aks approuting enable \
--resource-group <resource-group> \
--name <cluster-name>
Após a implantação, você pode comparar os IPs dos load balancers para garantir que ambos os controladores estejam ativos e isolados. A migração de workloads deve ser feita via Parallel Ingress Approach: criando um segundo objeto Ingress que aponte para o add-on (webapprouting.kubernetes.azure.com).
Validação e Cutover
A validação é a etapa mais crítica. Utilize curl para testar as rotas através do IP do add-on:
# Exemplo de teste para ingress público
curl -H "Host: myapp.example.com" http://$add-on_IP
Avalie certificados TLS, roteamento de caminhos e rate limiting. Quando tudo estiver validado, a alteração no DNS ou no backend pool (caso esteja utilizando App Gateway, API Management ou Front Door) consolidará a transição. TTLs de DNS reduzidos são vitais para mitigar riscos de rollback.
O Que Muda na Prática?
Embora o binário do NGINX seja o mesmo, a gestão muda. O App Routing add-on integra-se nativamente com Azure Key Vault para certificados e Azure DNS para zones, mas restringe a customização global via ConfigMap em comparação a uma instalação BYO. Audite suas customizações atuais (script Lua, custom modules) para garantir compatibilidade.
O futuro aponta para o Gateway API e inovações como o App Gateway for Containers (baseado em Envoy). Utilize este período de suporte estendido até novembro de 2026 para mapear sua estratégia de longo prazo, saindo de soluções de terceiros para opções gerenciadas mais resilientes e alinhadas aos roteiros de inovação da nuvem.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
