18 de fevereiro de 2025 Paulo Cerqueira 591 Views

Kubernetes Gateway API – um “adeus e obrigado” ao Ingress Controller

No Kubernetes, o recurso Ingress é utilizado para gerenciar o acesso externo a serviços dentro do cluster, fornecendo regras para o roteamento do tráfego HTTP e HTTPS atuando como um controlador de entrada (Ingress Controller) e possibilitando que diferentes serviços sejam acessados por meio de um único ponto de entrada.

O Ingress utiliza o roteamento com base em caminhos e domínios como metodologia de definição de regras para direcionamento de solicitações, tornando a exposição de aplicações mais eficiente do que o uso direto de serviços do Kubernetes (Services) do tipo LoadBalancer ou NodePort. Sua configuração se dá por meio de manifestos YAML que especificam hosts, regras de roteamento a backends definidos e implementação de certificados TLS para segurança (HTTPS).

Para possibilitar a utilização de recursos do tipo Ingress no Kubernetes, é necessário um controlador de entrada (Ingress Controller) como o NGINX Ingress Controller, Traefik ou HAProxy. Além de implementar as regras definidas, o Ingress Controller também permite funcionalidades avançadas, como reescrita de URLs, autenticação, limitação de taxa e balanceamento de carga.

Em resumo, o Ingress desempenha um papel essencial na exposição de aplicações para acesso externo ao ambiente do cluster, simplificando a gestão do tráfego de entrada, reforçando a segurança e facilitando a escalabilidade dos serviços, tornando-se um componente indispensável para arquiteturas modernas em ambientes Kubernetes.

Abaixo temos um exemplo de manifesto simples de um recurso do tipo Ingress do Kubernetes onde todos os protocolos HTTPS recebidos no cluster, cujo cabeçalho HOST possuam o DNS “meu-ingress.exemplo.com” sejam validados com o certificado “exemplo-tls” e direcionados para o service “meu-servico” na porta 80:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: meu-ingress
  namespace: 4Linux
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
    - hosts:
        - meu-ingress.exemplo.com
      secretName: exemplo-tls
  rules:
    - host: meu-ingress.exemplo.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: meu-servico
                port:
                  number: 80

Apesar de sua importância, o Ingress apresenta limitações que dificultam uma abordagem mais flexível e extensível. Dentre as principais restrições do Ingress estão:

A falta de granularidade torna complexa a separação de responsabilidades entre diferentes equipes.
Para protocolos não HTTP, os usuários precisam recorrer a soluções alternativas, como Services do tipo LoadBalancer ou NodePort.
Muitas configurações avançadas (como políticas de tráfego, autenticação e roteamento avançado) exigem o uso de anotações específicas para cada controlador (NGINX, Traefik, HAProxy), tornando a configuração e a mgiração entre controladores não padronizada e difícil de gerenciar.
Não há uma forma nativa de definir regras de roteamento de forma hierárquica, afetando aplicações que precisam de múltiplos pontos de entrada.

o Kubernetes Gateway API foi desenvolvido como uma alternativa moderna para lidar com essas limitações possibilitando a expansão do método de se trabalhar com o controle de ingresso no cluster Kubernetes ao introduzir novos recursos, como suporte aprimorado para protocolos além de HTTP/HTTPS (TCP, gRPC, WebSockets), estrutura de configuração mais granular e declarativa, melhor compatibilidade entre diferentes controladores e suporte nativo para multi-tenancy e escalabilidade.

Kubernetes Gateway API – Introdução

O Gateway API é um projeto oficial do Kubernetes focado no roteamento de protocolos das camadas L4 e L7 e representa a nova geração do Ingress Controller para balanceamento de carga e para APIs de malha de serviços (Service Mesh APIs). O Gateway API foi desenhado desde sua concepção para ser genérico, expressivo e orientado a papéis.

O modelo geral de recursos foca em 3 personas separadas e nos respectivos recursos que elas devem gerenciar:

A maioria das configurações do Gateway API está contida na camada de roteamento. Estes recursos são específicos a cada protocolo (HTTPRoute, GRPCRoute, etc) e possibilitam capacidades de roteamento avançadas tanto para Ingress quando para Mesh.

Gateway API para controle de entrada (Ingress)

Ao utilizar o Gateway API para gerenciar o tráfego de entrada, semelhante ao Ingress tradicional, o recurso de Gateway define um ponto de acesso onde o tráfego pode ser roteado para múltiplos contextos, como por exemplo, de tráfego externo para dentro do Cluster.

Em suma, cada recurso do tipo Gateway está associado hierarquicamente a um recurso do tipo GatewayClass, que descreve o tipo específico de controlador de gateway e lidará com o tráfego para o recurso de Gateway. Recursos individuais do tipo Rota (Route), como HTTPRoute e/ou TLSRoute, são associados a recursos de Gateway.

Separar essas diferentes responsabilidades em recursos distintos é uma parte fundamental da natureza orientada a funções do Kubernetes Gateway API pois, além de permitir múltiplos tipos de controladores de gateway (representados por recursos GatewayClass), cada um com múltiplas instâncias (representadas por recursos Gateway) e suas respectivas regras de roteamento em recursos do tipo Route dentro do mesmo cluster.

