Gateway API do Kubernetes

 (romaglushko.com)
4 pontos por GN⁺ 4 시간 전 | 2 comentários | Compartilhar no WhatsApp
  • Em novembro de 2025, o Kubernetes anunciou a descontinuação do NGINX Ingress Controller em março de 2026, usado em mais de 40% de todos os clusters; essa decisão se tornou um ponto de virada que posiciona a Gateway API como sucessora da Ingress API
  • A Gateway API cobre uma ampla gama de funcionalidades necessárias para o gerenciamento de tráfego de entrada, tem maior expressividade que a Ingress API e deixa mais clara a separação de responsabilidades entre equipes
  • As limitações da Ingress API incluem escopo de API restrito, extensibilidade rígida, ausência de imposição de políticas, limites de propriedade ambíguos e falta de suporte seguro a referências cross-namespace
  • A Gateway API fornece um modelo de recursos separado, como GatewayClass, Gateway, Listener e Route, além de mecanismos de segurança e extensão como ReferenceGrant e Policy attachment
  • Os CVEs recorrentes do NGINX Ingress Controller decorrem de falhas estruturais e, no longo prazo, a migração para a Gateway API é a única solução definitiva

Evolução do Ingress

  • No Kubernetes inicial de 2014, o recurso Service era o meio padrão de expor aplicações
    • ClusterIP fornecia apenas um nome DNS interno ao cluster, sem acesso externo
    • NodePort abria uma porta específica em todos os nós para receber tráfego externo; se o IP do nó fosse exposto, o acesso externo seria possível
    • LoadBalancer provisionava um balanceador de carga externo com IP público para encaminhar o tráfego
    • ExternalName fornecia um alias interno no cluster para um serviço externo por meio de um registro CNAME
  • Entre os quatro, apenas NodePort e LoadBalancer permitiam exposição externa direta
    • NodePort era um primitivo básico, porém de nível muito baixo, exigindo implementar manualmente balanceamento de carga externo entre nós e roteamento baseado em path
  • O LoadBalancer adicionava um balanceador L4 (TCP/UDP) sobre o NodePort com provisionamento automático, gerenciado pelo Cloud Controller Manager
    • Porém, era necessário administrar vários IPs públicos e balanceadores, o que aumentava os custos e deixava sem um ponto central de gestão do tráfego
  • Em vez de um balanceador separado para cada Service, a arquitetura em que um único Service do tipo LoadBalancer recebe todo o tráfego e o encaminha para um Deployment de reverse proxy como o NGINX, roteando com base em caminho e hostname, foi o ponto de partida da Ingress API e do Ingress Controller

Ingress Controller

  • Em 2015, a equipe do Kubernetes introduziu a Ingress API como um meio de definir regras para rotear tráfego HTTP(S) externo para Services internos

  • A Ingress API é composta por dois recursos, IngressClass e Ingress, definindo apenas uma interface comum; o comportamento real exige a instalação de um Ingress Controller

  • IngressClass

    • Recurso de escopo cluster-wide que especifica qual controlador processará um determinado conjunto de recursos Ingress
    • Permite operar em paralelo vários Ingress Controllers no mesmo cluster, e cada controlador observa apenas os recursos selecionados por sua própria IngressClass
    • O controlador precisa de permissões de ClusterRole para ler e usar a IngressClass

  • Recurso Ingress

    • O Ingress é o principal recurso da Ingress API e combina vários elementos
      • define o roteamento para Services internos por meio de regras de correspondência baseadas em path (exact/prefix) e host
      • define a configuração de TLS do tráfego de entrada
    • Quando o recurso é criado, o Ingress Controller o detecta, atualiza sua própria configuração e aplica as regras de roteamento

  • Problemas da Ingress API

    • Em ambientes reais de operação, surgem os seguintes problemas: escopo de API muito limitado, extensibilidade rígida, ausência de imposição de políticas, limites de propriedade ambíguos e falta de suporte seguro a referências cross-namespace

  • Escopo de API muito limitado

    • A Ingress API não é apenas simples; ela é simplista, cobrindo apenas o mínimo necessário para configurar tráfego de ingresso
    • Ela não oferece suporte direto aos seguintes recursos comumente desejados no NGINX
      • request timeout, CORS, limite de tamanho máximo do body, sessão com sticky cookie, divisão de tráfego canary, rate limiting, roteamento baseado em header·query·cookie e modificação de headers
    • Por isso, custom annotations se tornaram o meio padrão para transmitir configurações adicionais, e alguns controladores, como o Traefik, usam seus próprios CRDs
    • Ao usar vários Ingress Controllers simultaneamente, não há um método unificado de configuração; como as annotations diferem entre controladores, a portabilidade é reduzida
    • O Ingress lida apenas com roteamento HTTP(S), enquanto gRPC (L7) e TCP·UDP (L4) são tratados, dependendo da implementação, por meio de custom annotations

  • Extensibilidade rígida

    • As custom annotations são apenas pares de chave-valor em string, então configurações complexas precisam ser serializadas como strings, o que resulta em baixa expressividade

  • Ausência de imposição de políticas

    • A equipe de aplicações pode adicionar annotations arbitrárias ao recurso Ingress; por exemplo, pode até desativar o rate limiting esperado pela equipe de plataforma para todas as rotas
    • Como a própria Ingress API não tem um mecanismo para impor comportamento global, ela depende de mecanismos externos de políticas, como Kyverno ou OPA Gatekeeper

  • Limites de propriedade ambíguos

    • O recurso Ingress mistura várias configurações
      • as regras de roteamento geralmente pertencem à equipe de aplicações
      • as configurações de hostname e porta pertencem à equipe de plataforma, que gerencia DNS, balanceadores e rede
      • as configurações de TLS pertencem à equipe de plataforma, responsável pelo provisionamento de certificados
      • as custom annotations podem pertencer a qualquer uma das duas equipes
    • Em sistemas complexos implantados com umbrella Helm chart, o Ingress geralmente fica no subchart da aplicação, mas a equipe de plataforma também precisa atualizar ou impor parte dele
    • Do ponto de vista do princípio da responsabilidade única, o Ingress tem mais de um motivo para mudar, então é desejável separá-lo em recursos mais focados
    Publicidade

  • Falta de suporte seguro a cross-namespace

    • O recurso Ingress não pode referenciar um Service nem um secret TLS fora do seu próprio namespace, e rules[].backend.service sequer tem um campo para especificar namespace
    • Como alternativa, é possível criar um Service ExternalName no mesmo namespace apontando para o nome DNS interno ao cluster do Service de destino
    • No entanto, essa abordagem embute justamente um problema que caracteriza um confused deputy attack

