O anúncio do fim do suporte ao Ingress NGINX, realizado na última KubeCon + CloudNativeCon North America, não deve ser encarado apenas como uma mudança de ferramenta, mas como um ponto de inflexão na gestão de infraestrutura em larga escala. Embora os artefatos permaneçam disponíveis, o projeto entra em uma rota crítica de depreciação que exige dos gestores de TI brasileiros uma análise de risco imediata em suas arquiteturas.
Para empresas que operam ambientes complexos — seja em cenários multi-cloud, on-premise ou ambientes regulados — o Ingress NGINX serviu por anos como a espinha dorsal de conectividade, manuseando desde SSL termination até regras complexas de roteamento via Ingress Annotations. No entanto, a dependência excessiva dessas anotações criou um forte vendor lock-in e dívida técnica oculta.
Perspectivas de quem já iniciou a transição
Grandes organizações, como o CERN, exemplificam o desafio da diversidade de ambientes. Com cerca de 60% dos seus deployments ainda baseados em NGINX ao final de 2025, a estratégia adotada foi bifocal:
- Adoção da Gateway API (Recomendada): Como um padrão moderno superior ao Ingress tradicional, a Gateway API permite uma abstração mais eficiente. Em ambientes onde o CNI (como o Cilium) já suporta nativamente a API, a migração é tratada como prioridade. Quando o controle dos Helm charts é centralizado, a transição é fluida; em dependências externas, o esforço concentra-se em contribuições upstream.
- Substituição de Controlador: Para cenários onde a migração imediata para a Gateway API não é viável, o movimento tem sido para soluções mais estáveis ou alinhadas, como o Traefik, buscando paridade de recursos via annotations equivalentes.
Lições além da ferramenta
O caso Boeing destaca como essa transição atua como catalisador para uma evolução arquitetural. Em ambientes de alta criticidade e exigências de compliance, a adoção de Service Mesh (como Istio) tornou-se a resposta natural, não apenas para roteamento, mas para controle de tráfego, segurança e observabilidade granulares. A lição clara aqui é: não trate a substituição do Ingress como uma mera troca de componente isolado, mas como uma oportunidade de avaliar a maturidade da pilha de rede.
Outro ponto crítico é a governança. Sub-projetos dentro de ecossistemas maduros, como o Kubernetes, podem não gozar do mesmo nível de maturidade ou suporte a longo prazo que o projeto principal. A recomendação clara é manter o monitoramento rigoroso da sanidade dos componentes da stack, garantindo que o seu slack operacional permita absorver esse tipo de mudança imprevista sem comprometer os SLAs da empresa.
O futuro da Edge Networking
Empresas de tecnologia que buscam mitigar riscos operacionais estão convergindo para soluções que seguem padrões abertos e extensíveis. O uso de Envoy Gateway tem ganhado tração por aliar a robustez do proxy Envoy com a padronização e escalabilidade da Gateway API, oferecendo uma base mais sólida para arquiteturas Zero-Trust e mTLS em escala.
O fim de um ciclo de vida de um projeto não é uma falha operacional, mas uma evolução natural da tecnologia cloud-native. Para times brasileiros, a lição é clara: a resiliência não vem da ferramenta que você escolhe, mas da capacidade da sua infraestrutura de ser desacoplada e preparada para a mudança.
Artigo originalmente publicado pela CNCF End User Technical Advisory Board em Cloud Native Computing Foundation.
