Este é o primeiro post de uma série sobre o Kubernetes Gateway API.

Antes de continuar, se você não sabe o que é Docker e/ou Kubernetes recomendo fazer os cursos abaixo comigo ou ler e praticar o conteúdo desses links.

Curso Docker

Curso Kubernetes (k8s)

Introdução

O gerenciamento de tráfego no Kubernetes não é simples e, na maioria dos casos, envolve a exposição de aplicações compostas por múltiplos serviços, tais como: frontends, APIs e backends, que podem ser desenvolvidos em diferentes linguagens de aplicação.

Tradicionalmente, essas aplicações podem ser expostas usando uma combinação de objetos do Kubernetes, tais como: Ingress, Services, load balancers, e NetworkPolicies. O uso dessa combinação em larga escala gera uma grande configuração fragmentada que cria desafios operacionais e complexos, que podem atrasar novos deploys e dificultar a adaptação às novas demandas de microsserviços, onde: escalabilidade, confiabilidade e custos são requisitos cruciais para o negócio.

O objeto Ingress utiliza regras para o roteamento do tráfego HTTP e HTTPS com base em paths e nomes DNS para direcionar as requests vindas de fora do cluster para as aplicações implantadas no Kubernetes, e isso é mais eficiente do que o uso direto do objeto Service, do tipo LoadBalancer ou NodePort. O Ingress atua em conjunto com um Ingress Controller , que pode ser implementado por diferentes softwares. Um desses softwares é o o famoso ingress-nginx, que teve anunciado o fim do desenvolvimento de novas versões a partir de Março de 2026. O Ingress atua apenas na camada 7 do modelo OSI (Layer 7 ou apenas L7).

Obrigado a Ricardo Katz e demais contribuidores de código do ingress-nginx e também no Gateway API.

A figura abaixo foi extraída desse artigo do blog da AWS. Ela descreve em linhas gerais o fluxo de uma request vinda de um cliente (que pode ser uma pessoa ou uma aplicação) até chegar no Pod da aplicação destino implantada no Kubernetes.

A figura acima mostra que o Ingress Controller implanta, configura e gerencia os Pods que contêm o Nginx, um servidor web HTTP e proxy reverso de código aberto e muito popular. Os Pods do Nginx são expostos por meio do objeto Service do Ingress Controller, e eles recebem todo o tráfego externo ao Kubernetes. O Ingress Controller observa os objetos de Ingress configurados para cada Namespace de cada aplicação (via API do Kubernetes) e configura os pods do Nginx com base nas definições de IngressClass/Ingress, para que o tráfego seja roteado para os serviços apropriados. Aqui é verificado o path e nome DNS que o cliente deseja acessar. Uma vez que o controlador roteia o tráfego, a request é encaminhada ao objeto Service da aplicação destino. O Service, por sua vez, faz o descovery dos Pods da aplicação e repassa a request. Dentro do Pod, um conteiner da aplicação receberá a request e processará a solicitação do cliente. Depois da aplicação processar a request, a resposta segue o caminho inverso até o cliente.

O que é o Kubernetes Gateway API?

O Kubernetes Gateway API é uma especificação que padroniza a forma como o roteamento de tráfego é gerenciado no Kubernetes. Ele foi criado pelo Kubernetes SIG-NETWORK group como uma alternativa mais flexível e robusta às limitações Ingress, possibilitando uma abordagem modular, configuração mais granular e declarativa, melhor compatibilidade entre diferentes controllers, separação clara de responsabilidades e suporte nativo a diversos protocolos, tais como: HTTP, TCP, UDP, TLS, gRPC e WebSocket. Nesse post, você poderá ver mais detalhes sobre o Kubernetes Gateway API e o Ingress, bem como casos de uso e que limitações do Ingress o Gateway API promete resolver.

O principal ganho do uso Kubernetes Gateway API é a simplificação do gerenciamento de tráfego, permitindo que as equipes escalem as aplicações com menos esforço que usando o Ingress, mantendo a eficiência operacional e a segurança. Embora o Kubernetes não ofereça uma implementação padrão, existem diversas ferramentas populares de código aberto e comerciais, que suportam o Gateway API. A lista completa pode ser vista em: https://gateway-api.sigs.k8s.io/implementations/.

É importante dizer que o Gateway API não substitui o Ingress. É uma evolução a partir dele, que traz soluções para demandas mais complexas e necessidades não eram atendidas pelo Ingress. O Gateway API atua nas camadas 4 e 7 do modelo OSI (Layer 4 e7 ou apenas L4 e L7).

Componentes do Gateway API

A especificação do Gateway API introduz vários novos CRDs (Custom Resource Definition) e consiste nos seguintes componentes:

