Module overview
Kubernetes makes over-provisioning the rational choice for every individual team. Requests are set generously because the cost of being wrong downward is a page and the cost of being wrong upward is invisible. Multiply that by every workload and you get a cluster bill nobody can attribute and nobody feels responsible for. Two kinds of waste follow from that, and this module owns both. Workloads reserve more CPU and memory than they ever use, and pods that cannot be evicted pin otherwise-empty nodes in place so the autoscaler can never remove them. Good looks like a cluster bill where every line has an owner, requests that match what workloads actually use, and an autoscaler free to remove a node once nothing needs it.How the module works
Three capabilities, one per tab: cost allocation answers where the money goes, right-sizing and pod placement are the two ways it gets the money back.Cost allocation
Node cost is derived from instance type, region, operating system and lifecycle, then split across CPU and memory and attributed to the pods scheduled on the node. Resource requests drive the attribution, not usage, so the number a team sees is the capacity it reserved. The Allocation tab groups that by cluster, namespace or service, over a time window you pick. Each row carries CPU and memory hours, share of allocated cost, unallocated resources and total cost. Unallocated is node capacity no pod requested — it appears as its own column when grouping by cluster and as an aggregated row otherwise.Right-sizing
Per-workload CPU and memory recommendations are calculated over a 30-day sliding window from the percentile your policy sets, plus that policy’s buffers and limits. A workload needs at least seven days of history before it gets a recommendation. The Right Sizing tab lists workloads with their recommendations, active and potential savings, how many of their pods are already right-sized, and which policy governs them. Where a workload has no recommendation the row says why: it is still collecting data, it has not been seen in two days, it is managed by an HPA, or its QoS class is excluded by the policy. Applying is done by the admission controller, which mutates the pod on admission and labels it. Deployments and other controllers are never edited.Pod placement
Pods that cannot be evicted — those using local storage, those protected by a PodDisruptionBudget with no disruptions allowed, and those carryingcluster-autoscaler.kubernetes.io/safe-to-evict: "false" or karpenter.sh/do-not-evict: "true" — block a node from being scaled down even when the
rest of it is idle.
The admission controller detects them at creation and adds a soft node affinity that prefers
nodes already labelled komodor.com/unevictable=true, grouping them together and freeing the rest
of the cluster for scale-down. The affinity is a preference, so a pod that cannot satisfy it is
scheduled normally; existing affinities and taints are never overridden, and DaemonSets are ignored.
The Pod Placement tab shows per-cluster potential and active savings, and carries the enable and
disable action. Placement is turned on per cluster, not per workload.
Configuring right-sizing
Right-sizing is driven by policies, under K8s Cost → Settings → Right-Sizing Policies. A policy selects workloads and states how aggressively and when to resize them.
Apply Immediately needs Kubernetes 1.33 or later with the
InPlacePodVerticalScaling feature gate.
Workloads that cannot take an in-place resize — Windows pods, init and ephemeral containers, and any
change that would alter the pod’s QoS class — fall back to on-creation behaviour rather than being
restarted.
To take a single workload out of automation regardless of policy, turn off its Automated toggle
on the Right Sizing tab. To exclude it at the source, annotate it:
Module enablement
Cloud pricing is read from the providers’ public price lists and spot price history, refreshed daily
for on-demand and hourly for spot. Where a price cannot be resolved, K8s Cost → Settings
→ Discount Settings also holds the fallback CPU and memory monthly costs used instead.
Turning it on
1
Open Modules → Overview
Kubernetes Cost appears in the Cost Optimization family. It is enabled per account.
2
Connect your first cluster
K8s Cost → Settings → Configured Clusters → Add cluster walks three steps: name the cluster,
run the Helm command it gives you, and wait while it confirms the agent reporting in. The
command carries the installation key already filled in, with a copy button. Asking the co-pilot
to connect a cluster opens the same three steps.The agent installs in cost mode: metrics and live cost data only. It does not read pod logs or
exec into containers.
3
Wait for data
Cost data becomes available 24 hours after your first cluster connects. Right-sizing needs seven
days of history per workload; until then a banner names the clusters still collecting.
4
Create a right-sizing policy and enable placement
Add a policy under K8s Cost → Settings → Right-Sizing Policies to start applying recommendations, and
enable pod placement per cluster from the Pod Placement tab.
What you see when it runs
Overview carries total monthly cost split into allocated and unallocated, potential savings from right-sizing and pod placement, and the impact already realised — right-sized savings, automated workload count, placement savings, automated cluster count, and under-provisioned containers fixed. Allocation, Right Sizing and Pod Placement each hold the table behind one of those numbers, filterable by cluster and exportable. A right-sizing row expands into per-container usage against its recommendation, so you can see the evidence for a number before automating the workload. K8s Cost → Settings → Configured Clusters lists every K8s Cost agent reporting in with its version, when it was connected and how long ago it last sent a heartbeat. Agents that have stopped reporting are hidden until you turn on Show inactive agents. Opening a row shows the agent’s id, chart version, Kubernetes version and full reported Helm values, with credential-shaped values redacted. Every policy change and placement toggle is recorded in the audit log.Next steps
Cloud Cost
The same loop one layer down, on your cloud vendor bill.
Roles & permissions
Which role carries each cost capability.