Cost allocation
Cost allocation your finance team can sign off on
KubeOn splits each node's billed cost across the pods that ran on it and assigns every pod to a team, cost center and application. Idle and shared cost keep their own columns, and every cluster reconciles to its bill.
Shared clusters hide who spent what
Cloud bills price machines. Kubernetes runs many teams on each machine. Allocation has to bridge the two without inventing numbers.
List prices are the wrong starting point:
Estimates from on-demand rates ignore Savings Plans, reservations and discounts, so the totals drift away from the invoice.Requests and usage tell different stories:
Charge only usage and teams over-reserve for free. Charge only requests and bursty workloads look cheap.Idle capacity gets buried:
Spread it silently and nobody sees the waste. Leave it out and the totals stop adding up.
Allocation method
Each pod pays for what it reserved or used, whichever is higher
Node cost is split across pods on max(request, usage), for CPU and memory separately, weighted 50/50 by default. Where AWS split cost allocation data exists, KubeOn uses it directly and lays measured usage over it. GPU, persistent volume, network and load balancer cost get their own columns.
- max(request, usage) per resource, the rule AWS split cost allocation uses
- CPU, GPU, RAM, PV, network, load balancer, shared and idle columns
- Cumulative, monthly, daily or hourly rates
Showback and chargeback
Owners come from the labels you already have
KubeOn assigns each workload to a team, cost center and application from label selectors, workload labels, namespace mappings and cluster defaults, in that order. Owners are discovered from label values automatically, and mappings are effective-dated, so moving a namespace applies from the date you choose and days before it keep their allocation.
- team, owner and project labels; cost_center and department; app and product
- Team, team and TeamName resolve to one key at read time
- An audit trail on every mapping change
Reconciliation
Every dollar of the bill lands in a bucket
KubeOn ties each cluster to its bill, then puts every dollar of the bill in one bucket: owned by a team, shared platform, idle capacity, or outside Kubernetes, with what nobody owns shown on its own. The buckets add up to the bill. Anything KubeOn cannot attribute is listed with its resource IDs, so a missing label shows up as a fixable item rather than a gap in the total.
- Reconciled to invoice and ownership coverage, reported separately
- Net amortized cost: Savings Plans, reservations, EDP, credits, refunds and tax
- Unowned cost by service, account, cluster, namespace or reason
- Unallocated spend listed, never spread into idle
Idle and shared cost
Idle capacity stays visible, and you decide who pays for it
Workload idle (requested but unused) and infrastructure idle (node capacity nobody requested) are measured separately. Choose a policy for idle and shared platform cost: the platform team absorbs it, it is spread in proportion to direct cost, or a hybrid of both.
- Share idle within each cluster, within each node or across everything
- Default shared namespaces such as kube-system, monitoring and ingress-nginx
- Efficiency per cluster, namespace and workload, weighted by cost
Where the Kubernetes savings are
off the monthly bill: $21,842 a month found at our sample company
Sample company, not a customer result
How it works
Allocation rules, in full
The same rules apply on every cloud and in every data center. Nothing is hidden in a model.
| Rule | What KubeOn does |
|---|---|
| Pod cost | Node cost times the pod's share of max(request, usage), for CPU and memory, weighted 50/50 by default and configurable |
| Idle | Node cost minus all pod cost becomes an idle line. Workload idle and infrastructure idle are reported separately |
| Shared | Platform namespaces are shared cost: kube-system, kube-public, kube-node-lease, istio-system, monitoring, logging, cert-manager, ingress-nginx |
| Policies | Platform absorbs (default), proportional to direct cost, or hybrid with a platform share you set. Policies are effective-dated |
| Ownership order | Label selector mapping, then workload labels, then namespace mapping, then cluster default, then unallocated |
| Views | Up to 5 grouping dimensions plus any label, drill from cluster to namespace to controller to pod, an Other row so rows add up to the total |
| Repairs and re-runs | Days with late usage or billing are repaired automatically for the last 7 days. Admins and platform engineers can re-run up to 92 days back from Data health. Each day is recomputed atomically |
Everything you need for showback and chargeback
Multi-dimension views
Group by cluster, namespace, controller, pod, node, team, account, environment or any label, up to 5 at once.
Tag normalization
Team, team and TeamName become one key, with aliases and conflict detection. Nothing is re-tagged in your clusters.
Effective-dated ownership
Reassign a namespace from next month without changing what last month says.
Team-scoped access
Team leads see their own teams. A team lead with no team sees nothing.
GPU allocation
GPU node cost split by GPU requests, with idle GPU time reported on its own.
Change tracking
Every row shows its change against the previous window of equal length.
Chargeback exports
Monthly totals by team or cost center as CSV, scheduled to finance by email.
Allocation re-runs
Date a mapping fix from when it should have applied, then re-run up to 92 days back in one action.
Cost allocation: your questions answered
KubeOn
Keep exploring
Evaluate cost allocation with your team
Bring your platform and FinOps priorities. We will walk through the data, controls and evidence for your evaluation.