Kubernetes Cost Allocation with OpenCost: Showback, Chargeback and VPA Right-Sizing (2026)

The cloud invoice arrives as a list of virtual machines, disks and load balancers. Your engineers, however, deploy namespaces, Deployments and Pods, and none of those objects appear on the bill. That mismatch is why kubernetes cost allocation is its own discipline: somebody has to translate node-hours into the teams and services that caused them, and do it in a way that finance, platform and product engineers all accept as fair.

It matters more every year because shared clusters keep absorbing more workloads, including expensive GPU jobs, while a typical request-heavy manifest quietly reserves far more capacity than it uses. Without an allocation model, the conversation about cost degenerates into politics.

This guide walks through how OpenCost computes cost, how to carve up shared and idle spend, how to run showback and chargeback, and how to use the Vertical Pod Autoscaler (VPA) to shrink the waste that allocation exposes. You leave with a working mental model, runnable PromQL and YAML, and a list of the failure modes that break these programs.

What this covers: the OpenCost cost model, the allocation hierarchy, shared and idle cost strategies, request-versus-usage waste math, VPA modes, GPU and commitment attribution, FOCUS billing data, and the organizational design behind showback and chargeback.

Context and Background

Kubernetes was never designed to be a billing system. The scheduler places Pods on nodes using resource requests, the kubelet enforces limits, and the cloud provider bills for the virtual machines underneath. Everything between “this Pod asked for 2 CPUs” and “this team owes 41 dollars this month” is bookkeeping you have to build or buy.

The open source answer to that bookkeeping is OpenCost, described by its maintainers as a vendor-neutral project for measuring and allocating cloud infrastructure and container costs. It was created by Kubecost, and according to the CNCF project page it joined the Cloud Native Computing Foundation on June 17, 2022 and moved to the Incubating maturity level on October 25, 2024. Two things live under that name: a written specification of how Kubernetes costs should be calculated, and a reference implementation that exposes the numbers through an API, a UI and Prometheus metrics.

Before reaching for any tool, it helps to separate three practices that are often blurred together.

• Visibility means you can see spend by cluster, namespace, label and workload.
• Showback means you report each team’s cost back to them without moving money.
• Chargeback means finance actually bills or transfers the cost to the owning cost center.

Most organizations should spend a quarter in showback before moving to chargeback, because the first reports always expose allocation errors that would be explosive in a real invoice. That sequencing is a core idea of the FinOps community, and it applies directly to what FinOps Kubernetes practitioners call “the allocation problem.”

Cost allocation also connects to adjacent engineering topics. If you are tuning node supply, the trade-offs in Karpenter versus Cluster Autoscaler for GPU node scaling decide how much idle capacity exists in the first place. If you are tuning limits, the CFS quota behavior covered in Kubernetes CPU throttling with cgroup v2 determines how far you can safely cut requests. And the broader economics, including carbon, are in our piece on FinOps and GreenOps with carbon-aware scheduling.

The central claim of this article is simple. Allocation is not an accounting exercise that sits beside engineering; it is a feedback loop. The numbers only change behavior when they are trusted, attributed to a named owner, and paired with a mechanical way to act on them. OpenCost supplies the first two, and right-sizing automation such as the VPA supplies the third.

The Kubernetes Cost Allocation Reference Architecture

Direct answer: Kubernetes cost allocation takes the price of each node and disk from your cloud provider, splits it across containers using the larger of requested and used resources, aggregates containers up to namespaces, labels or teams, and then distributes idle and shared costs by an explicit policy. OpenCost implements this model and exposes it through an API and Prometheus metrics.

Figure 1: Reference architecture for kubernetes cost allocation, from billing and usage inputs through the OpenCost model to showback and chargeback outputs.

The diagram shows four stages. Pricing and billing data enter from the cloud provider. Resource usage and requests come from cAdvisor and the Kubernetes API through Prometheus. The OpenCost cost model joins the two, and the outputs feed dashboards, finance exports and automated right-sizing. Each stage has a distinct failure mode, which is why the architecture is worth drawing before it is built.