Gateway API

  • A Gateway API é a próxima geração da Ingress API e resolve essas limitações ao
    • cobrir um conjunto muito mais amplo de funcionalidades necessárias para o gerenciamento de tráfego de entrada, aumentando a expressividade
    • refletir padrões comuns de propriedade de recursos, deixando clara a separação de responsabilidades entre equipes
    • incluir um mecanismo de extensão definido chamado policies e referências flexíveis a objetos cross-namespace

GatewayClass

  • De forma semelhante ao IngressClass, define um conjunto de Gateways pertencente a uma implantação específica de controlador Gateway; na prática, tem significado e estrutura quase idênticos aos do IngressClass
  • Também pode referenciar um custom resource que contém configurações adicionais específicas da implementação do Gateway
    • incluindo a forma de expor o proxy do Gateway, configurações padrão de bootstrap e execução, estratégia de rollout e escalabilidade da implantação, além de outras opções específicas do controlador

Gateway

  • O recurso Gateway representa um edge gateway provisionado dinamicamente, uma abstração de infraestrutura que recebe tráfego de entrada e o roteia para os serviços de backend apropriados

    • Como o Ingress Controller no design do Ingress cumpria esse papel, ele pode ser visto como uma instância de Gateway provisionada estaticamente

  • Cada Gateway referencia uma GatewayClass para especificar qual controlador fará o provisionamento e o gerenciamento, e seu componente mais importante é a lista de listeners

  • Listeners

    • Define como o Gateway aceita tráfego de entrada; cada listener é um ponto de entrada distinto descrito por uma combinação de porta, protocolo e hostname
    • É possível configurar TLS termination; no mundo do Ingress, essas informações ficavam dentro do recurso Ingress
    • É a unidade mais granular à qual uma Route pode ser anexada em um Gateway

  • ListenerSet

    • Listeners são bons para centralizar a configuração dos pontos de entrada, mas não são adequados quando são necessários centenas deles
    • O caso principal é ter listeners HTTPS com configurações de hostname e TLS por serviço, em vez de um único certificado TLS wildcard; isso pode gerar tantos listeners quanto houver microsserviços
    • Ao modelar isso com um único Gateway, surgem dois problemas
      • O Gateway suporta no máximo 64 listeners
      • Se várias equipes gerenciam listener e TLS, o Gateway se torna um gargalo de coordenação
    • Para distribuir isso e permitir multi-tenant, usa-se o recurso ListenerSet

  • Listeners e Routes permitidos

    • Depois da separação entre os conceitos de Gateway e Route, surge um novo problema: controlar qual tenant pode anexar uma Route a qual listener
    • Listeners são infraestrutura compartilhada e têm finalidades diferentes; por exemplo, não é apropriado anexar uma HTTPRoute ao listener tls-passthrough-db, que é um canal de passthrough para banco de dados, e também não é apropriado anexar uma Route a partir de um namespace diferente de db
    • Como as Routes são adicionadas de forma autônoma, usa-se o mecanismo allowedRoutes para evitar configurações incorretas
    • O allowedRoutes estabelece uma relação de confiança entre um Gateway ou ListenerSet e Routes de determinados namespaces e tipos

