1. We Installed OpenCost, But the Numbers Didn't Match Reality
We set up a K3s cluster on-premise and installed OpenCost, a CNCF sandbox project, to get visibility into what it actually costs to run. The dashboard lit up with numbers, so we assumed the problem was solved. Then we checked those numbers against our actual power bill and hardware depreciation, and nothing lined up. The per-node unit price looked like it came from some generic "market rate," not anything tied to our own infrastructure.
This isn't an isolated case. A 2024 survey jointly conducted by CNCF and the FinOps Foundation found that 40% of organizations cited "visibility gaps" as a primary driver of Kubernetes cost overruns, while only 20% had reached FinOps maturity with active cost-reduction practices in place. Alongside overprovisioning (70%), simply not being able to see where the money goes is itself a major cost driver. If you install a tool like OpenCost but don't finish configuring it, you're still in that "can't see it" group — you've just added a dashboard on top.
2. The Cause: Default Pricing Is Based on GCP
According to the OpenCost official documentation, the default pricing for on-premise and bare-metal environments is based on "GCP us-central1 region pricing." Specifically, the defaults are roughly $0.0316 per CPU core-hour and $0.0042 per GB-hour of RAM. If you're running in the cloud, this design works in your favor automatically. As the OpenCost repository explains, the tool is built to integrate with AWS, Azure, and GCP billing APIs to reflect dynamic on-demand pricing.
The problem is that on-prem and bare-metal environments have no such billing API to connect to. OpenCost has no way to automatically infer your hardware's real cost structure — depreciation, electricity, rack space. Without a cloud API to query, it silently falls back to the default: GCP pricing. The dashboard doesn't throw an error or a warning; it just keeps showing numbers that look plausible, which makes the problem easy to miss. With Kubo, which delivers K3s as a managed service, you never have to think about this pricing assumption in the first place.
3. K3s Makes This Easier to Miss
K3s's official documentation describes it as a "lightweight, single-binary, under 100MB" fully conformant Kubernetes distribution — which is exactly why it's so often chosen for edge, home lab, IoT, and on-prem use cases. In other words, choosing K3s already raises the odds that you're in an environment with no cloud billing API to lean on.
OpenCost itself, as the CNCF blog describes, is designed around being a distribution-agnostic "common standard" for cost measurement. That generality — working the same whether you're on K3s or EKS — is a strength, but it also means there's no special handling that makes K3s "just work" correctly. Managed Kubernetes (EKS/AKS/GKE) tends to hide this problem because cloud API integration kicks in automatically; on-prem K3s doesn't get that free pass, so skipping the configuration step means you start out with skewed numbers from day one.
With a managed service like Kubo, which is K3s-based but comes with fixed, predictable pricing, this entire "tune the price model yourself" burden disappears. Cost predictability stops depending on how carefully you configured a third-party tool.
4. Getting Accurate Costs Means Setting Custom Pricing Explicitly
OpenCost lets you override pricing through its Helm chart's custom pricing configuration, using a customPricing section to specify your real unit costs.
opencost:
customPricing:
enabled: true
costModel:
CPU: 1.25
RAM: 0.50
storage: 0.25
Anything you don't explicitly override still falls back to the GCP default values described above. You need to work out your own per-unit costs — amortized server depreciation, electricity, rack and data center fees — and apply them to CPU, RAM, and storage individually before the dashboard numbers mean anything.
OpenCost was founded jointly by Adobe, AWS, Google, SUSE, and other cloud and infrastructure vendors as a vendor-neutral standard for cost measurement. But "vendor neutrality" and "automatically knowing your real costs" are two different things — the latter only happens once you, the operator, configure it explicitly. If you'd rather skip that configuration work entirely, Kubo Cloud offers a managed K3s option with fixed monthly pricing that's transparent from day one (for a 4vCPU/8GB/40GB × 3-node setup, roughly 58% of the equivalent EKS cost).
Summary
Installing a cost visibility tool doesn't automatically mean you understand your costs. Even Kubernetes's own documentation on resource requests and limits makes clear that if your allocation model is vague, no amount of accurate per-unit pricing in OpenCost will fix the underlying allocation problem. For on-prem and edge-leaning environments like K3s in particular, setting custom pricing — on top of accepting that you can't rely on a cloud billing API — is part of the job, not optional. If you'd rather skip that overhead altogether, there's also the option of starting with infrastructure whose operating cost is fixed and predictable from day one. Kubo offers managed Kubernetes on a K3s foundation at a lower cost than EKS, AKS, or GKE — before spending more time tuning a pricing tool, it might be worth comparing our pricing plans first. If cost visibility is something you're struggling with, feel free to get in touch.