Kubernetes showback by team: splitting a shared cluster fairly

Quick answer

Kubernetes showback splits a shared cluster's cost across the teams using it. The cluster bills for nodes, not for teams, so you allocate node cost down to workloads using Kubernetes metadata: map namespaces or labels to teams, and split each node's cost across the pods on it by their resource requests (or actual usage). Add the unschedulable overhead, idle node capacity, system pods, control plane, split proportionally or held as a shared platform cost. Tools like OpenCost or Kubecost automate this. The core idea is that requests, not raw usage, are usually the fairest basis, because a team reserving capacity costs the cluster whether or not it uses it.

A shared Kubernetes cluster is efficient to run and miserable to allocate. The cloud bill shows node costs, EC2 or GKE or AKS instances, but the whole point of Kubernetes is that many teams' workloads share those nodes, so the bill says nothing about who used what. Without allocation, a shared cluster is a black hole in your cost model where a big chunk of spend has no owner. Showback by team fills it in, using the cluster's own metadata to split node cost down to the teams that drove it, the Kubernetes-specific case of cluster cost allocation.

From node cost to team cost

The allocation chain goes node to pod to team. You know each node's cost from the cloud bill. You know which pods ran on which node from Kubernetes. And you map pods to teams via namespace or labels, most organizations give each team its own namespace, or label workloads by team. Sum the pod costs per team and you have showback. The only real question is how to split a node's cost across the pods sharing it, and that choice, requests versus usage, is where fairness lives.

Requests versus usage

Basis	Splits node cost by	Fair because
Resource requests	CPU/memory each pod reserves	Reserved capacity costs the cluster regardless of use
Actual usage	CPU/memory each pod consumes	Reflects real consumption

The common and usually fairer basis is resource requests, what each pod reserves, not what it uses. Here is why: Kubernetes schedules by requests, so a pod requesting 2 CPU reserves that capacity on the node whether or not it uses it, and that reservation prevents other teams from using the space. A team that over-requests costs the cluster real capacity even while idle, so charging by requests holds it accountable for the reservation. Charging by usage lets an over-requesting team look cheap while hoarding capacity, which is whyrequests and limits drive cost.

The overhead nobody requested

A cluster's cost is more than the sum of application pod requests. There is idle node capacity (nodes are never packed to 100 percent), system and daemonset pods, and the control plane. This unallocated overhead can be 20 to 40 percent of cluster cost, and how you handle it matters. You can split it proportionally across teams by their share of requests, or hold it as a shared platform cost owned centrally to incentivize the platform team to improve bin-packing and reduce idle capacity. Either way, name it explicitly rather than letting it vanish.

Automating with OpenCost or Kubecost

Doing this by hand is impractical at any real scale, so use tooling. OpenCost (the open-source standard) and Kubecost compute per-namespace, per-label, and per-team cost automatically by combining Kubernetes metadata with cloud pricing, handling the node-to-pod-to-team chain and the overhead split for you. They give teams a live view of their cluster cost, which is the visibility that cost accountability depends on. Point the tool at your cluster and cloud billing, map namespaces to teams, and showback becomes continuous rather than a monthly manual exercise.

From showback to right-sizing

Showback's real value is what it prompts. Once a team sees its cluster cost is driven by requests, the obvious move is to right-size those requests to actual usage, which shrinks its share and frees cluster capacity, a win for both the team and the platform. Showback by requests thus creates exactly the right incentive: request what you need. Feed the per-team numbers into shared cost allocation if you charge back, and price the cluster's node infrastructure against the resource catalog so the total being split is understood before the cluster even scales.

FAQ

What is Kubernetes showback?

It splits a shared cluster's cost across the teams using it. The cluster bills for nodes, not teams, so you allocate node cost down to workloads using Kubernetes metadata: map namespaces or labels to teams, and split each node's cost across the pods on it by their resource requests or actual usage. Adding the unschedulable overhead, showback gives each team a visible, fair share of a cost that the raw cloud bill leaves anonymous.

Should I allocate Kubernetes cost by requests or usage?

Usually by resource requests, because Kubernetes schedules by requests: a pod requesting 2 CPU reserves that capacity whether or not it uses it, preventing other teams from using the space. A team that over-requests costs the cluster real capacity even while idle, so charging by requests holds it accountable for the reservation. Charging by usage lets an over-requesting team look cheap while hoarding capacity, which distorts the incentive.

How do I handle Kubernetes cluster overhead in showback?

Cluster cost is more than application pod requests: there is idle node capacity, system and daemonset pods, and the control plane, often 20 to 40 percent of total. Either split it proportionally across teams by their share of requests, or hold it as a shared platform cost owned centrally to incentivize the platform team to improve bin-packing and reduce idle capacity. Either way, name the overhead explicitly rather than letting it vanish.

What tools automate Kubernetes showback?

OpenCost, the open-source standard, and Kubecost compute per-namespace, per-label, and per-team cost automatically by combining Kubernetes metadata with cloud pricing, handling the node-to-pod-to-team allocation chain and the overhead split. They give teams a live view of their cluster cost, the visibility cost accountability depends on. Point the tool at your cluster and cloud billing, map namespaces to teams, and showback becomes continuous rather than a monthly manual exercise.

How does showback lead to cost savings?

Once a team sees its cluster cost is driven by resource requests, the obvious move is to right-size those requests to actual usage, which shrinks its share and frees cluster capacity, benefiting both the team and the platform. Showback by requests creates exactly the right incentive, request what you need, so the visibility turns directly into action. Without showback, over-requesting is invisible and has no consequence, so it persists.

How does C3X help with Kubernetes cluster cost?

C3X prices the cluster's node infrastructure from Terraform against a live catalog before deploy, so the total node cost being split among teams is understood before the cluster scales. That complements showback tools, which allocate the running cluster's cost after the fact: C3X gives the forward-looking cost of the node groups and scaling configuration, so you know what the shared bill will be that showback then divides.

What to do next

Know your cluster node cost before it scales, then split it fairly. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.