Gateway API no EKS: O que muda com o fim do NGINX Ingress Controller
Source: Dev.to
O fim do NGINX Ingress Controller
O Ingress NGINX está sendo oficialmente descontinuado. A manutenção termina em março de 2026 — após essa data, não haverá mais releases, bug‑fixes ou correções de segurança.
A API Ingress do Kubernetes não está sendo descontinuada, apenas o NGINX Ingress Controller (a implementação). Você pode continuar usando a API Ingress com outros controllers como AWS Load Balancer Controller, Traefik, etc.
Por que está sendo descontinuado?
- Dívida técnica insustentável (snippets NGINX que viraram vulnerabilidades)
- Sobrecarga de reload nas configurações do NGINX a cada mudança
- Uso excessivo de annotations específicas do controller
- Falta crítica de mantenedores
O projeto InGate tentou resolver esses pontos, mas sem engajamento suficiente, também será descontinuado em 2026.
Fonte: Kubernetes Blog – Ingress NGINX Retirement
Gateway API: A evolução do Ingress
O Gateway API traz conceitos mais claros e separação de responsabilidades.
Componentes principais
- GatewayClass – Define qual controller gerencia os gateways (similar ao IngressClass)
- Gateway – Define o load balancer (ALB/NLB) e listeners
- HTTPRoute – Define as rotas HTTP (similar ao Ingress, mas mais poderoso)
Vantagens sobre o Ingress
- Separação clara de responsabilidades (infra vs. aplicação)
- Suporte nativo a múltiplos namespaces
- Roteamento avançado (header matching, weighted routing, retries)
- Padrão da indústria, não específico do Kubernetes
Importante: “Gateway API” aqui se refere ao Kubernetes Gateway API (substituição do Ingress), não ao Amazon API Gateway nem a produtos como Kong ou Apigee.
Opções no EKS
Assim como o Ingress precisava de um controller (NGINX, Traefik, etc.), o Gateway API também requer um GatewayClass instalado. No EKS, não há suporte nativo — você precisa escolher uma implementação.
Se você usa ingress‑nginx‑controller
Das implementações com status GA listadas em gateway‑api.sigs.k8s.io/implementations, destacam‑se:
- Envoy Gateway – Maturidade Open Source, amplo uso no mercado, baseado no proxy padrão do ecossistema Cloud Native (mesmo do Istio) e gerido pela CNCF.
- Traefik Proxy – Foco na experiência do desenvolvedor; substitui o “emaranhado de annotations” do NGINX por Middlewares (CRDs reutilizáveis), tornando a gestão de regras mais limpa e visual.
Ambas têm arquitetura semelhante ao NGINX Ingress Controller:
- NLB como serviço gerenciado (L4)
- Proxy como pods no cluster (L7)
OBS: Ferramentas como
external-dnsecert-managercontinuam funcionando com o Gateway API; apenas algumas configurações precisarão ser ajustadas.
Se você usa AWS Load Balancer Controller com Ingress hoje
Continue usando Ingress. Não faça a troca agora. O Ingress tradicional com AWS Load Balancer Controller está maduro, estável e pronto para produção.
O AWS Load Balancer Controller já suporta Gateway API, mas ainda está em beta. Conforme a documentação oficial:
“The team is actively trying to close conformance and support gaps. Using the LBC and Gateway API together is not suggested for production workloads (yet!).”
Funciona? Sim. Foi feita uma POC funcional em laboratório e funciona bem para testes.
Off‑topic: No GKE (Google Cloud), o Gateway API já está mais maduro e integrado nativamente, facilitando a adoção.
Conclusão
O Gateway API é a evolução natural do Ingress, mas no EKS ainda estamos em transição. Vale a pena se preparar para essa mudança, testando, conhecendo e planejando a migração das configurações atuais para a nova família de APIs do Kubernetes.