Kubernetes cost optimization: where resources leak
A cluster is billed by requested, not actual, consumption: the scheduler reserves resources for requests, and capacity is considered occupied even if an application uses only a small share of it.
That is why cluster resource overspend grows faster than the real load — in steps, with each successive service scaling.
The first source is requests without limits. A developer adds headroom “just in case,” the autoscaling mechanism focuses on requests rather than actual utilization, and keeps extra replicas.
At the same time, nodes remain underutilized but are paid for in full, together with the reserved but unconsumed volume.
The second is idle nodes and unused non-production resources: test namespaces, environments left after demos, shadow data copies, and test stands that were forgotten to be shut down.
No one considers them their own because infrastructure cost accounting is not labeled by teams, services, and owners.
We break down how this is addressed: labeling of namespaces and labels, allocating the bill across consumers via Kubecost and OpenCost, request and limit policies, and automatic shutdown of idle environments.
Kubernetes cost optimization begins with answering who exactly spends and on what — without this, any savings last only until the next release.
What cost management delivers: measurable effects
The key effect of implementing cost accounting is the transition from an “approximately” estimate to figures for each namespace.
Kubecost and OpenCost compare actual scheduler metrics with requests and limits, so overspend is visible by workload rather than as a single cluster-wide sum.
Utilization and overspend by namespace
Without control, utilization stays at 15–20%: requests are set with peak headroom, and limits are not set at all. After requests are revised according to actual consumption, it reaches 45–60%, and the share of containers without limits drops to almost zero.
The failure class “overspend due to missing limits” goes away: a node stops being held hostage by one workload that consumes memory and evicts its neighbors.
Cost transparency for teams and service owners
Costs are broken down by teams and services via labels and namespaces. A service owner sees their share and how it changes after a release, rather than a general bill addressed to no one.
Test environments and temporary stands stop being “no one’s” — their consumption is visible, and it can be turned off.
A separate effect is capacity planning: the historical profile shows where real headroom is allocated, and some nodes can be removed without risking fault tolerance.
Downtime due to resource shortage decreases because scaling decisions are made based on data, not after an incident.
Approaches to Kubernetes cost accounting: comparison
The accounting model is chosen for the question that needs answering: how much the cluster costs as a whole, how much a specific team or namespace costs, and what share we pay for idle resources.
In practice, there are three approaches to cost accounting: built-in node metrics, allocation by requests and limits, and external accounting systems with the provider’s price list.
On their own, none provides the full picture, so the approaches are combined. Allocation accuracy is determined not by the tool but by the quality of labeling: namespaces, team labels, and correct limits affect the result more than the collection method.
| Approach | When it fits | Limitations |
|---|---|---|
| Built-in node metrics | Need overall utilization and a quick estimate without additional components | No breakdown by teams and namespaces; overhead is not allocated |
| Allocation by requests and limits | Namespace labeling exists; need to split costs between teams | Overstates with excessive requests; actual consumption is not visible |
| External accounting system, e.g. Kubecost | Need provider rates, overhead allocation, and reporting by teams | Depends on access to price lists and stable labels; labeling errors distort the report |
| Reconciliation with the final bill | Need convergence control and identification of unallocated remainder | Only the overall total is visible, without breakdown by workloads |
When built-in metrics accounting fits
If the task is to see the skew between requests and actual consumption and understand how many nodes are idle, built-in metrics are sufficient. They are quick to enable, do not require access to billing, and provide a first estimate in days rather than weeks.
Limitations of external cost allocation
An external system always leaves an unallocated remainder: shared overhead, idle resources, disks, and network without attachment to a workload.
The higher this share, the lower the trust in the report, so allocation is calibrated regularly — otherwise the limitations of estimation methods outweigh the benefit of granularity.
Implementation stages: audit, scheme, verification, handover
Implementing cost allocation is not installing a metrics collector but a sequence of steps where an early mistake devalues everything that follows.
The order below is arranged so that each next step relies on a verified previous one, and the final figures converge with the actual infrastructure bill.
- Workload inventory and cluster audit: a list of namespaces, workloads, owners, and actual consumption. Without this, half of the cost remains unallocated.
- Cost allocation scheme: a “team — service — environment” hierarchy, rules for assigning shared resources, and procedures for handling idle capacity.
- Collection setup: the agent captures consumption and matches it with provider rates; reports are exported where they are actually read.
- Reconciliation of calculations: compare the total with the actual bill for the period and analyze discrepancies by category until the deviation falls within the margin of error.
- Threshold setup: limits per team and service, alerts on exceedance and on abnormal consumption growth within a day.
- Documentation handover: a procedure for reading reports, the process for disputing questionable items, and those responsible for responding to alerts.
Roles and control points at each step
Our engineers carry out the inventory and collection setup; the domain owner approves the allocation scheme and thresholds; the person responsible for the infrastructure budget confirms the reconciliation.
The transition to the next step occurs only after acceptance of the previous one: discrepancies surface during reconciliation, not in a report for executives.
Implementation artifacts: configurations, schemes, procedures
Implementation artifacts are not an acceptance report but working files that remain in your repository and wiki. Six months later, no one will remember why a service has exactly this limit and who approved the team’s quota if the answer is not next to the configuration.
Configurations and access policies
- Request and limit manifests by namespace, with separation into permanent and temporary values — with a comment on where the figure came from.
- Quota objects per namespace and per team: a ceiling on CPU, memory, and number of pods so that one experiment does not consume neighbors’ budget.
- Cost allocation scheme: rules for matching labels, namespaces, and teams by which expenses are allocated to owners.
- Access policies for the dashboard: a “view-only” role for teams, with permission to change limits held by the platform group.
- Configured threshold-breach alerts: to whom, at what deviation, and at what frequency they arrive.
- Instructions for connecting a new cluster and namespace to accounting — so the scheme does not fall apart as it grows.
Procedure for regular limit review
The document defines the cycle: monthly we reconcile actual consumption with the set limits; quarterly we review team quotas. It records the responsible parties, the deviation threshold at which the limit changes, and the rollback procedure. A separate section covers what to do with services that cannot be attributed to an owner.
Case study: how overspend in a cluster was reduced
The cluster grew for experiments: resource requests were set with headroom, environments were created for tasks and not deleted, and no one compared spend with actual consumption.
After a few months, a significant portion of reserved capacity was idle, and it was no longer possible to determine which team occupied it. The analysis began with accounting: Kubecost provided a breakdown not by the overall cluster bill but by namespaces, workloads, and owners.
Before and after
| Metric | Before | After |
|---|---|---|
| Share of idle requested resources | 58% | 14% |
| Environments without an assigned owner | 17 | 2 |
| Time from spend anomaly to response | 8-10 days | several hours |
| Workloads with defined consumption boundaries | 31% | 89% |
What was changed: requests were brought to the 95th percentile of actual consumption over two weeks of observation, boundaries were defined for each workload, and idle environments are deleted automatically by owner label and time to live.
Alerts are configured for deviation from the baseline, and once a month owners receive a report on their namespaces.
Repeatability is ensured by the cycle itself: inventory, baseline capture, request alignment, alerts, and reporting procedure. We followed the same order on a second cluster — the idle discrepancy decreased by a comparable amount without rewriting workloads.
How do Kubecost and OpenCost differ?
OpenCost is an open model for calculating workload cost: the agent collects metrics, matches node consumption with provider rates, and allocates costs by workloads, namespaces, and labels.
Kubecost is built on the same model but adds a product layer — a UI, ready-made reports, and aggregation of multiple clusters into a single picture.
The key difference is in configuring the calculation model itself. Both tools divide node cost proportionally to requested resources rather than actual consumption, so inflated requests turn into costs that no one sees.
Kubecost allows this to be corrected with rules: evaluate idle separately, allocate shared resources, and set markups for departments. In OpenCost, such logic is described manually in the configuration.
The labeling requirements are equally strict for both: without labels for team, environment, and cost center, reports break down into an unallocated remainder.
Kubecost partially fills gaps with heuristics and label inheritance, but it is more reliable to fix the labeling scheme once in deployment templates.
The comparison of accounting tools runs into a second divide — the set of reports. OpenCost provides basic slices: costs by workloads, nodes, and namespaces, and dynamics over a period. Kubecost adds potential savings analysis, spend forecasting, and deviation notifications.
Tool choice depends on scale. On a single deployed cluster with standard metrics and a requests/limits dashboard, separate accounting does not pay off.
When there are several clusters and shared resources appear, teams start with OpenCost as an open foundation, and take Kubecost where ready-made analytics are needed without in-house development.
Technical concerns and answers
Concerns about Kubernetes cost accounting come down to four questions: estimation accuracy under autoscaling, the load from metrics collection, splitting shared nodes between teams, and already-violated limits. Below are short answers without marketing.
How accurate are estimates under constant scaling?
Cost is calculated based on consumption over an interval, not on the fact that a pod was launched: requests set a guaranteed minimum, and actual metrics refine it.
During autoscaling spikes, the figures lag by several minutes and diverge by single-digit percentages — this is sufficient for optimization decisions; for mutual settlements between teams, we fix an averaging window.
Will the accounting system overload the cluster?
Metrics are taken from already running sources and aggregated separately, so nodes incur fractions of a percent of CPU time.
We limit the collector’s memory and disk with explicit limits, store detailed data for weeks and aggregated data for months, and exclude service namespaces from collection.
How do you split costs on shared nodes?
The shared pool is allocated proportionally to requests and actual pod consumption, and the unused remainder is assigned to system namespaces.
This works with owner labels at the workload level — then the report is built by team, product, and environment without manual spreadsheets.
Limits are already violated — where to start?
With a report on overspend relative to requests, without blocking. It shows where a request is inflated several times over and where it is insufficient and pods are evicted; next we adjust limits according to the actual consumption profile, and only then enable alerts and checks.
Let’s discuss the task and come back with an estimate and plan
The analysis of the current state begins with the data you already have: environment scheme, resource labeling, and exports on actual consumption. This is enough to see where costs are not tied to a team or service and which reports are not being built at all.
Below is what to send to get started; the list is short and intentionally without production access.
- Environment scheme — clusters, namespaces, dev/stage/prod separation, owners, and team boundaries.
- Resource labeling — which labels and annotations are applied, where requests/limits are set “by eye,” and which workloads have no labels at all.
- Current reports — provider billing exports, dashboards, and metric snapshots for a representative period together with peak days.
- Workload inventory — what is business-critical, what can be limited, and what downtime is acceptable.
- Accesses — a read-only role and a service account for metrics collection, without the right to change production.
- Goals — what you consider overspend and which slices executives need: by teams, services, or environments.
Next is a request for a proposal in working format.
We compare what you send with the real consumption picture, ask clarifying questions, and come back with an estimate and implementation plan: stages, what changes in the configuration, who is responsible for each part, and which metrics we use to verify the result.
The plan includes only what can be confirmed in your environment — without promises that “we’ll implement it and it will work on its own.”
Describe the task — we’ll come back with an estimate and plan. If cost accounting is already partially set up, send what exactly is being counted and what is missing: that will make the analysis shorter.