Биллинг и управление расходами

Назначение

Функциональность Биллинг и управление расходами отвечает на вопрос «сколько стоит использование инфраструктуры» и позволяет представить эту стоимость в виде, удобном для финансовой службы, руководителей подразделений и владельцев проектов.

Commander собирает фактические данные о потреблении ресурсов (CPU, память, хранилище) со всех управляемых кластеров, применяет к ним заданные администратором тарифы и показывает результат в трёх формах:

• интерактивный дашборд с разбивкой по рабочим пространствам, кластерам, проектам, неймспейсам, контроллерам, видам ресурсов и типам оборудования;
• отчёты — мгновенные (по запросу) и регулярные (по расписанию), с выгрузкой в CSV;
• единый список тарифов и тарифицируемых ресурсов с предупреждениями о непривязанных ресурсах и расхождениях с фактическим потреблением.

По умолчанию функциональность выключена. Порядок включения — в руководстве администратора.

Основные понятия

В биллинге участвуют три сущности: кластеры с вычислительными ресурсами, тарифы с ценами за эти ресурсы и тарифицируемые ресурсы, которые связывают первые со вторыми.

Тарифицируемый ресурс — связующее звено: с одной стороны он привязан к тарифу (это даёт цену), с другой — к кластеру (это даёт поток данных о потреблении). Как только связь установлена, Deckhouse Commander автоматически помечает узлы кластера служебными метками и начинает получать метрики. Дашборд и отчёты берут эти метрики, умножают на цены из тарифа и показывают стоимость.

Привязка к кластеру в большинстве случаев происходит автоматически — при подключении облачного кластера Deckhouse Commander сам создаёт классы и связывает их с группами узлов. Для статических кластеров привязку нужно выполнить вручную.

Для классов хранилища привязка работает строго по имени: если в кластере есть Kubernetes StorageClass с именем network-ssd, он автоматически сопоставляется с одноимённым классом хранилища в биллинге. Ручное переопределение привязки для классов хранилища пока не поддерживается. В действующем тарифе может быть несколько классов хранилища с разными ценами, однако цена задаётся на имя класса глобально: нельзя назначить разную стоимость для network-ssd в кластере на одной площадке и network-ssd в кластере на другой.

Подробнее о каждом термине:

• Тариф — прайс-лист: какие типы вычислительных ресурсов и хранилища сколько стоят за единицу в час. В один момент времени действует один тариф. Старые тарифы остаются в истории, чтобы не пересчитывать прошлые периоды.
• Вычислительный класс — именованный тип вычислительных ресурсов с собственной ценой. Аналог «размера виртуальной машины» в каталоге облачного провайдера: один класс объединяет узлы с одинаковыми характеристиками, для которых логично задать единую стоимость CPU и памяти. Примеры имён: standard-v3-cf-100, m1.large, c4-16gb.
• Класс хранилища — именованный тип хранилища с собственной ценой за гигабайт. Совпадает по имени с классом хранилища Kubernetes (StorageClass), через который в кластере создаются тома. Примеры: network-ssd, linstor-thin-r2, ceph-block-gold.
• Тарифицируемый ресурс — ресурс, для которого заданы цена в тарифе и фактические данные о потреблении. В текущем релизе это вычислительные классы и классы хранилища; в будущих релизах перечень может расшириться.
• Агент (commander-agent) — компонент, который устанавливается в каждый управляемый кластер и связывает его с Deckhouse Commander. Для биллинга агент выполняет две задачи: сообщает Deckhouse Commander данные о группах узлов и классах хранилища этого кластера, а также добавляет на узлы служебную метку, по которой Deckhouse Commander определяет, к какому вычислительному классу относится каждый узел.

Как Commander считает расходы

Механизм расчёта намеренно сделан прозрачным и опирается на уже привычную для Kubernetes-администратора связку с Prometheus:

1. В каждом управляемом кластере должен быть включён и работать штатный модуль prometheus Deckhouse — в Deckhouse Kubernetes Platform он включён по умолчанию. Prometheus собирает метрики потребления ресурсов (CPU, память, хранилище) — это стандартные данные, доступные в любом кластере с этим модулем.
2. На каждый узел автоматически добавляется служебный лейбл billing.commander.deckhouse.io/name со значением имени вычислительного класса. То же имя используется в действующем тарифе как ключ для поиска цены.
3. Для хранилища ключом выступает имя класса хранилища Kubernetes — оно уже присутствует в метриках по умолчанию.
4. Метрики потребления передаются из Prometheus управляемого кластера в Prometheus управляющего кластера с помощью механизма PrometheusRemoteWrite. Отдельная настройка не требуется: при включении биллинга Commander сам создаёт нужный PrometheusRemoteWrite в прикладном кластере. Commander умножает полученные метрики на цены из действующего тарифа и строит ряды стоимости по времени.
5. Эти ряды используются дашбордом и отчётами: любая выборка сводится к сумме стоимости по выбранным срезам.

