Tracking Container Costs on Oracle Cloud — Why It’s Harder Than It Looks and What Actually Helps
Cloud billing used to be straightforward. You had servers, you paid for servers. Costs were predictable, allocations were simple, and IT finance teams could plan around them without too much drama.
That era is over. The shift to containers and Kubernetes has introduced a layer of complexity that most cloud cost tools were not built to handle — and for organizations running shared infrastructure on Oracle Cloud, the gap between what OCI’s native billing tells you and what you actually need to know can be significant.
The Problem With How Most Teams Track Cloud Costs Today
Oracle Cloud Infrastructure gives you solid visibility into resource consumption at the service level. You can see what your compute instances cost, what storage is running, what networking is consuming. That works reasonably well when each team or application has its own dedicated infrastructure.
But modern infrastructure does not work that way. Most enterprises have moved toward multi-tenant Kubernetes clusters — a single cluster running workloads for multiple teams, departments, or products simultaneously. The reason is sensible: fewer clusters means better resource utilization, lower management overhead, and less fragmentation across environments.
The problem is that OCI’s cost tools see the cluster, not what’s inside it. You get a number for the whole thing, but no way to break that down by namespace, deployment, or workload. If your data science team and your product team are both running jobs on the same cluster, you have no reliable way to tell who consumed what — or to charge back costs accurately.
For GPU infrastructure, this becomes a real financial governance issue. GPUs are expensive and relatively scarce. Organizations consolidating GPU workloads into shared clusters to maximize utilization are making a smart operational call — but without workload-level cost visibility, the finance conversation becomes a mess.
What OpenCost Actually Does
OpenCost is an open-source project built specifically for this gap. It sits between your Kubernetes environment and your cloud provider’s billing data, and gives you cost visibility at the resource level that matters — namespace, pod, deployment, node, and cluster.
It works by using Prometheus — a widely adopted open source monitoring tool — to collect and store metrics about infrastructure usage. That data is then surfaced through several interfaces depending on how your team prefers to work:
A UI console for visual cost breakdowns
An API you can query programmatically
A kubectl plugin for teams that live in the terminal
Prometheus metric exporters for teams building custom dashboards in Grafana or setting up cost alerts via AlertManager
CSV export for anyone who needs to get this data into a spreadsheet or reporting tool
An MCP server that allows AI agents to access cost allocation data through a standardized interface
The result is that you can answer questions that were previously unanswerable — which team’s workloads are consuming the most resources, how costs have trended over time, and where inefficiencies are hiding across a shared cluster.
Running This on Oracle Cloud Infrastructure
OpenCost supports OCI natively. You can install it on OKE clusters or on Kubernetes running directly on OCI through Cluster API. The setup process involves installing Prometheus, creating an OpenCost namespace, configuring cluster pricing, and then installing OpenCost itself.
One useful detail: OpenCost automatically detects OCI as the cloud provider by reading node configuration data. When it does, it pulls pricing information directly from the OCI Price List API — no API key required for public pricing data. If you want to see your actual billed costs including any negotiated discounts, you can configure the OCI authorizer to connect OpenCost to your specific account billing data.
The end result is a cost monitoring setup that reflects what your organization is actually spending, broken down in a way that maps to how your teams are structured and how your workloads are organized.
Why This Matters Beyond the Technical Detail
Cost visibility at the Kubernetes level is not just a DevOps or platform engineering concern. It feeds directly into how organizations make decisions about infrastructure investment, how they structure internal chargebacks, and how they justify cloud spend to finance leadership.
Without it, organizations running shared Kubernetes infrastructure on OCI are essentially flying with instruments that only show altitude, not fuel consumption per passenger. You know how much the cluster costs. You do not know who is responsible for how much of it.
OpenCost closes that gap in a way that works with Oracle’s existing tooling rather than replacing it. OCI handles billing at the service level. OpenCost handles the Kubernetes-level granularity that sits below it. Together they give you the full picture.
A Few Things Worth Knowing Before You Start
OpenCost is open source, which means no licensing cost — but it does require Prometheus in your cluster, some configuration work upfront, and ongoing attention to make sure the cost data stays accurate as your infrastructure evolves.
If you’re already running OKE and want to understand what your cluster spend actually looks like by team or workload, OpenCost is worth evaluating seriously. If you’re still working out your Oracle Cloud infrastructure strategy more broadly, this is a useful starting point.
For teams running a mix of cloud and on-premise Oracle environments, understanding how costs flow across both environments is often the harder conversation — and the more important one. If your organization is navigating that complexity and wants a structured conversation about it, there are people who can help.