How the OpenCost model turns node prices into container costs

The OpenCost specification defines total cluster cost as asset costs plus overhead costs. Asset costs split into workload costs and idle costs. Overhead covers things like the cluster management fee your provider charges per hour.

For compute, the spec’s node-level formula is straightforward: cores (or gigabytes) multiplied by hours multiplied by the price per unit-hour. Persistent volumes use disk gigabytes times a price per gigabyte-hour that depends on disk class. Load balancers are charged by forwarding rules for allocation, or bytes ingressed for usage. Network is billed on bytes transferred.

The important design choice is at the workload level. For CPU, memory and GPU, the spec charges each container the maximum of what it requested and what it actually used. This is the reason a Pod that requests four CPUs and uses half a CPU still costs four CPUs. The scheduler reserved that capacity, so nobody else could use it.

That single rule changes engineering incentives more than any dashboard. Under a max-of-request-and-usage model, requests are a price tag, not a safety margin you can inflate for free.

The spec names the underlying inputs: cAdvisor series such as container_cpu_usage_seconds_total and container_memory_working_set_bytes for usage, and values derived from the Kubernetes API for cpu_requested, ram_requested and gpu_requested. Costs are calculated at the container level, then aggregated by pod, controller, namespace, label, annotation or cluster.

A detail that surprises people is how per-resource prices are derived. Clouds bill for a whole machine, not separately for CPU and RAM. When per-resource prices are missing, the spec says to derive CPU, GPU and RAM prices from base ratios and then scale them so they sum to the node’s total price. Your per-CPU cost is therefore a modeled number, which is fine as long as everyone agrees on the model.

The allocation hierarchy

Costs roll up along a hierarchy, and choosing the right level for accountability is the first design decision.

1. Container, the lowest level, where request and usage are measured.
2. Pod and controller, the Deployment, StatefulSet or Job that owns the Pods.
3. Namespace, the most common unit for a team or environment.
4. Label or annotation, such as team, cost-center or app, which cuts across namespaces.
5. Cluster, for environment and region views.

The OpenCost API documentation shows that the aggregate parameter accepts cluster, namespace, controller, pod, container, plus label:LABEL_NAME and annotation:name, and comma-separated lists for multi-dimensional rollups. Namespaces are easiest to enforce because Kubernetes already requires every object to live in one. Labels are more flexible but only as reliable as your admission policy.

A practical rule: use namespace as the primary key for chargeback, and use a mandatory cost-center or team label as a cross-check. If the two disagree for a workload, that workload is a data-quality bug to fix before invoicing anyone.

Idle cost and shared cost are different problems

Idle cost, per the spec, is cluster asset cost minus workload cost: allocated resources that no workload uses. Idle percentage divides idle cost by resource allocation cost. A cluster with expensive nodes half-filled by scheduled Pods has a high idle percentage even if every Pod is perfectly sized.

Shared cost is a separate category. It includes system workloads such as kube-system, ingress controllers, service meshes, monitoring stacks, and the cluster management fee. These are real costs that benefit every tenant but belong to nobody.

The OpenCost spec lists three distribution strategies for shared workload, idle and overhead costs:

1. Split evenly across tenants.
2. Split proportionally to each tenant’s asset consumption.
3. Split by a custom metric, such as network egress bytes.

Even splitting is simple and politically cheap, but it punishes small tenants. Proportional splitting is the safest default because it keeps each tenant’s share tied to the resources they hold. Custom metrics make sense for specific shared services, for instance charging an API gateway’s cost by request volume.

In the API, includeIdle=true returns idle cost as a separate __idle__ allocation, and shareIdle=true distributes it across non-idle allocations proportionally per resource. The idleByNode flag computes idle per node rather than per cluster, which matters when node pools have very different prices, for example GPU nodes next to general-purpose nodes.

Billing data: list price, discounts and the FOCUS specification

Node prices are not static list prices. Enterprise discounts, Savings Plans, committed use discounts, reserved instances and Spot all change the effective price. The OpenCost spec’s pricing appendix says to use the fully amortized net cost from the provider when available.

