<h2>O Que é Gateway API e Por Que Ela é o Futuro</h2>

<p>A Gateway API é uma evolução significativa da forma como gerenciamos tráfego de entrada em clusters Kubernetes. Enquanto o Ingress tradicional oferece uma solução básica para roteamento HTTP(S), a Gateway API foi projetada pelo SIG (Special Interest Group) Network do Kubernetes para fornecer uma abstração mais poderosa, flexível e expressiva. Em essência, ela separa as responsabilidades entre operadores de infraestrutura (que gerenciam gateways) e desenvolvedores de aplicações (que definem rotas), criando uma hierarquia clara de responsabilidades.</p>

<p>A Gateway API não substitui imediatamente o Ingress, mas oferece um caminho evolutivo com recursos que o Ingress simplesmente não consegue expressar: suporte nativo a protocolos além de HTTP(S), roteamento baseado em peso entre serviços, reescrita de headers mais sofisticada, e capacidades de TLS mais avançadas. Você pode pensar na Gateway API como um &quot;Ingress 2.0&quot; que aprendeu com os erros e limitações da primeira geração.</p>

<h3>Diferenças Fundamentais entre Ingress e Gateway API</h3>

<p>O Ingress é monolítico — um único recurso que concentra toda a lógica de roteamento. A Gateway API distribui essa responsabilidade em dois objetos principais: <code>Gateway</code> (a infraestrutura de rede, geralmente gerenciada por operadores) e <code>*Route</code> (as regras de roteamento para aplicações específicas, gerenciadas por desenvolvedores). Isso permite que múltiplas equipes trabalhem sem conflitos e que operadores mantenham a infraestrutura sem interferência das aplicações.</p>

<p>Outra diferença crítica é o suporte a protocolos. Enquanto Ingress focou em HTTP(S), a Gateway API possui suporte nativo para TCP, UDP e até mesmo WebSocket de forma mais elegante. Além disso, a Gateway API permite expressividade de roteamento muito maior, incluindo matching por hostname, path, header, query parameter, e método HTTP com regras de precedência bem definidas.</p>

<h2>Componentes Principais da Gateway API</h2>

<h3>Gateway e GatewayClass</h3>

<p>Um <code>GatewayClass</code> é como uma &quot;classe&quot; que descreve o tipo de gateway — similar a um <code>StorageClass</code> para volumes. Ela identifica qual implementação de gateway será usada (por exemplo, nginx, istio, aws-alb). Um operador de infraestrutura cria a <code>GatewayClass</code> uma única vez, configurando-a com parâmetros específicos da implementação.</p>

<p>O <code>Gateway</code> é a instância concreta de um <code>GatewayClass</code>. É o recurso que realmente escuta em portas e IPs, gerenciando certificados TLS e listeners. Diferentemente do Ingress que é tipicamente um por cluster, você pode ter múltiplos Gateways em diferentes namespaces ou endereços IP.</p>

<pre><code class="language-yaml"># gateway-class.yaml - Criado pelo operador de infraestrutura

apiVersion: gateway.networking.k8s.io/v1

kind: GatewayClass

metadata:

name: nginx-gatewayclass

spec:

controllerName: k8s.io/nginx-gateway-controller

description: &quot;Gateway class para roteamento HTTP(S) com NGINX&quot;

parametersRef:

group: nginx.org

kind: NginxGatewayClassConfig

name: nginx-config

---

gateway.yaml - Ainda operador, mas pode estar em namespace específico

apiVersion: gateway.networking.k8s.io/v1

kind: Gateway

metadata:

name: main-gateway

namespace: infrastructure

spec:

gatewayClassName: nginx-gatewayclass

listeners:

• name: http

port: 80

protocol: HTTP

• name: https

port: 443

protocol: HTTPS

tls:

mode: Terminate

certificateRefs:

• name: tls-cert

namespace: infrastructure</code></pre>

<h3>HTTPRoute, TCPRoute e GRPCRoute</h3>

<p>As rotas são onde desenvolvedores de aplicações definem como o tráfego deve ser direcionado. <code>HTTPRoute</code> é a mais comum, permitindo roteamento por hostname, path, header, query parameters e método HTTP. <code>TCPRoute</code> fornece roteamento em nível de camada 4, sem interpretação de HTTP. <code>GRPCRoute</code> é otimizada para gRPC, respeitando a semântica HTTP/2 que gRPC utiliza.</p>

<p>Uma rota é sempre vinculada a um Gateway através de <code>parentRefs</code>. Desenvolvedores definem suas rotas e o controlador do gateway as reconcilia com a configuração do gateway.</p>

