Quando o projeto Ingress-NGINX anunciou sua descontinuação, no fim de 2023, a equipe do Stack Overflow precisou correr contra o relógio para encontrar um novo “porteiro” capaz de receber bilhões de requisições mensais. A troca virou estudo de caso para qualquer pessoa que administra clusters Kubernetes – seja em nuvem pública, em data center corporativo ou até em home labs baseados em mini-PCs vendidos na Amazon.
O fim do Ingress-NGINX e a chegada do Gateway API
O Ingress tradicional existe desde as primeiras versões do Kubernetes, mas seus limites ficaram evidentes com o crescimento de aplicações modernas (microserviços, zero trust, etc.). A CNCF propôs então o Gateway API, que separa claramente quem lida com rede, segurança e rota de aplicações, dando poder granular a DevOps e equipes de SRE.
No Stack Overflow, o gateway antigo “dava conta do recado”, mas não justificava investir esforços – até ser oficialmente aposentado. Com o cronômetro correndo, a equipe estabeleceu um objetivo duplo: migrar o mais rápido possível e, se viável, já abraçar o Gateway API em vez de buscar outro controlador Ingress.
Critérios de escolha: conformidade, nuvem e recursos avançados
Para não testar “meio mundo” de projetos open source, a seleção começou pelos controladores 100% conformes com o Gateway API 1.4. Como o Stack Overflow opera em Google Cloud Platform e Microsoft Azure, qualquer solução atrelada a um provedor único (como um ELB exclusivo da AWS) saiu da lista.
Restaram três finalistas:
- NGINX Gateway Fabric
- Istio
- Traefik
Como plano B, duas opções continuariam no mundo Ingress: F5 NGINX Ingress e Traefik Ingress. Elas foram abandonadas rapidamente porque exigiam anotações proprietárias ou não cobriam todas as annotations usadas hoje.
O laboratório: hardware, tráfego realista e testes de estresse
Para reproduzir a rotina de uma das maiores comunidades de desenvolvedores do planeta, o time montou um ambiente com:
- 4 nós GCP e2-standard-4 (4 vCPUs Intel Xeon e 16 GB de RAM) – configuração similar aos servidores Intel Xeon de entrada vendidos na Amazon, ótima para clusters compactos.
- Cliente de testes (load generator) rodando no Azure em uma VM Standard DC8as_cc_v5, equipada com processadores AMD EPYC com instruções de segurança SGX.
- Back-ends: HTTPBin para inspeção de cabeçalhos e um servidor Go ultrarrápido para simular respostas com até 350 ms de latência.
A suíte de testes incluiu:
Imagem: Internet
- 10 000 requisições por segundo (RPS) sustentadas.
- Simulações de 0 ms, 150 ms e 350 ms de latência de aplicação.
- Escalonamento progressivo de até 1 000 HTTPRoutes (rotas) por gateway.
- Criação em massa de 5 000 rotas para medir convergência e tempo de propagação.
Resultados: quando a teoria encontra a prática
Nos cenários de tráfego pesado, os três candidatos mantiveram a média de resposta abaixo de 210 ms, valores aceitáveis para o tráfego diário da rede Stack Exchange. Entretanto, diferenças importantes apareceram:
- Tempo de convergência: NGINX e Istio aplicaram 5 000 rotas em ~42 s; Traefik precisou de >5 min.
- Atualização em produção: Com 1 000 rotas e tráfego de 10 k RPS, atualizar uma única HTTPRoute disparou picos de latência apenas no NGINX Gateway Fabric.
- Sintaxe e filtros: O Istio oferece o conjunto de filtros mais completo, embora sua escrita seja mais verbosa que a de NGINX ou Traefik – preço que se paga por flexibilidade.
- Compatibilidade com autenticação externa: O Stack Overflow usava o módulo ngx_http_auth_request; nos testes, foi necessário refatorar alguns fluxos para funcionar com a autorização externa do Istio.
Por que o Istio venceu?
No fim, a escolha recaiu sobre o Istio por quatro motivos decisivos:
- Estabilidade sob carga: manteve latências estáveis mesmo com modificações de rota em tempo real.
- Recursos futuros: oferece mTLS, balanceamento avançado e políticas de tráfego que podem ser ativadas quando a empresa precisar, sem trocar de ferramenta.
- Ecossistema maduro: ampla documentação, comunidade ativa e integrações com observabilidade (Prometheus, Jaeger), facilitando o dia a dia de DevOps.
- Risco reduzido: performance consistente nos limites atuais de 1 000 rotas por gateway e espaço para crescer.
O que isso significa para o seu cluster?
Se você está planejando migrar de Ingress para Gateway API, os testes do Stack Overflow indicam:
- Planeje limites realistas: 1 000 rotas já exigem tuning fino. Mais do que isso pode colapsar o plano de controle.
- Capriche no hardware: 4 vCPUs e 16 GB por nó foram suficientes, mas processadores mais novos – como a linha Intel Xeon Scalable “Sapphire Rapids” ou AMD EPYC “Genoa” (encontrados em servidores bare-metal ou em placas-mãe workstation na Amazon) – garantem folga térmica e energética para TLS e inspeção profunda de pacotes.
- Teste autenticação e filtros complexos antes da migração, pois a equivalência 1:1 entre módulos NGINX e filtros Gateway não é garantida.
O Stack Overflow inicia a migração definitiva para Istio nas próximas semanas. Caso surjam surpresas, a equipe prometeu publicar um post-mortem detalhado – e nós ficaremos de olho para trazer os aprendizados que podem economizar noites em claro no seu cluster Kubernetes.
Com informações de Stack Overflow Blog