This is where the FinOps Open Cost and Usage Specification, FOCUS, enters. It is an open specification that normalizes billing datasets across cloud, SaaS and other vendors. The FOCUS site currently advertises version 1.4 of the specification and lists data generators for providers including AWS, Microsoft, Google Cloud and Oracle at various spec versions (the page lists v1.2 for AWS, Microsoft and Google Cloud and v1.0 for Oracle as of this writing; check the site for current coverage).

For allocation, the practical value of FOCUS is that billed cost, effective cost and list cost have consistent definitions across vendors, so your Kubernetes layer can reconcile against a single schema instead of three provider-specific formats. I did not verify the exact column definitions in this run, so check the FOCUS column library before building reconciliation logic around any particular column.

Deeper Analysis: Waste Math, Queries and VPA Right-Sizing

The previous section described the model. This section puts numbers on it, shows how to query it, and explains how the VPA closes the loop. All dollar figures below are illustrative arithmetic, not benchmarks, and the prices are invented round numbers chosen so you can check the math by hand.

Request-versus-usage waste, worked through

Take a node pool priced at 0.04 dollars per vCPU-hour in effective cost after discounts. Suppose a namespace runs 50 Pods, each requesting 1 vCPU but averaging 0.25 vCPU of actual use.

Requested capacity is 50 vCPUs. Over a 730-hour month that is 50 x 730 x 0.04 = 1,460 dollars. Actual consumption is 12.5 vCPUs, which at the same price is 365 dollars. The OpenCost workload rule charges max(request, usage), so the namespace is billed 1,460 dollars and carries 1,095 dollars of request waste.

Request efficiency, a metric worth tracking on every dashboard, is usage divided by request. Here it is 25 percent. Raising it to 60 percent by right-sizing requests to roughly 0.42 vCPU per Pod would cut the billed CPU for that namespace to about 613 dollars, a saving near 850 dollars per month, if and only if the freed capacity is actually removed from the node pool.

That last condition is the trap. Right-sizing Pods frees scheduler capacity, but the cloud bill only drops when the node count drops. Between those two events sits your node autoscaler, which is why the scheduling and consolidation behavior discussed in our Karpenter versus Cluster Autoscaler comparison is a precondition for realizing savings. Request savings that do not become node savings turn into idle cost, which the model then redistributes to everyone.

Figure 2: The right-sizing loop. Allocation exposes request waste, the VPA produces recommendations, workloads are resized, and node consolidation turns freed capacity into a smaller bill.

The figure shows why right-sizing is a loop and not a one-time cleanup. Usage drifts with traffic and releases, so request efficiency decays unless something keeps adjusting requests. Every pass that skips node consolidation leaves savings stranded as idle capacity.

Querying OpenCost through its API

The OpenCost allocation endpoint accepts a time window and an aggregation. The following call returns the last seven days grouped by namespace, with idle cost shared out proportionally. Parameters are those documented in the OpenCost API reference.

# OpenCost default API port is 9003 in the standard install (verify for your Helm values)
curl -G http://opencost.opencost.svc:9003/allocation \
  --data-urlencode "window=7d" \
  --data-urlencode "aggregate=namespace" \
  --data-urlencode "includeIdle=true" \
  --data-urlencode "shareIdle=true" \
  --data-urlencode "idleByNode=true"

To group by a label instead of a namespace, change aggregate to label:team. To multi-key, pass a comma-separated list such as namespace,controller. The step parameter defaults to the whole window, so set step=1d if you want a daily series for charts. The resolution parameter defaults to one minute; coarser values are faster but less accurate for short-lived workloads, which matters for batch Jobs.

Prometheus queries for cost and efficiency

OpenCost also exports metrics to Prometheus. The OpenCost Prometheus integration page shows node_total_hourly_cost, container_cpu_allocation and kubecost_load_balancer_cost in its examples. I am limiting the queries below to metrics I verified, plus standard cAdvisor and kube-state-metrics series that you should confirm exist in your cluster.

