Ingress NGINX foi aposentado: o que usar no Kubernetes agora

Se você administra um cluster Kubernetes, existe uma boa chance de ele estar rodando um componente que não recebe mais correções de segurança desde março de 2026. Ele continua funcionando normalmente. Continua roteando o tráfego. E é exatamente por isso que o problema passa despercebido.

O componente é o Ingress NGINX, o controlador de entrada mais usado do ecossistema. Segundo o comunicado oficial do projeto, ele era infraestrutura crítica para cerca de metade dos ambientes cloud native. Neste artigo você vai entender o que aconteceu, como descobrir se o seu cluster está exposto e como migrar para o substituto oficial, o Gateway API.

O que aconteceu com o Ingress NGINX

Em 11 de novembro de 2025, o SIG Network do Kubernetes e o Security Response Committee anunciaram a aposentadoria do projeto. Em 29 de janeiro de 2026, o Steering Committee publicou um comunicado conjunto reforçando a urgência. A retirada aconteceu em março de 2026, e o repositório foi arquivado em modo somente leitura.

O comunicado oficial não usa meias palavras:

“Não haverá mais releases para correções de bugs, patches de segurança ou atualizações de qualquer tipo depois que o projeto for aposentado.”

E, sobre o risco de simplesmente deixar como está:

“Implantações existentes continuarão funcionando, então a menos que você verifique proativamente, você pode não saber que está afetado até ser comprometido.”

Essa é a parte que engana. Um componente aposentado não quebra no dia seguinte. Ele apenas para de ser consertado. Como o Ingress NGINX fica na borda do cluster, recebendo tráfego da internet antes de qualquer outra coisa, ele é justamente onde uma vulnerabilidade sem patch dói mais.

Como saber se o seu cluster está exposto

O próprio comunicado do Kubernetes indica o comando de verificação. Rode isto no seu cluster:

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

Se a saída listar qualquer pod, você está rodando o componente aposentado. Se voltar No resources found, seu cluster não usa esse controlador.

Vale rodar também em clusters que você herdou ou que ninguém toca há meses. São exatamente esses que costumam guardar a surpresa.

Um esclarecimento importante: a API Ingress não foi removida

Aqui mora a confusão mais comum, e ela vale a pena separar com clareza.

O que foi aposentado é o Ingress NGINX, um controlador específico, mantido pela comunidade, que implementa a API Ingress usando o NGINX por baixo.

O que continua existindo é o recurso Ingress do Kubernetes, aquele que você escreve no YAML. Ele permanece disponível e estável. O que mudou é que ele está congelado: não recebe mais funcionalidades novas, porque o desenvolvimento ativo migrou para o Gateway API.

Ou seja: seus manifestos Ingress não param de valer. Mas o controlador que os executava precisa ser trocado, e o caminho recomendado leva a um modelo diferente.

O que é o Gateway API

O Gateway API é o sucessor oficial. Na versão v1.6.1, o canal estável inclui os recursos GatewayClass, Gateway, HTTPRoute e ReferenceGrant.

A diferença de fundo não é de sintaxe, é de responsabilidade. No modelo Ingress, um único objeto misturava tudo: quem expõe a porta, qual o certificado, para onde vai cada rota. E qualquer comportamento fora do básico virava anotação, aquelas linhas nginx.ingress.kubernetes.io/... que só funcionavam naquele controlador específico.

O Gateway API separa isso em papéis. Quem cuida da infraestrutura declara o Gateway, que define as portas e os protocolos expostos:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-web
spec:
  gatewayClassName: example
  listeners:
  - protocol: HTTP
    port: 80
    name: prod-web-gw
    allowedRoutes:
      namespaces:
        from: Same

E quem cuida da aplicação declara o HTTPRoute, que se conecta a esse Gateway através do campo parentRefs e diz para qual Service o tráfego vai:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: foo
spec:
  parentRefs:
  - name: prod-web
  rules:
  - backendRefs:
    - name: foo-svc
      port: 8080

