OpenCost for Kubernetes: How to Set Up Open-Source Cost Monitoring

OpenCost is an open-source, vendor-neutral tool for measuring and allocating Kubernetes infrastructure costs. A CNCF Incubating project, it was originally built by Kubecost (now IBM/Apptio) and donated to the foundation in June 2022. It runs in-cluster as a Golang service, pulls metrics from Prometheus and the Kubernetes API, and maps them to actual cloud costs by namespace, workload, node, and label. With 6,616 GitHub stars and backing from IBM, Google, AWS, and Azure, OpenCost has emerged as one of the most widely adopted open-source tools for Kubernetes cost monitoring, a standing reinforced by its CNCF Incubating status and FinOps Foundation certification.

Key Learnings

This guide covers how to install OpenCost, what it exposes once running, where it falls short, and what to do after you have visibility.

• Learn how to install OpenCost with Helm, what it measures, and where it fits in a Kubernetes FinOps workflow.
• OpenCost is free and open source under the Apache 2.0 license, with no paid edition or feature restrictions.
• Attribute Kubernetes costs by namespace, workload, pod, node, labels, and annotations for detailed cost visibility.
• Integrate with AWS, Azure, and Google Cloud billing APIs to estimate infrastructure costs using cloud provider pricing.
• Understand OpenCost’s limitations, including the lack of automated optimization and rightsizing recommendations.
• See how OpenCost’s FinOps Foundation–certified allocation methodology provides the foundation for accurate Kubernetes cost reporting.

What Is OpenCost?

OpenCost measures what Kubernetes workloads actually cost. It does not optimize, recommend, or automate. That distinction matters before you deploy it, because teams sometimes install it expecting an all-in-one cost management solution and find a monitoring tool instead.

The project was created by Kubecost and donated to the CNCF as a vendor-neutral allocation engine. The CNCF accepted it into Sandbox in June 2022 and promoted it to Incubating status in October 2024. The OpenCost GitHub repository is written in Go under the Apache 2.0 license. The latest release as of this writing is v1.120.4 (Helm chart opencost-2.5.22). Kubernetes 1.21 and later are supported.

OpenCost is FinOps Foundation certified. Its allocation methodology aligns with FinOps standards. That matters if your organization runs charge-backs or show-backs across engineering teams, because the numbers OpenCost produces map to a recognized framework rather than a proprietary calculation.

How OpenCost Works

OpenCost runs as a Kubernetes deployment inside your cluster. The data flows like this: the Kubernetes API and kube-state-metrics feed resource usage into Prometheus. OpenCost’s exporter reads those metrics and combines them with cloud pricing data from billing APIs. The cost allocation engine maps results to individual workloads, namespaces, nodes, and labels. Output is available via a REST API on port 9003 and a web UI on port 9090.

OpenCost uses two pricing layers. The first is real-time on-demand pricing pulled directly from cloud provider APIs. The second is reconciliation against actual cloud billing data: AWS CUR via Athena, Azure Rate Card, and GCP Billing. On-demand pricing is available immediately. Reconciled costs take 24-48 hours to populate but reflect actual spend more accurately, especially if you have reserved capacity or savings plans.

How to Install OpenCost on Kubernetes (Helm)

Helm is the only supported install method. Reference the official OpenCost documentation for the full values schema and advanced configuration options.

Prerequisites: Kubernetes 1.21 or later, kubectl configured against the target cluster, Helm 3.x.

Step 1: Install Prometheus

OpenCost requires Prometheus to collect resource usage metrics. If you already have Prometheus running, skip this step and configure OpenCost to point to your existing instance via values.yaml.

To install a fresh Prometheus instance with the correct scrape configuration:

helm install prometheus --repo https://prometheus-community.github.io/helm-charts prometheus \
  --namespace prometheus-system --create-namespace \
  --set prometheus-pushgateway.enabled=false \
  --set alertmanager.enabled=false \
  -f https://raw.githubusercontent.com/opencost/opencost/refs/tags/v1.120.4/kubernetes/prometheus/extraScrapeConfigs.yaml

(The tag v1.120.4 is OpenCost’s release tag; this pins the scrape configuration to a tested version of OpenCost’s recommended Prometheus setup.)

The extraScrapeConfigs.yaml adds the scrape targets OpenCost needs. Without it, the exporter will not find the metrics it expects and cost data will not populate.

Verify Prometheus pods are running before proceeding:

kubectl get pods -n prometheus-system

Step 2: Add the OpenCost Helm Chart

helm repo add opencost-charts https://opencost.github.io/opencost-helm-chart
helm repo update

Step 3: Create a Namespace

The Helm install command below creates the namespace automatically with --create-namespace. This step is here if you need to create it separately or apply labels before installing — for example, to attach a cost center label to the namespace itself:

kubectl create namespace opencost

Step 4: Create values.yaml

Create a values.yaml before installing. At minimum, tell OpenCost where your Prometheus server is and give the cluster a stable ID. The cluster ID appears in all API responses and the UI, so use something meaningful.

opencost:
  prometheus:
    internal:
      namespaceName: prometheus-system
      serviceName: prometheus-server
      port: 9090
  exporter:
    defaultClusterId: "my-cluster"
    resources:
      requests:
        cpu: "10m"
        memory: "55Mi"
      limits:
        memory: "1Gi"
  ui:
    enabled: true

The resource requests are conservative. The exporter is lightweight and typically stays well below the memory limit. Increase the limit if you run a large cluster with long Prometheus retention or many labels.

Step 5: Install OpenCost

helm install opencost opencost-charts/opencost --namespace opencost --create-namespace -f values.yaml

Verify OpenCost pods are running. Cost data typically appears within 5-15 minutes of deployment:

kubectl get pods -n opencost

Step 6: Access OpenCost

Forward the ports:

kubectl port-forward --namespace opencost service/opencost 9003 9090

This single command forwards both ports. Keep the terminal open — the port-forward closes when you exit it. For persistent access, consider using Ingress or a LoadBalancer service in non-local environments.

Open the UI at http://localhost:9090. Query the API directly at:

http://localhost:9003/allocation/compute?window=60m

The API returns JSON. The window parameter accepts values like 7d, yesterday, or an explicit date range. You can slice results by namespace, controller, label, or pod using the aggregate parameter.

RBAC note: The Helm chart creates the necessary RBAC resources automatically, including a ClusterRole with read access to nodes, pods, namespaces, and PersistentVolumes. If OpenCost pods start but cost data does not populate, check for permission errors with:

kubectl describe clusterrolebinding opencost

In RBAC-restricted clusters, a missing or misconfigured ClusterRoleBinding will cause OpenCost to fail silently. Verify the ServiceAccount binding before assuming a configuration problem elsewhere.

Step 7 (Optional): Cloud Billing Integration

Out of the box, OpenCost uses on-demand list pricing from cloud APIs. That is accurate enough for relative comparisons within a cluster. For reconciliation against your actual invoice, configure cloud billing credentials in values.yaml:

• AWS: CUR export to S3 and Athena query credentials
• Azure: Rate Card API service principal credentials
• GCP: Billing API export to BigQuery credentials
• On-premises: custom CSV pricing file mapping instance types to hourly costs

OpenCost can integrate with AWS CUR, Azure Rate Card, and GCP Billing APIs to show actual on-demand rates, replacing static list pricing. However, it does not reconcile negotiated discounts, committed-use discounts, savings plans, or enterprise discount programs (EDP/EDA). The gap between on-demand and effective negotiated rates can reach 30-50% for enterprise accounts, according to observed patterns from enterprise cloud cost audits; the exact gap varies by provider, commitment tier, and portfolio size. Reconciled costs appear after a 24-48 hour delay.

What OpenCost Shows You

Once running, OpenCost gives you cost allocation across every meaningful Kubernetes dimension. The data model is straightforward and covers everything you need for Kubernetes cost allocation across teams and environments.

Resource and Workload Dimensions

OpenCost tracks CPU, memory, GPU, Persistent Volume storage, and network egress costs. Network egress breaks down by zone, region, and internet traffic, which is useful for identifying cross-zone data transfer costs that are easy to miss on the cloud bill.

Each cost dimension is available per cluster, node, namespace, controller kind (Deployment, StatefulSet, DaemonSet), controller name, service, pod, and any Kubernetes label or annotation. The label and annotation grouping is especially powerful. Label your workloads with team=payments or env=production and OpenCost surfaces the cost breakdown by those labels automatically, with no custom instrumentation required. These dimensions power showback and chargeback processes, enabling teams to attribute costs to the teams, products, or cost centers that generated them.

Supported Cloud Providers

OpenCost integrates with AWS, Azure, GCP, Oracle Cloud, DigitalOcean, and STACKIT. On-premises and bare-metal clusters are supported via a custom CSV pricing file. OpenCost uses the same allocation engine regardless of the underlying pricing source.

Where OpenCost Stops

OpenCost is a visibility tool. It does not act on what it finds. Understanding these limits before deployment saves the frustration of discovering them in production when your FinOps team asks why nothing has changed after a month of dashboards.

• No rightsizing recommendations. OpenCost shows you that namespace X spent $800 last week. It does not tell you that its pods are 60% over-provisioned or suggest target resource requests.
• No automation. OpenCost reads the cluster state. It writes nothing back.
• No built-in alerting. Spend alerts require Prometheus AlertManager plus custom recording rules and alert policies.
• No governance or policy enforcement. Teams can continue to over-provision without guardrails.
• No negotiated discount reconciliation. OpenCost integrates with AWS CUR, Azure Rate Card, and GCP Billing APIs to replace static list pricing with actual on-demand rates. What it cannot do is reconcile committed-use discounts, savings plans, or negotiated enterprise rates (EDP/EDA). Enterprise teams using these instruments will see a gap between OpenCost’s reported costs and their actual cloud bills. This reconciliation gap can reach 30-50% for organizations with significant committed use, according to observed patterns from enterprise cloud cost audits; the exact gap varies by provider, commitment tier, and portfolio size. If that gap matters for your charge-back model, consider Kubecost commercial, which adds discount reconciliation on top of the same OpenCost allocation engine.
• No multi-cluster federation in OSS. Each OpenCost instance reports on one cluster. Aggregating across dozens of clusters requires building something on top.
• No SaaS option. OpenCost is self-hosted. You manage the deployment, storage, upgrades, and retention.
• No Spot or reserved instance optimization.

None of these are criticisms of the project. OpenCost does its defined job well. But if your goal is to reduce costs rather than observe them, you need to add more tooling on top.

OpenCost vs Kubecost vs Cast AI

Here is a quick comparison across the three tools. For a broader view of the tooling landscape, see the best Kubernetes cost optimization tools.

The key distinction is the layer each tool operates at. OpenCost measures. Kubecost commercial measures and recommends. Cast AI measures and acts.

If you evaluate Kubecost on Kubernetes for its recommendations layer, note that Kubecost’s core engine is OpenCost. The commercial product adds features on top of the same allocation foundation OpenCost provides for free.

What Comes After OpenCost

OpenCost tells you where money is going. That is genuinely useful, especially early in a cost awareness program. But visibility without action is just an expensive dashboard.

Teams that extract the most value from OpenCost pair it with an automation layer. The typical pattern works like this:

• OpenCost identifies which namespaces and workloads drive the largest costs
• The team reviews request-to-limit ratios against actual usage data
• An automation layer handles the changes: rightsizing pods, cycling in Spot nodes, and scaling down idle capacity

Cast AI is built for that third step. It reads the same cluster signals OpenCost surfaces and acts on them autonomously. You get automated node rightsizing, Spot instance lifecycle management, and workload bin-packing to reduce node count. At 500 nodes, manual rightsizing is not a realistic workflow. Automation is the only path to capturing the full savings opportunity at that scale.

Cast AI customers typically see 50-75% reduction in Kubernetes infrastructure spend. The two tools do not compete. OpenCost handles visibility. Cast AI handles execution. Together they cover the full loop: measure, understand, act.

To see what that combination looks like for your cluster, start with a Cast AI demo.

Conclusion

OpenCost is the right starting point for any team that wants to understand Kubernetes costs without a commercial tool. It installs in minutes via Helm, runs on minimal resources, and provides cost allocation across every Kubernetes dimension that matters. CNCF Incubating status and FinOps Foundation certification confirm that the methodology is sound and maintained by a broad community of contributors.

The ceiling is clear: OpenCost is a monitoring tool. Reducing costs requires acting on the data it provides. If your goal is to lower the bill rather than understand it, visibility is the first step, not the last one.

Frequently Asked Questions