Ingress NGINX será descontinuado.
Chegou a hora de migrar para o Gateway API — o novo padrão Kubernetes.
O Kubernetes anunciou oficialmente o fim do Ingress NGINX, incluindo encerramento de atualizações de segurança e congelamento do projeto. A partir de março de 2026, qualquer ambiente que ainda dependa do controlador ficará desprotegido, vulnerável e fora das melhores práticas.
Por que o Ingress NGINX está sendo aposentado?
- Falta de manutenção ativa
- Acúmulo de vulnerabilidades
- Dívida técnica histórica
- Arquitetura não sustentável
- Substituição oficial pelo Gateway API
O aviso foi claro: Ingress NGINX entrou em fim de vida.
Por que migrar direto para o Gateway API? (e não para Traefik)
O Gateway API não é apenas “mais um controlador”. Ele é o novo padrão oficial do Kubernetes, suportado por:
- AWS
- Azure
- Istio
- Cilium
- Traefik
- Envoy
- Contour
- Emissary
- HAProxy
Migrar para Traefik agora significa ter que migrar novamente para o Gateway API mais tarde.
Migrar para o Gateway API agora significa:
- Uma migração só
- Zero retrabalho
- Arquitetura preparada para o futuro
- Padronização total com o ecossistema Kubernetes
- Melhor segurança e governança
Migrar para Traefik agora só adia o inevitável: o padrão do Kubernetes já é Gateway API.
E o RH nem sempre tem tempo para estruturar um programa de capacitação contínua para os colaboradores..
Mas a ‘roda gira’ e colaboradores motivados buscam por oportunidades reais de evolução na carreira.
Migrar para Traefik é um movimento defensivo do tipo: “vamos só resolver isso rápido e depois a gente ataca a solução definitiva.”
Veja os argumentos para migrar diretamente para o Gateway API agrupados em 4 grandes pilares:
O Kubernetes já abandonou Ingress como padrão e substituiu oficialmente por Gateway API.
A migração “simples” para Traefik vira uma segunda migração no futuro — ou seja, mais custo.
A governança, segurança e multi-tenancy são muito superiores no Gateway API.
A indústria inteira (cloud providers, CNCF, vendors) está padronizando em Gateway API, não em Traefik.
Argumentos Técnicos
1. Traefik, Istio e Cilium continuarão sendo implementações” — não o padrão
Traefik, Istio e Cilium implementam Gateway API, mas não são o padrão em si. O que o Kubernetes oficializou é o modelo API. Não o controlador. Logo: migrar para Traefik = mudar só de controlador (continua preso à abstração dele) migrar para Gateway API = migrar para o padrão da plataforma Kubernetes Gateway API é o único caminho que nunca será depreciado.
2. Migrar para Traefik agora obriga uma segunda migração futura
Se o cliente migrar assim: NGINX → Traefik e depois: Traefik → Gateway API
Isso implica em trabalho dobrado: 2 ondas de projeto, 2 ondas de mudança, 2 ondas de risco e 2 ondas de validações, homologações, auditorias e CAB. Isso implica em dobro do custo, dobro da complexidade e dobro da exposição a falhas.
3. O Ingress NGINX tinha seus problemas e Gateway API resolve 90% das dores antigas
O Ingress NGINX tinha limitações históricas:
- sem suporte nativo a TCP/UDP
- sem roteamento avançado L4/L7
- sem gestão de múltiplos Gateways por time
- sem granularidade de permissões
- anotações inconsistentes por controlador
O Gateway API resolve tudo isso com:
- Route especifica por serviço/li>
- Listeners/li>
- Policies/li>
- RBAC granular/li>
- Suporte nativo multi-tenancy/li>
- Menos dependência de anotações que quebram/li>
4. Traefik tem sintaxe proprietária
Esses controladores têm:
- CRDs próprias (Middleware no Traefik, VirtualService/Gateway no Istio)
- especificações diferentes
- “dialetos” de roteamento diferentes
- muda controlador
- não muda a configuração
O Kubernetes quer esse futuro.
Argumentos de Negócio
O seu gerente técnico ou CTO precisa saber disso:
1. O mercado inteiro está padronizando em Gateway API
Quem já anunciou suporte total a Gateway API como padrão:
- GKE
- AKS
- EKS
- Istio
- Cilium
- Contour
- Linkerd
- Traefik
- Emissary
- HAProxy
- Envoy
Ou seja, migrar para Gateway API é uma aposta ganha. Migrar inicialmente para Traefik é apenas adiar o inevitável.
2. Compliance e Segurança de 2026 em diante exigirão Gateway API
Se sua empresa segue compliances as auditorias de segurança irão questionar:
- "Por que vocês continuam usando APIs proprietárias de fornecedores?"
- "Como é realizada a governança de rotas por equipe?"
- "Como garantem isolamento de tenants?"
- "Por que usam anotações fora do padrão oficial?"
O Gateway API foi criado exatamente para: padronizar, reduzir risco, facilitar auditorias e permitir traceabilidade clara de tráfego.
3. É muito mais barato fazer uma migração definitiva do que duas
Quando você mostra este cálculo, somando os dois custos, todo gerente entende:
Custo da migração agora:
NGINX → Traefik (médio)
+ futura migração Traefik → Gateway API (alto)
= custo total maior
Custo da migração única:
NGINX → Gateway API (médio)
= custo total menor
Historicamente, projetos de TI são mais baratos quando vão direto ao padrão final.
Ainda está em dúvida sobre migrar diretamente para o Gateway API?
Reflita sobre estas sete afirmações abaixo e migre com tranquilidade com nossos serviços de migração.
“Migrar para Traefik agora só adia o inevitável: o padrão do Kubernetes já é Gateway API.”
“Traefik é controlador. O Gateway API é o padrão.”
“A escolha que evita retrabalho é migrar direto para Gateway API.”
“Gateway API elimina dívida técnica enquanto Traefik a mantém.”
“Com Gateway API você escreve a configuração uma vez e usa com qualquer controlador.”
“É muito mais barato fazer uma migração definitiva do que duas.”
“É muito mais barato fazer uma migração definitiva do que duas.”
Como a 4Linux ajuda sua empresa?
Assessment de Risco e Arquitetura NGINX
Mapeamos ingress, regras, TLS, anotações, rotas e dependências.
Plano de Migração Personalizado
Definimos a estratégia mais segura e eficiente para o seu cluster.
Implementação da Camada Gateway API
Criação de Gateways, Routes, Listeners, Policies e segurança.
Testes, validação e Traffic Shifting
Realizamos a transição de maneira controlada e sem interrupção.
Testes, validação e Traffic Shifting
Realizamos a transição de maneira controlada e sem interrupção.
Atenção: você tem até março de 2026
Depois disso, Ingress NGINX não receberá nenhum patch de segurança. Ambientes em produção estarão vulneráveis.