# Estimated monthly cost of all nodes (730 hours), from the OpenCost docs pattern
sum(node_total_hourly_cost) * 730

# Requested CPU per namespace (cores), from OpenCost allocation metric
sum by (namespace) (avg_over_time(container_cpu_allocation[7d]))

# Actual CPU use per namespace (cores), from cAdvisor
sum by (namespace) (
  rate(container_cpu_usage_seconds_total{container!="",container!="POD"}[7d])
)

# CPU request efficiency per namespace, 0 to 1
sum by (namespace) (rate(container_cpu_usage_seconds_total{container!="",container!="POD"}[7d]))
/
sum by (namespace) (avg_over_time(container_cpu_allocation[7d]))

A recording rule keeps dashboards fast and makes the efficiency series durable:

groups:
  - name: cost-efficiency
    interval: 5m
    rules:
      - record: namespace:cpu_request_efficiency:ratio7d
        expr: |
          sum by (namespace) (rate(container_cpu_usage_seconds_total{container!="",container!="POD"}[7d]))
          /
          sum by (namespace) (avg_over_time(container_cpu_allocation[7d]))

Seven-day windows smooth out daily peaks, but they hide monthly or quarterly cycles. For finance-grade reports, base chargeback on the OpenCost allocation API over a full billing period and use these ratios only for engineering feedback.

VPA modes and what they cost you operationally

The Vertical Pod Autoscaler watches usage and produces CPU and memory recommendations for a workload. Its updateMode decides what happens next. According to the upstream VPA features documentation, the modes named there include InPlaceOrRecreate, InPlace and Recreate, alongside the older Off and Initial that are described in the VPA API reference.

• Off computes recommendations only and applies nothing. This is the right starting point for cost work because it is risk-free and gives you a recommendation to compare against the request.
• Initial applies recommendations only when Pods are created. Existing Pods are untouched.
• Recreate evicts Pods so they restart with new requests. The upstream limitations page states that each VPA update recreates the Pod, restarting all its containers, and the new Pod may land on a different node.
• Auto was historically the mode that applies updates automatically; check the current API reference for how it maps onto the newer modes before relying on it, since I did not verify its present semantics.
• InPlaceOrRecreate tries to resize a running Pod in place and falls back to recreation. The features page says it was alpha in VPA v1.4.0, beta in v1.5.0 and GA in v1.6.0, and requires Kubernetes 1.33 or later with the InPlacePodVerticalScaling feature gate enabled. The VPA feature gate was required in v1.4.0, enabled by default from v1.5.0 and removed in v1.7.0.
• InPlace is described as eviction-free, attempting in-place updates only and never evicting Pods. The same page lists it as alpha in v1.7.0.

In-place resize matters for cost work because restarts were the main reason teams kept VPA in Off mode for production. If a latency-sensitive service can be resized without a restart, you can adopt automated right-sizing without a rolling-restart storm. Test it first: the semantics of what can be resized without a restart depend on resource and container resize policies, so do not assume memory decreases are always applied live.

A minimal recommendation-only VPA looks like this:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: checkout-api
  namespace: payments
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: checkout-api
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
      - containerName: "*"
        minAllowed:
          cpu: 50m
          memory: 64Mi
        maxAllowed:
          cpu: "2"
          memory: 4Gi
        controlledValues: RequestsOnly

The minAllowed and maxAllowed bounds protect against absurd recommendations, and controlledValues: RequestsOnly leaves limits alone, which is usually what you want when limits encode a deliberate burst ceiling. Read the recommendation with kubectl describe vpa checkout-api -n payments and look at the lower bound, target and upper bound for each container. The target is the number to compare with your current request.

VPA and HPA: do not fight on the same metric

The upstream limitations page is blunt that VPA should not be used with the Horizontal Pod Autoscaler on the same resource metric, CPU or memory. HPA adds replicas when average CPU utilization rises against requests, while VPA changes the requests that define that utilization. The two controllers chase each other.

The supported combinations it lists are VPA on memory with HPA on CPU, or HPA on custom or external metrics. For cost allocation this is good news: an HPA driven by requests per second can scale replica count while VPA keeps each replica sized correctly.

