O Ingress NGINX foi aposentado. E agora?

Fala pessoal, tudo bem?

"O controlador mais usado para expor aplicações no Kubernetes parou de receber atualizações em março de 2026. Se ele ainda está no seu cluster, você está sem patches de segurança."

Em novembro de 2025 o projeto Kubernetes anunciou algo que pegou muita gente de surpresa: o Ingress NGINX seria aposentado em março de 2026. Esse prazo já passou.

Estamos falando de um componente usado em cerca de metade dos ambientes cloud native, segundo o próprio comunicado do Kubernetes. E o motivo não foi técnico: foi falta de mantenedores.

🚨 O que significa na prática: sem novas versões, sem correção de bug e sem patch de segurança. O controlador continua rodando, mas qualquer vulnerabilidade nova fica aberta para sempre.

Obs: estamos falando do projeto comunitário kubernetes/ingress-nginx. O controlador mantido pela F5/NGINX é outro projeto.

Como saber se você usa

# quais IngressClasses existem no cluster
$ kubectl get ingressclass

# procurando o controlador comunitário em qualquer namespace
$ kubectl get pods -A -l app.kubernetes.io/name=ingress-nginx

# quantos Ingress dependem dele
$ kubectl get ingress -A

Se apareceu algo, o assunto é com você. Rode isso em todos os clusters, inclusive aquele de homologação esquecido.

A lição maior: infraestrutura crítica sem dono

Antes da parte técnica, vale a reflexão. Um componente que está na frente de metade das aplicações do mundo foi mantido por pouquíssimas pessoas, muitas no tempo livre. Quase ninguém que usava contribuía.

Isso não é exclusivo do Ingress NGINX. Pergunte-se: quantas peças do seu ambiente dependem de projetos que você nunca olhou quem mantém?

Para onde ir: Gateway API

A recomendação oficial é migrar para a Gateway API (ou para outro controlador Ingress mantido). A Gateway API é o sucessor do Ingress, e a maior mudança é a separação de responsabilidades:

Cada recurso tem um dono GatewayClass qual implementação usar Provedor de infraestrutura Gateway porta, TLS, quem pode se ligar Time de plataforma / operação HTTPRoute host, path, para qual Service Time da aplicação

No Ingress, tudo isso ficava num único objeto, cheio de annotations específicas do controlador. Na Gateway API, cada time mexe só no que é seu.

Exemplo: o mesmo roteamento, antes e depois

# ANTES: Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: loja
spec:
  ingressClassName: nginx
  rules:
    - host: loja.exemplo.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: loja-web
                port:
                  number: 80

# DEPOIS: HTTPRoute (o Gateway "publico" é do time de plataforma)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: loja
spec:
  parentRefs:
    - name: publico
      namespace: infra-gateway
  hostnames:
    - loja.exemplo.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: loja-web
          port: 80

💡 Atalho útil: o projeto ingress2gateway (kubernetes-sigs) converte Ingress existentes em recursos da Gateway API. Use como ponto de partida e revise o resultado. Annotations específicas do NGINX nem sempre têm equivalente direto.

Plano de migração em 4 passos

1. Inventário: liste todos os Ingress e, principalmente, as annotations usadas (rewrite, auth, rate limit).
2. Escolha a implementação da Gateway API e suba em paralelo, sem tirar o NGINX.
3. Migre por aplicação, começando pela menos crítica. Teste apontando DNS ou peso de tráfego.
4. Desligue o antigo só quando nenhum Ingress depender dele.

Considerações Finais

A aposentadoria do Ingress NGINX é um lembrete duro: open source é gratuito para usar, mas não é gratuito para manter. Alguém paga essa conta, e às vezes ninguém está pagando.

Se o seu cluster ainda depende dele, a migração não é mais "algum dia". É agora.

Abs e até a próxima!!!

:wq!