Никакие решения о цене не принимаются в момент построения отчёта — цена берётся из того тарифа, который действовал на каждый конкретный час периода.

Включение и предварительные шаги

Шаги, которые обычно выполняются один раз при запуске функциональности:

1. Администратор включает биллинг в настройках модуля Commander.
2. Агент (commander-agent), уже работающий в каждом управляемом кластере, начинает дополнительно передавать в Deckhouse Commander информацию о группах узлов и классах хранилища. Одновременно Deckhouse Commander создаёт в управляемом кластере ресурс PrometheusRemoteWrite, направленный на Prometheus управляющего кластера, — через него поступают метрики потребления. Никаких ручных действий с конфигурацией Prometheus в прикладных кластерах не требуется.
3. Для облачных кластеров Commander автоматически создаёт вычислительные классы и классы хранилища на основе полученных данных.
4. Для статических кластеров классы хранилища также создаются автоматически. Вычислительные классы в статическом кластере администратор создаёт самостоятельно либо заранее указывает в шаблоне группы узлов лейбл billing.commander.deckhouse.io/name: <имя-класса> — тогда Commander предложит создать соответствующий класс, как только увидит этот лейбл на появившихся узлах.
5. Администратор создаёт тариф и задаёт цены для появившихся вычислительных классов и классов хранилища.

После этого дашборд и отчёты начинают показывать стоимость с момента начала действия тарифа.

Управление доступом

Доступ к функциональности настраивается в разделе «Пользователи и права». Биллинг разделён на четыре независимых ресурса, каждый из которых можно выдать отдельной роли:

• billingdashboard — доступ к дашборду и аналитике.
• billingtariffs — управление тарифами (вкладка «Тарифы» в разделе «Тарификация»).
• billingresources — управление вычислительными классами, классами хранилища и их назначениями на ресурсы кластеров (вкладки «Вычислительные классы» и «Классы хранилища»).
• billingreports — управление отчётами.

В боковом меню отображаются только те разделы, к которым у пользователя есть доступ.

Вычислительные классы и классы хранилища

Зачем нужны классы

Для облачных кластеров вычислительные классы и классы хранилища создаются и привязываются автоматически — Deckhouse Commander определяет типы инстансов и классы хранилища по данным от агента. Ручная настройка не требуется, однако при необходимости можно скорректировать автоматически созданные классы и их привязки.

Для статических кластеров автоматическое определение вычислительных классов невозможно (нет метаданных облачного инстанса), поэтому их нужно создать и привязать вручную. Классы хранилища при этом всё равно определяются автоматически.

В предыдущих версиях администратор должен был вручную прописывать метку billing.commander.deckhouse.io/name на каждую группу узлов в каждом кластере — и в облачных, и в статических. Классы убирают эту ручную работу для облачных кластеров:

• Commander сам формирует имена классов из параметров облачного инстанса (или получает их из шаблона группы узлов), сам добавляет соответствующий лейбл на узлы через агента и сам поддерживает его при пересоздании узлов. Правка манифестов кластеров больше не нужна.
• У класса два атрибута: технический идентификатор и понятное имя. Идентификатор используется как значение лейбла billing.commander.deckhouse.io/name на узлах и как ссылка на класс из тарифа, поэтому он должен соответствовать требованиям Kubernetes к значению лейбла. Понятное имя отображается в интерфейсе и отчётах, его можно свободно редактировать, не меняя идентификатор: например, для идентификатора standard-v3-cf-100 задать имя «Стандартный (2 vCPU, 4 ГиБ)».
• Класс — единая сущность, видимая в разделе биллинга: идентификатор, имя, описание, список кластеров, где он используется. Можно открыть класс и увидеть, какие группы узлов ему соответствуют.
• Один класс может использоваться сразу в нескольких кластерах (например, одинаковая конфигурация узлов в трёх кластерах одной площадки) и в нескольких тарифах.
• Цена задаётся один раз в тарифе на идентификатор класса.

