Com a aposentadoria do Ingress-NGINX e a Gateway API v1.5 estabilizando recursos essenciais, o modo como expomos serviços no Kubernetes mudou de vez. Entenda o que aconteceu e como planejar a transição sem sustos.
</>Se você opera clusters Kubernetes há algum tempo, provavelmente já digitou dezenas de anotações mágicas em um recurso Ingress para fazer um simples path rewrite ou habilitar CORS. Esse capítulo está se encerrando. Em 2026 dois movimentos convergiram e mudaram, na prática, como expomos serviços em produção: a aposentadoria do Ingress-NGINX e o amadurecimento da Gateway API. Este artigo explica o que houve, por que importa para SRE e times de plataforma, e como conduzir a migração com segurança.
O Ingress-NGINX foi, por muitos anos, o controlador de Ingress mais usado do ecossistema. Justamente por isso, tornou-se grande e sensível demais em termos de segurança para o time atual de mantenedores sustentar com folga. Depois de esgotar as tentativas de reforçar a manutenção, o SIG Network e o Security Response Committee decidiram aposentar o projeto, priorizando a segurança dos usuários.
Na prática, isso significa que, após março de 2026, não há mais novas versões, correções de bugs nem patches para vulnerabilidades que venham a surgir. Instalações existentes continuam funcionando e os artefatos de instalação permanecem disponíveis, mas rodar em produção um componente de borda sem correções de segurança é um risco que cresce a cada dia.
A API de Ingress em si não foi removida: ela segue disponível, porém congelada. Todo o desenvolvimento ativo migrou para a Gateway API.
A Gateway API não é apenas um “Ingress melhorado”. É um redesenho da forma como descrevemos tráfego de entrada, pensado para ser modular, extensível e com forte suporte a RBAC nativo do Kubernetes. Em vez de empilhar anotações específicas de cada fornecedor, você trabalha com recursos tipados e com responsabilidades separadas por papel.
Esse modelo separa quem cuida da infraestrutura de quem cuida da aplicação:
Essa divisão resolve um problema recorrente em clusters multi-inquilino: liberar que times de aplicação configurem suas rotas sem dar a eles controle sobre a infraestrutura compartilhada de borda.
A versão 1.5 da Gateway API concentrou-se em promover recursos experimentais para o canal Standard (estável), o que remove o principal receio de quem adiava a adoção. Entre os recursos promovidos estão o ListenerSet, o TLSRoute, o filtro de CORS no HTTPRoute, a validação de certificado de cliente e a seleção de certificado para TLS. O ListenerSet merece destaque: ele permite definir listeners de forma independente que se agregam a um Gateway existente, viabilizando ultrapassar o limite de 64 listeners em um gateway compartilhado e delegar propriedade a vários times sem coordenação manual.
Outra mudança relevante de processo: a partir da v1.5 o projeto adotou um modelo de “trem de releases”, com data de congelamento de recursos e a regra de que nada é lançado sem documentação pronta. Para quem opera em produção, isso significa uma cadência mais previsível.
A boa notícia é que existe ferramenta oficial para reduzir o trabalho manual. O Ingress2Gateway 1.0 traduz recursos Ingress e suas anotações específicas para o equivalente na Gateway API, avisa sobre configurações que não têm tradução direta e sugere alternativas.
Um roteiro pragmático seria:
O ponto de atenção é não tratar isso como um mero find-and-replace. Como a Gateway API muda o modelo mental, vale investir tempo entendendo a separação de papéis antes de mover produção.
A aposentadoria do Ingress-NGINX não é motivo de pânico, mas é um prazo real. Com a Gateway API estável e ferramentas de migração maduras, 2026 é o momento certo para planejar a transição com calma, em vez de reagir a uma vulnerabilidade sem correção. Comece pelo inventário, valide em ambientes controlados e trate a mudança como uma oportunidade de organizar melhor as responsabilidades entre plataforma e aplicação.
DevOps</>Segunda e última parte da série: a pipeline que criava a branch agora abre o Pull Request, vincula o Work Item, liga o auto-complete em nome de quem executou — e cria as branch policies que fazem tudo isso significar alguma coisa.
DevOps</>Primeiro post da série sobre Azure DevOps Pipelines: uma pipeline YAML executada manualmente que recebe projeto, atividade e squad como parâmetros e cria uma branch padronizada no repositório, via git CLI ou REST API.