Routes

  • O listener recebe o tráfego, mas não sabe como tratá-lo depois; isso é responsabilidade dos recursos Route, que são o núcleo da flexibilidade da Gateway API

  • Existem cinco recursos Route para lidar com diferentes protocolos

    • HTTPRoute: roteamento de tráfego HTTP aprimorado e expandido
    • GRPCRoute: roteamento com reconhecimento de gRPC
    • TLSRoute: roteamento baseado em TLS SNI
    • TCPRoute·UDPRoute: encaminham diretamente o tráfego TCP/UDP da porta do listener para o backend
    Publicidade

  • Todos os recursos Route (chamados coletivamente de xRoutes) têm uma estrutura envelope semelhante

    • parentRefs é uma referência tipada ao recurso pai que recebe a Route — geralmente Gateway, ListenerSet ou Service de service mesh — e as opções sectionName e port podem ser usadas para apontar para um listener específico
    • rules inclui regras de roteamento, filtros e configurações específicas do protocolo; cada rule é composta por matches, filters opcionais e backendRefs opcionais; se um filtro tratar a requisição completamente, backendRefs pode ser omitido
    • Quando o protocolo permite, o campo hostnames possibilita roteamento baseado em host no nível da Route

  • HTTPRoute

    • Define regras de roteamento de tráfego HTTP(S) no nível L7

    • Traffic Matching

      • Suporta roteamento por path e host, semelhante ao Ingress, além de regras de correspondência baseadas em header, query e método
      • Exemplo: é possível direcionar um canary release apenas para clientes internos a um deployment de teste usando correspondência baseada em header
      • O data plane aplica a regra mais específica, então a ordem de definição das regras não importa

    • URL Rewrites

      • Com filtros, é possível reescrever partes da URL da requisição antes de ela chegar ao backend

    • Header Modifications

      • Fornece o filtro HeaderModifier para adicionar, remover e modificar headers de requisição e resposta
      • Também fornece um filtro dedicado de CORS para configuração de Cross-Origin Resource Sharing; conceitualmente é um caso especial de modificação de headers de resposta, mas é exposto como um tipo de filtro separado

    • Redirects

      • Em vez de encaminhar ao backend, pode retornar uma resposta de redirecionamento ao cliente; há suporte a redirects baseados em path com código 3xx e a redirects de HTTP para HTTPS

    • Traffic Control

      • O peso permite dividir o tráfego entre serviços de backend, o que é útil para implantações blue-green e testes A/B
      • Traffic mirroring envia uma cópia do tráfego de produção para um backend adicional e é configurado com o filtro RequestMirror; a requisição original continua para o backend padrão
      • O mirroring é um componente central do teste tap-and-compare, usado para comparar os resultados das versões antiga e nova durante refatorações e migrações

    • Sticky Sessions

      • Há suporte a persistência de sessão, usando cookie ou header como marcador de sessão para rotear consistentemente as requisições do mesmo cliente para a mesma instância de backend

    • External Authentication

      • Há suporte a um filtro experimental de autenticação externa baseado em gRPC ou HTTP; antes de encaminhar ao backend, o Gateway envia os headers da requisição a um serviço de autenticação externo, e o corpo da requisição só é enviado se isso for explicitamente habilitado
      • No caso de gRPC, o serviço de autenticação externo precisa implementar a API protobuf ext_authz do Envoy
      • No caso de HTTP, o sucesso da autenticação exige retorno 200; qualquer outro status é tratado como falha de autenticação

    • Retries & Timeouts

      • É possível configurar retry em uma rota específica, e a BackendTrafficPolicy fornece um retry budget global para evitar retry storm

  • GRPCRoute

    • Como gRPC é baseado em HTTP/2, ele também pode ser tratado com HTTPRoute, mas há motivos para modelá-lo como um recurso separado
      • Isso separa opções sem sentido para gRPC, como URL rewrite, permitindo que cada recurso evolua de forma independente e adequada ao protocolo
      • Respostas gRPC podem retornar HTTP 200 e ainda assim expressar erros de aplicação pelos headers grpc-status e grpc-message, o que é importante para retries e métricas corretos
      • Definir regras em termos de mais alto nível do gRPC melhora a experiência do usuário
    • O path matcher do HTTPRoute é substituído por um method matcher; internamente ainda faz correspondência por path, mas isso é exposto no formato service e method
    • É possível tratar headers de requisição e resposta, mas como o payload gRPC não é decodificado, não é possível rotear com base em campos específicos do protobuf
    • Suporta parte dos filtros do HTTPRoute, como traffic mirroring, weighted load balancing e modificação de headers

  • TCPRoute e UDPRoute

    • Simplesmente encaminham para os serviços de backend o tráfego que chega à porta do listener; atualmente não oferecem suporte a matcher nem filter
    • Ambos os tipos suportam weighted load balancing entre múltiplos backends

  • TLSRoute

    • Roteia tráfego TLS criptografado para o backend com base no SNI fornecido durante o handshake TLS
    • É usado principalmente para TLS passthrough; o Gateway inspeciona o SNI, escolhe o backend e encaminha a conexão criptografada sem encerrar o TLS, deixando a terminação TLS a cargo do backend
    • Algumas implementações, como Envoy Gateway e kgateway, também suportam TLS termination na borda, mas isso é uma funcionalidade estendida
    • É necessário especificar o hostname na Route; ele precisa corresponder ao valor de SNI e ter interseção com o hostname do listener do Gateway; matcher e filter não são suportados, mas há suporte a weighted load balancing

  • Route Filter Extensions

    • HTTPRoute e GRPCRoute incluem um mecanismo de extensão para filtros customizados e processamento de requisição/resposta por meio do filtro extensionRef, que aponta para outro recurso usando uma referência tipada
    • Exemplo: o Envoy Gateway fornece um CRD HTTPRouteFilter que retorna uma resposta diretamente sem precisar de um serviço de backend

  • Backends de destino

    • Por padrão, suporta Service padrão (o mais comum) e ServiceImport para multicluster como alvos de backend
    • Como são especificados por typed object reference, é possível expandir com custom resources específicas de cada implementação
    • Ex.: o Envoy Gateway oferece suporte ao recurso customizado Backend, que aponta para upstreams externos como FQDN, IP e socket UNIX
    Publicidade

  • ReferenceGrant

    • A Gateway API trata referências entre namespaces como um conceito de primeira classe no design padrão, mas há riscos de segurança
    • Exemplo de confused deputy attack: se um invasor comprometer um namespace, ele pode vazar acesso a serviços protegidos com permissões para criar Ingress, Service e EndpointSlice
      • Um novo Ingress aponta para um novo Service no namespace comprometido
      • Esse Service não tem selector e, portanto, não corresponde a nenhum deployment, permitindo fornecer manualmente um EndpointSlice
      • O invasor forja um EndpointSlice incluindo o IP de um pod de backend protegido em outro namespace e, com o alinhamento de portas, cria uma segunda rota de entrada para a API protegida
      • O mesmo resultado também pode ser obtido com um Service do tipo ExternalName
    • Para mitigar isso, foi introduzido o recurso ReferenceGrant, um mecanismo de confiança bilateral em que um namespace define quais namespaces podem referenciar seus recursos
    • O Gateway Controller considera o ReferenceGrant ao fazer referências entre namespaces para alvos de backend e secrets TLS, dificultando confused deputy attacks
    • Porém, o ReferenceGrant garante apenas a legitimidade da referência e não interfere no comportamento após o encaminhamento do tráfego; isso pode ser complementado com NetworkPolicies para bloquear o acesso às portas da API protegida

