Kubernetes cost visibility in 2026: revisit OpenCost, Kubecost and Robusta KRR before you buy another FinOps tool or add another node

When the cloud bill jumps, many teams reach for one of two habits. The first is to add another node because some pods are Pending and nobody wants an outage. The second is to buy another FinOps dashboard because finance wants a number per team by Friday. Both can be right. Both are also easy ways to skip the slower question: who is actually using the capacity we already pay for, and are their requests honest?

Kubernetes makes that harder than it looks. Nodes are shared, pods come and go, and the scheduler reserves capacity based on requests, not real usage. So a namespace can look cheap in a usage graph and still be the reason you needed a new node. This post revisits three open-source tools that teams still meet when they want to answer that question before spending more: OpenCost, Kubecost, and Robusta KRR. The aim is not to crown a winner. The aim is to help you see where the money goes, fix the requests that cause waste, and only then decide whether you need a bigger product or a bigger cluster.

The short version

  • OpenCost: CNCF Incubating project under Apache-2.0. A vendor-neutral cost allocation model and API for Kubernetes and cloud spend, backed by Prometheus. Strong as the free, open baseline for “cost per namespace, label or team”.
  • Kubecost: the commercial product that started OpenCost, owned by IBM since September 2024. Version 3 adds its own agent and ClickHouse storage, a free tier with limits, and paid features such as unified multi-cluster views and automated request sizing at scale. Strong when you want a supported product and accept IBM licence terms.
  • Robusta KRR: MIT-licensed CLI that reads your existing Prometheus data and recommends CPU and memory requests and limits. It does not price anything. Strong as the rightsizing step that turns cost reports into actual changes.

What cost visibility and rightsizing actually do

Before comparing tools, it helps to separate two jobs that often get mixed up in sales decks.

  • Cost allocation answers “who spent what”. It takes the price of nodes, disks, load balancers and network, and splits it across containers, pods, namespaces, labels and teams. It also shows idle cost: capacity you pay for that no workload has reserved.
  • Rightsizing answers “what should the requests be”. It looks at real CPU and memory usage over time and suggests requests and limits that match it, so the scheduler stops reserving capacity that never gets used.

The OpenCost specification is a good place to learn the allocation idea properly. It says workload cost for resources like CPU and GPU should be read as the greater of request and usage. In plain words, if you request four cores and use half a core, you still pay for four cores, because the scheduler kept them aside for you. That one rule explains a lot of surprise bills. It also explains why allocation alone does not save money. Somebody still has to lower the requests, and that is the rightsizing job.

Neither job replaces commitment planning or deleting forgotten environments. What these tools give you is an honest picture inside the cluster, so talks with finance and application teams start from data.

OpenCost: the open cost model and API

History and licence. The project lives at opencost/opencost, and the repository README states it was originally developed and open sourced by Kubecost. The CNCF project page says OpenCost was accepted to CNCF on 17 June 2022 and moved to the Incubating maturity level on 25 October 2024. The code is under the Apache License 2.0. The project is two things together: a written specification for measuring and allocating Kubernetes costs, and a Go implementation of that specification. The web UI lives in a separate repository, opencost/opencost-ui.

How it works. OpenCost is installed with its official Helm chart; the README notes that the old standalone manifests were removed. The install docs state plainly that OpenCost requires Prometheus for scraping metrics and data storage, and they show how to point OpenCost at your own Prometheus or at a global query endpoint like Thanos, Cortex or Mimir in sharded setups. Prices come from cloud billing and pricing APIs for AWS, Azure and GCP, or from a custom CSV for on-premises clusters. You can then read allocation by cluster, node, namespace, controller, service or pod through the UI, a REST API, the kubectl cost plugin, Prometheus metrics, or CSV and Parquet exports.

The README also lists carbon cost estimates, plugins for external costs such as Datadog, an opt-in MCP server and cost tracking for vLLM-based inference. Treat these as features to test, not reasons to adopt.

At the time of writing, the latest release on GitHub is v1.121.3 (16 September 2026). The repository was still receiving pushes in late October 2026.

Where it is strong.

  • Teams that want a free, open, vendor-neutral answer to “cost per namespace or label” without a licence conversation.
  • Platform groups that already run Prometheus and are comfortable adding one more scrape config.
  • Teams that want to feed cost data into their own reports or chargeback scripts through a documented API.

What to watch.

  • Prometheus is not optional. Its retention, cardinality and storage now decide how much cost history you have.
  • Without billing integration you see list prices, not your discounts.
  • Multi-cluster views need a central data source and some work on your side.
  • OpenCost shows waste. It does not change any requests for you.

Kubecost: the commercial product, now under IBM

