Счёт от облака отвечает на вопрос «сколько стоит EC2-инстанс», но молчит о том, сколько стоит ваш payments-api. На одной ноде живут десятки workloads, и в билле они неразличимы. По данным CNCF 2026 средняя утилизация Kubernetes-кластеров — 35–50 %: половина оплаченной мощности простаивает, и никто не видит, чья именно. До 35 % облачных расходов — предотвратимые потери, а первая причина, почему их не предотвращают, — их некому предъявить. FinOps начинается не с оптимизации, а с аллокации: кто сколько тратит.
Почему Kubernetes ломает облачный биллинг
Три проблемы, которых нет в традиционном облаке. Shared infrastructure: биллинг оперирует инстансами, а не workloads — «EC2 = $X», но не «pod payments-api = $Y». Ловушка overprovisioning: инженер, чей сервис однажды упал по OOM, удваивает memory request; индивидуально это рационально, коллективно — расточительно, и именно защитный запас — главный источник waste. Проблема времени: pod, три недели назад съевший лишнюю память за 72 часа и умерший, в месячном билле уже неразличим — медленные биллинговые сигналы не ловят эфемерные ресурсы.
Вывод один: считать стоимость нужно на уровне pod и в реальном времени.
OpenCost — движок, а не дашборд
OpenCost — CNCF Incubating-проект (Apache 2.0), выросший из cost-allocation-движка Kubecost; среди контрибьюторов — AWS, Google и Microsoft, а заявленная цель — стать «Prometheus для стоимости». Механика прозрачна: движок берёт метрики Prometheus (kube_pod_container_resource_requests) и прайсинг облака и раскладывает: стоимость pod = CPU request × цена CPU-часа + memory request × цена памяти + storage (PVC) + network. Ставится одним helm install с указанием Prometheus; наружу смотрит API вида GET /allocation?window=1d&aggregate=namespace.
Главная граблина: встроенный UI OpenCost — тонкий viewer, а не хранилище. Он держит ограниченное in-memory-окно и «теряет» историю примерно через неделю — и это не баг. Задуманная архитектура другая: OpenCost экспортирует cost-метрики обратно в Prometheus или VictoriaMetrics, а дашборд строится в Grafana. Кто строит отчётность на встроенном UI — быстро упирается в стену.
OpenCost, Kubecost и AWS SCAD: два решения, а не три
Частая путаница — считать их трёхсторонней гонкой. OpenCost и Kubecost — один класс и один движок: real-time-аллокация внутри кластера. Выбор между ними — effort против control: OpenCost — vendor-neutral-движок, которому нужны Prometheus и Grafana; Kubecost — тот же движок плюс UI с retention и savings-рекомендациями, бесплатно на один кластер, multi-cluster и SSO — от ~$449/мес (проект в собственности IBM). Для single-cluster EKS есть бесплатный EKS-optimized-бандл.
AWS SCAD — другая категория: биллинговая фича, которая делит стоимость EC2 до pod-level прямо в данных счёта. Данные попадают только в CUR — в Cost Explorer их нет, запрашивать через Athena. Зато SCAD сверяется с реальным счётом — с учётом Savings Plans, RI и Spot, тогда как OpenCost и Kubecost считают по on-demand-прайсу и с реальным биллом не сойдутся. Зрелая связка — держать оба: OpenCost или Kubecost для инженерной эффективности («где waste прямо сейчас»), SCAD — для finance-grade chargeback («что списать какой команде»).
Idle cost и правила аллокации
Базовое правило: namespace = команда. Тоньше — аллокация по labels (team, cost-center, service). Pod без resources.requests не аллоцируется вовсе — такому поду нечего предъявить; требование requests стоит зашить в admission policy через Kyverno или Gatekeeper.
Отдельная категория — idle cost: (ёмкость ноды − сумма requests) × цена ноды. Прятать её нельзя: либо раскидать pro-rata по namespace, либо завести выделенный __idle__-namespace — чтобы сам факт overprovisioning был виден на дашборде. Анти-паттерн — один namespace на несколько команд: аллокация превращается в фикцию.
От аллокации к unit economics
Следующий уровень — стоимость бизнес-единицы: cost-per-request, cost-per-tenant. PromQL-запрос делит cost-метрику namespace на бизнес-метрику сервиса — и дашборд показывает «$X за миллион запросов, тренд Y % за месяц». Дальше стоимость становится таким же quality gate, как error rate: AnalysisTemplate в Argo Rollouts блокирует деплой, если cost-per-request превысил порог.
Для базовых случаев есть путь и без OpenCost: AWS импортирует K8s labels как Cost Allocation Tags, и «сколько потратила команда X» видно прямо в Cost Explorer. Но idle-аллокацию, network-атрибуцию и unit-запросы этот путь не покрывает.
Порядок внедрения укладывается в неделю: OpenCost с экспортом в Prometheus, Grafana-дашборд, labels на workloads, idle в явном виде. Топ-10 namespaces обычно дают ~80 % расходов — начинать с них. У зрелых FinOps-практик экономия достигает 20–54 %, но первый шаг всегда один: увидеть, кто тратит. Оптимизация без аллокации — guesswork.