GatewayController: é um recurso a nível de cluster que corresponde a implementação dos tipos de gateway que fará o balanceamento de carga do tráfego no Kubernetes. Existem diferentes softwares que implementam o GatewayController, e a lista pode ser encontrada em: https://gateway-api.sigs.k8s.io/implementations/#gateway-controller-implementation-status
GatewayClass: é um recurso também a nível de cluster que gerencia todos os recursos do Gateway. Ele torna fácil e explícito para os administradores do cluster entenderem quais recursos estão disponíveis a determinado grupo de gateways, que compartilham a mesma configuração e que são gerenciados pelo GatewayController seguindo as especificações da classe.
Gateway: é aqui que o tráfego é gerenciado. Um gateway funciona como um ponto de entrada para o cluster Kubernetes, que direciona o tráfego de entrada para os destinos apropriados com base na configuração do GatewayClass. Pode existir um gateway por cluster e/ou por namespace. O Gateway define as portas (listeners), protocolo (HTTP, TCP, TLS…), nomes, hostname, etc para encaminhar as requests às aplicações de destino.
RouteTyped: essas rotas descrevem regras de roteamento e usam parentRefs para referenciar quais Gateways (e quais listeners dentro deles) devem receber essa rota. Há também um modelo de confiança (trust model), onde o Gateway pode filtrar quais rotas são permitidas em cada listener (allowedRoutes), garantindo que apenas rotas autorizadas sejam vinculadas. Na versão 1.4.0 do Gateway API existem os seguintes tipos:
- HTTPRoute: é aqui que são definidas as regras de roteamento do tráfego HTTP.
- TCPRoute: é aqui que são definidas as regras de roteamento do tráfego TCP e Websocket.
- UDPRoute: é aqui que são definidas as regras de roteamento do tráfego UDP.
- TLSRoute: é aqui que são definidas as regras de roteamento do tráfego criptografado com o TLS.
- GRPCRoute: é aqui que são definidas as regras de roteamento do tráfego gRPC.
- HTTPRoute for Mesh: é aqui que são definidas as regras de roteamento do tráfego HTTP quando as aplicações estão usando Service Mesh.

Mais detalhes dos CRDs podem ser obtidos em:

Como funciona o Gateway API?

A figura abaixo foi extraída deste post e descreve o fluxo da request em cada um de seus componentes e de como ele funciona:

O GatewayController é o controlador que implementa a lógica para os objetos GatewayClass, Gateway e Route. Ele monitora as alterações nesses objetos e, em seguida, atualiza a configuração de rede para lidar com o tráfego de entrada conforme definido. Isso permite que o cluster Kubernetes reaja às mudanças nas configurações de roteamento e gerencie o tráfego com eficiência. O Route conecta o tráfego a um backend específico e assim a request pode chegar na aplicação de destino.

Cada Gateway precisa referenciar uma GatewayClass, mas existem algumas maneiras de vincular uma Rota a um Gateway. Aqui estão alguns padrões de configuração comuns:

Rota única para um único Gateway: Um único recurso de Rota é associado a um único Gateway. Isso é ideal para casos de uso com escopo bem definido, onde o Gateway atende a um aplicativo ou serviço específico.
Múltiplas Rotas em um único Gateway: Um único Gateway pode atender a múltiplos recursos de Rota em diferentes namespaces. Este é um padrão comum para ambientes multi-tenant, onde equipes ou aplicativos compartilham um Gateway, mas possuem Rotas gerenciadas independentemente.
Rota única em múltiplos Gateways: Uma única Rota pode ser vinculada a múltiplos Gateways. Isso é particularmente útil para cenários onde um aplicativo precisa ser exposto em diferentes ambientes (por exemplo, redes públicas e privadas) ou através de diferentes IPs ou balanceadores de carga.

Divisão de responsabilidades do Gateway API

A figura abaixo foi extraída da doc oficial do Kubernetes Gateway API.

A figura acima mostra três tipos de papéis (“personas”) organizacionais, cada um responsável por diferentes recursos no Kubernetes Gateway API:

Infrastructure Provider: define a classe de gateway. Por exemplo, pode haver uma classe para o controlador Nginx, outra para Istio, etc.
Cluster Operator: cria instâncias de Gateways, configurando pontos de entrada de rede.
Application Developer: define as rotas (HTTPRoute, etc), portas, protocolo (HTTP, TCP, TLS…), nomes, “hostname”, etc.; que vinculam tráfego do Gateway para as aplicações a serem expostas.

As principais vantagens desse modelo são:

Separação de responsabilidades: como cada persona tem seus recursos, infraestrutura, operação e desenvolvimento ficam desacoplados, o que melhora governança e segurança.
Expressividade: você pode definir rotas mais complexas (cabeçalhos HTTP, pesos, tempo limite, etc) porque não está limitado aos recursos simples de Ingress.
Extensibilidade: pela estrutura modular (GatewayClass → Gateway → Route), é possível adicionar tipos novos (novos protocolos, filtros customizados, políticas) de forma mais limpa.
Multi-namespace / Multi-equipe: rotas podem vir de namespaces diferentes e se ligar ao mesmo Gateway, permitindo que equipes diferentes compartilhem a infraestrutura de entrada de tráfego sob políticas controladas.