Gateway API para Malha de Serviços (Iniciativa GAMMA – Gateway API for Service Mesh)

Gerenciar uma malha de serviços (service mesh) através do Gateway API torna as coisas um pouco diferente do contexto anterior pois, como geralmente há apenas uma malha ativa no cluster, não se utiliza os recursos Gateway e GatewayClass. Em vez disso, recursos individuais de rota (como HTTPRoute e TLSRoute) são associados diretamente aos recursos Service do Kubernetes, permitindo que a malha gerencie o tráfego direcionado aos Services enquanto mantém a natureza orientada a funções da Gateway API.

Visão geral da API e seus componentes

Os recursos da Gateway API pertencem ao grupo de APIs gateway.networking.k8s.io como Definições de Recursos Personalizados (CRDs). Os nomes de recursos abaixo pertencem implicitamente a esse grupo de API.

Em seu modelo de recursos, existem basicamente três tipos principais de objetos:

O GatewayClass define um conjunto de gateways com configuração e comportamento comuns.
O Gateway solicita um ponto onde o tráfego pode ser traduzido para Services dentro do cluster.
Os recursos do tipo Routes descrevem como o tráfego vindo pelo Gateway é mapeado para os Services.

Para fins de exemplo vamos trabalhar com a seguinte arquitetura:

GatewayClass

O recurso GatewayClass define um conjunto de Gateways que compartilham configurações e comportamentos em comum. Cada GatewayClass é gerenciado por um único controlador, embora um controlador possa gerenciar mais de um GatewayClass.

Um GatewayClass é um recurso com escopo de cluster e deve haver pelo menos um GatewayClass definido para que os Gateways possam ser funcionais. Um controlador que implementa a Gateway API faz isso fornecendo um recurso GatewayClass associado, que o usuário pode referenciar a partir de seus Gateways.

Esta estrutura é semelhante ao IngressClass para Ingress ou ao StorageClass para PersistentVolumes. No Ingress v1beta1, o equivalente mais próximo ao GatewayClass é a anotação ingress-class, e no Ingress v1, o equivalente mais próximo é o objeto IngressClass.

Manifesto de um recurso GatewayClass:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: http-gatewayclass
spec:
  controllerName: exemplo.com/gateway-controller  # Nome do controlador responsável por este GatewayClass
  description: "GatewayClass de exemplo para configuração do Gateway API"
  parametersRef:
    group: example.com  # Grupo da API para parâmetros personalizados (quando aplicável)
    kind: ConfigMap      # ConfigMap contendo parâmetros adicionais
    name: gateway-config # Nome do ConfigMap
    namespace: kube-system # Namespace onde está o ConfigMap

Gateway

Um recurso do tipo Gateway descreve como o tráfego pode ser traduzido para Serviços dentro do cluster. Ou seja, ela define uma solicitação para uma maneira de traduzir o tráfego de um ambiente externo que não conhece o ambiente Kubernetes para um que conhece como, por exemplo, o tráfego externo enviado com destino a um Serviço Kubernetes. Embora muitos casos de uso envolvam tráfego de clientes originado de fora do cluster, isso não é necessariamente um requisito.

O recurso Gateway representa uma solicitação específica para a criação de um balanceador de carga. Ele atua como um ponto de entrada para um tráfego definido, determinando como as conexões externas devem ser gerenciadas e direcionadas para os serviços dentro do cluster. Um Gateway utiliza uma GatewayClass, que especifica a implementação e o comportamento do balanceador de carga, garantindo que a configuração atenda aos requisitos da infraestrutura subjacente.

A cada declaração de Gateway é configurado um ou mais escutadores/ouvintes (Listeners) que irão receber e lidar com protocolos específicos. Abaixo temos um exemplo de manifesto de um Gateway vinculado ao GatewayClass anterior onde se configura um Listener para o protocolo HTTP:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata: 
  name: http-gateway
spec:
  gatewayClassName: http-gatewayclass
  listeners:
    - name: http
      protocol: http
      port: 80

Um Gateway pode ser associado a uma ou mais referências de Rota (Route), que servem para direcionar um subconjunto de tráfego para um serviço específico.

Routes

Os recursos de Rotas (Route) definem regras específicas a cada protocolo para mapeamento de requisições de um Gateway para um serviço do Kubernetes e pode ser do tipo:

