Demo Cost Visibility with OpenCost

Many platform engineers are surprised to learn their Kubernetes clusters are wasting money — not because pods are idle, but because workloads are overprovisioned. A team may request 2 CPUs per pod while actually using 50 millicores. Multiply that across dozens of deployments and the wasted spend adds up. The root cause is visibility: without tooling you can’t easily map spend to the team, namespace, or workload responsible. OpenCost fixes this by mapping Kubernetes resource usage to dollar cost per namespace, deployment, and pod in (near) real time. In this walkthrough we’ll:

Verify OpenCost and Prometheus are running.
Inspect the OpenCost UI.
Map pod and deployment resource requests to the costs OpenCost attributes.
Show how to make changes (scale/rightsizing) and where to look for the impact.
Demonstrate the OpenCost API for automation.

Prerequisites

A running Kubernetes cluster.
OpenCost deployed in the opencost namespace.
Prometheus available (OpenCost consumes Prometheus metrics).

Check that the OpenCost pod is running:

kubectl get pods -n opencost
NAME                          READY   STATUS    RESTARTS   AGE
opencost-5b676b669f-pc9hk     2/2     Running   3          78m

OpenCost consumes metrics from Prometheus. In this environment Prometheus runs in the prometheus-system namespace. For day-to-day exploration use the OpenCost UI — it provides a visual breakdown and lets you drill down by namespace, deployment, or pod. Below is an example OpenCost dashboard showing namespace cost allocation.

The image shows a cost allocation dashboard from OpenCost, displaying a chart and table that breaks down costs by namespace for a selected date. It includes details on CPU, GPU, RAM, personal volume, efficiency, and total costs in USD.

List relevant pods across namespaces so we can map costs back to workloads:

kubectl get pods --all-namespaces
NAMESPACE           NAME                                           READY   STATUS    RESTARTS   AGE
opencost            opencost-5b676b669f-pc9hk                      2/2     Running   3          78m
prometheus-system   prometheus-server-86854bc5f-qbmn5              1/1     Running   0          78m
prometheus-system   prometheus-kube-state-metrics-978b594b-cnzq8   1/1     Running   0          78m
team-backend        api-d5c5679c                                   2/2     Running   0          60m
team-data           cache-2dcff5f6d-2jm2s                          1/1     Running   0          100m
team-frontend       web-55fcdc9cf-49f9b                             1/1     Running   0          32m
team-frontend       web-5592c8e0f-7h2qm                             1/1     Running   0          32m
team-frontend       web-55fcdc9cf-lwz4q                             1/1     Running   0          32m

Summary of the running workloads (observations from the pod list):

team-frontend: several web replicas (3 total in this sample).
team-backend: two api replicas.
team-data: a single cache replica (Redis).

Inspect each deployment’s resource requests — OpenCost attributes cost primarily from resource requests (requests/limits) rather than instantaneous CPU usage, so requests drive allocated cost. Inspect the frontend deployment (web) in team-frontend:

kubectl describe deploy web -n team-frontend

In this deployment the container requests 500m CPU and 512Mi memory and the deployment is configured with 3 replicas (500m * 3 = 1.5 CPU requested across the namespace). Those requests drive the cost allocation, even if actual usage is much lower. Inspect the backend API deployment:

kubectl describe deploy api -n team-backend

Example (trimmed) output:

Name:                   api
Namespace:              team-backend
Replicas:               2 desired | 2 updated | 2 total | 2 available
Pod Template:
  Containers:
   nginx:
    Image:    nginx
    Limits:
      cpu:     200m
      memory:  256Mi
    Requests:
      cpu:      100m
      memory:   128Mi
Conditions:
  Available        True    MinimumReplicasAvailable
  Progressing      True    NewReplicaSetAvailable

The backend API requests 100m CPU and 128Mi memory per replica, so with 2 replicas it requests ~200m CPU in total. Inspect the cache deployment in team-data (Redis):

kubectl describe deploy cache -n team-data

Example (trimmed) output:

