A infraestrutura de ingress no Azure Kubernetes Service (AKS) passa por uma mudança estrutural necessária. Após a aposentadoria do projeto comunitário Ingress NGINX em março de 2026, a Microsoft estabeleceu uma janela de suporte para sua versão do add-on App Routing baseada em NGINX até novembro de 2026. Para engenheiros e gestores que operam workloads críticas, o novo App Routing Gateway API não é apenas uma atualização, mas uma mudança de paradigma na forma como gerenciamos o tráfego de entrada em nossos clusters.
O que muda com o Gateway API?
Diferente da API de Ingress tradicional, o novo App Routing adota a Kubernetes Gateway API. Quando você habilita este add-on, o AKS faz o provisionamento de um control plane de Istio (istiod) — porém, é vital destacar: não se trata do full Istio service mesh. Não há injeção de sidecars nem instalação de CRDs que impactem o data plane das aplicações. O papel aqui é restrito ao gerenciamento dos gateway proxies via Envoy.
Ao criar um recurso do tipo Gateway, o AKS automatiza componentes críticos como Envoy Deployment, LoadBalancer Service, HorizontalPodAutoscaler e PodDisruptionBudget. A grande vantagem estratégica aqui é a separação de responsabilidades (layers): o time de infraestrutura define o GatewayClass e o Gateway, enquanto as squads de desenvolvimento gerenciam seus próprios HTTPRoutes. Isso elimina erros comuns onde uma alteração indevida em um Ingress compartilhado impactava a disponibilidade de todo o cluster.
Limitações e Atenção para Produção
Como o recurso está em preview, ele não está pronto para cenários de produção exigentes. A lacuna principal é a ausência de automação nativa para DNS e certificados TLS — fluxos que hoje são facilmente resolvidos com az aks approuting e integração com Key Vault/Azure DNS. Até que o recurso atinja o General Availability (GA), times precisarão orquestrar o TLS manualmente (via Secrets) ou adotar soluções paralelas como ExternalDNS.
Além disso, é importante notar que esta implementação é mutuamente exclusiva com o Istio service mesh add-on completo. Se o seu ambiente exige mTLS entre serviços ou políticas de tráfego complexas no data plane, você deverá manter o Service Mesh padrão. Caso o objetivo seja apenas um ingress gerenciado, performático e moderno, a nova abordagem via Gateway API torna-se a recomendação oficial.
Roteiro de Migração
Para quem utiliza o NGINX, o caminho de migração deve priorizar um inventário rigoroso, especialmente de custom snippets e configurações Lua, que não são portáveis diretamente para a Gateway API. A ferramenta ingress2gateway é essencial para essa transição, mas a revisão manual pós-conversão é inegociável.
O processo de migração permite uma estratégia de coexistence: o novo controller pode rodar em paralelo ao antigo, possibilitando testes exaustivos sob a nova infraestrutura antes de apontar seu tráfego DNS. Mantenha o antigo controller ativo por 48 horas como um plano de rollback de emergência. A partir de novembro de 2026, qualquer infraestrutura baseada em Ingress NGINX estará em um estado de risco operacional pela falta de suporte, tornando essa migração uma prioridade no roadmap para times de plataforma.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
