[Opinião] O fim do ingress-nginx e o que adotar agora
A aproximação do fim do suporte ao ingress-nginx torna urgente que equipes de plataforma analisem cuidadosamente alternativas. A seguir compartilho minha sugestão pessoal estou adotando o Traefik mas há outros controladores válidos no mercado que também merecem avaliação.
Por que avaliar a migração agora
O ingress-nginx está projetado para entrar em modo de manutenção: sem novas funcionalidades relevantes, apenas patch-fixes de segurança.
Além disso, vulnerabilidades recentes evidenciaram falhas arquiteturais graves, como injeção de configuração que transcende bugs isolados.
Enquanto isso, a proposta de substituição oficial InGate ainda está em estágio pouco maduro, o que faz com que muitas organizações não possam esperar anos por uma solução viável.
Portanto, a migração deixa de ser apenas opcional: torna-se uma consideração de risco operacional.
Quatro requisitos centrais para o controlador de ingress moderno
Para selecionar um controlador de ingress que realmente sustente produção pelos próximos anos, recomendo considerar quatro critérios críticos:
1. Segurança por design
O controlador não deve depender de templating dinâmico, interpolação de strings ou carregamento de bibliotecas externas práticas que abriram espaço para vulnerabilidades.
2. Adoção ampla e comprovada
Importante que o controlador tenha escala real de produção, comunidade ativa, histórico de uso e maturidade no ecossistema Kubernetes.
3. Alinhamento ao padrão Gateway API
O padrão Gateway API está emergindo como a direção futura das redes em Kubernetes. Um controlador que investe nisso já terá caminho evolutivo.
4. Compatibilidade com ingress-nginx
Para preservar investimentos em manifestos, anotações e conhecimento operacional, é essencial que você consiga reutilizar o máximo possível da configuração existente.
Como o Traefik atende a esses requisitos (e o porquê da minha escolha)
Segurança como fundamento
Traefik foi projetado com escolhas arquiteturais claras: escrita em Go (evitando classes típicas de bugs em C/C++), binário estaticamente linkado, configuração fortemente tipada ao invés de templates, e superfície de ataque reduzida.
Esses fatores ajudam a mitigar ataques de injeção de configuração que afetam controladores baseados em NGINX.
Adoção consolidada
Traefik é amplamente adotado: bilhões de downloads, dezenas de milhares de estrelas no GitHub, centenas de colaboradores ativos atributos que indicam maturidade real em ambientes de produção.
Seu DNA “cloud-native” faz diferença quando serviços surgem e desaparecem dinamicamente em clusters Kubernetes.
Liderança em Gateway API
Traefik não trata o Gateway API como experimento: suporta versão v1.4 do specification e posiciona-se como first-class para usuários que desejam evoluir suas redes.
Isso fornece um caminho de evolução, em vez de permanecer preso à abstração antiga de Ingress.
Compatibilidade com ingress-nginx
A novidade decisiva: Traefik introduziu o “NGINX Provider” para que ele possa aceitar recursos de ingress-nginx (Ingress + anotações) e traduzi-los internamente para Traefik.
Com esse mecanismo, você pode migrar parcialmente preservando investimentos existentes e evoluir gradualmente para funcionalidades nativas de Traefik ou Gateway API.
Como migrar na prática (exemplo)
Suponha que você tenha um recurso de Ingress com anotações específicas do ingress-nginx:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-with-nginx-annotation
namespace: default
annotations:
nginx.ingress.kubernetes.io/auth-type: \"basic\"
nginx.ingress.kubernetes.io/auth-secret-type: \"auth-file\"
nginx.ingress.kubernetes.io/auth-secret: \"default/basic-auth\"
nginx.ingress.kubernetes.io/auth-realm: \"Authentication Required\"
nginx.ingress.kubernetes.io/ssl-redirect: \"true\"
spec:
ingressClassName: nginx
rules:
- host: whoami.localhost
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: whoami
port:
number: 80
tls:
- hosts:
- whoami.localhost
secretName: external-certs
E o Secret correspondente:
kind: Secret
apiVersion: v1
metadata:
name: basic-auth
namespace: default
type: Opaque
data:
auth: dXNlcjp7U0hBfVc2cGg1TW01UHo4R2dpVUxiUGd6RzM3bWo5Zz0=
Com ingress-nginx, você poderia testar via:
curl http://whoami.localhost -L -u \"user:password\" --location-trusted
Para expor a mesma aplicação com Traefik, você instalaria o Deployment + Service e habilitaria o NGINX Provider conforme documentação oficial: a funcionalidade está marcada como experimental.
kind: Deployment
apiVersion: apps/v1
metadata:
name: traefik
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: traefik
template:
metadata:
labels:
app: traefik
spec:
serviceAccountName: traefik-ingress-controller
containers:
- name: traefik
image: traefik:v3.5.0
args:
- --log.level=DEBUG
- --api.insecure
- --api.debug
- --entrypoints.web.address=:80
- --entrypoints.websecure.address=:443
- --experimental.kubernetesIngressNGINX
- --providers.kubernetesIngressNGINX
ports:
- name: web
containerPort: 80
- name: admin
containerPort: 8080
- name: websecure
containerPort: 443
apiVersion: v1
kind: Service
metadata:
name: traefik
namespace: default
spec:
type: LoadBalancer
selector:
app: traefik
ports:
- protocol: TCP
port: 80
name: web
- protocol: TCP
port: 443
name: websecure
- protocol: TCP
port: 8080
name: admin
Observe que --providers.kubernetesIngressNGINX habilita o Traefik para descobrir e processar recursos de ingress-nginx automaticamente, o que preserva sua configuração existente enquanto você evolui para novos padrões.
Suporte a anotações mais usadas e limitações
O NGINX Provider prioriza as anotações mais comuns baseadas em dados de uso real autenticação/autorização, TLS/SSL, comunicação com backend, balanceamento de carga, CORS, roteamento avançado.
Importante notar: não cobre todas as anotações do ingress-nginx.
Portanto, durante a migração, revise as anotações específicas que você está usando, teste comportamento em staging, e planeje a adoção de funcionalidades nativas de Traefik quando necessário.
Caminho de evolução pós-migração
A migração para Traefik não precisa implicar ruptura completa. Você pode:
Continuar rodando seus Ingress existentes enquanto migra gradualmente para recursos nativos Traefik ou Gateway API.
Adotar o Gateway API conforme for conveniente: o provider do Traefik suporta o padrão Gateway API (v1.4) para HTTPRoute, GRPCRoute, TCPRoute, entre outros.
Usar a compatibilidade com ingress-nginx como ponte e evoluir para melhores práticas de rede e segurança ao longo do tempo.
Essa abordagem permite que a transição ocorra com mínima interrupção, preservando investimentos em configurações e conhecimento operacional.
Outros controladores a considerar
Embora minha escolha pessoal seja o Traefik, há outros controladores de ingress/networking que merecem avaliação:
-
HAProxy Ingress – robusto, com longa história no mundo NGINX/HAProxy.
-
Contour – projetado pela comunidade CNCF, compatível com Gateway API.
-
Istio (com seu componente de ingress) – se você já está usando um Service Mesh, pode fazer sentido centralizar.
Avalie cada solução com base nos critérios acima (segurança, adoção, padrão Gateway, compatibilidade) e no contexto específico da sua empresa/plataforma.
Conclusão
Dado que ingress-nginx está entrando em manutenção, e que a substituição oficial ainda não está pronta para produção em massa, considero que Traefik apresenta uma alternativa prática, segura e alinhada com o futuro do Kubernetes.
Graças à compatibilidade com ingress-nginx, à arquitetura voltada para segurança, à adoção consolidada e ao suporte robusto ao Gateway API, a migração para Traefik pode ser feita de forma gradual e estratégica.
Minha sugestão pessoal é: planeje e execute agora, preservando seus investimentos e preparando a infraestrutura de rede para os próximos anos.
Fontes: