OpenCost is an open-source-based CNCF project that provides "real-time cost monitoring of Multi-Cluster & Cloud for Kubernetes.
Key Features of OpenCost
- Real-time cost allocation by cluster, node, namespace, pod, service, and more
- Multi-cloud cost monitoring for AWS, Azure, and GCP
- Dynamic Kubernetes asset pricing via cloud billing API integrations
- Supports on-prem Kubernetes clusters with custom pricing models
- In-cluster resource allocation (CPU, GPU, memory, persistent volumes)
- Prometheus integration for cost data export
- Carbon cost tracking for cloud resources
- Support for external costs (e.g., Datadog) through OpenCost Plugins
- Fully open-source under an Apache 2.0 license
OpenCost addresses this need as an open-source tool designed to make Kubernetes cost management more accessible and standardized. It’s currently being used by all hyperscalers with native API directly getting their publicly available Price Lists.
Top comments (2)
Useful compact overview, especially the OpenCost + Prometheus framing. One edge case I keep seeing in chargeback reviews: namespace/pod allocation is measurable, but not always audit-defensible tenant attribution.
The OpenCost spec separates workload costs from shared and idle costs, and says workload costs can aggregate by label, annotation, namespace, cluster, etc. In your implementations, when a workload retries work for another tenant or a CI/job step runs after ownership changes, do you treat namespace/service ownership as enough, or do you require the tenant identity to be carried at the destructive call site?
I am trying to separate “OpenCost can report this dimension” from “finance can defend this as tenant chargeback.”
@ibbus I converted my tenant-attribution review into a very narrow OpenCost triage around three known failure modes:
1) Post-upgrade allocation inflation when node labels miss instance_type (#3620)
2) PVC attribution drops when persistentvolume fields are missing (#2851)
3) idleByNode requests collapsing to cluster-level idle (#3402)
Current decision rule is simple: any observed failure = RED (not chargeback-defensible), unknown checks = AMBER, all clear with evidence = GREEN.
Could you challenge one rule from real FinOps practice: what is wrong or incomplete in that decision logic? A useful response for me is one concrete correction, one scoped inquiry, one better citation, or a direct no-fit objection.