Repare no ganho prático: o time de aplicação publica rotas sem precisar de acesso ao objeto que expõe o cluster. Em um ambiente com várias equipes, isso deixa de ser elegância de design e vira controle de permissão de verdade. Além disso, roteamento por cabeçalho, reescrita de caminho e divisão de tráfego passam a ser campos do próprio recurso, e não anotações de um fornecedor.

Migrando na prática com o ingress2gateway

Em 20 de março de 2026 o SIG Network publicou a versão 1.0 do ingress2gateway, uma ferramenta que traduz seus recursos Ingress existentes para Gateway API. A versão 1.0 cobre mais de 30 anotações comuns do Ingress NGINX, incluindo CORS, TLS de backend, casamento por regex e reescrita de caminho.

Instale com:

go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0

O binário vai para $(go env GOPATH)/bin. Também há binários prontos na página de releases.

Para ver a tradução dos recursos do cluster atual, sem aplicar nada:

# lê o kubeconfig ativo e imprime o resultado na tela
ingress2gateway print --providers=ingress-nginx

# varrendo todos os namespaces
ingress2gateway print --providers=ingress-nginx --all-namespaces

# a partir de arquivos, sem tocar em cluster nenhum
ingress2gateway print --providers=ingress-nginx --input-file=meu-ingress.yaml

O comando print apenas escreve na saída padrão. Nada é aplicado no cluster, o que torna seguro rodar em produção só para inspecionar.

Um ponto que os próprios mantenedores fazem questão de deixar claro: a migração é assistida, não automática. A ferramenta converte o que consegue e avisa sobre o que não consegue, com sugestões. O comunicado oficial é direto quanto a isso:

“Nenhuma das alternativas disponíveis é um substituto direto.”

Trate a saída como rascunho revisável, nunca como resultado final. Na prática, esse momento é uma boa oportunidade para descartar configuração antiga que ninguém lembra por que existe.

Quem já migrou

Dois casos públicos ajudam a dimensionar o esforço real.

O GitLab adotou o Gateway API com o Envoy Gateway como configuração padrão a partir do GitLab 19.0, documentando a transição no planejamento público de infraestrutura. Quem não consegue migrar de imediato pode reabilitar explicitamente o NGINX Ingress empacotado, que segue disponível até a remoção planejada no GitLab 20.0. Repare no padrão: mesmo uma empresa com time de infraestrutura dedicado tratou a migração como transição com porta de saída, e não como troca de um dia.

A AWS publicou um guia prático de migração no blog de Networking, voltado a quem roda o controlador em EKS. Provedores gerenciados publicarem guia próprio é um bom indicador de quantos clientes foram afetados.

Erros comuns nessa migração

Achar que o recurso Ingress foi removido. Não foi. Ele continua válido e estável, apenas congelado. O que acabou foi um controlador específico.
Confiar que a ferramenta resolve tudo. O ingress2gateway traduz o que dá e avisa o resto. Anotações específicas do NGINX sem equivalente precisam de decisão humana.
Procurar um substituto drop-in. Não existe. Trocar o controlador exige testar o comportamento de roteamento, e não apenas aplicar YAML novo.
Adiar porque “está funcionando”. Esse é o erro caro. Continuar funcionando é o comportamento esperado de software sem manutenção; a falta de patch só aparece quando alguém explora a falha.
Migrar direto em produção. Suba o Gateway em paralelo, mova uma rota de baixo risco, compare o comportamento e só então avance. O print existe justamente para permitir esse ensaio.

Por onde começar hoje

Se você está estudando Kubernetes agora, aprenda Gateway API como o caminho padrão e trate Ingress como o modelo que você vai encontrar em sistemas já existentes. Os dois aparecem no mercado, mas só um deles ainda está sendo desenvolvido.

Um roteiro curto para praticar em cluster local: rode o comando de verificação, instale os CRDs do Gateway API, suba um Gateway e um HTTPRoute apontando para um Service qualquer, e depois use o ingress2gateway print em um Ingress que você mesmo escreveu para comparar as duas formas lado a lado. Ver o mesmo roteamento escrito nos dois modelos ensina mais rápido do que qualquer tabela comparativa.

Para contexto, o Kubernetes 1.37.0 foi liberado em 26 de agosto de 2026, então vale conferir a compatibilidade de versão do controlador que você escolher.