HTTPRoute: Utilizado para multiplexar conexões HTTP ou HTTPS terminadas e é destinado a casos onde é necessário inspecionar o fluxo HTTP sendo possível modificar e/ou definir o roteamento baseado em informações de cabeçalhos HTTP.
TLSRoute: Usado para multiplexar conexões TLS, discriminadas via SNI (ou Indicação de Nome do Servidor). Destinado a cenários onde se deseja usar o SNI como o principal método de roteamento, não interessando as informações dos protocolos de nível superior, como o HTTP. O fluxo é encaminhado para o backend sem qualquer inspeção.
TCPRoute e UDPRoute: Utilizados para mapear uma ou mais portas para um único backend. Nesse caso, o roteamento é realizado na camada 4 e não há qualquer discriminação do que pode ser usado para escolher diferentes backends para uma mesma porta. Então cada TCPRoute precisa de uma porta diferente no ouvinte (em geral).
GRPCRoute: Usado para roteamento de tráfego gRPC de maneira idiomática. Gateways que suportam GRPCRoute devem oferecer suporte ao HTTP/2 sem necessidade de atualização inicial do HTTP/1, garantindo assim que o tráfego gRPC flua corretamente.

Abaixo temos o exemplo de um manifesto para configuração de um recurso HTTPRoute onde mapeamos e roteamos as requisições com destino ao host meuapp.com.br através dos caminhos “/blog” e “/docs”:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: httproute-pathmatch
  labels:
    name: http-pathmatch
spec:
  parentRefs:
    # Aqui definimos a associação da nossa rota ao Gateway criado anteriormente
    - group: gateway.networking.k8s.io/v1beta1
      kind: gateway
      name: http-gateway
  hostnames: 
  - meuapp.com.br # DNS no cabeçalho host do protocolo HTTP
  rules:
  # Aqui serão definidas  as regras de roteamento de acordo com o path
  - matches:
    - path:
      type: Prefix
      value: /blog 
    # Através do backendRefs definimos o serviço de destino da requisição
    backendRefs:
    - name: svc_blog
      port: 8081
  - matches:
    - path:
      type: Prefix
      value: /docs 
    backendRefs:
    - name: svc_docs
      port: 8082

Neste exemplo vimos como podemos rotear uma requisição HTTP de acordo com o caminho (Path) tal qual o modelo do Ingress tradicional. Como vimos anteriormente, uma das principais vantagens do Kubernetes Gateway API é permitir mais maleabilidade e granularidade no roteamento dos pacotes.

Com base nas novas funções, podemos imaginar um cenário onde a nossa aplicação web ofereceria backends diferentes para usuários acessando em desktops ou aparelhos mobile e o roteamento não seria configurado baseado no caminho, mas no campo user-agent do cabeçado HTTP.

O cabeçalho User-Agent é responsável por permitir que um servidor identifique a aplicação, sistema operacional, fornecedor, e/ou versão do agente de usuário que enviou a requisição e é formatado semelhante aos exemplos abaixo:

Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1
Mozilla/5.0 (iPad; CPU OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Mobile Safari/537.36

Esta configuração não seria possível com o Ingress tradicional mas é possível através do Gateway API conforme podemos verificar no manifesto abaixo:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: httproute-headermatch
  labels:
    name: http-headermatch
spec:
  parentRefs:
    - group: gateway.networking.k8s.io/v1beta1
      kind: gateway
      name: http-gateway
  hostnames: 
  - meuapp.com.br
  rules:
  - matches:
    - headers:
      type: RegularExpression
      name: User-Agent
      value: ".*(Android|iPad|iPhone|Mobile).*"
    backendRefs:
    - name: svc_mobile
      port: 8081
  - (...)

Um outro exemplo de roteamento possibilitado pela implementação do Kubernetes Gateway API é o roteamento baseado em métodos. Com esta nova forma de roteamento podemos enviar uma requisitção com o método GET para um Backend enquanto enviamos requisições com o método POST para outro como podemos verificar no manifesto abaixo:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: httproute-methodmatch
  labels:
    name: http-methodmatch
spec:
  parentRefs:
    - group: gateway.networking.k8s.io/v1beta1
      kind: gateway
      name: http-gateway
  hostnames: 
  - meuapp.com.br
  rules:
  - matches:
    - path:
        type: Prefix
        value: /api/v2 
      method: GET
    backendRefs:
    - name: svc_api_get
      port: 8081
  - matches:
    - path:
      type: Prefix
      value: /api/v2 
    method: POST
    backendRefs:
    - name: svc_api_post
      port: 8082

Conclusão

A Kubernetes Gateway API representa uma evolução significativa na gestão do tráfego em clusters Kubernetes, oferecendo maior flexibilidade, extensibilidade e um modelo de recursos mais estruturado em comparação ao tradicional Ingress Controller. Com uma abordagem baseada em papéis bem definidos, a API permite que diferentes equipes colaborem de forma eficiente. Além disso, sua compatibilidade com múltiplos tipos de protocolos de tráfego proporciona uma solução mais abrangente e moderna para a exposição de serviços em Kubernetes.

Ao adotar a Gateway API, as organizações se beneficiam de um controle mais refinado sobre o tráfego, incluindo roteamento avançado, suporte aprimorado a políticas de segurança e melhor integração com provedores de serviços de rede. Seu design modular e extensível permite a evolução contínua do ecossistema sem comprometer a compatibilidade com implementações existentes. Assim, a Gateway API se consolida como uma alternativa poderosa ao Ingress Controller, trazendo uma arquitetura mais escalável e adaptável às necessidades das aplicações modernas.