Gateway API: O Futuro do Roteamento no Kubernetes

O roteamento de tráfego externo para dentro de um cluster Kubernetes sempre foi um dos tópicos mais complexos na jornada de adoção da plataforma. Durante anos, o recurso Ingress foi o padrão de facto para essa tarefa. No entanto, à medida que os clusters cresceram em complexidade, abrigando múltiplas equipes e requisitos avançados de rede, as limitações do Ingress tornaram-se evidentes.

É nesse contexto que surge o Gateway API, um projeto oficial da SIG-Network do Kubernetes, desenhado para ser o sucessor espiritual do Ingress. Este artigo explora profundamente a arquitetura, o funcionamento e as vantagens do Gateway API em ambientes cloud-native.

1. Introdução

O Contexto do Problema

O recurso Ingress foi introduzido nas primeiras versões do Kubernetes com um objetivo simples: expor serviços HTTP/HTTPS. Sendo um recurso da API muito básico, ele define apenas regras de roteamento baseadas em host e path.

Limitações do Ingress Tradicional

Com a evolução das aplicações modernas, desenvolvedores e operadores de infraestrutura precisavam de mais:

• Falta de Portabilidade: Para suportar funcionalidades avançadas (como header matching, canary deployments, rate limiting), cada controlador de Ingress (NGINX, Traefik, HAProxy) começou a usar Annotations customizadas. Isso quebrou a portabilidade; um YAML de Ingress do NGINX não funciona no Traefik.
• Acoplamento de Responsabilidades: O Ingress junta a configuração de infraestrutura (qual IP escutar, quais certificados TLS usar) com a configuração de roteamento da aplicação (para qual serviço enviar a requisição /api). Isso gera atrito entre o time de Infraestrutura e os Desenvolvedores.
• Suporte Limitado a Protocolos: O Ingress foi desenhado exclusivamente para HTTP e HTTPS. Expor tráfego TCP, UDP ou gRPC nativo sempre exigiu “gambiarras” ou CRDs proprietários.

O Gateway API nasceu para resolver exatamente esses problemas, oferecendo uma API extensível, orientada a papéis (role-oriented) e rica em funcionalidades nativas.

2. Arquitetura do Gateway API

O design do Gateway API é baseado na separação de responsabilidades. Em vez de um único objeto monolítico (como o Ingress), ele divide o roteamento em uma hierarquia de recursos.

Explicação Detalhada dos Principais Recursos

1. GatewayClass

Define um “modelo” ou “tipo” de infraestrutura de gateway disponível no cluster. Geralmente é criado pelo administrador do cluster ou instalado automaticamente pelo provedor de nuvem/controlador.

• Analogia: “Temos um balanceador de carga do tipo Envoy interno e outro do tipo AWS ALB externo.”

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy-internal
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

2. Gateway

Representa uma instância física ou lógica de um balanceador de carga. Ele define onde e como o tráfego entra no cluster (quais portas escutar, quais protocolos, quais certificados TLS).

• Responsabilidade: Time de Infraestrutura/Plataforma.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: gateway-system
spec:
  gatewayClassName: envoy-internal
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: wildcard-cert-secret
    allowedRoutes:
      namespaces:
        from: All

3. Rotas (HTTPRoute, TCPRoute, TLSRoute, etc.)

Definem as regras de roteamento específicas da aplicação. As rotas se “anexam” (attach) a um Gateway.

• Responsabilidade: Desenvolvedores da aplicação.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: app-team-a
spec:
  parentRefs:
  - name: main-gateway
    namespace: gateway-system
  hostnames:
  - "api.empresa.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1
    backendRefs:
    - name: api-service-v1
      port: 8080

Relação entre os Componentes

A magia do Gateway API está na relação de parentRefs (referências de pai). Um desenvolvedor no namespace app-team-a cria um HTTPRoute que aponta para o Gateway no namespace gateway-system. O Gateway, por sua vez, tem regras de allowedRoutes que ditam quais namespaces podem se anexar a ele. Isso cria um modelo de governança perfeito: a infraestrutura controla a porta de entrada, e os desenvolvedores controlam o roteamento de suas próprias aplicações de forma autônoma.

3. Dependências e Integração

O Gateway API em si é apenas uma coleção de definições (CRDs - Custom Resource Definitions). Para que ele faça algo real, você precisa de implementações (Controllers).

Componentes Adicionais Necessários

1. Gateway API CRDs: Devem ser instalados no cluster antes de qualquer coisa.
2. Gateway Controller: O software que lê os recursos do Gateway API e configura o proxy de dados subjacente.
3. Data Plane (Proxy): O componente que efetivamente move os pacotes (Envoy, NGINX, etc.).