History and licence. Kubecost was founded in 2019. IBM announced the acquisition of Kubecost on 17 September 2024, placing it in the IBM FinOps suite next to Apptio Cloudability and Turbonomic. Today the product is sold as IBM Kubecost. IBM’s support page lists IBM Kubecost Self Hosted 3.x as generally available from 29 September 2025 under the IBM International Program License Agreement. The kubecost/kubecost GitHub repository, which holds the Helm chart and release notes, shows an Apache-2.0 licence for the chart, but the product images and features are governed by IBM terms. Do not read the chart licence as the product licence.

How it works. Version 3.0 (GitHub release dated 29 September 2025) was a large change. The release notes describe a new agent, a new database and a new cluster controller. The AWS EKS documentation summarises it as a move to ClickHouse in place of DuckDB, and a unified agent that removes the Prometheus dependency while keeping OpenCost compatibility. The 3.0 notes also say the Helm chart was renamed from cost-analyzer to kubecost, images come from IBM Cloud Container Registry (icr.io) by default, the aggregator needs at least 8 GB of RAM, and a side-by-side install is recommended before switching from v2.

The 3.3.0 notes describe a beta MCP server enabled by default on aggregator installs, a rebuilt Namespace Turndown action and AWS NAT Gateway network costs. IBM’s 3.3 blog says 3.3 is the last release that supports the older v1 enterprise licence format. At the time of writing, the latest release on GitHub is v3.3.1 (14 October 2026).

Free tier, in IBM’s own words. The product page lists a free Foundations tier with unlimited clusters up to 250 cores, 15-day metric retention, unlimited users and community support. Kubecost’s 3.0 announcement blog also describes a free tier gate based on spend, measured as USD 100,000 over the last 30 days, and the AWS EKS documentation repeats that limit. IBM’s install docs add that the free edition shows one cluster at a time in the UI. The EKS optimised bundle is documented by AWS as exempt from the spend limit. On automated request sizing, the 3.0 release notes and the 3.0 blog do not read the same way about free access, so check the docs for your exact version. Savings figures on the product page, such as “30 to 50 percent”, are the vendor’s own claims.

Where it is strong.

  • Teams that want a supported product with reports, budgets, anomaly detection and automation in one place.
  • Larger estates that need a unified multi-cluster view, RBAC and longer retention, and can pay for Enterprise.
  • EKS users, who get an optimised bundle at no extra charge from AWS, within its documented feature set.

What to watch.

  • Licence and limits are a product decision by IBM and have changed between major versions. Re-read them at each upgrade.
  • The free tier caps by cores, spend and retention. A growing estate can cross a line quietly.
  • v3 pulls images from icr.io by default; air-gapped and regulated environments need a mirror plan.
  • Default-on features such as the MCP server and telemetry deserve a security review.

Robusta KRR: rightsizing from the Prometheus data you already have

History and licence. The project lives at robusta-dev/krr. The repository was created in February 2023 by Robusta, the company behind the Robusta platform for Kubernetes alerting and troubleshooting. It is under the MIT licence.

How it works. KRR (Kubernetes Resource Recommender) is a CLI. You run it from a laptop or as an in-cluster job, it queries Prometheus (or Thanos, VictoriaMetrics, Mimir and several managed Prometheus services), and it prints recommended CPU and memory requests and limits for each workload. The README lists the requirements: Prometheus 2.26 or later, kube-state-metrics and cAdvisor metrics. Output includes JSON, CSV, Markdown and Slack reports.

The default “simple” strategy is easy to explain to an application team, which is a real advantage. As the README describes it, the CPU request is set at the 95th percentile of usage with no CPU limit, and the memory value is the maximum over the past week plus a 15 percent buffer. The numbers can be changed with CLI flags, and you can write your own strategy in Python. Unlike the Vertical Pod Autoscaler, KRR needs no per-workload VPA object. For automatic application, Robusta offers a KRR Enforcer mutating webhook, which its docs say needs Robusta installed in the cluster and a Robusta UI account.

At the time of writing, the latest release on GitHub is v1.31.3 (4 November 2026).

Where it is strong.

  • Teams on kube-prometheus-stack who want a first list of over-requested workloads in an afternoon.
  • Platform groups that prefer reviewed pull requests to changes applied by a controller.

What to watch.

  • KRR does not price anything. It speaks cores and bytes, not rupees or dollars.
  • Recommendations are only as good as your Prometheus history. Short retention, missed batch peaks or month-end jobs lead to bad advice.
  • The README’s headline saving, built on a third-party study about unused CPU, is a vendor claim, not a forecast for your cluster.
  • The UI, explanation graphs and Enforcer sit on the Robusta SaaS side.

If you would rather stay close to the VPA, Fairwinds Goldilocks (Apache-2.0, latest v4.16.3 on 3 November 2026) creates VPA objects in recommendation mode and shows the results in a dashboard. It is a reasonable alternative to KRR, not a fourth peer in this post.

Side by side, without a table

Primary job

  • OpenCost: cost allocation and idle cost, through a vendor-neutral model and API.
  • Kubecost: cost allocation plus reports, budgets, anomaly detection and automated actions, as a product.
  • Robusta KRR: CPU and memory request and limit recommendations.