Policies

  • Policy attachment é um poderoso padrão de extensão que aplica comportamento e efeitos de forma hierárquica a um ou mais componentes da Gateway API sem modificar o recurso original
  • Autenticação é um exemplo representativo
    • Se a autenticação for aplicada ao Gateway inteiro (ou ListenerSet), ela afeta hierarquicamente todas as Routes anexadas agora e no futuro, ao mesmo tempo permitindo exceções no nível da Route, como rotas públicas
    • A autenticação pode ser controlada por uma equipe diferente da que gerencia Gateway e Route, e por isso foi projetada para não exigir modificação direta desses recursos
    • Mesmo existindo padrões como OAuth 2 e OIDC, a configuração de autenticação depende muito da implementação, o que dificulta uma abstração comum a todas elas
  • Ex.: com o recurso SecurityPolicy do Envoy Gateway, é possível configurar a validação de tokens JWT; Policies são uma forma moderna e expressiva de substituir as configurações baseadas em annotations da era do Ingress
  • Há apenas duas Policies nativas
    • BackendTLSPolicy: instrui o Gateway a se conectar ao backend upstream via TLS
    • BackendTrafficPolicy: define o retry budget de um backend específico; quando o limite global de retries é excedido, retorna 503, funcionando como um circuit breaker e evitando retry storms