<pre><code class="language-yaml"># http-route.yaml - Criado por desenvolvedores

apiVersion: gateway.networking.k8s.io/v1

kind: HTTPRoute

metadata:

name: api-route

namespace: default

spec:

parentRefs:

• name: main-gateway

namespace: infrastructure

port: 443

hostnames:

• &quot;api.example.com&quot;

rules:

• matches:
• path:

type: PathPrefix

value: /v1

backendRefs:

• name: api-v1-service

port: 8080

weight: 80

• name: api-v2-service

port: 8080

weight: 20

filters:

• type: RequestHeaderModifier

requestHeaderModifier:

add:

X-Forwarded-By: &quot;gateway&quot;

timeouts:

request: 30s

• matches:
• path:

type: PathPrefix

value: /health

backendRefs:

• name: health-check-service

port: 9000</code></pre>

<h2>Implementando Gateway API na Prática</h2>

<h3>Instalação e Configuração Inicial</h3>

<p>Para usar Gateway API, você precisa de um controlador que implemente a especificação. Existem várias opções maduras: nginx-gateway-controller (mantido pela NGINX), Istio com seu Gateway, AWS ALB Controller, e outras. Vamos usar o NGINX como exemplo por ser amplamente acessível.</p>

<pre><code class="language-bash"># Instale o CRD da Gateway API (requerido em clusters &lt; 1.29)

kubectl apply -k github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.0.0

Instale o controlador NGINX Gateway

helm repo add nginx-stable https://helm.nginx.com/stable

helm repo update

helm install nginx-gateway nginx-stable/nginx-gateway \

--namespace nginx-gateway \

--create-namespace \

--set service.type=LoadBalancer</code></pre>

<p>Depois de instalado, o controlador observa recursos <code>Gateway</code> e <code>HTTPRoute</code> no cluster e configura o NGINX automaticamente. Esse é um grande diferencial — a declaratividade completa sem scripts de inicialização manuais.</p>

<h3>Exemplo Prático Completo: Aplicação Multi-Tenant</h3>

<p>Vamos construir um cenário realista onde você tem três ambientes diferentes (staging, canary, production) usando um único Gateway com múltiplas rotas.</p>

<pre><code class="language-yaml">---

Namespace para infraestrutura

apiVersion: v1

kind: Namespace

metadata:

name: infrastructure

---

GatewayClass

apiVersion: gateway.networking.k8s.io/v1

kind: GatewayClass

metadata:

name: nginx

spec:

controllerName: k8s.io/nginx-gateway-controller

---

Gateway principal

apiVersion: gateway.networking.k8s.io/v1

kind: Gateway

metadata:

name: production-gateway

namespace: infrastructure

spec:

gatewayClassName: nginx

listeners:

• name: http

port: 80

protocol: HTTP

• name: https

port: 443

protocol: HTTPS

tls:

mode: Terminate

certificateRefs:

• name: tls-wildcard

---

Secret com certificado TLS

apiVersion: v1

kind: Secret

metadata:

name: tls-wildcard

namespace: infrastructure

type: kubernetes.io/tls

data:

tls.crt: LS0tLS1CRUdJTi... # Base64 do seu certificado

tls.key: LS0tLS1CRUdJTi... # Base64 da sua chave privada

---

HTTPRoute para staging

apiVersion: gateway.networking.k8s.io/v1

kind: HTTPRoute

metadata:

name: staging-route

namespace: staging

spec:

parentRefs:

• name: production-gateway

namespace: infrastructure

hostnames:

• &quot;staging.example.com&quot;

rules:

• matches:
• path:

type: Exact

value: /

backendRefs:

• name: staging-app-service

port: 3000

---

HTTPRoute para canary (com canary deployment)

apiVersion: gateway.networking.k8s.io/v1

kind: HTTPRoute

metadata:

name: canary-route

namespace: production

spec:

parentRefs:

• name: production-gateway

namespace: infrastructure

hostnames:

• &quot;api.example.com&quot;

rules:

• matches:
• path:

type: PathPrefix

value: /api

backendRefs:

• name: app-service-stable

port: 8080

weight: 90

• name: app-service-canary

port: 8080

weight: 10

filters:

• type: RequestHeaderModifier

requestHeaderModifier:

add:

X-Served-By: &quot;gateway-api&quot;

---

Serviços exemplo

apiVersion: v1

kind: Service

metadata:

name: staging-app-service

namespace: staging

spec:

selector:

app: staging-app

ports:

• port: 3000