Goldilocks as a recommendation front-end

Fairwinds Goldilocks is a separate open source project that creates VPA objects in recommendation mode for the Deployments in labeled namespaces and renders a dashboard of suggested requests. I did not verify its current release status in this run, so treat it as an optional convenience layer. The underlying engine is still the VPA recommender, so the same caveats about workload history and bursty traffic apply.

Figure 3: How a node’s price is divided into workload cost, idle cost and shared cost, and how each portion is distributed to tenants.

The figure makes one structural point: a node’s bill splits into three buckets, and only one of them, workload cost, is directly attributable. The other two need policy, and the policy is where most disagreements start.

Commitments, Spot and GPUs

Three pricing realities complicate attribution.

First, commitments such as Savings Plans or committed use discounts apply at the account or billing level, not at the node. If you attribute using list price, every team looks more expensive than finance’s real bill. If you attribute using amortized net cost, the benefit of the commitment is spread across whoever runs on the covered nodes. The OpenCost spec recommends the fully amortized net cost where the provider supplies it.

Second, Spot nodes are cheaper but interruptible. Attribute the actual Spot node price to the Pods that ran there, then decide whether teams that opt into interruptible capacity keep the entire discount. Letting them keep it creates the right incentive to build interruption-tolerant services.

Third, GPUs are expensive enough that whole-device allocation dominates the bill. The spec treats GPU like CPU and RAM, charging max of requested and used, and names gpu_requested and a chipset-specific gpu_usage as inputs. In practice, a Pod that requests one GPU holds the entire device, so a team using 15 percent of GPU compute still pays for 100 percent of the allocation. Time-slicing, Multi-Instance GPU partitioning or fractional sharing change what a request means, and your allocation model must reflect the sharing scheme actually deployed. I did not verify how OpenCost currently handles shared GPU partitions, so validate that against your own cluster before billing anyone.

Showback, Chargeback and the Organization Behind the Numbers

Technology is the easy half. The harder half is deciding who sees which numbers, who is accountable for them, and when money moves. A good rollout treats showback and chargeback as stages in a maturity path, not as alternatives.

Figure 4: A staged path from raw visibility through showback to chargeback, with the controls that must exist before each transition.

Stage one: make the data trustworthy

Before anyone sees a report, validate it. Reconcile the sum of allocated cost plus idle plus shared against the cloud invoice for a closed month. The difference should be small and explainable, such as taxes, support fees or untracked services. If the gap is large, fix the pricing configuration first, because every later argument will start with “your numbers do not match finance.”

Then enforce ownership metadata. A policy engine such as Kyverno or OPA Gatekeeper can reject namespaces that lack a team or cost-center label. Unlabeled spend is the largest source of disputes, since it ends up in an “unallocated” bucket that nobody claims.

Stage two: showback with a consistent cadence

Showback works when the report is regular, comparable and delivered where teams already look. Send a weekly per-team summary with spend, trend, request efficiency and the top three right-sizing opportunities. Keep the report to one page.

Two metrics are worth putting side by side. Cost tells a team how much it spends. Efficiency tells it how much of that spend is waste it controls. A team can have a large bill with excellent efficiency, and it should not be shamed for that. Conversely, a small bill at 8 percent efficiency is a cheap lesson waiting to happen.

Be explicit about what is not in the report. If shared costs are allocated proportionally, say so. If the cluster management fee is excluded, say so. Transparency about the model is what turns a number into a trusted number.

Stage three: chargeback with agreed allocation rules

Chargeback moves money, so the allocation rules need sign-off from finance and from each consuming team. Document the rules in a short policy covering:

1. The cost basis (list, net or amortized) and how commitments are credited.
2. Which dimension is the billing key (namespace, label, or a mapping table).
3. How idle and shared costs are distributed (even, proportional or custom metric).
4. How disputes are raised and resolved, and how adjustments are posted.
5. Which costs are explicitly out of scope.

