Adobe propone un proxy que filtra por namespace las métricas de GPU en Kubernetes
El diseño añade un proxy multi-tenant delante de Prometheus que reescribe las consultas PromQL para encerrar a cada equipo en su namespace, con instancias por tenant opcionales para reducir el ruido.
Adobe ha descrito una capa de observabilidad multi-tenant para Kubernetes que da a cada equipo acceso a sus propias métricas de Prometheus sin abrirle las de los demás. La pieza central es un proxy que reescribe las consultas PromQL antes de que lleguen al almacén compartido para forzar un filtro por namespace. El caso que empujó el trabajo es concreto: saber si las GPU que alguien ha reservado están haciendo algo.
El problema es fácil de enunciar y difícil de resolver sin romper nada. Un Prometheus central acumula series de miles de namespaces, así que abrir la consulta a todo el mundo expone datos ajenos, y dejar que cientos de desarrolladores disparen consultas contra el mismo almacén genera vecinos ruidosos y problemas de rendimiento. Pedirle a cada desarrollador que incluya el namespace correcto en su PromQL no es una frontera de seguridad, solo una convención.
Cómo queda el camino de la consulta
La petición pasa primero por NGINX y por kube-rbac-proxy para autenticación y autorización, y de ahí al proxy multi-tenant. Ese proxy identifica al tenant, descubre qué backends de Prometheus hay disponibles y limita la consulta a su namespace. El encargado de imponer la restricción es prom-label-proxy, que modifica la consulta entrante antes de que Prometheus la vea: aunque el usuario construya a propósito una consulta que apunte a otro namespace, el filtro ya está aplicado cuando llega.
Para pedir métricas hay un recurso propio de Kubernetes, MetricAccess, donde cada equipo declara lo que necesita con nombres exactos, expresiones regulares o selectores PromQL. Es autoservicio para el que consume y control para el equipo de plataforma, que sigue siendo quien decide qué se recoge y quién puede verlo.
Si un equipo quiere sus propios paneles y alertas, el diseño puede hacer remote-write periódico de un conjunto curado de series hacia un Prometheus del tenant. Con metricIsolation activado solo se recogen las series de ese tenant. En uno de los ejemplos que citan los autores, la instancia del tenant pasó de más de 10.000 series a unas 300. Además del ahorro en almacenamiento y consulta, esto levanta una segunda barrera: lo que nunca se recogió en su almacén no se puede filtrar después desde ahí.
GPU ociosas y alternativas ya existentes
El ejemplo que usan para justificar todo esto es una GPU que estuvo once días seguidos con utilización cero, asignada y encendida. Con métricas de utilización, memoria de framebuffer, consumo y tasa de peticiones, un equipo puede montar consultas para cazar GPUs ociosas, GPUs que consumen energía sin tráfico de aplicación detrás, o cargas que reciben peticiones con la GPU infrautilizada. La arquitectura no es específica de aceleradores: el patrón sirve para cualquier clúster compartido entre equipos de aplicación, cargas de datos y cargas de IA.
El problema de multi-tenencia en métricas tiene soluciones asentadas. Grafana Mimir lleva el aislamiento en su arquitectura, con identificadores de tenant para acotar consultas y una capa de autenticación que fija el contexto. Cortex, base de varios servicios gestionados compatibles con Prometheus, usa un modelo parecido con X-Scope-OrgID. La diferencia del enfoque de Adobe es que no sustituye el Prometheus compartido: lo deja donde está y le coloca alrededor control de acceso consciente de Kubernetes y filtrado por namespace.
Los autores han descrito el diseño en el blog de la CNCF, sobre tecnologías que ya existen, sin plataforma de métricas nueva. Lo que no queda claro es si publicarán el código, porque de momento lo que hay es la descripción de la arquitectura y las cifras que dan ellos mismos.