targetPort: 3000

---

apiVersion: v1

kind: Service

metadata:

name: app-service-stable

namespace: production

spec:

selector:

app: myapp

version: stable

ports:

• port: 8080

targetPort: 8080

---

apiVersion: v1

kind: Service

metadata:

name: app-service-canary

namespace: production

spec:

selector:

app: myapp

version: canary

ports:

• port: 8080

targetPort: 8080</code></pre>

<h3>Monitoramento e Debugging</h3>

<p>Para verificar se suas rotas foram aplicadas corretamente, use:</p>

<pre><code class="language-bash"># Listar todos os gateways

kubectl get gateways -A

Detalhes de um gateway específico

kubectl describe gateway main-gateway -n infrastructure

Listar rotas HTTP

kubectl get httproutes -A

Verificar o status de uma rota

kubectl get httproute api-route -n default -o yaml

Logs do controlador

kubectl logs -n nginx-gateway -l app.kubernetes.io/name=nginx-gateway --tail=100

Testar conectividade (após expor o gateway)

curl -H &quot;Host: api.example.com&quot; http://localhost/api/test</code></pre>

<h2>Vantagens Reais e Casos de Uso</h2>

<h3>Quando Usar Gateway API ao Invés de Ingress</h3>

<p>Gateway API brilha quando você precisa de separação clara de responsabilidades. Em organizações com múltiplas equipes, o fato de operadores gerenciarem Gateways e desenvolvedores gerenciarem Routes elimina conflitos e facilita auditoria. Se seu cluster executa diferentes tipos de tráfego (HTTP, gRPC, TCP), a Gateway API oferece abstração unificada enquanto Ingress força workarounds.</p>

<p>Canary deployments, blue-green deployments e teste A/B ficam muito mais simples com o suporte nativo a roteamento com peso. Você não precisa mais de ferramentas externas como Istio para isso — está no padrão Kubernetes. Para empresas com requisitos estritos de segurança e conformidade, a possibilidade de definir RBAC fino por recurso é invaluável.</p>

<h3>Limitações Atuais</h3>

<p>Apesar do potencial, a Gateway API ainda é um padrão em evolução. Nem todas as implementações suportam todos os recursos, e algumas features experimentais podem mudar entre versões. Adoption no ecossistema ainda está crescendo — nem todos os provedores (como AWS ALB Controller) possuem suporte completo. Em clusters muito antigos (&lt; 1.19), você terá dificuldade em encontrar suporte.</p>

<p>A documentação de algumas implementações ainda é escassa comparada ao Ingress. Para migrações em larga escala, você terá que planejar cuidadosamente a coexistência entre Ingress e Gateway API durante a transição, pois ainda não há ferramenta padrão de migração automática.</p>

<h2>Conclusão</h2>

<p>A Gateway API representa uma evolução genuína na forma como gerenciamos ingress em Kubernetes. Aprendemos que ela não é apenas um &quot;Ingress melhorado&quot;, mas sim uma arquitetura fundamentalmente diferente que separa infraestrutura (Gateways) de aplicação (Routes), permitindo múltiplas equipes trabalharem de forma independente. Sua expressividade — suporte a múltiplos protocolos, roteamento com peso, filtros sofisticados — torna problemas complexos como canary deployments triviais de resolver. Por fim, embora ainda em adoção, a Gateway API é o futuro inequívoco do roteamento em Kubernetes, e investir tempo em compreendê-la agora coloca você à frente da curva de evolução da plataforma.</p>

<h2>Referências</h2>

<ul>

<li><a href="https://gateway-api.sigs.k8s.io/" target="_blank" rel="noopener noreferrer">Documentação Oficial da Gateway API - Kubernetes SIG Network</a></li>

<li><a href="https://docs.nginx.com/nginx-gateway-controller/" target="_blank" rel="noopener noreferrer">NGINX Gateway Controller - Implementação Oficial</a></li>

<li><a href="https://kubernetes.io/blog/2023/07/05/gateway-api-v0-8/" target="_blank" rel="noopener noreferrer">Gateway API Concepts - Kubernetes Blog</a></li>

<li><a href="https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/" target="_blank" rel="noopener noreferrer">Istio Gateway API Support</a></li>

<li><a href="https://medium.com/kubernetes-native/gateway-api-a-new-era-for-kubernetes-load-balancing-72a2d31e4f0c" target="_blank" rel="noopener noreferrer">Comparing Ingress and Gateway API - Medium/Community Articles</a></li>

</ul>

<p>&lt;!-- FIM --&gt;</p>