Licence (as stated upstream)

  • OpenCost: Apache-2.0, CNCF Incubating.
  • Kubecost: IBM International Program License Agreement for the product; Helm chart repository shows Apache-2.0.
  • Robusta KRR: MIT; Robusta SaaS features under Robusta’s own terms.

Latest releases checked for this post (November 2026)

  • OpenCost: v1.121.3 (16 September 2026).
  • Kubecost: v3.3.1 (14 October 2026).
  • Robusta KRR: v1.31.3 (4 November 2026).

Data dependency

  • OpenCost: Prometheus is required, plus cloud billing APIs or custom pricing.
  • Kubecost: v3 uses its own agent and ClickHouse, with no Prometheus dependency per the AWS docs.
  • Robusta KRR: Prometheus-compatible history with kube-state-metrics and cAdvisor.

Changes workloads?

  • OpenCost: no, it reports.
  • Kubecost: yes, through licensed actions such as request sizing and namespace turndown.
  • Robusta KRR: CLI only recommends; the Enforcer webhook applies changes with Robusta installed.

We did not run install drills or benchmarks for this post. Use the official guides on a non-production cluster before you trust any number in a review meeting.

A practical way to start this week

For an Indian platform team about to raise a purchase request for a FinOps tool or a node pool, a calm sequence looks like this:

  1. Write down the real question: chargeback per team, a bill spike, Pending pods, or unit cost per product.
  2. Check labels first. Agree on two or three labels such as team, product and environment, and make sure most namespaces and workloads carry them. No tool can allocate cost to labels that do not exist.
  3. Install OpenCost with Helm on one staging or low-risk cluster, pointed at your existing Prometheus. Add billing integration or a custom pricing CSV so the numbers resemble your bill.
  4. After a week, look at idle cost and the top ten namespaces. Note where requests are far above usage.
  5. Run KRR against the same Prometheus for those namespaces. Turn its output into small pull requests for requests and limits, reviewed by the owning team, starting with stateless services.
  6. Watch for a week: throttling, OOMKilled events, latency and Pending pods. Only then move to the next batch.
  7. If you still need a unified multi-cluster view, budgets and vendor support, evaluate Kubecost: read the current licence and free tier limits, plan for icr.io access, and install it side by side.
  8. Revisit node pool sizing only after requests are honest. With Karpenter or Cluster Autoscaler, smaller requests are what let nodes go away.

How to choose

  • If you need an open, free cost allocation baseline and already run Prometheus, start with OpenCost.
  • If you want a supported product with automation, multi-cluster views and budgets, and your organisation is comfortable with IBM licence terms, evaluate Kubecost. On EKS, check the AWS optimised bundle first.
  • If the real problem is inflated requests rather than missing reports, start with KRR, and keep the changes in git.
  • For most teams, OpenCost plus KRR is a sensible first pair: one shows the waste, the other proposes the fix.
  • Pick one source of cost truth; do not run two allocation tools for months without an owner.

Revisit checklist

  • Are we adding nodes because usage grew, or because requests were copied from an old template?
  • Do most workloads carry team and environment labels that finance can map to cost centres?
  • Is our Prometheus retention long enough to cover month-end and batch peaks?
  • Do our cost numbers include discounts and commitments, or only list prices?
  • Who reviews request changes, and how do we roll back if a service gets throttled or OOMKilled?
  • For Kubecost: which tier are we on, what are its current limits, and when did we last re-read the licence?
  • Is idle cost shown to teams, or hidden in a shared platform line that nobody owns?

Closing

Adding another node when the bill rises, or buying another dashboard when finance asks questions, is a habit worth unlearning. Revisit Kubernetes cost with the mindset that fits this site: learn how allocation really works, unlearn the idea that usage graphs equal cost, re-learn requests as a financial decision, practise on one cluster with OpenCost and KRR, and apply a commercial product like Kubecost only where its extra value is clear and its licence fits your organisation.

Sources

comments powered by Disqus

Releted Posts

Container registries in 2026: revisit Harbor, Zot and CNCF Distribution before you push another image

Picture a product engineering team in Bengaluru that runs about forty microservices on Kubernetes for a B2B payments product used by NBFCs across Karnataka and Maharashtra (an invented example, not a real client).

Read more

Kubernetes autoscaling in 2026: revisit Karpenter, Cluster Autoscaler and KEDA before you scale another node

Picture a mid-size ecommerce SaaS in Ahmedabad with about 2,200 active sellers (an invented example, not a real client). Its platform team of eight runs checkout, catalogue, search and about 55 other services on Kubernetes on a public cloud.

Read more

Fluent Bit, Vector and the OpenTelemetry Collector: revisit your log pipeline before you ship more logs

A logistics company in Pune runs about 600 pods across three Kubernetes clusters. A Fluentd DaemonSet, set up in 2019 with a dozen Ruby plugins, ships about 25 crore log lines a day to Loki.

Read more