Откуда берутся классы

В большинстве случаев классы создаются автоматически:

• Облачные кластеры. Как только в кластере появляется группа узлов с облачным типом (CloudEphemeral, CloudPermanent), Commander получает от агента описание используемого InstanceClass, вычисляет по нему имя вычислительного класса по правилам провайдера и создаёт класс, если такого ещё нет. Сразу после создания облачного кластера пользователь видит в разделе «Тарификация» полный набор классов, которыми пользуется этот кластер.
• Классы хранилища создаются автоматически во всех кластерах — и в облачных, и в статических. Как только агент сообщает Commander, что в кластере появился класс хранилища Kubernetes с именем, для которого ещё нет биллингового класса хранилища, Commander создаёт его автоматически.

Для статических кластеров вычислительные классы автоматически не появляются (агент не может вывести их из конфигурации оборудования). У пользователя есть два способа:

• Создать вычислительные классы вручную в разделе «Тарификация → Вычислительные классы».
• Заранее указать в шаблоне группы узлов лейбл billing.commander.deckhouse.io/name: <имя-класса>. Когда агент увидит этот лейбл на появившихся узлах, Commander предложит создать соответствующий вычислительный класс — принять предложение можно в один клик.

Автоматически сгенерированные имена классов

Имя вычислительного класса не случайное — оно формируется из характеристик инстанса, которые влияют на цену. Так администратор сразу видит, о каком типе ресурса идёт речь, а Commander гарантирует, что узлы с одинаковой конфигурацией попадут в один класс.

Если созданное автоматически имя не устраивает, его можно изменить в момент принятия предложения Commander. После того как класс уже связан с кластером, имя становится защищённым от редактирования — оно используется как ключ в метриках Prometheus, и переименование разорвёт связь с историческими данными о потреблении.

Приоритет ручных назначений

Если администратор вручную изменил соответствие «группа узлов ↔ класс» (например, решил перевести одну группу узлов из класса standard-v3-cf-100 в отдельный класс gpu-enabled), автоматическое сопоставление не вернёт назначение обратно. Ручные назначения всегда имеют приоритет над автоматическими.

Раздел «Тарификация»

Раздел «Тарификация» в боковом меню содержит три вкладки:

• Вычислительные классы — список классов, действия создания, редактирования и удаления, переход на детальную страницу класса.
• Классы хранилища — список классов, действия создания, редактирования и удаления, детальная страница класса в режиме просмотра.
• Тарифы — список тарифов, создание и редактирование тарифов.

Если на какой-то из вкладок есть расхождение (группы узлов без класса, метрики в Prometheus без соответствующего класса, ресурсы без цены в тарифе и т.п.), на заголовке вкладки появляется оранжевый индикатор, а внутри — предупреждение с описанием проблемы и подсказками по её устранению.

Вычислительные классы

На вкладке отображается таблица: имя класса, описание и перечень кластеров, где класс используется. По имени класса открывается детальная страница со списком групп узлов во всех связанных кластерах. Там же можно:

• вручную назначить класс на дополнительную группу узлов (например, в статическом кластере);
• снять назначение, если класс был выставлен автоматически, но не подходит для этого конкретного кластера;
• увидеть, какие назначения выставлены вручную (имеют приоритет), а какие — автоматически.

На этой же вкладке отображаются предложения Commander:

• «Создать вычислительный класс для такой-то группы узлов» — если Commander увидел в кластере тип инстанса, для которого класс ещё не создан;
• «Класс для лейбла из Prometheus» — если в исторических метриках есть значения лейбла billing.commander.deckhouse.io/name, которым сейчас не соответствует ни один класс (типичная ситуация после миграции с предыдущих версий).

Принятие предложения создаёт класс автоматически; при желании перед принятием можно изменить сгенерированное имя.

Классы хранилища

Устройство вкладки аналогично. Отличие одно: назначение классов хранилища на кластеры происходит полностью автоматически по совпадению имён с классами хранилища Kubernetes. Детальная страница класса хранилища в этой версии Commander работает в режиме просмотра: список кластеров, где найден класс хранилища Kubernetes с таким именем, обновляется сам. Ручное назначение для классов хранилища не предусмотрено.

