À medida que empresas brasileiras escalam suas iniciativas de Inteligência Artificial, os times de infraestrutura e plataforma enfrentam um desafio crescente: como oferecer acesso fluido aos serviços de AI sem que uma única aplicação consuma, inadvertidamente, todo o orçamento ou a cota de tokens disponível?
A natureza dos serviços de IA frequentemente centraliza a autenticação via chaves de API compartilhadas. Em ambientes Kubernetes, isso cria um ponto único de falha e uma visibilidade distorcida de quem está, de fato, gerando custos. O uso do Azure Kubernetes Application Network (AppNet), em conjunto com o agente agentgateway, permite evoluir dessa gestão passiva para uma governança ativa e transparente no nível de rede.
O desafio do modelo de cotas compartilhadas
O workflow padrão de inferência de IA geralmente segue este caminho:
- Configuração de uma conta no provedor de IA.
- Distribuição de uma Service Account ou API Key global.
- Aplicações consumindo o serviço via shared quota.
Quando a cota é atingida, o erro 403: Insufficient Quota afeta toda a plataforma. Identificar qual serviço foi o responsável por esse estouro é uma tarefa complexa que consome latência operacional, gerando o chamado "noisy neighbor effect", onde uma aplicação mal configurada impacta o SLA de todo o ecossistema.
Por que o gerenciamento manual de chaves não escala
A estratégia de mitigar isso via API keys individuais é frequentemente ineficiente. Ela exige que o time de DevOps gerencie o ciclo de vida (provisionamento, rotação e governança de segredos) para cada nova micro-serviço. Isso transforma a camada de plataforma em um gargalo, contrariando a agilidade proposta pelo Kubernetes.
Uma abordagem orientada à plataforma com AppNet
O diferencial desta solução é mover a política de rate limiting da camada de aplicação para a camada de rede, utilizando Identity em vez de Secrets. O Azure Kubernetes Application Network (que utiliza os princípios do Istio Ambient Mode) estabelece mtls automaticamente entre as workloads.
Ao configurar o agentgateway para interceptar esse tráfego e realizar o rate limiting (Token Rate Limiting) baseado na identidade da workload (obtida via mTLS), eliminamos a necessidade de expor chaves aos pods. Veja os componentes principais para essa implementação:
1. Configuração do agentgateway:
apiVersion: agentgateway.dev/v1alpha1
kind: AgentgatewayParameters
metadata:
name: agentgateway
spec:
deployment:
spec:
template:
metadata:
labels:
istio.io/dataplane-mode: none
networking.istio.io/tunnel: http
istio: {}
rawConfig:
binds:
- listeners:
port: 15008
tunnelProtocol: hboneGateway
2. Definindo a política de rate limit:
apiVersion: agentgateway.dev/v1alpha1
kind: AgentgatewayPolicy
metadata:
name: minute-token-budget
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: Gateway
name: gateway
traffic:
rateLimit:
global:
backendRef:
group: ""
kind: Service
name: ratelimit
namespace: ratelimit
port: 8081
descriptors:
- entries:
- expression: source.identity.namespace
name: client_ns
unit: Tokens
domain: token-budgets
Esta configuração permite que, após atingir a cota (ex: 100 tokens), o agentgateway bloqueie apenas a aplicação excedente com um 429 Too Many Requests, mantendo a estabilidade total das demais instâncias no cluster.
Conclusão e visão estratégica
Esta arquitetura é um exemplo prático de como aplicar princípios de FinOps e SecOps na ponta, sem adicionar complexidade ao código das aplicações. Para empresas brasileiras, a transição para métodos de autenticação baseados em identidade, em vez de chaves estáticas, não é apenas uma boa prática de segurança — é uma necessidade de eficiência operacional.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
