Kubernetes — Ingress vs Gateway API

março 1, 2026 Danilo Marques

Que vai mudar, a gente já sabe. Mas o que muda de fato?

Vou explicar e trazer algumas analogias — gosto pessoal por analogias rs’ — pra você que usa Kubernetes no dia a dia, mas não quer decorar RFC nem spec (se você já não entendeu o que é RFC ou spec, esse post é pra você mesmo rs’ 😄).

Acho que praticamente todo mundo já teve que se apresentar ou interagir com uma portaria e/ou com um porteiro para entrar em algum lugar (consultório, balada, condomínio, trabalho etc.). Então vamos partir desse ponto…

👉 Ingress é um porteiro simples
👉 Gateway API é um prédio com portaria profissional, síndico, regras, turnos e controle de acesso

O que cada um é ?

Ingress — “o porteiro do prédio pequeno”

Imagine um prédio pequeno:

Um porteiro
Uma prancheta
Ele olha:
“Qual apartamento?”
“Qual horário?”
“Pode subir”

Prazer, Ingress:

Um objeto único
Pouca separação de responsabilidades
Funciona, mas pode virar bagunça em projetos maiores — acredite…

No K8s:

Ingress define host, path e backend
Um Ingress Controller (NGINX, ALB…) interpreta tudo

Gateway API — “prédio corporativo”

Agora pense num prédio corporativo grande:

Construtora define o prédio
Síndico define regras
Portaria aplica regras
Cada empresa se encarrega de decidir quem entra na sua sala

Prazer, Gateway API:

Vários recursos, cada um com um papel
Pensado para times e projetos maiores
Separação clara entre infra e apps

No K8s:

GatewayClass → quem controla (NGINX, Istio, Envoy…)
Gateway → portas, TLS, listeners
HTTPRoute → regras de tráfego da aplicação

Analogia direta (Ingress vs Gateway API)

Criei uma tabelinha no excel para ficar mais visual…

Observação: Eu poderia pedir para alguma IA criar? Poderia. Mas o “artesanal” da coisa dá mais graça — as vezes…

Arquitetura — antes (Ingress)

Tudo concentrado num lugar só.

Internet
   |
[ LoadBalancer ]
   |
[ Ingress Controller (NGINX) ]
   |
[ Ingress ]
   ├── host app1.com → Service A
   └── host app2.com → Service B

❌ Problemas que enxergo

Infra + dev mexendo no mesmo YAML
Annotations viram 🤡:

nginx.ingress.kubernetes.io/rewrite-target
nginx.ingress.kubernetes.io/proxy-body-size
nginx.ingress.kubernetes.io/auth-url

Cada controller inventa sua regra

Trabalhoso:
Split de tráfego
Multi-namespace

Arquitetura — depois (Gateway API)

Tudo separado por função.

Internet
   |
[ LoadBalancer ]
   |
[ Gateway ]
   |
 ┌───────────────┬───────────────┐
 |               |               |
[HTTPRoute A] [HTTPRoute B] [HTTPRoute C]
   |               |
[Service A]     [Service B]

🔑 Quem cuida do quê

+uma tabela artesanal pra vcs…

Exemplo prático (bem realista)

Cenário

app1 quer:

/ → v1

/beta → v2 (20%)

app2 é outro time, outro namespace…

❌ Ingress (tudo junto e misturado, confuso)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: apps
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
spec:
  rules:
  - host: app1.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: app1-v1

👉 Infra + dev “brigando” no mesmo arquivo.

✅ Gateway API (limpo e organizado)

Infra only

kind: Gateway
spec:
  listeners:
  - port: 443
    protocol: HTTPS

Devs do app1

kind: HTTPRoute
spec:
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: app1-v1
      weight: 80
    - name: app1-v2
      weight: 20

👉 Infra não toca na app
👉 App não quebra o cluster

Quando você deve migrar (cada caso, um caso…)

Use Ingress se:

Cluster pequeno
1 ou 2 times
Regras simples
Não quer adicionar uma camada de complexidade agora…

Use Gateway API se:

AKS/EKS/GKE corporativo
Muitos times (so many apps)
Canary, blue/green, split
Platform Engineering
Quer futuro sem refatorar tudo correndo…

Conclusão (reta e direta)

Ingress funciona
Gateway API organiza
NGINX continua existindo
A mudança é de modelo mental, não só de YAML

E ai, qual você vai usar no seu projeto?

myrootspace