El problema parte de una paradoja operativa clara: los datos de uso de las unidades GPU en el entorno de Adobe se recopilaban cada segundo en un Prometheus centralizado, pero los equipos que asumían el coste de esas unidades no podían consultar directamente sus métricas. Según los ingenieros Bingi Narasimha Karthik y Ramkumar Nagaraj, esto llevó a descubrir una unidad GPU que permaneció con un uso del cero por ciento durante 11 días; estaba asignada y en ejecución, pero era invisible para el equipo responsable de ella.
El material publicado en el blog de CNCF el 9 de septiembre de 2026 no presenta un nuevo producto comercial, sino que explica un patrón práctico para crear acceso autoservicio y seguro a las métricas en clústeres de Kubernetes multiinquilino. La idea central consiste en colocar una capa intermediaria consciente del inquilino delante del Prometheus centralizado y, después, conceder a cada equipo una selección de sus datos, con la opción de copiar esos datos a su propio Prometheus.
¿Por qué no basta con abrir el Prometheus centralizado?
Los autores consideran que conceder a los equipos permisos de lectura en el punto de consulta del Prometheus centralizado plantea dos problemas. El primero es de seguridad: el punto de consulta de Prometheus no es consciente de los espacios de nombres, y quien pueda ejecutar una consulta PromQL podría, en teoría, solicitar datos de otros equipos, como tasas de solicitudes o planes de capacidad.
El segundo problema es el rendimiento. El almacén central sirve las métricas de toda la flota, y las consultas largas o mal planteadas de cientos de ingenieros podrían consumir recursos y aumentar la latencia para todos. Por tanto, abrir el almacén compartido no resuelve el problema de visibilidad; puede añadir a la misma arquitectura el riesgo de filtración de datos y el problema del vecino ruidoso.
Una capa intermediaria con tres responsabilidades
El diseño propone una capa ligera delante de Prometheus que desempeña tres funciones relacionadas:
- Identificación: autenticar al solicitante y saber a qué inquilino pertenece.
- Aislamiento: limitar cada consulta al espacio de nombres del inquilino, aplicando la restricción antes de que la consulta llegue a Prometheus para que no pueda eludirse mediante PromQL.
- Entrega: copiar periódicamente un conjunto seleccionado de métricas del inquilino a su Prometheus privado cuando sea necesario.
La ruta de lectura utiliza Nginx para equilibrar la carga, después kube-rbac-proxy para la autenticación y autorización, y finalmente las solicitudes llegan al proxy, que descubre los servidores Prometheus mediante la API de Kubernetes y recopila los resultados de los servidores saludables. La ruta de escritura utiliza remote write para enviar las métricas seleccionadas al Prometheus del inquilino. En entornos de alta disponibilidad, los datos se envían a todas las réplicas mediante los nombres DNS de los Pods.
El aislamiento comienza con la identidad y termina en los datos
kube-rbac-proxy utiliza la identidad de Kubernetes y RBAC para determinar quién realiza la solicitud y después transmite la identidad del inquilino como una afirmación del espacio de nombres. prom-label-proxy aplica el aislamiento durante la consulta: reescribe la solicitud para añadir un selector del espacio de nombres antes de enviarla a Prometheus. De este modo, el aislamiento no es simplemente una política recomendada para el usuario, sino una restricción aplicada a cada consulta.
La fuente también señala medidas de refuerzo para el propio proxy, como ejecutarlo como un usuario no root con el identificador UID 65534, utilizar un sistema de archivos raíz de solo lectura, eliminar todos los permisos adicionales, impedir la escalada de privilegios y asignarle una cuenta de servicio con los permisos mínimos posibles.
¿Qué cambia en la práctica en cuanto a coste y rendimiento?
El aislamiento no se limita a impedir la visibilidad de los datos de otros. La configuración metricIsolation permite aplicar el filtro del espacio de nombres desde la fase de recopilación de métricas, de modo que el Prometheus del inquilino solo almacene las series que le corresponden. Según la experiencia de los autores, el número de series almacenadas de un inquilino típico puede disminuir alrededor de un 97 %, pasando de más de 10.000 series a unos pocos cientos.
Esta reducción implica un almacén más pequeño, consultas más rápidas y un menor coste de almacenamiento; también reduce la probabilidad de filtración de datos, porque las métricas no solicitadas ni siquiera llegan al almacén privado. El diseño también reduce la presión sobre el Prometheus centralizado, ya que los paneles y las alertas diarias pasan a los almacenes de los inquilinos en lugar de depender continuamente del almacén compartido.
El autoservicio necesita límites claros
El equipo define un recurso personalizado de Kubernetes llamado MetricAccess, que especifica el espacio de nombres, las métricas solicitadas, el destino de remote write y el periodo de recopilación. Los inquilinos pueden elegir nombres de métricas concretos, expresiones regulares o selectores PromQL. El Prometheus de destino debe activar la recepción de remote write mediante web.enable-remote-write-receiver, mientras que el resto de la arquitectura se basa en los componentes habituales de Prometheus y Kubernetes.
El material presenta seis tipos de consultas útiles, entre ellas el uso medio de GPU por espacio de nombres, el recuento de unidades cuyo uso sea inferior al 5 % durante una hora, el porcentaje de memoria utilizada, el consumo de energía, la detección de unidades ocupadas sin movimiento de solicitudes y la existencia de solicitudes mientras las unidades GPU permanecen inactivas. El ejemplo se basa en métricas del tipo DCGM, con la advertencia de que los nombres deben adaptarse al exportador utilizado realmente.
La experiencia confirma que el autoservicio no significa eliminar las barreras. Los conjuntos seleccionados de métricas y los distintos periodos de recopilación funcionan como cuotas que limitan la carga. Además, la opción de remote write debería reservarse para los equipos que realmente tengan paneles y alertas, mientras que para los equipos pequeños puede bastar con un acceso restringido durante la consulta.
Lectura de certi.news
El cambio importante no consiste en añadir otra herramienta de monitorización, sino en transferir el control de la visibilidad del equipo de plataforma al inquilino, manteniendo el aislamiento bajo el control de la infraestructura. Esto aborda simultáneamente un problema de seguridad, uno de coste y otro de rendimiento. Sin embargo, la solución no es automática: la selección de métricas, el ajuste de la cardinalidad, la gestión de los reintentos, la escritura en réplicas de alta disponibilidad y la fijación de las versiones de los exportadores son responsabilidades operativas continuas.
Asimismo, los resultados numéricos mencionados, incluida la reducción de las series de alrededor del 97 %, corresponden a la experiencia de los autores y a un «inquilino típico», y no constituyen una garantía general para todos los clústeres. Por ello, conviene probar el patrón con los nombres de métricas, el tamaño de las series y los periodos de recopilación propios de cada entorno antes de adoptarlo a gran escala. El proyecto está disponible bajo Apache 2.0, y el material incluye un enlace al repositorio prometheus-multi-tenant-proxy en GitHub.