Это техническое ограничение текущего релиза: метрики потребления хранилища привязаны к имени класса хранилища Kubernetes, а способа пометить сам StorageClass произвольным лейблом (по аналогии с лейблом billing.commander.deckhouse.io/name на узлах) пока нет. Поэтому, если нужно выделить отдельный прайс для конкретного кластера, создайте в этом кластере класс хранилища Kubernetes с отдельным именем — он автоматически появится в биллинге как отдельный класс.

Тарифы

На вкладке отображается список тарифов: имя, модель расчёта, дата начала действия, статус. По кнопке Создать тариф открывается форма, в которой:

• в блоке «Вычислительные ресурсы» добавляются строки вида «вычислительный класс + цена CPU + цена памяти» — класс выбирается из выпадающего списка уже существующих классов;
• в блоке «Хранилище» добавляются строки вида «класс хранилища + цена за гигабайт» — аналогично, класс выбирается из списка;
• задаются модель расчёта, модель агрегации и дата начала действия тарифа.

Если какие-то вычислительные классы или классы хранилища существуют в системе, но не упомянуты в текущем тарифе, на вкладке отображается предупреждение, чтобы администратор не забыл задать для них цену.

Создание тарифа

Создание тарифа сводится к одному большому решению — «какую цену считать справедливой» — и нескольким механическим шагам. Примеры ниже иллюстрируют типичные ситуации.

Общие шаги

1. Откройте Тарификация → Тарифы и нажмите Создать тариф.
2. Введите имя тарифа (например, «Yandex Cloud — 2026» или «Внутренний прайс R&D, I квартал»).
3. Выберите модель расчёта и модель агрегации.
4. Задайте дату начала действия тарифа (по умолчанию — сегодня).
5. В блоке Вычислительные ресурсы последовательно добавьте все вычислительные классы и для каждого укажите стоимость CPU и памяти.
6. В блоке Хранилище добавьте классы хранилища и стоимость за гигабайт.
7. Сохраните тариф.

Дашборд и отчёты начнут использовать тариф с даты начала действия; задним числом можно как вводить, так и отменять тарифы.

Пример: Yandex Cloud (или другой публичный провайдер)

Цены берутся из прайс-листа провайдера и делятся на час.

Ставки приведены условно; для публичного облака их удобно поддерживать в такт с официальным прайс-листом провайдера.

Пример: частное облако (vSphere, OpenStack)

В частном облаке «цены» у внешнего поставщика нет — инфраструктурой владеет сама организация. Типовой подход: составить внутренний прайс-лист (chargeback), основанный на:

• амортизации серверов и систем хранения за ожидаемый срок эксплуатации (обычно 3–5 лет);
• стоимости электроэнергии, охлаждения и размещения в ЦОД;
• стоимости лицензий гипервизора, СХД и сопутствующего ПО;
• ставках труда команды эксплуатации (пропорционально);
• коэффициенте на простой и резерв.

Полученная стоимость часа CPU и гигабайта памяти фиксируется в тарифе, который прикладывается к классам частного облака так же, как к публичному.

Пример (OpenStack):

Пример (vSphere, имена классов формируются как {cpu}c-{memory}m):

Для частного облака ставки в тарифе не обязаны совпадать с рыночными. Важно, чтобы сумма по тарифу за период отражала те средства, которые организация рассчитывает перевыставить подразделениям-потребителям.

Для хранилища частного облака в тариф обычно заносятся:

• отдельно — «быстрое» хранилище (NVMe, SSD) с более высокой ставкой;
• отдельно — «массовое» хранилище (HDD, object storage) с более низкой ставкой;
• при необходимости — отдельная ставка за реплицированные или зашифрованные классы.

Если оборудование формально принадлежит другому юридическому лицу (материнской компании, сервисной компании группы), роль тарифа — зафиксировать трансфертную цену: она согласуется с финансовой службой и не обязана совпадать ни с рыночной, ни с внутренней себестоимостью.

Пример: статический кластер (bare-metal)

Для статического кластера Commander сам вычислительные классы не создаёт. Порядок действий:

1. В Тарификация → Вычислительные классы создайте классы, отражающие реальные типы узлов (например, bm-cpu-2x32, bm-gpu-a100).
2. Дополнительно можно в шаблоне группы узлов указать лейбл billing.commander.deckhouse.io/name с тем же именем класса — тогда Commander автоматически привяжет класс к группе узлов при появлении узлов в кластере.
3. Перейдите на детальную страницу класса и вручную назначьте его на соответствующие группы узлов кластера.
4. Для классов хранилища никаких действий не требуется — они создаются автоматически по именам классов хранилища Kubernetes.
5. Создайте тариф и задайте цены.

