Finance wants to know what each team costs on a shared Kubernetes cluster. How do you answer them?

TL;DR: Define allocation explicitly: an OpenCost-style model uses the maximum of requested and used resources, with documented unit rates and shared-cost treatment. Requests consume scheduler accounting capacity; ordinary CPU requests do not reserve exclusive physical cores. Show allocated cost and utilization together, then reconcile to the bill.

How to approach it

Separate the measurement question from the behaviour question, because they have different answers and the second is the one that matters. Then be honest about the allocation choice, since there is no perfect one.

A strong answer

The measurement first. A node costs a fixed hourly rate whether or not the pods on it are busy, so the question is how to divide that cost among pods. Two defensible bases:

Requests affect scheduling admission. A request of four CPUs can stop other pods being scheduled even if the pod uses one, but those idle CPU cycles are not necessarily inaccessible to already-running pods. Report this gap as a scheduling-efficiency signal rather than exclusive core ownership.

Usage shows consumption above or below requests. Use a declared allocation basis such as the maximum of request and usage over each interval, with separate CPU and memory rates. This is the basis documented by the OpenCost specification. Reconcile workload, idle and shared allocations so they do not double-count the same node cost.

Then the parts that are not workload:

• Idle capacity: nodes running with nothing scheduled, plus the headroom you deliberately keep. Someone owns this and it is usually the platform team, because it is a platform decision. It is also larger than people expect, so compute it rather than assuming it rounds away: 40 nodes at $0.50 an hour is 40 × 0.5 × 730 = $14,600 a month, and if pods request 5 of each node's 8 allocatable CPUs then 1 − 5/8 = 37.5 percent of that, about 14,600 × 0.375 = $5,475 a month, belongs to no workload at all. Spreading it across teams by usage makes the platform's own capacity decisions invisible and inflates every team's unit cost by a factor they cannot influence; holding it as a named line makes headroom a reviewable choice.
• System overhead: kube-system, the CNI, log shippers, the mesh. Distribute proportionally rather than absorbing it, or the platform team's bill grows with everyone else's usage and nobody sees it.
• Non-compute: load balancers, persistent volumes, and cross-zone data transfer, which is frequently the surprise line item on a chatty multi-zone estate.

Mechanically this needs labels that are enforced rather than requested. A namespace per team with required labels, and an admission policy that rejects workloads without an owner label, because a voluntary convention produces an unallocated bucket that grows until it is the largest line on the report. OpenCost or Kubecost implement the arithmetic; the labelling discipline is the part you have to own.

Now the half that actually reduces spend. A monthly report sent to finance changes nothing, because finance cannot resize a deployment. The number has to reach the team that controls it, weekly, next to something they can act on: your requests are 3.2x your p95 usage, here are the five deployments driving it. Chargeback (real budget transfer) works in some organisations and creates gaming in others; showback (visibility without transfer) is usually enough and is far less politically expensive.

What interviewers probe next

"How do you attribute a spot interruption or an autoscaler event?" Use events to explain capacity changes, but do not assign the entire shared-node cost to whichever pending pod happened to trigger scale-up. Allocate the node over its lifetime under the agreed usage/request and shared-capacity policy. An interruption is a reliability event, not a separate cost allocation unit.

"What is the first thing you would fix?" Request accuracy, almost always. The gap between requests and usage is typically the largest single recoverable number on the report and it needs no architectural change.

"How do you stop teams gaming it?" The stated max(request, usage) allocation limits under-requesting as a billing tactic. Separately monitor contention and eviction risk; the allocation formula does not enforce resource safety.

Common mistakes

Allocating on usage, which produces a comfortable report and no behaviour change.

Ignoring shared overhead, so the platform team absorbs a cost that grows with everyone else's decisions.

Reporting to finance rather than to engineers. The bill goes to the person who can move the number.