O Fim de um Turno Longo e Cansativo

Pense no Ingress NGINX como aquele porteiro antigo e confiável do prédio da sua infraestrutura. Ele conhecia todo mundo, sabia todos os atalhos e resolvia tudo, mas a verdade é que ele estava sobrecarregado e o sistema de segurança do prédio ficou moderno demais para seus métodos. Conforme anunciado na Kubecon NA 2025, o Comitê de Resposta de Segurança e a SIG Network do Kubernetes decidiram que era hora de uma aposentadoria merecida. O suporte de "melhor esforço" continuará até março de 2026, mas depois disso, o porteiro entrega as chaves de vez: sem mais lançamentos, correções de bugs ou, o mais importante, atualizações de segurança.

A razão por trás dessa decisão é uma história clássica no mundo do software de código aberto. Segundo o comunicado, o projeto sofria de uma escassez crônica de mantenedores. Chegou a um ponto insustentável em que apenas uma ou duas pessoas estavam dedicando seu tempo livre, depois do expediente e nos fins de semana, para manter essa peça fundamental de infraestrutura funcionando para o mundo inteiro. É como pedir para o porteiro fazer a segurança, a limpeza e a contabilidade do prédio nas horas vagas. Simplesmente não escala. Os esforços para recrutar mais apoio e tornar o projeto viável, infelizmente, não deram resultado.

Além da falta de pessoal, havia uma montanha de "dívida técnica insuperável", como descrito pelos próprios mantenedores. A flexibilidade que tornou o Ingress NGINX tão popular no início da história do Kubernetes, permitindo o uso de diretivas de configuração arbitrárias do NGINX através de anotações de "snippets", transformou-se em seu calcanhar de Aquiles. O que antes era um recurso poderoso, hoje é visto como uma vulnerabilidade de segurança séria no contexto da computação nativa em nuvem moderna. Houve até uma tentativa de criar um substituto, chamado InGate, mas o projeto não gerou interesse suficiente e também será descontinuado junto com seu predecessor.

De Ativo a Passivo: O Risco da Ferramenta Defasada

O advogado da nuvem nativa, Jimmy Song, capturou perfeitamente o momento, descrevendo-o como "um ponto de inflexão na evolução da infraestrutura". Ele ressalta uma verdade inconveniente, mas necessária: "uma vez que os componentes de infraestrutura não podem mais ser atualizados com segurança, eles deixam de ser ativos e se tornam passivos". O Ingress NGINX, que já foi um pilar, corre o risco de se tornar um tijolo solto na parede de qualquer cluster que ainda o utilize após março de 2026.

A análise de Song, citada pelo InfoQ, enfatiza que o problema central não é uma queda no uso, mas sim uma dinâmica de manutenção insustentável. A flexibilidade extrema do controlador criou uma superfície de ataque extensa, e o custo para mantê-la segura excedeu permanentemente o ritmo das contribuições da comunidade. A maioria dos usuários, segundo ele, tratava o Ingress NGINX como uma "caixa preta": simplesmente funcionava, e ninguém se preocupava em olhar para dentro. Agora, essa caixa preta tem uma data de validade, e ignorá-la pode trazer consequências sérias.

O Novo Porteiro Chegou: Bem-vinda, Gateway API!

A boa notícia é que o prédio não ficará sem portaria. A comunidade Kubernetes não está apenas aposentando o antigo sistema, mas também recomendando fortemente seu sucessor moderno: a Gateway API. Lançada em disponibilidade geral no final de 2023, a Gateway API foi projetada desde o início para resolver muitas das limitações do padrão Ingress.

Sua principal vantagem é um design baseado em funções que separa as responsabilidades entre os provedores de infraestrutura, os operadores de cluster e os desenvolvedores de aplicações. Na prática, isso significa menos conflitos e uma gestão mais clara e segura. Além de suportar todos os recursos do Ingress, a Gateway API oferece suporte nativo para protocolos além do HTTP e HTTPS, como TCP, UDP e gRPC. Recursos avançados, como divisão de tráfego (traffic splitting) e correspondência baseada em cabeçalho (header-based matching), que exigiam anotações específicas de fornecedores no Ingress NGINX, agora são funcionalidades padrão. É a evolução natural, trocando as gambiarras por uma solução integrada e robusta.

E Agora? Como Saber se Meu Cluster Está na Berlinda?

Se você chegou até aqui se perguntando "será que eu uso isso?", a comunidade forneceu uma maneira simples de verificar. Com permissões de administrador de cluster, execute o seguinte comando:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

Se algo aparecer, é hora de começar a planejar a migração. Para aqueles que não podem ou não querem adotar a Gateway API imediatamente, existem outras alternativas de controladores de ingresso que ainda são mantidos ativamente. Fornecedores como NGINX (com seu próprio NGINX Gateway Fabric), Kong, Traefik, HAProxy e outros já estão se posicionando, publicando guias de migração e oferecendo seus produtos como sucessores. A HAProxy, por exemplo, até disponibilizou uma ferramenta de migração para facilitar a transição. O mercado, como sempre, não perde tempo.

No fim das contas, como concluiu Jimmy Song, a aposentadoria do Ingress NGINX "não é um fracasso, mas um resultado inevitável do avanço do sistema para o próximo estágio". É um sinal de maturidade do ecossistema, que agora exige soluções mais seguras, extensíveis e sustentáveis. Para as equipes de DevOps e SRE, a contagem regressiva começou. Planejar a migração o mais rápido possível é a única forma de garantir que seus clusters permaneçam confiáveis e, acima de tudo, seguros.