RBAC

O design do Gateway API está naturalmente alinhado com o Role-based access control (RBAC) do Kubernetes. Um modelo simples de 3 níveis de permissões de escrita por função pode parecer algo assim (onde um Papel é criado para cada persona):

	GatewayClass	Gateway	Route
Provedor de infraestrutura	✅	✅	✅
Operador de cluster	❌	✅	✅
Desenvolvedor de aplicativos	❌	❌	✅

Dado que o RBAC foi configurado como neste exemplo, você saberá que protegeu sua configuração de infraestrutura de alterações indesejadas por atores não autorizados. Esse alinhamento impõe fluxos de trabalho seguros e eficientes, permitindo que as equipes se concentrem em suas responsabilidades sem ultrapassar quaisquer limites.

Diferenças entre o Gateway API e Ingress

A tabela abaixo mostra as principais diferenças entre o Gateway API e o Ingress e quando utilizar cada um deles.

Características	Gateway API	Ingress
Suporte de protocolo	Suporta mais protocolos como gRPC, HTTP/2 e WebSockets, permitindo um gerenciamento de tráfego complexo.	Suporta principalmente tráfego HTTP e HTTPS.
Camada OSI suportada	L4 e L7	L7
Complexidade de roteamento	Permite roteamento complexo, incluindo divisão de tráfego ponderada e regras avançadas para diferentes serviços e protocolos.	Suporta regras básicas de roteamento para tráfego HTTP/HTTPS.
Facilidade de gerenciamento	Facilita aos operadores de cluster a criação e o gerenciamento de várias classes de gateway, a implantação de novos gateways e o teste de configurações antes da implantação em produção.	O Ingress é mais simples, mas carece de recursos avançados para gerenciar múltiplos gateways ou configurações complexas.
Extensibilidade	Mais extensível, com a capacidade de definir novos protocolos e regras de roteamento, tornando-o adequado para cenários de rede complexos.	Extensibilidade limitada, focada principalmente em casos de uso baseados em HTTP.
Gestão Colaborativa	Permite delegar controle a diferentes equipes, com gerenciamento de rotas e políticas por namespaces diferentes	Limitada
Suporte a Políticas	Suporte a autenticação, rate limiting e outras políticas de rede diretamente nas rotas	Depende do controlador
Balanceamento de Carga	Balanceamento mais flexível, controle via políticas diretamente no Gateway	Balanceamento simples entre pods via Serviço
RBAC	Suporte granular a Role-based access control (RBAC) e controle de acesso	Não é suportado nativamente
Caso de uso	Ideal para gerenciar cenários de rede complexos e múltiplos serviços com requisitos diversos.	Mais adequado para aplicações mais simples com necessidades básicas de roteamento HTTP/HTTPS.

Migrando do Ingress para o Gateway API

Em linhas gerais, a estratégia de migração do Ingress para o Gateway API, envolve:

Escolha uma aplicação menos crítica ao negócio
Mapeie todas necessidades do tráfego dessa aplicação
Mantenha o Ingress rodando e configurado.
Configure o Gateway API de acordo com a necessidade.
Crie um loadbalancer externo para direcionar para o novo gateway sem alterar o loadbalancer usado pelo Ingress.
Crie um janela de manutenção para essa atividade
Altere o DNS para apontar para o novo loadbalancer.
Monitore o tráfego por alguns dias. Em caso de problema, faça o rollback da mudança no DNS.
Remova o loadbalancer antigo e o ingress controller antigo apenas quando tiver migrado todas as aplicações para o Gateway API

Conclusão

Em resumo, o Gateway API oferece uma maneira mais flexível e escalável de gerenciar o tráfego no Kubernetes em comparação com o Ingress tradicional. Com novos recursos como GatewayClass, Gateway e Route, ele proporciona às equipes maior controle sobre roteamento, segurança e infraestrutura. Seu design orientado a funções permite a colaboração entre diferentes equipes, oferecendo maior flexibilidade na definição de políticas de rede e no tratamento de cenários de tráfego complexos. Além disso, com suporte a múltiplos protocolos e recursos avançados como roteamento ponderado, o Gateway API é uma ferramenta robusta para o gerenciamento de tráfego em ambientes Kubernetes modernos.

Nos próximos posts serão abordadas a instalação e exemplos de configuração para diferentes tipos de aplicação.

Conhecendo o Kubernetes Gateway API

Introdução

O que é o Kubernetes Gateway API?

Componentes do Gateway API

Como funciona o Gateway API?

Divisão de responsabilidades do Gateway API

RBAC

Diferenças entre o Gateway API e Ingress

Migrando do Ingress para o Gateway API

Conclusão

Referências

Deixe um comentário

Latest Post

Tags