Migrando do Ingress para o Gateway API no Kubernetes

Você que trabalha com Kubernetes já deve ter se deparado com a tarefa de configurar o Ingress, seja para roteamento de tráfego ou para integrar serviços. Essa tarefa, no entanto, está prestes a ganhar uma nova cara graças ao Gateway API. Quando li sobre essa novidade, me veio à mente todas aquelas vezes em que precisei lidar com anotações customizadas no Ingress para conseguir algo que deveria ser simples. Se você já apanhou com isso, sabe do que estou falando.

A notícia que me chamou atenção foi sobre o Gateway API, uma nova API que promete fornecer uma infraestrutura dinâmica e avançada para roteamento de tráfego. A premissa é simples: tornar a configuração de rede nos clusters Kubernetes mais extensível e orientada a papéis, facilitando a vida de quem gerencia essas redes.

O que aconteceu

O Gateway API surge como uma evolução do Ingress API. Ele não apenas substitui o Ingress, mas o leva a um novo nível de personalização e controle. A arquitetura do Gateway API é baseada em papéis organizacionais, como o Provedor de Infraestrutura, o Operador de Cluster e o Desenvolvedor de Aplicações, cada um com suas responsabilidades e foco.

Além disso, a API se destaca por oferecer suporte a casos de uso comuns de roteamento de tráfego, como correspondência de cabeçalhos e ponderação de tráfego, que antes exigiam anotações complexas no Ingress. Outra característica importante é sua natureza extensível, permitindo que recursos customizados sejam vinculados em várias camadas da API.

Por que isso importa

O Ingress sempre foi uma ferramenta crucial no ecossistema Kubernetes, mas sua simplicidade muitas vezes foi uma limitação. Muitos de nós acabamos recorrendo a anotações específicas para obter o comportamento desejado, o que poderia levar a uma configuração pouco clara e difícil de manter.

Com o Gateway API, temos um modelo de recurso mais robusto e flexível. O conceito de GatewayClass, por exemplo, permite definir um conjunto de gateways com configurações comuns, gerenciado por um controlador específico. Isso significa que podemos ter diferentes classes de gateways para diferentes necessidades ou ambientes, algo que o Ingress não oferecia de forma nativa.

Além disso, a separação clara entre o Gateway e as rotas HTTP ou gRPC (HTTPRoute e GRPCRoute) permite uma configuração mais granular e adaptável, facilitando adaptações conforme a evolução das necessidades do serviço.

Outro ponto a se destacar é a portabilidade. O Gateway API é definido como recursos customizados (CRDs), o que o torna suportado por uma variedade de implementações. Isso abre espaço para inovações e melhorias contínuas, sem depender de uma única solução de controle.

Na prática

Para quem está acostumado com o Ingress, a migração para o Gateway API pode parecer um grande desafio. No entanto, essa mudança oferece muito mais controle e flexibilidade. Vamos a um exemplo básico de como configurar um Gateway e uma HTTPRoute:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
  namespace: example-namespace
spec:
  gatewayClassName: example-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "www.example.com"
    allowedRoutes:
      namespaces:
        from: Same

Com o Gateway configurado, podemos definir uma rota HTTP:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /login
    backendRefs:
    - name: example-svc
      port: 8080

Neste exemplo, o tráfego HTTP com o cabeçalho Host para www.example.com e o caminho /login será roteado para o serviço example-svc na porta 8080.

O que eu acho disso

Se você, como eu, já passou horas configurando anotações no Ingress para obter um comportamento específico, o Gateway API pode ser o que você esperava. Ele traz uma clareza e organização que faltavam no Ingress, além de uma flexibilidade que permitirá adaptar-se mais rapidamente às mudanças.

No entanto, também é importante ressaltar que essa transição pode exigir um tempo de adaptação. A complexidade inicial pode ser um obstáculo para quem está começando a usar Kubernetes ou para equipes menores que já têm processos bem estabelecidos com o Ingress.

Ainda assim, acredito que o esforço de migração pode valer a pena a longo prazo, especialmente para ambientes de produção que exigem configurações de rede mais complexas e seguras.

Fechamento

E você, já começou a transição do Ingress para o Gateway API no seu cluster? Como tem sido sua experiência?