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

Назначение

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

Deckhouse 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 определяет, к какому вычислительному классу относится каждый узел.

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

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

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

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

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

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

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

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

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

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

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

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

Отдельно назначать права держателям лицевых счетов не нужно: когда администратор биллинга добавляет пользователя или группу в поле «Держатели лицевого счёта», доступ на просмотр этого счёта выдаётся автоматически — через предустановленную роль billing-account-user. Такой пользователь видит только свои счета и связанные с ними данные дашборда. Подробнее — в документации по RBAC.

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

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

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

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

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

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

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

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

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

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

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

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

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

Провайдер	Правило формирования имени	Пример
Yandex Cloud	{platformID}-cf-{coreFraction}	standard-v3-cf-100
AWS	{instanceType}	m5.xlarge
GCP	{machineType}	n1-standard-4
Azure	{machineSize}	standard-f4
OpenStack	{flavorName}	m1.large
vSphere / zVirt / Dynamix	{numCPUs}c-{memory}m	4c-8192m
VMware Cloud Director	{sizingPolicy}	4cpu-8mem
Huawei Cloud	{flavorName}	s6.xlarge.2
DVP (Deckhouse Virtualization Platform)	{virtualMachineClassName}-cf-{coreFraction}	generic-cf-100

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Устройство вкладки аналогично. Отличие одно: назначение классов хранилища на кластеры происходит полностью автоматически по совпадению имён с классами хранилища Kubernetes. Детальная страница класса хранилища в этой версии Deckhouse 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 (или другой публичный провайдер)

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

Вычислительный класс	CPU, ₽/ядро·час	Память, ₽/ГиБ·час
standard-v3-cf-100	1.50	0.40
standard-v3-cf-50	0.75	0.40

Класс хранилища	₽/ГиБ·час
network-ssd	0.02
network-hdd	0.005

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

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

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

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

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

Пример (OpenStack):

Вычислительный класс	CPU, ₽/ядро·час	Память, ₽/ГиБ·час
m1.large	0.80	0.25
m1.xlarge	0.80	0.25
c4.large (вычислительный флейвор)	1.00	0.25

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

Вычислительный класс	CPU, ₽/ядро·час	Память, ₽/ГиБ·час
4c-8192m	0.70	0.20
8c-16384m	0.70	0.20
16c-32768m	0.70	0.20

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

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

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

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

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

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

1. В Тарификация → Вычислительные классы создайте классы, отражающие реальные типы узлов (например, bm-cpu-2x32, bm-gpu-a100).
2. Дополнительно можно в шаблоне группы узлов указать лейбл billing.commander.deckhouse.io/name с тем же именем класса — тогда Deckhouse 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. Нажмите Сохранить. Расписание появится на вкладке Управление регулярными отчётами.

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

Раздел «Лицевые счета»

Лицевой счёт — предоплаченный баланс, к которому привязываются рабочие пространства. Он отвечает на вопрос «за чей счёт работает эта инфраструктура и хватает ли на неё средств»: пока на счёте есть деньги, привязанные к нему рабочие пространства работают как обычно; когда баланс исчерпан, в них перестаёт запускаться установка новых кластеров.

Одно рабочее пространство принадлежит ровно одному лицевому счёту, а один счёт может объединять несколько рабочих пространств.

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

Кто что видит

С лицевыми счетами работают две роли:

• администратор биллинга — видит все счета, создаёт и редактирует их, пополняет баланс и выставляет счета;
• держатель лицевого счёта — видит только те счета, куда он добавлен, и только для просмотра: баланс, накопленный расход и историю операций. Кнопок пополнения и списания у него нет — эти операции выполняет администратор биллинга по договорённости.

Держатели лицевого счёта назначаются в форме самого счёта; подробнее о правах — в разделе Управление доступом.

Создание счёта и привязка рабочих пространств

