Проблема начинается с очевидного операционного парадокса: данные об использовании GPU в среде Adobe собирались каждую секунду в централизованном Prometheus, однако команды, несущие расходы на эти устройства, не могли напрямую видеть свои метрики. По словам инженеров Bingi Narasimha Karthik и Ramkumar Nagaraj, это привело к обнаружению GPU, который 11 дней использовался на нулевом уровне: он был выделен и запущен, но оставался невидимым для ответственной за него команды.
Материал, опубликованный в блоге CNCF 9 сентября 2026 года, не представляет новый коммерческий продукт, а объясняет практический шаблон построения самостоятельного и безопасного доступа к метрикам в мультитенантных кластерах Kubernetes. Основная идея заключается в размещении перед централизованным Prometheus промежуточного слоя, учитывающего арендаторов, а затем в предоставлении каждой команде отобранного сегмента её данных с возможностью копировать эти данные в собственный Prometheus.
Почему недостаточно открыть централизованный Prometheus?
Авторы считают, что предоставление командам прав чтения на центральной точке запросов Prometheus сталкивается с двумя проблемами. Первая — безопасность: точка запросов Prometheus не учитывает пространства имён, поэтому тот, кто может выполнять запрос PromQL, теоретически способен запросить данные других команд, например показатели частоты запросов или планы ёмкости.
Вторая проблема — производительность. Центральное хранилище обслуживает метрики всего флота, и длинные или неоптимальные запросы от сотен инженеров могут расходовать ресурсы и повышать время отклика для всех. Поэтому открытие общего хранилища не решает проблему видимости, а может добавить к архитектуре риск утечки данных и проблему «шумного соседа».
Промежуточный слой с тремя функциями
Проект предлагает тонкий слой перед Prometheus, выполняющий три взаимосвязанные функции:
- Идентификация: аутентификация инициатора запроса и определение арендатора, к которому он относится.
- Изоляция: ограничение каждого запроса пространством имён арендатора с применением ограничения до передачи запроса в Prometheus, чтобы обойти его через PromQL было невозможно.
- Доставка: периодическое копирование отобранного набора метрик арендатора в его собственный Prometheus при необходимости.
В пути чтения используется Nginx для балансировки нагрузки, затем kube-rbac-proxy для аутентификации и авторизации, после чего запросы поступают к прокси, который обнаруживает серверы Prometheus через Kubernetes API и собирает результаты с исправных серверов. Путь записи использует remote write для отправки отобранных метрик в Prometheus арендатора. В высокодоступных средах данные отправляются во все реплики через DNS-имена Pods.
Изоляция начинается с идентичности и заканчивается на уровне данных
kube-rbac-proxy использует идентичность Kubernetes и RBAC для определения инициатора запроса, а затем передаёт идентичность арендатора в виде утверждения о пространстве имён. prom-label-proxy применяет изоляцию во время выполнения запроса: он переписывает запрос, добавляя селектор пространства имён перед отправкой в Prometheus. Таким образом, изоляция становится не просто политикой, рекомендованной пользователю, а ограничением, применяемым к каждому запросу.
Источник также указывает на меры усиления безопасности самого прокси: запуск от имени пользователя без root с идентификатором UID 65534, использование корневой файловой системы только для чтения, удаление всех дополнительных разрешений, запрет повышения привилегий и предоставление сервисного аккаунта с минимально необходимыми правами.
Что практически меняется в стоимости и производительности?
Изоляция не ограничивается запретом на просмотр чужих данных. Настройка metricIsolation позволяет применять фильтр пространства имён уже на этапе сбора метрик, поэтому Prometheus арендатора хранит только относящиеся к нему временные ряды. Согласно опыту авторов, количество хранимых временных рядов для типичного арендатора может снизиться примерно на 97% — с более чем 10 тысяч рядов до нескольких сотен.
Такое сокращение означает меньшее хранилище, более быстрые запросы и меньшую стоимость хранения, а также снижает вероятность утечки данных, поскольку ненужные метрики изначально не попадают в частное хранилище. Проект также уменьшает нагрузку на централизованный Prometheus: панели мониторинга и ежедневные оповещения переносятся в хранилища арендаторов вместо постоянной зависимости от общего хранилища.
Самостоятельная работа требует чётких границ
Команда определяет пользовательский ресурс Kubernetes под названием MetricAccess, который задаёт пространство имён, необходимые метрики, назначение remote write и период сбора. Арендаторы могут выбирать конкретные имена метрик, регулярные выражения или селекторы PromQL. Для целевого Prometheus необходимо включить приём remote write с помощью web.enable-remote-write-receiver, тогда как остальная инфраструктура строится на стандартных компонентах Prometheus и Kubernetes.
В материале представлены шесть полезных типов запросов, включая среднее использование GPU для каждого пространства имён, подсчёт устройств с использованием ниже 5% в течение часа, долю используемой памяти, энергопотребление, обнаружение занятых устройств без трафика запросов и наличие запросов при простаивающих GPU. Пример основан на метриках типа DCGM с предупреждением о необходимости сопоставить имена с фактически используемым экспортёром.
Опыт подтверждает, что самостоятельная работа не означает устранение ограничений. Отобранные наборы метрик и различные периоды сбора действуют как квоты, ограничивающие нагрузку, а вариант с remote write следует предоставлять командам, у которых действительно есть панели мониторинга и оповещения; небольшим командам может быть достаточно ограниченного доступа во время выполнения запросов.
Комментарий certi.news
Важное изменение здесь заключается не в добавлении ещё одного инструмента мониторинга, а в передаче контроля над видимостью от одной команды платформы арендатору при сохранении изоляции под контролем инфраструктуры. Это одновременно решает проблему безопасности, стоимости и производительности. Однако решение не является автоматическим: выбор метрик, настройка cardinality, обработка повторных попыток, запись во множество высокодоступных реплик и фиксация версий экспортёров остаются постоянными операционными обязанностями.
Кроме того, приведённые числовые результаты, включая сокращение числа временных рядов примерно на 97%, относятся к опыту авторов и «типичному арендатору», а не являются общей гарантией для каждого кластера. Поэтому перед широким внедрением этот шаблон следует протестировать с именами метрик, объёмом временных рядов и периодами сбора, характерными для каждой среды. Проект доступен по лицензии Apache 2.0, а материал содержит ссылку на репозиторий prometheus-multi-tenant-proxy на GitHub.