Ownership

  • Os recursos da Gateway API no cluster normalmente pertencem a duas equipes
    • A equipe de plataforma define GatewayClass, Gateway, ListenerSet e as configurações de LoadBalancer e TLS, além de poder gerenciar Policies globais aplicadas a parte ou a todo o Gateway
    • A equipe de aplicação/serviço normalmente se concentra em seus próprios recursos de Route e, quando necessário, aplica Policies no nível da Route
  • A flexibilidade é alta, então também é possível montar vários modelos de propriedade, como a equipe de plataforma reunir e controlar as Routes em um único namespace

Arquitetura típica

  • A Gateway API não pressupõe rigidamente uma arquitetura de implementação, mas a abordagem mais comum é a separação entre control plane e data plane
  • O Gateway Controller atua como um operator do Kubernetes no papel de control plane, observando recursos da Gateway API e CRDs para compor a configuração desejada do data plane, e precisa de permissões ampliadas para ler e modificar recursos
  • O data plane do Gateway é o proxy que processa o tráfego conforme a configuração, com uso frequente de Envoy Proxy, NGINX e Traefik; dependendo da implementação, pode haver um proxy por Gateway ou um proxy compartilhado
  • A separação entre control plane e data plane é uma escolha de design vantajosa para evitar falhas fundamentais de segurança encontradas no NGINX Ingress Controller

Migração de Ingress

  • Há quatro opções para lidar com a descontinuação do NGINX Ingress Controller, consideradas em ordem da menos invasiva para a mais invasiva

  • Não fazer nada

    • Não é o ideal, mas em alguns casos pode ser viável; em homelabs pode haver pouca motivação para mudar

    • Em ambientes enterprise, isso costuma ser difícil de aceitar por causa de frameworks regulatórios, de segurança e de compliance que esperam operação com software mantido e corrigido

      • ISO 27001: espera gestão de vulnerabilidades, patches e acompanhamento de EOL
      • SOC 2 Type II: espera varredura de vulnerabilidades, gestão de patches e SLA de correção
      • HIPAA Security Rule: exige incluir software legado e sem patch na análise de risco
      • PCI DSS v4.0.1: exige identificar componentes sem suporte, ter plano de correção e cumprir prazos para tratar vulnerabilidades graves
      • FedRAMP: espera substituir software sem suporte por alternativas mantidas e define prazos de correção por severidade

    • Na maioria dos frameworks, software em EOL se torna um problema prático quando novas vulnerabilidades são divulgadas

    • Análise de CVEs

      • Situação dos CVEs do NGINX Ingress Controller nos últimos 5 anos
        • Total de 20 vulnerabilidades
        • Em 2021, 4 High relacionados a vazamento de secrets
        • Em 2022, 1 High relacionado a vazamento de credenciais do controller
        • Em 2023~2024, 3 High
        • Em 2025, 6 casos, incluindo 1 Critical (IngressNightmare) e 4 High relacionados a injeção de configuração do NGINX
        • Em 2026, 6 casos, incluindo 3 High relacionados a injeção de configuração do NGINX
      • Os CVEs de 2021~2022 eram principalmente problemas com configurações NGINX fornecidas por usuários sem sanitização em annotations, causando injeção de configuração, exposição de informações e vazamento de secrets; o Kubernetes adicionou validação
      • Os CVEs de 2023~2024 foram principalmente formas de contornar essa validação de annotations
      • IngressNightmare (CVE-2025-1974) piorou a situação: antes era necessário ter permissão para criar ou modificar recursos Ingress, mas bastando acesso de rede ao admission controller tornou-se possível executar código remotamente no contexto do controller ingress-nginx por meio de um bug semelhante a injeção de configuração, e depois disso vazar Secrets acessíveis ao controller
      • O conjunto de 2026 também manteve o padrão de injeção de configuração por meio de annotations, paths e comments
      • Essas vulnerabilidades repetidamente exploram a mesma fraqueza de design
        • O controller é extremamente flexível e expõe amplos recursos do NGINX, o que dificulta validação perfeita e faz a injeção de configuração reaparecer repetidamente
        • O controller executa o control plane e o data plane no mesmo pod e compartilha o sistema de arquivos, ampliando o impacto quando ocorre um incidente
        • O controller frequentemente tem acesso a Secrets de todo o cluster, então uma injeção de configuração bem-sucedida pode levar ao vazamento de secrets em escala de cluster
      • Devido a esses problemas estruturais, são esperados novos CVEs no futuro; permanecer no controller original sem um plano de migração é uma escolha arriscada
      Publicidade

  • Usar um fork do NGINX Controller

    • O caminho mais simples é migrar para um fork que continue mantido
      • O fork da Chainguard aparentemente não fornece imagens prontas, e isso parece fazer parte da oferta comercial
    • Isso reduz o risco de exposição a novos CVEs e permite manter o sistema sem grandes mudanças, mas é uma solução de curto prazo
    • A Chainguard não pretende continuar desenvolvendo o controller como um projeto de longo prazo; ela oferece correções de CVEs em regime best-effort para dar aos usuários tempo para migrar

  • Uso de outro Ingress Controller

    • Como o recurso Ingress em si não está deprecated, também é válido migrar para outro Ingress Controller que continue sendo mantido, como HAProxy · Istio · Traefik
    • É necessária a migração de annotations em todo o sistema, e a dificuldade varia conforme o grau de dependência de recursos específicos do NGINX
    • No futuro, mais projetos devem migrar para a Gateway API e a relevância do Ingress tende a diminuir, mas por enquanto continuar com Ingress também é totalmente aceitável

  • Migração para a Gateway API

    • A única opção de longo prazo é migrar da Ingress API para a Gateway API
      • Instalar a CRD e a implementação da Gateway API
      • Configurar GatewayClass, Gateway e, se necessário, recursos de Policy
      • Migrar os recursos Ingress existentes para Route
    • A CLI ingress2gateway, criada pela equipe do Kubernetes, oferece conversão automática em regime de best-effort, mas annotations customizadas ainda precisam ser revisadas manualmente depois
    • É preciso migrar com precisão itens como timeout, limite de upload de arquivos e limite de body size; omissões ou mapeamentos incorretos podem quebrar silenciosamente premissas da aplicação
    • A troca de tráfego do LoadBalancer do Ingress Controller para o LoadBalancer do novo proxy Gateway deve ser planejada com cuidado, e não precisa ser um big bang
      • É possível manter temporariamente o Ingress Controller como ponto de entrada público e enviar apenas parte do tráfego para o data plane da Gateway API, testando com tráfego real antes de fazer uma transição gradual

