Por anos, o ingress-nginx foi a resposta padrão para a pergunta "como exponho meus serviços no Kubernetes?". Simples de instalar, bem documentado e com ampla adoção da comunidade, ele se tornou parte quase automática de qualquer cluster de produção. Mas em novembro de 2025, o projeto Kubernetes anunciou oficialmente a descontinuação do ingress-nginx — e a recomendação é clara: migre para o Kubernetes Gateway API.
Neste artigo, vamos além do anúncio. Com base em um estudo de benchmarks independente e rigoroso, apresentamos quais implementações do Gateway API são as mais maduras hoje, quais são os resultados técnicos que embasam essa recomendação, e o que você precisa considerar ao planejar a migração.
Créditos: os dados, gráficos e descobertas apresentados neste artigo são baseados no estudo conduzido por Howard John, disponível em github.com/howardjohn/gateway-api-bench. Todo o mérito pela metodologia e execução do benchmark é do autor original.
O fim do nginx-ingress
Em 11 de novembro de 2025, o projeto Kubernetes publicou o anúncio formal de aposentadoria do ingress-nginx. Não se trata de abandono imediato — há um período de transição previsto —, mas a direção está traçada: a Ingress API está em modo de manutenção, e o desenvolvimento ativo migrou para o Gateway API.
O que isso significa na prática para equipes que operam nginx-ingress hoje?
- Nenhuma nova funcionalidade será adicionada ao
ingress-nginx - Correções de segurança têm prazo definido, não indefinido
- A comunidade e os mantenedores estão concentrando esforços no Gateway API
Essa não é uma mudança surpresa. O Gateway API existe como projeto oficial desde 2020 e atingiu GA (Generally Available) em 2023. O nginx-ingress sempre foi uma solução pragmática para um momento em que o Kubernetes ainda não tinha uma API de roteamento expressiva o suficiente. Aquele momento passou.
O que é o Gateway API?
O Gateway API não é apenas um substituto sintático do Ingress. É uma reformulação do modelo de roteamento de tráfego no Kubernetes, projetada para cenários modernos de multi-tenancy, segurança por namespace e extensibilidade.
Hierarquia de recursos
GatewayClass → Gateway → HTTPRoute
(infra) (operador) (desenvolvedor)
Essa separação é intencional e poderosa:
- GatewayClass: define a implementação (Istio, Envoy Gateway, etc.). Gerenciado pelo time de plataforma/infra.
- Gateway: instancia um ponto de entrada de tráfego em um namespace específico. Gerenciado por operadores ou times de plataforma.
- HTTPRoute: define as regras de roteamento para uma aplicação. Pode ser gerenciado pelo próprio time de desenvolvimento, sem acesso privilegiado ao cluster.
Vantagens frente ao Ingress
| Característica | Ingress API | Gateway API |
|---|---|---|
| Separação de responsabilidades | Única anotação (tudo junto) | Recursos distintos por papel |
| Multi-tenancy nativo | Não | Sim, por design |
| Suporte a múltiplos protocolos | HTTP/HTTPS apenas | HTTP, HTTPS, TCP, UDP, gRPC |
| Data plane no namespace correto | Depende da implementação | Requisito da especificação |
| Extensibilidade | Anotações proprietárias | Policies e extensões padronizadas |
| Suporte a múltiplos backends por rota | Limitado | Nativo (pesos, canary, etc.) |
O Estudo de Benchmarks
Para além das promessas da especificação, o que importa é como as implementações se comportam na prática. O estudo conduzido por Howard John realizou dois ciclos de testes (v1 e v2) em um ambiente kind de nó único com hardware de ponta (AMD 9950x, 16 cores, 96 GB RAM), avaliando:
Implementações no v1: Cilium, Envoy Gateway, Istio, Kgateway, Kong, Traefik, Nginx
Implementações no v2: Agentgateway, Envoy Gateway, Istio, Nginx
Nota: o autor possui associações com alguns dos projetos testados (Istio, Envoy, Kgateway, Agentgateway). O benchmark foi conduzido com esforço explícito de imparcialidade, e os resultados podem ser reproduzidos por qualquer pessoa.
Categorias de testes
| Teste | O que mede |
|---|---|
| Attached Routes | Velocidade e corretude na atualização do status de rotas |
| Route Propagation | Tempo até uma nova rota estar disponível no data plane |
| Route Changes | Downtime durante atualização de rotas com tráfego ativo |
| Route Scale | Consumo de recursos com 5.000 rotas simultâneas |
| Traffic Performance | Throughput e latência do data plane |
| ListenerSet Scale | Desempenho com 2.500 ListenerSets e 40.000 rotas |
| Backend Failover | Comportamento durante indisponibilidade de backends |
Resultados por Categoria
Attached Routes — Corretude do Status
Neste teste, mil rotas são criadas e o campo attachedRoutes do Gateway é monitorado. O objetivo não é apenas velocidade, mas corretude: o gateway está reportando o estado correto?
Problemas identificados:
- Nginx continua violando a especificação, inserindo entradas duplicadas no status — um comportamento que persistiu tanto no v1 quanto no v2.
- Envoy Gateway utiliza 10x mais CPU neste teste em comparação com as outras implementações.
- Istio e Agentgateway passam sem ressalvas.
// Nginx escrevendo entradas duplicadas no status (comportamento indevido)
{
"user": "system:serviceaccount:nginx-system:nginx-nginx-gateway-fabric",
"gw": [
"gateway.nginx.org/nginx-gateway-controller",
"kgateway.dev/agentgateway",
"istio.io/gateway-controller",
"gateway.envoyproxy.io/gatewayclass-controller",
"kgateway.dev/agentgateway", // ← duplicado
"gateway.envoyproxy.io/gatewayclass-controller" // ← duplicado
]
}
Route Propagation — Velocidade de Propagação
Quanto tempo leva para uma nova rota estar disponível para tráfego após ser criada? O teste cria 3.000 rotas sequencialmente e mede o tempo até o primeiro 200 OK.
| Gateway | Latência de propagação | Comportamento sob carga |
|---|---|---|
| Agentgateway | 10–30 ms (constante) | 30 ms (sem degradação) |
| Istio | 120–300 ms | 375 ms (+25%) |
| Envoy Gateway | ~600 ms | ~2.000 ms (+233%) |
| Nginx | ~800 ms | Travamento total (>5 min) |
Resultado crítico: O Envoy Gateway gerou 14.808 erros HTTP 503 durante o teste. Na prática, isso significa que novas regras de roteamento podem causar erros visíveis para usuários finais no momento da publicação. As demais três implementações completaram o teste com zero erros.
O Nginx, quando testado sob carga simultânea de escala, travou completamente durante mais de 5 minutos, sem processar nenhuma alteração de configuração. Foi excluído dos testes seguintes por esse motivo.
Route Changes — Zero Downtime
Tráfego contínuo é enviado para um gateway enquanto uma rota é modificada. Uma implementação passa se retornar 100% de respostas 200. É um teste binário — sem meio-termo.
| Gateway | Resultado | Motivo |
|---|---|---|
| Istio | ✅ Passa | Propagação atômica e sem interrupção |
| Agentgateway | ✅ Passa | |
| Nginx | ❌ Falha | Retorna 500 durante as mudanças |
| Envoy Gateway | ❌ Falha | Retorna 503 durante as mudanças |
Este é talvez o teste mais crítico para ambientes de produção. Deployments progressivos, canary releases e mudanças de roteamento são operações rotineiras. Uma implementação que causa downtime durante essas operações representa risco direto ao usuário final.
Route Scale — Consumo de Recursos com 5.000 Rotas
Este teste cria 50 namespaces com 100 rotas cada (5.000 rotas no total), simula churn constante (pods escalando, rotas sendo modificadas) e mede o consumo de CPU e memória.
Data plane
| Gateway | Memória inicial | Memória final | CPU em steady state |
|---|---|---|---|
| Agentgateway | 4 MB | 40 MB | < 1% |
| Istio | ~60–90 MB | ~1–2 GB | 20–240% |
| Envoy Gateway | ~60–90 MB | ~1–2 GB | 20–240% |
| Nginx | ~60–90 MB | ~1–2 GB | 20–240% |
O Agentgateway apresenta resultados 25 a 50x melhores que qualquer outra implementação no data plane.
Control plane — alocações Go (GC)
Pelo fato de todos os control planes serem escritos em Go, foi possível comparar o padrão de alocações de memória — um indicador direto de eficiência algorítmica:
| Gateway | Objetos alocados/s (steady state) | Memória alocada/s |
|---|---|---|
| Agentgateway | 6.000 | baseline |
| Istio | ~50.000 | ~4x |
| Envoy Gateway | 10.000.000 | 2.000x |
Score normalizado (80% data plane, 20% control plane)
Comparando cada implementação com o melhor desempenho em cada categoria:
| Gateway | Recursos relativos ao Agentgateway |
|---|---|
| Agentgateway | 1x (referência) |
| Istio | 44x mais recursos |
| Envoy Gateway | 108x mais recursos |
| Nginx | 295x mais recursos |
Traffic Performance — Throughput e Latência
O teste mede throughput máximo conforme o número de conexões aumenta, e latência P99 a 30.000 QPS fixos.
Throughput (maior é melhor):
| Gateway | 1 conexão | 16 conexões | 512 conexões |
|---|---|---|---|
| Kgateway | ~37k QPS | ~170k QPS | ~400k QPS |
| Envoy Gateway | ~34k QPS | ~138k QPS | ~325k QPS |
| Istio | ~29k QPS | ~130k QPS | ~328k QPS |
| Agentgateway | Bom | Cresce com conexões | Melhor no v2 |
| Nginx | ~1,7k QPS | ~33k QPS | ~91k QPS |
O principal achado aqui é o Nginx: seu desempenho é 20x pior que a média das demais implementações. A causa identificada é a ausência de connection pooling — cada requisição HTTP abre uma nova conexão TCP com o upstream. Todas as outras implementações reutilizam conexões, resultando em throughput muito superior.
Agentgateway, Istio e Envoy Gateway apresentam bom desempenho e ficam dentro da margem de comparação aceitável.
ListenerSet Scale — Múltiplos Domínios HTTPS
O XListenerSet é uma API experimental do Gateway API para gerenciar múltiplos domínios HTTPS de forma escalável — um caso de uso frequente em plataformas multi-tenant. O teste criou 2.500 ListenerSets e 40.000 rotas.
Apenas Agentgateway e Istio suportam esta API. Envoy Gateway e Nginx não têm suporte.
| Métrica | Agentgateway | Istio |
|---|---|---|
| Memória data plane | baseline | 15x mais |
| CPU data plane | baseline | 50x mais |
| Memória control plane | baseline | 1,3x mais |
| CPU control plane | baseline | 2,8x mais |
| Bandwidth control plane | baseline | 30x mais |
Um detalhe curioso: o Nginx e Envoy Gateway, mesmo sem nenhuma configuração relevante neste teste (nenhuma rota apontando para eles), consumiam recursos significativos — o Nginx chegou a usar 10x mais CPU que o Agentgateway apenas processando recursos que não eram destinados a ele.
Backend Failover — Resiliência a Instâncias Doentes
O teste simula um backend que alterna entre saudável e não saudável, analisando como cada gateway lida com as requisições durante as transições.
Sem configuração adicional:
| Gateway | Comportamento |
|---|---|
| Istio | Sem tratamento especial; mantém distribuição uniforme de tráfego |
| Envoy Gateway | Sem tratamento especial; mantém distribuição uniforme de tráfego |
| Nginx | Zero erros visíveis (mascarado por retries implícitos e eviction de 10s habilitados por padrão) |
| Agentgateway | ~25% menos erros (algoritmo de LB favorece endpoints saudáveis) |
Istio e Envoy Gateway oferecem outlier detection configurável, equivalente ao comportamento padrão do Nginx. No entanto, um detalhe arquitetural importante distingue os dois:
- Istio cria 1 cluster Envoy por
Service, centralizando as informações de saúde → outlier detection eficiente - Envoy Gateway cria 1 cluster por
HTTPRoute backend→ informações de saúde fragmentadas por rota → política de saúde muito menos eficiente quanto mais rotas distintas existirem para o mesmo backend
Envoy Gateway oferece também active health checks (como probes do Kubernetes, mas na camada do gateway), que resolvem o problema acima — porém com custo: cada instância do Envoy passa a enviar 1.000 requisições/s por rota configurada apenas para health check.
As Duas Alternativas Recomendadas
Com base na análise completa dos dois ciclos de benchmarks, duas implementações se destacam como as mais sólidas para ambientes de produção que estão migrando do nginx-ingress.
Istio — Maturidade e Ecossistema
O Istio é uma das implementações mais testadas em batalha do ecossistema Kubernetes. Foi o único projeto que não apresentou nenhum problema crítico em nenhum dos dois ciclos de benchmarks.
Pontos fortes:
- Arquitetura 100% conforme a especificação (data plane no namespace do Gateway, control plane separado)
- Zero falhas em Route Changes, Route Propagation e Attached Routes
- Ecossistema rico: mTLS automático, telemetria, circuit breaking, traffic management
- Suporte de múltiplos vendors (Red Hat, Google, Solo.io, Tetrate, entre outros)
- Comunidade ativa e projeto CNCF graduado
Considerações:
- Consumo de recursos moderado a alto em escala (44x vs. Agentgateway no benchmark de Route Scale)
- Curva de aprendizado maior para times sem experiência prévia com service mesh
- Ideal para times que já utilizam ou planejam utilizar Istio como service mesh — o Gateway API torna-se um benefício adicional sem overhead operacional novo
Quando escolher o Istio:
Você opera um cluster multi-tenant com múltiplos times, precisa de observabilidade avançada, mTLS entre serviços, ou já usa Istio como service mesh.
Agentgateway — Performance e Eficiência
O Agentgateway é uma implementação mais recente, construída especificamente para o Kubernetes Gateway API, com foco declarado em alta performance e eficiência de recursos. Os benchmarks confirmam essas promessas de forma inequívoca.
Pontos fortes:
- Melhor desempenho absoluto em todos os testes do ciclo v2
- Data plane com uso de memória 25–50x menor que qualquer outro implementação
- CPU do data plane abaixo de 1% mesmo sob carga pesada
- Propagação de rotas 20x mais rápida que a média (10–30ms constante, sem degradação sob carga)
- Zero erros em Route Changes e Route Propagation
- Algoritmo de load balancing que favorece backends saudáveis por padrão
Considerações:
- Projeto mais jovem, ecossistema em desenvolvimento
- Menor base de adoção em produção comparado a Istio
- Suporte a XListenerSet existe, mas o ecossistema ainda está amadurecendo
- Utiliza Kgateway como control plane — conhecer os dois projetos é necessário
Quando escolher o Agentgateway:
Você prioriza eficiência de recursos (custos de infra, density de workloads), precisa de propagação de rotas extremamente rápida, ou está construindo uma plataforma nova onde a maturidade do ecossistema é menos crítica que a performance.
Desafios Técnicos da Migração
Migrar do nginx-ingress para o Gateway API não é uma substituição de YAML. Há mudanças conceituais e operacionais que precisam ser planejadas.
1. Mapeamento de recursos
O Ingress é um único recurso. No Gateway API, a responsabilidade é dividida:
# Antes: tudo em um único Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: minha-app
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: app.exemplo.com
http:
paths:
- path: /api
backend:
service:
name: api-service
port:
number: 80
# Depois: Gateway (operador) + HTTPRoute (desenvolvedor)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: minha-app
namespace: minha-app
spec:
parentRefs:
- name: gateway-producao
namespace: infra
hostnames:
- "app.exemplo.com"
rules:
- matches:
- path:
type: PathPrefix
value: /api
filters:
- type: URLRewrite
urlRewrite:
path:
type: ReplaceFullPath
replacePrefixMatch: /
backendRefs:
- name: api-service
port: 80
2. Anotações proprietárias
O nginx-ingress usa extensivamente anotações como nginx.ingress.kubernetes.io/*. No Gateway API, funcionalidades equivalentes são expressas via recursos padronizados (HTTPRoute filters, BackendTLSPolicy, HTTPRouteFilter) ou via extensões da implementação escolhida. Cada anotação utilizada hoje precisa ser mapeada para o equivalente na nova API.
3. Gestão de TLS
No Gateway API, certificados TLS são referenciados diretamente no Gateway:
spec:
listeners:
- name: https
protocol: HTTPS
port: 443
tls:
mode: Terminate
certificateRefs:
- name: meu-certificado-tls
namespace: infra
Integrações com cert-manager são suportadas nativamente pelo Gateway API via anotações no Gateway ou via CertificateSigningRequest.
4. RBAC e modelo de namespaces
O Gateway API introduz um modelo de permissões mais granular. Times de desenvolvimento criam HTTPRoute nos seus próprios namespaces. O Gateway define quais namespaces podem se anexar a ele via allowedRoutes:
spec:
listeners:
- allowedRoutes:
namespaces:
from: Selector
selector:
matchLabels:
kubernetes.io/metadata.name: minha-app
Isso exige revisão das políticas de RBAC existentes.
5. Período de coexistência
O Kubernetes suporta Ingress e Gateway API simultaneamente. A migração pode ser feita de forma gradual:
- Instalar a implementação Gateway API escolhida em paralelo ao nginx-ingress
- Migrar aplicações não críticas primeiro
- Validar comportamento em produção
- Migrar aplicações críticas
- Remover o nginx-ingress
Ferramentas como o ingress2gateway podem auxiliar na conversão automatizada de recursos Ingress para HTTPRoute.
Resumo Comparativo Final
| Critério | Istio | Agentgateway |
|---|---|---|
| Maturidade | Alta (CNCF Graduated) | Média (projeto novo) |
| Conformidade com a spec | ✅ Total | ✅ Total |
| Route Changes sem downtime | ✅ | ✅ |
| Propagação de rotas | 120–300ms | 10–30ms |
| Consumo de recursos (data plane) | Moderado | Muito baixo |
| Ecossistema (mTLS, telemetria, etc.) | Rico | Em desenvolvimento |
| Suporte a XListenerSet | ✅ | ✅ |
| Backend failover padrão | Sem tratamento | Favorece backends saudáveis |
| Ideal para | Multi-tenant, service mesh | Eficiência de recursos, plataformas novas |
Conclusão
A descontinuação do nginx-ingress não é uma ameaça — é uma oportunidade. O Gateway API representa uma evolução real no modelo de roteamento do Kubernetes: mais seguro, mais expressivo e melhor adequado para ambientes multi-tenant modernos.
Os benchmarks independentes analisados neste artigo mostram que a pergunta não é se migrar, mas para qual implementação:
-
Se você já usa Istio como service mesh, ou precisa de um ecossistema rico com mTLS, observabilidade e gerenciamento de tráfego avançado: Istio é a escolha natural e comprovada.
-
Se você está construindo uma plataforma nova e eficiência de recursos é uma prioridade — seja por custo, densidade de workloads ou velocidade de propagação de configuração: Agentgateway merece atenção séria.
O que não recomendamos é manter o nginx-ingress em novos projetos ou adiar o planejamento da migração. O projeto está em modo de manutenção, e a janela de suporte tem prazo.
Estudo original: github.com/howardjohn/gateway-api-bench — Howard John
Anúncio oficial: kubernetes.io/blog/2025/11/11/ingress-nginx-retirement
