Pricing Kubernetes in your own data center

Cloud clusters arrive with a bill attached. Clusters in your own data center don't: the servers were bought years ago from a capital budget, the power is on a facilities invoice, the rack space is a lease, and the support contract renews once a year. None of it reaches the team that runs a namespace on the cluster, so data center capacity looks free, and free capacity gets used generously.

The fix is not a different allocation method. It is a price. Give every node an hourly cost, and everything that works for cloud clusters (allocation, idle cost, rightsizing, chargeback) works here too.

Four inputs to a rate card

Power is the input most often under-counted. Servers are only part of a data center's load: cooling, power distribution and lighting add to it. The industry measures this as power usage effectiveness (PUE), total facility power divided by IT power. Uptime Institute's 2024 global survey put the average at 1.56, essentially unchanged for several years (Uptime Institute, Global Data Center Survey 2024). If your facility doesn't measure its own, 1.56 is a defensible starting point.

A worked example

One general-purpose server, bought for $40,000 and depreciated over 48 months, with 64 vCPU and 512 GiB of memory. It averages 0.6 kW, power costs $0.15 per kWh, and space and support come to $150 a month.

hardware  = 40,000 / 48                    = 833.33power     = 0.6 kW x 1.56 x 730 h x 0.15   = 102.49space and support                          = 150.00total                                      = 1,085.82 per month

Split it 50/50 between CPU and memory, as in the cloud, and divide by capacity and hours:

Two things follow. First, a team running 16 vCPU of requests around the clock on this cluster now has a cost: about $136 a month, before memory. Second, the cluster's idle capacity has a cost too, which turns "we have spare servers" into a number someone can weigh against the next hardware order.

Unit rates or amortized hardware

There are two ways to express the result. Unit rates per vCPU-hour, GiB-hour and GPU-hour are simple and match how cloud prices are quoted. Amortized hardware, the purchase price and monthly costs attached to the nodes they cover, keeps the link to the actual assets, which is useful when finance wants the rate card to add up to the depreciation schedule. KubeOn's rate card accepts either, matched to nodes by pool or label:

# rate-cards/dc1-standard.yamlapiVersion: kubeon.io/v1kind: RateCardmetadata:  name: dc1-standardspec:  currency: USD  effectiveFrom: "2026-01-01"  # Option 1: unit rates, per node pool or node label  rates:    - match: { nodeLabel: "node.kubernetes.io/pool=general" }      vcpuHour: 0.0312      memoryGiBHour: 0.0041    - match: { nodeLabel: "node.kubernetes.io/pool=gpu" }      vcpuHour: 0.0312      memoryGiBHour: 0.0041      gpuHour: 1.18  storage:    - storageClass: ceph-rbd      gibMonth: 0.06  # Option 2: amortized hardware, spread across the nodes it covers  hardware:    - match: { nodeLabel: "kubeon.io/rack=r12" }      purchasePrice: 184000      depreciationMonths: 48      monthly:        power: 1450        space: 900        support: 610

Keep it honest

• Date every rate card. A new support contract or power price changes next month's rates, not last year's.
• Review it yearly with finance. The rate card is the invoice for these clusters; it should be as defensible as one.
• Keep idle visible. Owned hardware that sits unused is still depreciating. Report it, so capacity planning sees it.
• Compare like for like. When you compare on-premises and cloud costs, include the same things on both sides: support, power and staff time are part of the data center number, and commitments and data transfer are part of the cloud one.