Методика ценообразования в статическом кластере, как правило, такая же, как в частном облаке: амортизация оборудования, электроэнергия, лицензии, обслуживание — разделённые на прогнозируемый совокупный объём потребления.

Модели расчёта и агрегации

Модель расчёта определяет, какое значение потребления умножается на цену:

• По запросам (requests) — учитываются значения resources.requests, указанные в подах. Подходит, если организации важнее планируемая нагрузка, чем фактическая. Условие корректного расчёта: во всех подах, стоимость которых должна попасть в отчёт, должны быть указаны resources.requests для CPU и памяти. Поды без requests в этой модели учитываются как нулевое потребление, и их ресурсы не тарифицируются.
• По реальному использованию — учитывается фактическое потребление CPU и памяти подами. Ближе к модели публичного облака; наличие requests для расчёта не требуется.

Модель агрегации определяет, как часовое значение потребления получается из более частых измерений:

• По среднему — среднее за час;
• 95-й процентиль — агрегация «по пиковой загрузке», сглаживающая редкие выбросы.

Минимальная единица тарификации — один час.

Раздел «Дашборд»

Дашборд предназначен для анализа расходов в реальном времени.

Доступные срезы и фильтры:

• рабочее пространство;
• кластер;
• проект (для рабочих пространств с включёнными проектами);
• неймспейс;
• контроллер (Deployment, StatefulSet, DaemonSet и т.п.);
• вид ресурса — CPU, память, хранилище;
• вычислительный класс;
• класс хранилища.

Для выбранного фильтра дашборд показывает графики и таблицы стоимости с группировкой по дням, неделям или месяцам, а также итоговую сумму за период. Значения всех фильтров формируются только из ресурсов, к которым у текущего пользователя есть доступ.

Раздел «Отчёты»

Раздел используется для генерации аналитических отчётов по запросу и по расписанию.

Основные элементы:

• вкладка Все отчёты — список уже сформированных отчётов, доступных для скачивания;
• вкладка Управление регулярными отчётами — список расписаний, по которым формируются периодические отчёты.

Создание мгновенного отчёта

1. Нажмите Создать.
2. Укажите имя отчёта.
3. Выберите тип Мгновенный.
4. Укажите период.
5. Выберите вложенные колонки для детализации (например: рабочее пространство, проект, кластер, неймспейс).
6. Для разделения стоимости по типу ресурса включите Детализировать по ресурсам.
7. Нажмите Сохранить. Отчёт появится в списке и начнёт формироваться.
8. Готовый отчёт доступен для скачивания в формате CSV (разделитель — запятая, первая строка содержит имена колонок).

Создание регулярного отчёта

1. Нажмите Создать.
2. Укажите имя отчёта.
3. Выберите тип Регулярный.
4. Задайте дату начала и периодичность.
5. Выберите колонки для детализации и при необходимости включите Детализировать по ресурсам.
6. Нажмите Сохранить. Расписание появится на вкладке Управление регулярными отчётами.

Отчёты формируются автоматически по расписанию и попадают на вкладку Все отчёты.

Миграция с предыдущих версий

Если биллинг в вашей установке настраивался до появления вычислительных классов и классов хранилища как отдельных сущностей (например, вы вручную добавляли метку billing.commander.deckhouse.io/name на группы узлов и задавали имена в тарифе), после обновления ничего не ломается — биллинг продолжает работать без перерыва. Никаких действий не требуется. Исторические данные дашборда и отчётов сохраняются полностью.

Что происходит автоматически

1. Миграция данных: для каждого имени метки, которое было задано в тарифе, создаётся вычислительный класс с тем же именем и сохраняется его связь с тарифом (цена).
2. Обнаружение ресурсов: при формировании вычислительного класса для облачной нод-группы автоматика проверяет, есть ли на нод-группе уже проставленная метка billing.commander.deckhouse.io/name. Если метка есть — создаётся класс с тем же именем. Таким образом автоматически созданный класс совпадает с тем, что уже используется, и конфликтов не возникает.
3. Классы хранилища создаются сразу по данным от агента.

После обновления метку billing.commander.deckhouse.io/name можно убрать из шаблонов групп узлов (spec.nodeTemplate.labels). Теперь за проставление метки на узлы отвечает агент, и ручная метка в шаблоне больше не нужна. Если оставить — метка просто дублируется без негативных эффектов.