Kubernetes cost allocation: what the tooling costs against the waste it finds

The bill arrives as nodes, and the waste is already measured

A Kubernetes cluster bills as nodes, not as the workloads running on them. One node can host pods from a dozen teams, so the cloud invoice shows compute and storage with no record of which application drove it, and without allocation every team sees a single shared number that nobody owns. That is the gap cost tooling fills: it maps node cost down to namespaces, labels, controllers and pods so the spend lands on a team.

The size of the prize is no longer a matter of opinion. Cast AI's 2026 State of Kubernetes Optimization Report, measured across tens of thousands of production clusters, found average CPU utilisation at 8% and memory at 20%, both down on the previous year. Datadog's State of Cloud Costs report puts 83% of container costs on idle resources, split between overprovisioned cluster infrastructure at 54% and oversized workload requests at 29%.

The mechanism behind those figures is the resource request. Kubernetes schedules on requested CPU and memory, not on what a pod actually uses, so a service that requests four cores and uses one reserves three idle cores the cluster still pays for. Engineers set requests for worst-case scenarios and rarely revisit them, and the cluster autoscaler then provisions nodes to match the inflated requests. A cluster that looks full to the scheduler can run nodes at 10 to 15% actual CPU utilisation.

Kubecost publishes no per-node price, and that is the first thing to fix

The Kubecost pricing page offers three deployment options and no rate card. There is a free tier for individuals, small teams or anyone who needs a quick snapshot of current Kubernetes spend and individual cluster usage in a self-hosted deployment. Above that sit a self-hosted version for teams running Kubernetes at scale and a SaaS version that runs the Kubecost agent locally on clusters across public cloud and on-prem while the vendor carries the management overhead.

Neither paid tier carries a published figure. The page says Kubecost is free to install and takes under five minutes to get started, and it stops there. That makes the licence quote-only, which means the comparison a buyer actually needs cannot be run from the website: the per-cluster or per-node rate, the retention period included, and whether the SaaS tier is priced on clusters, nodes or monitored spend all have to come from the vendor in writing.

The summary this page was commissioned against asked for the published per-node tiers and the monthly spend at which the licence stops being a rounding error. The first does not exist on the page, so the second cannot be computed from it. What can be said is the shape of the break-even: the licence is justified when the waste it removes exceeds its cost, and the waste figures above suggest that threshold is low for any estate running more than a handful of clusters at meaningful spend. Ask the vendor for the price at 5 clusters and at 50, and for the retention and support terms that come with each.

Three options a buyer would actually shortlist

OpenCost is the CNCF project that standardised how shared cluster cost is split. It pulls node pricing, watches pod resource usage and produces allocation by namespace, label and controller, and because it is open source and vendor neutral it has become the reference implementation. It gives clean allocation with no licence fee, and it gives nothing else: no longer retention, no alerting, no rightsizing recommendations.

Kubecost is a commercial platform built on top of that lineage, adding longer retention, alerting and rightsizing recommendations to the allocation engine. Its own page describes real-time cost across clusters, teams, namespaces, workloads and shared resources, reconciliation with the cloud bill for showback and chargeback, budgets, forecasting and anomaly alerts, and automated actions such as request sizing and namespace turndown. The open-source roots are the pitch: it is designed for Kubernetes rather than adapted to it.

Cast AI comes at the same problem from the optimisation side. Its published material leads with the utilisation figures above and with autoscaling and rightsizing as the action, including right-sizing workloads with Karpenter or Cast AI's own autoscaler and consolidating capacity. The distinction matters at purchase: Kubecost and OpenCost tell you where the waste is, Cast AI sells the mechanism that removes it, and the two are not substitutes even when they overlap on a dashboard.

Where each one breaks

The limit common to all three is that a tool can show you the waste but cannot decide the trade-off for you. They surface idle requests and overprovisioned workloads; an engineer who owns the service still has to judge whether trimming a request risks a latency spike. Teams that buy optimisation tooling before fixing request sizing are paying to observe waste rather than eliminate it, which is the most expensive way to run this category.

OpenCost's limit is scope. It allocates, and the moment you want retention past the default, alerting on drift or a recommendation queue, you are building it or buying it. Native cloud advisors such as AWS Compute Optimizer, Azure Advisor and GCP Recommender sit at the other end: they see the nodes but not the pod-level allocation, so they cannot answer the question the finance team asks about which team spent the money.

Kubecost's limit is commercial visibility. A buyer cannot model the licence against the savings without a quote, and the page gives no retention, support or seat terms to compare. Cast AI's limit is the inverse: the utilisation numbers it publishes are its own measurement across its own sample, and the savings case rests on acting on them, which is an engineering commitment rather than a product feature.

What it costs, and what to ask before signing

Kubecost is free to install, and that is the only price on the page. The self-hosted and SaaS tiers are quote-only, so the number that decides the purchase is the one the vendor sends you. Ask for the annual price at 5 clusters and at 50, whether the unit is the cluster, the node or the monitored spend, what retention is included at each tier, and what the SaaS tier charges for the agent running on-prem.

The cost side of the ledger is easier to state than the licence side. Compute is typically 60 to 80% of total cluster spend, and a cluster running nodes at 10 to 15% actual CPU utilisation is paying full price for a fraction of the value. Storage accumulates silently through Persistent Volumes for deleted or scaled-to-zero workloads and snapshots kept for disaster recovery and never cleaned up, which is rarely the largest category but is close to free to fix.

The comparison that matters is therefore not Kubecost against OpenCost on licence fee alone. It is the quoted annual cost against the waste the estate can actually remove, and the second figure depends on whether anyone owns the recommendations. A 50-cluster estate with no FinOps cadence will buy a dashboard; a 5-cluster estate with one platform engineer who acts on request sizing may find the free tier sufficient for a quarter and the quote unnecessary.

The decision rule

Choose OpenCost if you already have an engineer who owns cluster cost and you need allocation by namespace, label and controller without a procurement cycle, because the CNCF project gives you the split and nothing you have to renew. Choose Kubecost's paid self-hosted or SaaS tier if you run enough clusters that retention, alerting and rightsizing recommendations would otherwise be built in-house, and only after the vendor has put an annual price at your cluster count in writing. Choose Cast AI if the problem you have diagnosed is utilisation rather than attribution, because its product acts on the requests rather than reporting them.

Wait if the estate is small, the requests have never been reviewed, and nobody has been named to act on the output, since the first pass of request sizing costs nothing but engineering time and will change the size of the licence you need. Whichever route you take, ask the vendor for the post-optimisation utilisation its own customers reach, because none of the pages above publishes one.