One organizational pattern that works well is to allocate idle cost to the platform team rather than to tenants during the first quarters of chargeback. The platform team controls node pools, autoscaling and bin-packing, so it is the only party that can reduce node-level idle. Passing idle to tenants charges them for decisions they cannot influence. Later, as platform tooling matures, you can move to a hybrid in which tenants carry a small proportional share of idle to encourage them to cooperate on right-sizing.

Stage four: automate governance

Mature teams turn allocation into policy. Namespaces get cost budgets, with alerts when a team’s trailing seven-day efficiency falls below a floor. Pull requests that raise requests above a threshold trigger a review comment that shows the monthly cost delta. Staging environments get automatic scale-down outside working hours.

None of this requires a particular vendor. It requires that the allocation API is reachable from CI, from chat and from your scheduler of record. Because OpenCost exposes both an HTTP API and Prometheus metrics, either integration route is available.

Trade-offs, Gotchas, and What Goes Wrong

Allocation programs fail in predictable ways. Knowing them in advance is cheaper than discovering them in a quarterly review.

Idle-cost politics. Idle cost is nobody’s fault and everybody’s problem. If you distribute it to tenants proportionally, teams that right-size diligently still see their bills fall less than expected because idle shifts onto the rest. If you leave it with the platform team, the platform team’s budget looks bloated. Neither is wrong, but you must pick deliberately and document it.

The max-of-request-and-usage rule has an edge. Because workloads are billed the larger of request and usage, a Pod with no requests but heavy usage is billed for usage, while a Pod with generous requests and little usage is billed for the requests. That is fair to the scheduler but can surprise teams who run best-effort Pods. Missing requests also hurt scheduling quality, so enforce them with a LimitRange or admission policy.

Bursty and spiky workloads. The VPA recommender derives recommendations from observed history. A batch job that runs for 20 minutes a day will look tiny on a seven-day average and then get squeezed into a request that makes it throttle or crash with out-of-memory errors. The upstream limitations page notes that VPA handles most out-of-memory events but not all. For bursty services, pair VPA with generous lower bounds and review the CPU throttling behavior described in our CFS quota and cgroup v2 deep dive.

Recommendations that cannot be scheduled. The limitations list also warns that recommendations can exceed node, quota or available capacity and leave Pods pending. Set maxAllowed below your largest node’s allocatable resources.

VPA versus HPA conflicts. Running both on the same CPU or memory metric produces oscillation. Split the metrics, or use HPA on a custom signal.

Short-lived workloads and resolution. The API’s resolution parameter defaults to one minute. Pods that live shorter than the resolution can be missed or mis-measured. Lower the resolution for batch-heavy clusters, accepting the extra Prometheus query load.

Savings that never land. Reducing requests does not reduce the invoice unless nodes are removed. If your node autoscaler is conservative, or if PodDisruptionBudgets and do-not-disrupt annotations block consolidation, savings turn into idle capacity.

Unvalidated cloud billing integration. The default OpenCost behavior uses public pricing unless you configure the integration with your cloud billing data. Public prices overstate cost if you hold discounts. Verify the integration for your provider in the OpenCost configuration documentation.

Cardinality and storage. Per-container, per-minute data across large clusters stresses Prometheus. Use recording rules, sensible retention and, for long-term reporting, export allocation data to a warehouse. Upstream VPA documentation also notes that performance in large clusters has not been tested, so roll out gradually.

Gaming the metric. Once efficiency is on a scoreboard, teams optimize it. Cutting requests to the bone raises efficiency and also raises the risk of throttling, evictions and tail latency. Pair efficiency with reliability signals such as restart counts and p99 latency, so a good score cannot be bought at the expense of availability.

Practical Recommendations

Start small and sequence the work so each step produces trusted data for the next.

First, install OpenCost against your primary cluster and configure your cloud billing integration so prices reflect real discounts. Reconcile one closed month against the invoice and write down the residual gap and its explanation.

Second, define the allocation key. Use namespace as the billing dimension and a mandatory team label as a cross-check, enforced by admission policy. Decide how shared and idle costs are distributed and publish that decision.