Name:                   cache
Namespace:              team-data
Replicas:               1 desired | 1 updated | 1 total | 1 available
Pod Template:
  Containers:
   redis:
    Image:    redis
    Limits:
      cpu:  500m
    Requests:
      cpu:     250m
      memory:  1Gi
Conditions:
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
Events:
  Normal  ScalingReplicaSet  38m  deployment-controller  Scaled up replica set cache from 1 to 2
  Normal  ScalingReplicaSet  34m  deployment-controller  Scaled down replica set cache from 2 to 1

Although Redis requests 250m CPU and 1Gi memory, this example only has a single replica. Deployment resource-request summary

Deployment	Namespace	Replicas	CPU request (per pod)	Memory request (per pod)	Total CPU requested
web	`team-frontend`	3	500m	512Mi	1.5 CPU
api	`team-backend`	2	100m	128Mi	0.2 CPU
cache	`team-data`	1	250m	1Gi	0.25 CPU

Why is Team Frontend more expensive in OpenCost? OpenCost attributes cost based on resource requests (and observed usage) to allocate spend to namespaces and workloads. Team Frontend requested 500m per replica across three replicas (1.5 CPUs total requested), while Backend requested only 100m per replica with two replicas (0.2 CPUs total). Those request differences explain the larger cost for frontend.

OpenCost maps requested resources (requests/limits) and observed usage to cost. Over-requesting increases allocated cost even if actual usage is low — that’s why rightsizing requests and replica counts matters.

Actionable steps: scale or rightsize based on OpenCost insights You can use the cost signals to change replica counts or adjust requests. For example, scale the frontend down and scale the cache up to better match demand (and to move costs where they belong):

# Scale frontend web down to 1 replica
kubectl scale deployment web -n team-frontend --replicas=1
# Scale cache up to 2 replicas
kubectl scale deployment cache -n team-data --replicas=2

Example responses:

deployment.apps/web scaled
deployment.apps/cache scaled

Return to the OpenCost UI and refresh. As Prometheus metrics are aggregated you should see namespace and deployment costs adjust to reflect the new requested resources and replica counts.

The image is a cost allocation dashboard from OpenCost displaying a pie chart and a table showing namespace daily costs, with details on CPU, GPU, RAM, PV, efficiency, and total cost.

OpenCost API for automation If you prefer automation or integration, OpenCost exposes an API you can query. Example: get compute allocation aggregated by namespace over the last hour and format results with jq:

curl -sG "http://localhost:3904/allocation/compute?window=1h&aggregate=namespace" | \
jq -r '
  (.data[0] // {}) 
  | to_entries[]
  | {namespace: .key, cpuCost: .value.cpuCost, ramCost: .value.ramCost}
'

Sample JSON output (trimmed):

{
  "namespace": "kube-flannel",
  "cpuCost": 0.00271,
  "ramCost": 0.00018
}
{
  "namespace": "kube-system",
  "cpuCost": 0.02307,
  "ramCost": 0.00085
}
{
  "namespace": "opencost",
  "cpuCost": 0.00054,
  "ramCost": 0.00039
}
{
  "namespace": "team-backend",
  "cpuCost": 0.00543,
  "ramCost": 0.00091
}
{
  "namespace": "team-data",
  "cpuCost": 0.00764,
  "ramCost": 0.00041
}
{
  "namespace": "team-frontend",
  "cpuCost": 0.05045,
  "ramCost": 0.00676
}

Use cases for the API:

Scheduled cost reports.
CI/CD gates to prevent cost spikes from PRs.
Automated alerts when request-to-usage ratios indicate overprovisioning.

Conclusion For exploration and fast triage, the OpenCost UI is convenient; for automation and programmatic workflows, use the API. Either way, OpenCost provides the visibility needed to identify overprovisioning, allocate cost to teams, and take concrete remediation steps like rightsizing requests or adjusting replica counts. Links and references

Course Introduction

Platform Architecture and Infrastructure

GitOps and Continuous Delivery

Platform APIs and Self-Service Capabilities

Observability and Operations

Security and Policy Enforcement

Conclusion

Demo Cost Visibility with OpenCost

Watch Video

Practice Lab