Qual Gateway escolher

  • Depois de decidir pela migração, a primeira grande pergunta é qual implementação de Gateway API usar

  • A definição de API Gateway genérico neste artigo é: um gateway escalável para tráfego público North-South, implantado em um ambiente totalmente controlado, com padrões comuns de autenticação e rate limiting flexível oferecidos por padrão

  • Além de API Gateway, também existem LLM Gateway e Agent Gateway, mas esta seção foca no API Gateway clássico

  • Conformance da Gateway API

    • A equipe do Kubernetes preparou testes padrão de conformance para verificar se a implementação processa corretamente os protocolos centrais; o foco é principalmente no comportamento funcional, e aspectos não funcionais como confiabilidade, desempenho, escalabilidade e complexidade operacional não estão incluídos
    • Deve-se preferir implementações conformant e, se não houver resultados no site oficial, recomenda-se pedir o relatório de conformance aos mantenedores

  • Benchmarks públicos

    • Além dos testes oficiais, existem benchmarks públicos que cobrem confiabilidade e desempenho; John Howard, colaborador do Istio e funcionário da Solo.io, produziu benchmarks das principais implementações, e a Solo.io é a empresa controladora do kgateway
    • Eles incluem casos de teste úteis como route attachment, propagação, escala e desempenho no processamento de tráfego geral; como se baseiam na experiência dele, podem estar inclinados para casos específicos, mas ainda servem como uma perspectiva de avaliação

  • OSS vs Proprietário

    • Hoje há muitas implementações OSS robustas de Gateway API prontas para produção, então elas devem ser seriamente consideradas na avaliação; para muitas organizações, OSS é o ponto de partida padrão
    • Recursos como OAuth2 e OIDC, que no passado justificavam a compra de soluções comerciais, viraram commodity, e controladores OSS também os oferecem por padrão
    • Em OSS, é possível avaliar diretamente a qualidade antes de assumir um compromisso, enquanto no comercial é preciso confiar mais cedo no fornecedor

  • Recomendações

    • Agrupadas com base no data plane

      • Baseadas em Envoy Proxy: Envoy Gateway, Istio, Cilium, kgateway etc.
      • Baseadas em NGINX: NGINX Gateway Fabric, Kong
      • Outros proxies: HAProxy Ingress, Traefik

    • Envoy Gateway

      • Controlador open source de Gateway API baseado em Envoy Proxy, desenvolvido pela equipe do Envoy Proxy; ele mapeia os recursos do Envoy de forma mais direta para a Gateway API, com menos abstrações específicas de produto do que o Istio, o que facilita o entendimento
      • Não oferece suporte à Ingress API, e pode expandir recursos de gateway para LLM, gateway MCP e Inference Pools com o Envoy AI Gateway
      • É leve, simples de implantar e operar, e focado em API Gateway (North-South); recursos suportados
        • padrões de segurança como external authentication, validação de JWT, authorization baseada em claims de JWT, OIDC, IP allowlisting, autenticação com chave de API estática e credential injection
        • política flexível de global rate limit com configurações globais e por rota, shadow mode, configuração de custo de requisição etc.
        • limites de conexão, largura de banda e tamanho de arquivo, roteamento com consciência de availability zone, multicluster básico com ServiceImport, compressão de resposta com Brotli, gzip e zstd, direct response e response override
        Publicidade
      • Também tem alta extensibilidade: é possível escrever serviços gRPC para modificar requisições, respostas e configurações xDS, e criar plugins em Lua ou em linguagens compiláveis para WASM, como Go e Rust
      • Inclui um recurso customizado Backend para apontar para recursos externos por FQDN ou IP e sockets UNIX para sidecar
      • Atualmente está listado como partially conformant por causa de alguns testes ignorados, mas na prática atende quase todos os itens, além de integrar-se com projetos CNCF como KEDA e KNative
      • Se você só precisa de um API Gateway rico em funcionalidades, é uma boa opção

    • Istio

      • Service mesh baseado em Envoy Proxy e projeto CNCF Graduated, listado como conformant nos testes da Gateway API
      • É um pacote que inclui Ingress Controller, controlador de Gateway API e service mesh, e pode oferecer recursos de gateway para LLM, MCP e A2A com integração ao agentgateway
      • Oferece suporte avançado a multicluster com ferramentas como Admiral, ampla variedade de perfis de implantação, grande comunidade e vasta documentação, incluindo livros da O'Reilly; a criptografia pod-to-pod baseada em mTLS é útil em ambientes governamentais e FedRAMP
      • Como ponto negativo, no modo sidecar consome muitos recursos e tem muitos conceitos próprios, o que torna a curva de aprendizado íngreme
      • O ambient mode oferece uma configuração mais leve, mas pode não ser tão funcional quanto o sidecar em casos avançados de L7; se forem necessárias políticas mais fortes e controle L7 mais fino, vale considerar usar o Envoy Gateway junto como ingress gateway e waypoint proxy
      • É a melhor opção quando service mesh vem primeiro e a Gateway API é secundária; se você precisa apenas de um API gateway, pode parecer um pouco insuficiente

    • kgateway

      • Gateway open source em CNCF Sandbox baseado no projeto Gloo, com suporte a Envoy Proxy e agentgateway (recursos de AI gateway) como data plane, além de permitir o uso de instâncias próprias de data plane gerenciadas externamente
      • Tem conformance perfeita da Gateway API, sendo uma das raras implementações que cumprem praticamente todos os itens
      • No data plane do Envoy, expõe validação de JWT, OAuth2/OIDC, external authentication, controle de acesso por IP, Envoy global rate limiting e processamento de requisição/resposta baseado em ext_proc, embora não pareça expor plugins Lua ou WASM nem edição direta de xDS bruto
      • Com base em templates MiniJinja, oferece um poderoso mecanismo de transformação para definir declarativamente, no recurso TrafficPolicy, transformações de header, body de resposta e status
      • Pode integrar-se ao Istio como edge proxy, mas não atua como service mesh próprio; oferece suporte a rotas hierárquicas, nas quais uma Route delega o processamento de tráfego a outra Route, e possui uma CRD customizada AwsLambda para chamar diretamente o AWS Lambda
      • Apesar das alegações do fornecedor sobre ampla adoção, ainda há pouco feedback independente, e do ponto de vista da comunidade pública parece ser um projeto ainda em crescimento

  • Traefik

    • Popular reverse proxy de código aberto escrito em Go; oferece suporte tanto à Ingress API quanto à Gateway API e é especialmente popular na comunidade de homelab por sua excelente documentação, base de código organizada, configuração simples e implantação fácil

    • Suporta os recursos centrais da Gateway API e alguns recursos adicionais, mas ainda não oferece suporte a ListenerSet nem a traffic mirroring via Gateway API (o mirroring é possível com backend customizado TraefikService)

    • O modelo de extensão é baseado em middleware: conecta Routes a CRDs de Middleware por meio do filtro ExtensionRef; os middlewares nativos oferecem ForwardAuth (delegação de autenticação externa, semelhante ao ext_authz do Envoy), allowlisting de IP e CORS, limitação de conexões, retry e circuit breaker, compressão, páginas de erro personalizadas etc.

    • Com middleware de Plugin, é possível conectar plugins customizados em YAEGI e WASM (principalmente para modificar requisições e respostas), mas validação de JWT, OIDC e OAuth2 Client Credentials são oferecidos apenas como plugins pagos

    • O CRD de Middleware oferece rate limiting distribuído básico (baldes por IP, host e header), mas a configuração não é flexível, e como ele é anexado por ExtensionRef em vez de policy attachment, é difícil fazer hierarquias como aplicação global seguida de override no nível de rota

    • Não há uma separação clara entre control plane e data plane, então a arquitetura se parece mais com a do NGINX Ingress: o mesmo pod observa recursos e processa tráfego; em vez de provisionar proxies dinamicamente para cada Gateway, um único deployment gerencia todos os Gateways no namespace observado, o que pode causar problemas de resiliência em grande escala devido a ponto único de falha e menor isolamento

    • Ao escolher essa opção, recomenda-se fazer testes de carga com o tráfego esperado; como já houve relatos de insatisfação com o desempenho do Traefik, é preciso ainda mais cautela

    • NGINX Gateway Fabric

      • Implementação oficial da Gateway API da F5 baseada em NGINX (NGF), com conformance sólida; nas versões recentes, adicionou suporte à Gateway API 1.5 e a CORS e modificação de headers de requisição/resposta por meio de filtros padrão de HTTPRoute
      • Alguns recursos, como autenticação JWT e OIDC, persistência de sessão baseada em cookie e atualização de upstream sem reload do NGINX, ainda dependem do NGINX Plus, embora esses sejam requisitos comuns de API Gateway
      • Com SnippetsPolicy e SnippetsFilter customizados, é possível injetar configurações NGINX customizadas em vários níveis da config gerada, facilitando a migração sem reescrever a vasta configuração customizada já existente no NGINX Ingress
      • Oferece suporte a rate limiting com a RateLimitPolicy customizada, mas como é local rate limiting, o estado fica no data plane do NGINX; ao operar múltiplas réplicas do NGF, o limite efetivo varia conforme o número de instâncias, dificultando limites estritos por usuário
      • Como escape hatch de extensão do próprio NGINX, oferece scripting leve em JavaScript e Lua, auth_request para delegação de autenticação externa (semelhante ao ext_authz do Envoy e ao ForwardAuth do Traefik) e módulos C customizados; porém, não oferece suporte a modificação de requisição/resposta baseada em serviço externo no modelo ext_proc
      • No NGF 2.0, a arquitetura foi reformulada para separar control plane e data plane e suportar múltiplos recursos Gateway; antes disso, a arquitetura era uma grande preocupação

    • Cilium Service Mesh

      • Muitos clusters usam Cilium como CNI, e o service mesh sidecar-less baseado em eBPF inclui uma implementação de Gateway API baseada em Envoy Proxy, o que pode reduzir componentes e enxugar a stack tecnológica
      • No entanto, o foco principal está na conformance da Gateway API, e recursos úteis do Envoy fora da Gateway API não são expostos como configuração de primeira classe; por exemplo, faltam suporte de primeira classe a extensões e plugins do Envoy, allowlisting de IP, validação de JWT, autorização baseada em claims e OIDC
      • A menos que você tenha certeza de que os recursos atuais de Gateway API do Cilium são suficientes, ele não é recomendado como API Gateway de uso geral em vez de opções mais completas como Envoy Gateway, kgateway ou Istio

    • Kong

      • API Gateway popular baseado em NGINX; o Kong Operator oferece suporte tanto a Ingress quanto a Gateway API
      • A principal preocupação é a estratégia de OSS: parece ter sido interrompida a publicação de imagens Docker prebuilt para novas versões open source do Gateway, e as imagens OSS podem ter parado por volta da linha de release 3.10, o que pode exigir build, patch, hardening e manutenção por conta própria
      • Há especulações públicas de que essa medida esteja relacionada à redução da perda de clientes enterprise; isso não pode ser tratado como fato confirmado, mas a direção do OSS parece menos previsível
      • Portanto, não é recomendado a menos que você vá adquirir uma licença enterprise ou esteja preparado para assumir por conta própria o empacotamento e a manutenção do OSS

Summary

  • Acompanha a evolução dos padrões de ingress do Kubernetes desde o início até a era da Gateway API, e aborda em profundidade o próprio protocolo Gateway API
  • GAMMA (extensão das ideias da Gateway API para service mesh) e Inference Extension (definição e otimização de workloads de inferência no Kubernetes) foram intencionalmente deixados fora do escopo, por serem temas que exigem discussão aprofundada separada
  • Também analisa as implementações disponíveis da Gateway API e os critérios para escolhê-las

Leituras relacionadas

2 comentários

 
click 1 시간 전

No ano passado tentei usar o NGF, mas lembro que acabei indo de envoy porque não havia uma forma de criar autenticação baseada no cabeçalho Authorization
Prefiro nginx ao invés de envoy, então, se o suporte completo ao Gateway API chegar, acho que da próxima vez vou experimentar o NGF
 
hmmhmmhm 2 시간 전

Parece que o Envoy vai ganhar ainda mais destaque.