Papel dos Controllers

A adoção da indústria tem sido massiva. Quase todos os grandes players reescreveram seus controladores para suportar o Gateway API nativamente:

• Envoy Gateway: Uma implementação oficial da comunidade Envoy projetada especificamente para o Gateway API. É altamente recomendada para ambientes on-premise.
• Cilium: Integra o Gateway API diretamente no kernel via eBPF, oferecendo performance extrema sem a necessidade de proxies sidecar para muitas funções.
• Istio: O Istio adotou o Gateway API como a forma padrão de configurar roteamento de entrada, substituindo o antigo recurso Gateway proprietário do Istio.
• Kong, NGINX, HAProxy: Todos oferecem controladores robustos que traduzem os recursos do Gateway API para suas respectivas configurações de proxy.

O verdadeiro poder do Gateway API é que você pode trocar o Envoy Gateway pelo Cilium amanhã, e seus arquivos YAML (HTTPRoute, Gateway) permanecerão exatamente os mesmos!

4. Integração com Load Balancers

O Gateway API dita como o tráfego é roteado dentro do cluster, mas como esse tráfego chega até o cluster em primeiro lugar? É aqui que a integração com os Load Balancers entra em jogo. Quando você cria um recurso Gateway, o controlador correspondente geralmente provisiona um serviço do tipo LoadBalancer no Kubernetes.

Load Balancers de Cloud Providers (AWS, GCP, Azure)

Em ambientes de nuvem pública, a criação de um Gateway desencadeia a criação de um balanceador de carga nativo da nuvem.

• GCP (GKE): O GKE possui um controlador nativo do Gateway API. Ao criar um GatewayClass específico (ex: gke-l7-gxlb), o GKE provisiona um Google Cloud Global Load Balancer. O roteamento definido no HTTPRoute é traduzido diretamente para as regras de roteamento do balanceador de carga do Google, sem a necessidade de um proxy rodando dentro do cluster.
• AWS (EKS): O AWS Load Balancer Controller suporta o Gateway API. Ele provisiona um Application Load Balancer (ALB) ou Network Load Balancer (NLB) e mapeia os HTTPRoutes para as regras do ALB.
• Vantagem na Nuvem: A principal vantagem é que o tráfego não precisa passar por um proxy extra dentro do cluster; o próprio balanceador de carga da nuvem faz o roteamento L7 diretamente para os Pods.

Soluções On-Premise como MetalLB

Em ambientes bare-metal ou on-premise, não existe um provedor de nuvem para fornecer um IP externo magicamente. É aqui que entra o MetalLB.

• O MetalLB atua como o provedor de LoadBalancer para o cluster.
• Quando você usa o Envoy Gateway (ou outro controlador) e cria um Gateway, o Envoy Gateway cria um Deployment do Envoy Proxy e um Service do tipo LoadBalancer.
• O MetalLB detecta esse Service, aloca um IP de seu pool configurado e o anuncia para a rede física (usando ARP/NDP em L2 ou BGP).
• Fluxo de Tráfego: Cliente -> IP anunciado pelo MetalLB -> Envoy Proxy (onde as regras do Gateway API são aplicadas) -> Pod da Aplicação.

Em ambientes on-premise modernos, a combinação de MetalLB (para L4/IPs) + Envoy Gateway API (para L7/Roteamento) é considerada o “estado da arte” para roteamento de entrada.

5. Comparação com Ingress

Por que abandonar o Ingress que usamos há anos? A resposta está na arquitetura.

Principais Limitações do Ingress

1. Foco Exclusivo em HTTP: O Ingress não entende TCP, UDP ou TLS passthrough de forma nativa.
2. Monolítico: O desenvolvedor que escreve o Ingress precisa saber detalhes da infraestrutura (qual Ingress Class usar, qual Secret de TLS).
3. Falta de Padronização Avançada: Funcionalidades como divisão de tráfego (traffic splitting para canary deployments), reescrita de cabeçalhos e redirecionamentos dependem inteiramente de Annotations não padronizadas.

Vantagens do Gateway API

1. Expressividade Nativa: Divisão de tráfego baseada em pesos, header matching, reescrita de caminhos e espelhamento de tráfego são recursos nativos da API, não requerem annotations.
2. Separação de Responsabilidades (Role-Oriented):
   • O Administrador de Infraestrutura gerencia o GatewayClass e o Gateway (Portas, IPs, TLS).
   • O Desenvolvedor gerencia o HTTPRoute (Caminhos, Headers, Pesos).
