What Is OpenCost? Setup, Limits, and When to Upgrade

OpenCost answers a question that was unanswerable for the first decade of Kubernetes: what does this namespace cost. It is free, it is a CNCF project rather than a vendor's, and it is the engine inside Kubecost and several commercial tools, so adopting it is adopting the industry's data model. For a platform team whose cluster is the whole cost question, it is often enough. The trouble starts when the cluster stops being the whole question, which in most estates happens about the time finance asks what a service costs and the answer has to include the database the pods query, the storage they read, and the egress they generate, none of which OpenCost sees.

This guide covers what OpenCost is and does, how to set it up, how it compares to Kubecost, the three limits that matter once Kubernetes is a share of the bill rather than all of it, and when to move cluster cost into a platform that allocates everything. It is the practical companion to our comparison of Kubecost alternatives and sits inside the method in our guide to container cost visibility.

What OpenCost Does

OpenCost started as the open-source core of Kubecost, was contributed to the CNCF in 2022, and became an incubating project in 2024, which gives it a neutral home and a specification other tools can implement. The engine does one thing well: it joins Kubernetes usage to cost.

How to Set It Up

1. Have Prometheus, or let OpenCost install one

OpenCost needs a Prometheus scraping kube-state-metrics and node and container metrics. If the cluster already runs one, including a managed Prometheus endpoint, point OpenCost at it; otherwise the Helm chart installs a bundled Prometheus.

2. Install with Helm

Add the OpenCost chart, set the Prometheus endpoint and the cloud provider, and install into its own namespace. The documentation covers the values; the API responds within a few minutes of pods starting. Deploy the UI chart separately if you want a browser view, or query the API from your own dashboards.

3. Configure cloud billing integration

This is the step teams skip and regret. Without it, OpenCost prices nodes at on-demand list rates, so a cluster on Spot and Savings Plans is reported at two or three times its real cost and nothing reconciles to the bill. Connect the AWS Cost and Usage Report, the Azure cost export, or the GCP billing export so node prices reflect what you actually paid.

4. Decide the allocation rules

Choose whether to charge by requests, usage, or the greater of the two (the defensible choice, since requests reserve capacity), how idle capacity is distributed, and how system namespaces are treated. These decisions determine whether teams accept the numbers, and they should be written down.

5. Expose it somewhere engineers look

The API feeds Grafana, the kubectl plugin gives a command-line view, and the UI gives a basic one. OpenCost has no alerts or routing, so whatever it finds reaches people only through what you build on top.

OpenCost vs Kubecost

Choose OpenCost when you want the data model without a vendor and have engineers to build on it; choose Kubecost when you want the product and your clusters fit the free tier or your budget fits IBM's. Both stop at the cluster edge, which is the subject of the next section, and both are compared with the alternatives in our Kubecost alternatives guide.

The Three Limits That Matter in Production

1. The cluster edge

OpenCost allocates the nodes. A service's cost is the nodes plus the RDS or Aurora cluster it queries, the S3 or Blob it reads, the NAT Gateway its traffic passes through, the egress it generates, the load balancer in front of it, and often a Snowflake warehouse downstream, which together frequently exceed the pods. OpenCost's cloud cost view lists those charges from the billing export; it does not attribute them to the namespace that incurred them, so the number it gives a team is the smaller half of what the team actually costs, the gap our guide to the hidden cloud costs around Kubernetes catalogs.

2. One cluster, one cloud, one API

Each OpenCost instance sees one cluster. Aggregating ten clusters across EKS and GKE into one view, comparing them, and allocating a product that spans several means collecting each instance's data into something you build. Allocation to business dimensions, product, customer, cost center, is likewise yours to construct on top of the namespace and label data OpenCost provides.

3. Reports, not workflow

OpenCost has no anomaly detection, no budgets, no owners, no tickets, and no record of what a finding saved. A namespace whose cost tripled overnight is visible in the API to anyone who queries it; nobody is told. For an engineer watching a Grafana panel that is fine; for a platform team responsible for forty namespaces across four clusters, it is the gap between knowing and acting.

When to Upgrade

• Kubernetes is a share of the bill, not the bill, and the RDS, S3, and egress a service uses matter.
• Finance needs cost per customer or per product for a Kubernetes-hosted application.
• You run clusters on more than one cloud, or more than a handful anywhere.
• Findings need to reach an owner as a ticket, with the saving tracked.
• You want anomalies and budgets on namespaces, not a Grafana panel someone may check.

None of these means abandoning OpenCost. The cluster-internal view it gives engineers stays useful; the upgrade is putting that view inside a platform that allocates everything around it.

How Opslyft Does This

Opslyft covers the cluster the way OpenCost does and then crosses the edge. Explorer breaks Kubernetes cost down by pod, service, and namespace, allocated from per-pod metrics and real node prices, in the same view as the EC2, EBS, load balancer, NAT, and egress around the cluster and the RDS, S3, and Snowflake the services inside it depend on, across AWS, Azure, GCP, OCI, and Kubernetes with one allocation model, so the checkout namespace's cost is its whole footprint rather than its pods. Canvas puts the cluster view on the platform team's screen and the per-product view on finance's, from the same numbers.

Dimension Studio attributes shared services to the namespaces that consume them and maps namespaces to teams, products, and customers, including the shared cluster capacity and system overhead that OpenCost leaves as an allocation decision, which is how a Kubernetes product reports cost per customer. Atlas inventories every node, volume, and load balancer with an owner and records the change behind a cost movement, and its recommendations surface the requests-versus-usage gap per workload with purpose and criticality weighed. Monitor detects namespace-level anomalies with a root cause and routes them to the owning team's Slack channel; Tickets turns each into an assigned item in Jira, ServiceNow, or Asana tracked to a measured saving; and Iris answers which namespaces grew fastest this month and why. OpenCost's API can remain the engineers' cluster-internal view underneath.

That whole-bill attribution across six platforms is what gave Disprz 100 percent automated allocation of 50 to 60 shared services to customers and 40 hours a month back.

The Bottom Line

OpenCost is the right first tool for Kubernetes cost: free, neutral, accurate inside the cluster once it knows your real node prices, and the data model the industry has standardized on. Its limits are not defects but scope. It stops at the cluster edge, it sees one cluster at a time, and it reports rather than routes, and each of those becomes the problem the moment the question shifts from what the cluster costs to what a service or a customer costs. Keep it for the engineers; when finance asks the second question, put it inside a platform that answers it. That is what Opslyft's cost visibility is built for; the Kubernetes levers it then makes actionable are in our Kubernetes cost optimization guide.