Third, create VPA objects in Off mode for your top spenders. Compare the recommendation target with the current request, and apply changes through your normal deployment pipeline first. Once confidence builds, consider automated modes for workloads that tolerate restarts, and evaluate InPlaceOrRecreate if you run Kubernetes 1.33 or later with the required feature gate enabled and a supported VPA release.

Fourth, close the loop at the node layer. Confirm that your autoscaler consolidates under-used nodes, and measure the node count before and after each right-sizing wave. If node count does not move, the savings are not real yet.

Fifth, run showback for at least one quarter before any chargeback. Move to chargeback only after teams stop disputing the numbers and finance signs the allocation policy.

A short checklist you can paste into a runbook:

• [ ] OpenCost deployed and connected to cloud billing data
• [ ] One closed month reconciled to the invoice
• [ ] Mandatory ownership labels enforced by policy
• [ ] Idle and shared cost rules written down and approved
• [ ] Recording rules for request efficiency in place
• [ ] VPA in recommendation mode for top spenders
• [ ] No VPA and HPA on the same metric
• [ ] Node consolidation verified end to end
• [ ] Weekly one-page showback report delivered
• [ ] Reliability metrics tracked beside efficiency

This article is a systems and engineering analysis, not financial or investment advice.

Frequently Asked Questions

What is kubernetes cost allocation?

Kubernetes cost allocation is the process of attributing cloud spend to the namespaces, labels, teams or services that consumed it. Because the cloud bills for nodes, disks and networks rather than Pods, a model must split node prices across containers, usually by requested or used resources, and then distribute idle and shared costs by policy. OpenCost is the open source implementation of this model.

Is OpenCost free, and what is its CNCF status?

OpenCost is an open source project, and per the CNCF project page it was accepted into the foundation on June 17, 2022 and reached Incubating maturity on October 25, 2024. The core allocation engine, API and UI are open source. Commercial products built on the same lineage add enterprise features, but you can run the open source version yourself against Prometheus and your cloud billing data.

How does OpenCost calculate the cost of a Pod?

OpenCost calculates cost at the container level and rolls it up. For CPU, memory and GPU it charges the maximum of what the container requested and what it used, multiplied by hours and a per-unit price derived from the node’s price. Persistent volumes, load balancers and network are added using their own formulas. Idle and shared costs are then distributed according to your chosen strategy.

What is the difference between showback and chargeback?

Showback reports each team’s costs to them for awareness without transferring money. Chargeback actually bills or allocates the cost to a team’s budget or cost center. Showback is lower risk and exposes data-quality problems early, so most organizations run it first. Chargeback needs signed allocation rules covering the cost basis, billing key, idle and shared treatment and a dispute process.

Can I use VPA and HPA together?

Only if they act on different signals. Upstream VPA documentation says VPA should not be used with the Horizontal Pod Autoscaler on the same CPU or memory metric, because the controllers interfere with each other. Supported patterns include VPA on memory with HPA on CPU, or HPA on custom or external metrics such as request rate. Always test the combination under load.

Does right-sizing Pods automatically lower my cloud bill?

No. Lower requests free scheduler capacity, but the invoice only falls when nodes are removed or replaced with smaller ones. If your node autoscaler does not consolidate, the freed capacity shows up as idle cost. Measure node count and node-hours before and after each right-sizing change, and check for PodDisruptionBudgets or annotations that block consolidation.

Further Reading

• FinOps and GreenOps: cloud cost and carbon-aware scheduling, the broader cost and carbon context for this allocation work.
• Karpenter versus Cluster Autoscaler for GPU workloads, on how node supply affects idle cost.
• Karpenter versus Cluster Autoscaler GPU node scaling in 2026, a companion treatment of node autoscaling trade-offs.
• Kubernetes CPU throttling, CFS quota and cgroup v2, on the latency risk of cutting requests and limits too far.
• OpenCost specification, the authoritative description of the cost model.
• FOCUS, the FinOps Open Cost and Usage Specification, the billing data standard.

By Riju — about