3. Extensibilidade via Policy Attachment: Se você precisar adicionar Rate Limiting ou Autenticação, o Gateway API usa um conceito chamado Policy Attachment, permitindo anexar políticas de segurança/roteamento a rotas específicas de forma padronizada.
4. Suporte Multi-Protocolo: Suporte nativo a TCPRoute, UDPRoute, GRPCRoute e TLSRoute.

Casos onde ainda faz sentido usar Ingress

Apesar de obsoleto do ponto de vista arquitetural, o Ingress não vai desaparecer da noite para o dia. Ainda faz sentido usá-lo se:

• Você tem um cluster pequeno, com uma única equipe, onde a separação de responsabilidades não é uma preocupação.
• Suas aplicações requerem apenas roteamento HTTP básico baseado em path.
• Você possui um grande legado de automações (Helm charts, pipelines) que dependem pesadamente do formato Ingress e a migração não traz ROI imediato.

6. Casos de Uso Reais

A flexibilidade do Gateway API brilha quando aplicado a cenários complexos do mundo real.

Ambientes Cloud (GCP/AWS)

Cenário: Uma empresa possui um cluster GKE e quer expor duas APIs diferentes (/v1/auth e /v1/payments) gerenciadas por equipes distintas. Solução com Gateway API:

1. A equipe de plataforma cria um Gateway associado ao gke-l7-gxlb. O GCP provisiona um Global Load Balancer com um IP público.
2. A equipe de Auth cria um HTTPRoute para o path /v1/auth no seu próprio namespace.
3. A equipe de Payments cria um HTTPRoute para o path /v1/payments no seu namespace. Resultado: Ambas as rotas se anexam ao mesmo Gateway (mesmo IP, mesmo Load Balancer), mas cada equipe gerencia seu próprio roteamento sem risco de quebrar a configuração da outra.

Ambientes On-Premise

Cenário: Um data center local executando Kubernetes bare-metal, precisando expor serviços TCP (como um banco de dados) e serviços HTTP na mesma infraestrutura. Solução com Gateway API:

1. O cluster utiliza MetalLB para fornecer IPs da rede local.
2. Instala-se o Envoy Gateway como controlador.
3. Cria-se um Gateway escutando na porta 80/443 para HTTP e na porta 5432 para TCP.
4. Usa-se um HTTPRoute para o tráfego web e um TCPRoute para o tráfego do banco de dados, ambos atrelados ao mesmo Gateway. Resultado: O Envoy Proxy recebe um IP do MetalLB e gerencia todo o tráfego L4 e L7 através de uma única API unificada.

Multi-cluster e Multi-tenant

Cenário: Uma plataforma SaaS multi-tenant onde clientes podem trazer seus próprios domínios personalizados. Solução com Gateway API: A separação de papéis permite que um sistema automatizado (ou os próprios clientes via um portal) crie objetos HTTPRoute especificando seus domínios customizados, anexando-os a um Gateway central compartilhado. O Gateway pode usar recursos como o ReferenceGrant para permitir que certificados TLS (Secrets) de um namespace sejam usados de forma segura por rotas em outro namespace.

7. Conclusão

O Kubernetes Gateway API não é apenas uma atualização incremental do Ingress; é uma reimaginação completa de como o tráfego de rede deve ser gerenciado em ambientes cloud-native.

Quando adotar o Gateway API?

• Novos Clusters: Se você está construindo um novo cluster hoje, comece com o Gateway API. Não há razão técnica para iniciar um projeto novo usando o Ingress tradicional.
• Múltiplas Equipes: Se o seu cluster é compartilhado por várias equipes de desenvolvimento, a governança baseada em papéis do Gateway API resolverá inúmeras dores de cabeça organizacionais.
• Roteamento Avançado: Se você precisa de canary releases, A/B testing, header manipulation ou suporte a gRPC/TCP nativo sem depender de anotações obscuras.

Maturidade Atual

O Gateway API já alcançou o status de General Availability (GA) (v1.0+) para seus recursos principais (GatewayClass, Gateway, HTTPRoute). A adoção pelos principais fornecedores (Google, AWS, Microsoft, Envoy, Istio, Cilium) é massiva, garantindo que esta é, sem dúvida, a API de rede padrão do Kubernetes para a próxima década.

A transição pode exigir uma curva de aprendizado inicial para entender a nova hierarquia de recursos, mas a clareza, segurança e extensibilidade que o Gateway API traz para a infraestrutura compensam amplamente o esforço.