Platform Monkey ctx

OpenCost and Kubernetes FinOps: Real Costs, Not Estimates

· By
Sources

Most Kubernetes "cost monitoring" tools are essentially fancy calculators that multiply average CPU usage by a static price. For a Senior Principal Engineer, this is useless—it's an estimate, not a cost. In production, the gap between an "estimated cost" and the actual cloud invoice is where budgets go to die.

OpenCost shifts the paradigm from estimation to attribution. By treating the Kubernetes cluster as a shared asset and using a strict max(requested, used) allocation model, it creates a mathematically defensible link between a Pod's resource footprint and the cloud bill.

The Architectural Blueprint

OpenCost is not a data store; it is a computation engine. It operates as a stateless layer that joins real-time resource metrics from Prometheus with dynamic pricing data from cloud provider APIs.


+-----------------------+       +-----------------------+       +-----------------------+
|  Kubernetes Cluster   |       |       Prometheus       |       |    Cloud Provider API   |
| (cAdvisor / Kube-S)    | ----> | (Metric Aggregation)  | <---- | (Price List / CUR / API) |
+-----------------------+       +-----------------------+       +-----------------------+
                                            |                               |
                                            | (Usage Query)                 | (Unit Price)
                                            v                               v
                                 +---------------------------------------------------+
                                 |                 OpenCost Engine                  |
                                 |                                                   |
                                 | 1. Identify Assets (Nodes, PVs, LBs)              |
                                 | 2. Apply Formula: max(Request, Usage) * Price     |
                                 | 3. Allocate Shared/Idle Costs                     |
                                 | 4. Map to Labels (Namespace, Team, CostCenter)    |
                                 +---------------------------------------------------+
                                            |                               |
                                            v                               v
                                 +-----------------------+       +-----------------------+
                                 |      REST API / MCP     | ----> |    Grafana / FinOps    |
                                 |      (Port 9003/8081)  |       |       Dashboards      |
                                 +-----------------------+       +-----------------------+

The Allocation Formula: The Core Mechanic

The critical technical distinction of OpenCost is the Reservation-Aware Costing model. Unlike simple usage monitors, OpenCost calculates workload cost as:


Workload_Cost = max(Resource_Requested, Resource_Used) * Unit_Price * Duration

Why max()? If a developer requests 32GB of RAM but only uses 2GB, they have effectively "locked" 30GB of capacity that the cluster cannot use for other workloads. In a production environment, this is a real cost (opportunity cost). Charging only for the 2GB used creates a "tragedy of the commons" where developers over-provision without penalty.

Idle Cost Attribution

Idle cost is the remaining capacity of a node that is neither requested nor used. OpenCost identifies this as:


Idle_Cost = Total_Node_Asset_Cost - Sum(All_Workload_Costs)

Architects must choose a distribution policy for this:

Production Implementation Guide

1. Production-Grade Deployment

For production, OpenCost should be deployed via Helm with strict resource boundaries and the CLOUD_COST_ENABLED flag to allow for future billing API integration.


# values.yaml
opencost:
  # Enable billing API integration for actual invoice reconciliation
  cloudCostEnabled: true
  
  # Cloud provider auto-detection (AWS, Azure, GCP)
  cloudProvider: "aws" 
  
  # Prometheus integration
  prometheus:
    url: "http://prometheus-server.monitoring.svc.cluster.local:9090"
    
  # Resource boundaries to prevent the engine from competing with workloads
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 100m
      memory: 256Mi

  # MCP server for AI-driven cost analysis (Opt-in)
  mcp:
    enabled: true
    port: 8081

2. The "Waste Detection" Query

The real value of OpenCost is identifying Efficiency Gaps. Use the following Prometheus query to find namespaces where the gap between requested and used resources is highest (indicating over-provisioning).


# Ratio of Actual Usage to Requested Resources
# High values (near 1) = Efficient; Low values (near 0) = Wasted
sum by (namespace) (
  container_cpu_usage_seconds_total / 
  kube_pod_container_resource_requests{resource="cpu"}
)

Production Realities

The "Discount Gap" (The OSS Trap)

OpenCost (OSS) fetches on-demand list prices. If your organization uses Reserved Instances (RIs), Savings Plans, or committed use discounts, OpenCost will over-report your costs by 30-50%. The OSS version does not reconcile against your actual monthly invoice. To solve this, you must either:

  1. Use a commercial wrapper (e.g., Kubecost) that ingests the CUR (Cost and Usage Report).
  2. Implement a custom multiplier in Grafana to approximate your effective discount rate.

Metric Cardinality Explosion

Cost metrics can become high-cardinality if you aggregate by Pod name in a high-churn environment (e.g., frequent CronJobs or Serverless pods). Action: Aggregate by controller or namespace at the Prometheus recording rule level to prevent TSDB bloat.

The "Idle" Black Hole

In highly fragmented clusters, "Idle Cost" can exceed 40% of the total bill. If you redistribute this proportionally, you might punish a highly efficient team just because their neighbors are inefficient. The architectural recommendation is to report Idle Cost as a separate Cluster Health Metric rather than a workload charge.

Who Should Skip This

References & Further Reading