A comunidade cloud native recebeu um alerta definitivo: em março de 2026, o Ingress NGINX será oficialmente aposentado. O comunicado conjunto do Kubernetes Steering Committee e do Security Response Committee não deixa margem para interpretações ambíguas: o projeto, que sustenta cerca de 50% dos ambientes Kubernetes globalmente, deixará de receber correções de bugs, patches de segurança ou qualquer tipo de atualização.
Para as empresas brasileiras que utilizam infraestrutura cloud para escalar operações, esse movimento exige uma resposta estratégica imediata. Não se trata apenas de uma troca de versão, mas de uma migração de infraestrutura crítica que impacta a disponibilidade e a segurança dos serviços expostos à internet.
O Cenário: Por que o Ingress NGINX chegou ao fim?
Embora amplamente adotado por empresas de todos os tamanhos, o projeto enfrentava um paradoxo: alta dependência do mercado e baixa contribuição ativa. Por anos, o Ingress NGINX foi mantido por apenas um ou dois profissionais em seu tempo livre.
Além do fator humano, o projeto acumulou um technical debt significativo. Decisões fundamentais de design, que antes garantiam flexibilidade, tornaram-se vetores de vulnerabilidades difíceis de mitigar sob os padrões modernos de SecOps. O anúncio é o reconhecimento de que o custo de manter o projeto seguro tornou-se insustentável.
Impacto Real para Empresas Brasileiras
Ignorar este prazo significa aceitar um risco operacional inaceitável. Após março de 2026, qualquer nova vulnerabilidade descoberta no Ingress NGINX permanecerá aberta, tornando clusters inteiros alvos fáceis para ataques.
É importante notar que os deployments existentes não pararão de funcionar magicamente, mas estarão em um estado de degradação de segurança contínua. Sem suporte oficial, SLAs de segurança e conformidade (como LGPD e PCI-DSS) podem ser severamente comprometidos.
Como agir agora: Diagnóstico e Caminhos de Migração
O primeiro passo para gestores de TI e times de engenharia no Brasil é identificar a dependência. Muitas vezes, o Ingress NGINX é instalado como parte de pacotes de terceiros ou via Helm charts genéricos.
Você pode verificar a presença do controlador em seu cluster com o seguinte comando de kubectl (com permissões de cluster-admin):
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
Alternativas Estratégicas
Não existe uma substituição direta (drop-in replacement) de um para um. A migração exigirá tempo de engenharia e planejamento de pipeline:
- Gateway API: A evolução natural e recomendada pela comunidade. Ele oferece um modelo mais expressivo, orientado a papéis (infra, cluster e app) e com melhor suporte a cenários de multi-cloud e shared infrastructure.
- Controladores de Terceiros: Opções baseadas em Envoy ou outras tecnologias que já nasceram com foco em performance e segurança moderna, como Traefik, Kong ou Istio Ingress.
Conclusão: O tempo é o recurso mais escasso
Com apenas dois meses restantes até a data final (março de 2026), a janela para testes de carga, validação de ingress rules e configurações de SSL/TLS em novas ferramentas está se fechando. O posicionamento da Nuvem Online é claro: a migração não é uma tarefa opcional de manutenção, mas uma prioridade de continuidade de negócio e FinOps (evitando custos reativos de incidentes de segurança).
Verifique seus clusters hoje. Planeje sua migração amanhã. A segurança da sua operação depende dessa proatividade.
Artigo originalmente publicado por Kat Cosgrove em Kubernetes Blog.