1. Откройте «Биллинг» → «Лицевые счета» и нажмите Создать счёт.
2. Укажите название и валюту счёта.
3. В поле Держатели лицевого счёта выберите пользователей и группы, которым нужен доступ к счёту.
4. В поле Привязанные рабочие пространства выберите рабочие пространства, потребление которых оплачивается с этого счёта. Пространства, уже привязанные к другому счёту, в списке недоступны.
5. Нажмите Создать. Счёт появится в таблице с нулевым балансом.

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

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

Рабочие пространства без лицевого счёта

При обновлении установки лицевые счета для уже существующих рабочих пространств автоматически не создаются. Вместо этого над таблицей на вкладке «Лицевые счета» появляется предупреждение со списком рабочих пространств, не привязанных ни к одному счёту.

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

Пополнение баланса

Пополнение выполняет администратор биллинга по договорённости с держателем лицевого счёта. Откройте счёт, нажмите Пополнить баланс, укажите сумму и подтвердите. Баланс увеличится, а в истории операций появится запись о пополнении.

Выставление счёта (списание)

Списание тоже выполняет администратор биллинга — кнопкой Выставить счёт (списать) в карточке счёта. В открывшемся диалоге период и сумма уже заполнены:

• Начало периода — рубеж «оплачено до»: конец последнего списанного периода. Если списаний ещё не было, началом становится самая ранняя дата, за которую есть данные о потреблении привязанных рабочих пространств, — поэтому рабочее пространство, работавшее до появления счёта, не остаётся неоплаченным. Пока по счёту не было ни одного списания, начало можно изменить: выберите любую прошедшую дату, и сумма пересчитается за указанный период. После первого списания начало приклеено к рубежу и недоступно для правки, поэтому один и тот же период не будет списан дважды.
• Конец периода — последние списываемые сутки, по умолчанию вчерашние. Списываются только закрытые сутки: сегодняшние и будущие даты в календаре недоступны, текущие сутки будут списаны позже. Дату можно сдвинуть назад, вплоть до суток рубежа.
• Сумма — стоимость потребления привязанных рабочих пространств за предложенный период, рассчитанная тем же механизмом, что и отчёты. При смене любой из границ периода сумма пересчитывается, и её можно скорректировать вручную — правка суммы сохраняется до отправки.

Если после рубежа «оплачено до» не закрылось ни одних суток, списывать нечего — кнопка Выставить счёт (списать) заблокирована, а в подсказке указано, что все закрытые сутки уже оплачены.

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

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

Текущий расход, остаток и прогноз

В карточке счёта, помимо баланса, отображаются оценочные величины, рассчитываемые в момент открытия:

• Текущий расход (с даты рубежа «оплачено до») — стоимость потребления, которое ещё не списано. В него входят и незакрытые сутки, поэтому сразу после списания расход показывает не ноль, а стоимость текущего дня.
• Остаток баланса — баланс за вычетом текущего расхода.
• Скорость расхода — средний расход в сутки за то же окно.
• Прогноз исчерпания — на сколько дней хватит остатка при текущей скорости и до какой даты. Если расхода нет или остаток уже неположителен, прогноз не показывается.

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

Если по прогнозу средств хватит менее чем на 7 дней, в карточке счёта появляется предупреждение о низком балансе. Счёт с неположительным балансом заметен и без чисел: остаток выделяется красным, а в таблице счетов рядом с балансом появляется предупреждающий маркер с пояснением. И предупреждение, и маркер видны обеим ролям в пределах доступных им счетов.

История операций

На вкладке «История операций» карточки счёта перечислены все проведённые операции: дата, тип (пополнение или списание), сумма, период (для списаний) и комментарий.

Отдельно фиксируется смена принадлежности рабочего пространства. Когда рабочее пространство привязывают к лицевому счёту или отвязывают от него (в том числе при удалении счёта), в журнале истории изменений этого рабочего пространства появляется запись типа «Лицевой счёт»: кто и когда изменил привязку, а в изменениях — прежний и новый счёт. Записи видны тем, у кого есть право billingaccounts/audit (документацию по RBAC).

Финансовая блокировка

Когда баланс счёта становится неположительным (<= 0), привязанные к нему рабочие пространства считаются финансово заблокированными:

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

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

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

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

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

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

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

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