Equipes de Kubernetes agora têm um jeito mais seguro de acessar as próprias métricas de GPU sem expor dados de outros times. A Adobe divulgou uma abordagem de código aberto que permite acesso em self-service ao Prometheus em ambientes multi-tenant, mantendo isolamento total entre os usuários.
O problema é bem conhecido em infraestruturas compartilhadas: quando vários times usam o mesmo cluster de Kubernetes, todos conseguem ver todas as métricas — inclusive as de times concorrentes ou sensíveis. Isso cria um risco de segurança e vazamento de informações. A solução dos engenheiros da Adobe resolve isso controlando o acesso granular ao Prometheus, deixando cada time enxergar só suas próprias GPUs.
Como o Kubernetes e Prometheus se relacionam
O Kubernetes orquestra contêineres, mas não mostra sozinho o quanto de GPU cada workload está consumindo. Para isso, a maioria das equipes usa o Prometheus como sistema de coleta e armazenamento de métricas. No entanto, em um cluster compartilhado, o Prometheus fica exposto a todos — todos têm acesso às mesmas séries de dados.
A Adobe propôs usar Prometheus com autenticação e autorização granular. Cada time recebe credenciais que funcionam só para seus próprios namespaces e labels. Dessa forma, a query “container_gpu_memory_used” de um time retorna apenas os pods daquele time, nunca de outros.
A arquitetura aberta da solução
A abordagem usa um proxy ou gateway entre o cliente Prometheus e o servidor central. Esse intermediário intercepta cada requisição, valida a identidade do time, e reescreve a query para incluir automaticamente filtros de isolamento.
Os engenheiros da Adobe disponibilizaram o código no GitHub. Não é uma ferramenta pronta para plugar, mas sim um padrão que outros podem adaptar. Entre os principais componentes:
- Autenticação: credenciais por time ou namespace
- Reescrita de queries: filtros automáticos adicionados ao Prometheus PromQL
- Auditoria: logs de quem consultou quais métricas e quando
- Cache: para não sobrecarregar o servidor central com queries idênticas
Como o PratiqueTech já mostrou em análises anteriores, esse tipo de isolamento é crítico em ambientes corporativos onde times pagam por uso de recursos.
Por que isso importa na prática
Sem um controle assim, qualquer engenheiro com acesso ao cluster conseguia descobrir:
- Quanto de GPU está sendo usado por um projeto concorrente interno
- Se um serviço crítico está falhando ou em degradação
- Quais experimentos de IA estão rodando em qual equipe
- Padrões de uso que revelam roadmap ou produto em segredo
Com a solução da Adobe, o acesso fica blindado. Um time não enxerga nada além do seu próprio consumo. Além disso, a auditoria deixa registrado quem consultou o quê — um requisito comum em empresas grandes e em setores regulados.
Na prática, Kubernetes já oferecia isolamento de namespace para pods. Mas as métricas viviam soltas — era uma falha de segurança bem conhecida que faltava documentação ou ferramentas prontas para tampar.
Quando essa abordagem vale a pena
Se sua empresa tem:
- Múltiplos times rodando no mesmo cluster de Kubernetes
- GPUs compartilhadas (muito comum em ambientes de IA e ciência de dados)
- Preocupação com confidencialidade de métricas
- Necessidade de rastreabilidade e auditoria
…então implementar esse padrão faz sentido. O esforço é mediano — você precisa entender PromQL e ter experiência com Kubernetes, mas não é complexo.
Se sua equipe usa um cluster pequeno com 2 ou 3 times muito próximos e com confiança total um no outro, pode não justificar a complexidade extra agora. Mas à medida que o cluster cresce, essa abordagem vai ficar obrigatória.
Alternativas e trade-offs
A Adobe não inventou isolamento de métricas, mas padronizou um jeito aberto de fazer. Outras opções:
| Abordagem | Vantagem | Desvantagem | |———–|———-|————| | Prometheus separado por time | Isolamento perfeito | Custo alto, operação cara | | Proxy com reescrita (Adobe) | Barato, auditável | Precisa manutenção e conhecimento | | Solução comercial (Datadog, New Relic) | Suporte profissional | Caro, vendor lock-in | | Nenhuma (tudo aberto) | Simples inicialmente | Risco alto, insustentável |
Para a maioria das empresas, a solução da Adobe é o meio termo melhor custo-benefício.
Perguntas frequentes
Qual é a performance dessa solução? A reescrita de queries cria latência?
O overhead é mínimo — microssegundos por requisição. O gargalo real continua sendo o Prometheus respondendo a query, não o proxy. O cache ajuda bastante em padrões de acesso repetidos.
Preciso de uma ferramenta específica ou posso implementar isso sozinho?
Você pode implementar do zero com Go ou Python, ou adaptar o código aberto que a Adobe compartilhou. Não é exigido comprar nada, mas exige engenheiro dedicado.
Isso funciona com Prometheus remoto (Thanos, Cortex)?
Sim, a solução funciona independente de onde o Prometheus vive — local, remoto ou gerenciado em cloud.
Se você gerencia um cluster Kubernetes com múltiplas equipes e GPUs, considere usar o calculadora de subrede para planejar a segmentação de rede que vai acompanhar esse isolamento de métricas — é comum que isolamento em network policy ande junto com isolamento em observabilidade.
