Se você usa EKS, provavelmente expõe aplicações com NGINX Ingress Controller e/ou AWS Load Balancer Controller usando Ingress tradicional. Mas há uma mudança importante chegando: o Kubernetes SIG-Network anunciou oficialmente a aposentadoria do Ingress NGINX.
Nesse artigo, meu objetivo é explicar alguns conceitos novos e deixar mais claros quais passos podem ser seguidos, para cuidar bem de seus ambientes de produção.
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, bugfixes 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 foi uma tentativa de resolver esses pontos negativos, mas sem o engajamento suficiente, não atingiu um estado maduro e 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 (produto AWS) nem ao conceito de API Gateway (Kong, Apigee, etc.). São coisas diferentes.
Opções no EKS
Assim como o Ingress precisava de um controller (NGINX, Traefik, etc.), o Gateway API também precisa de um GatewayClass instalado. No EKS, não há suporte nativo — você precisa escolher uma implementação.
Se você usa ingress-nginx-controller
Das opções de implementações com status GA (General Availability) em gateway-api.sigs.k8s.io/implementations, se destacam as opções Envoy Gateway e Traefik Proxy. Explico:
Maturidade Open Source e amplo uso no mercado.
Aposta segura para longo prazo (Envoy Gateway): Baseado no proxy de facto do ecossistema Cloud Native (o mesmo do Istio) e gerido pela CNCF, garantindo inovação contínua sem vendor lock-in.
Simplicidade Operacional (Traefik): Foca na Experiência do Desenvolvedor. Ele substitui o complexo "emaranhado de annotations" do NGINX por Middlewares (objetos CRDs reutilizáveis), tornando a gestão de regras muito mais limpa e visual.
Ambas as opções têm similaridades com a arquitetura do NGINX Ingress Controller:
- NLB como serviço gerenciado (L4)
- Proxy como pods no cluster (L7)
OBS: É muito comum usar em conjunto com o Ingress as ferramentas external-dns e cert-manager. Felizmente, elas vão continuar funcionando perfeitamente com o Gateway API, será necessário mudar apenas algumas configurações de uso.
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. Segundo a documentação oficial, o próprio time da AWS afirma:
"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. Fiz 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 parte mais difícil, que é levar as configurações atuais para uma nova família de APIs do Kubernetes.
Referências:
Top comments (0)