Kubernetes has become the default platform for many cloud workloads, and with it has come a stubborn cost problem. A cluster bill is a bill for nodes, but the decisions that drive it are made in thousands of pod specifications written by different teams. Requests are padded “just in case,” autoscalers keep half-empty nodes alive, and nobody sees which namespace is responsible for which part of the invoice.
Two developments make 2026 a good moment to revisit Kubernetes cost management. In-place pod resize reached general availability in Kubernetes 1.35 in December 2025, removing one of the main obstacles to continuous rightsizing. And open-source cost tooling has matured, with the CNCF’s OpenCost project shipping frequent releases and adding features aimed at AI-driven analysis. This guide sets out the decisions that matter most, the options for each, and a checklist you can use to assess any cluster.
Why Kubernetes Waste Is Hard to See
Kubernetes cost has a structural gap. The cloud provider charges for nodes, load balancers, storage volumes and data transfer. Teams, however, think in terms of deployments and namespaces. Without an allocation layer that translates node costs into workload costs, nobody can tell whether a cluster’s spend is efficient or whether a particular service is driving it.
Waste typically accumulates in four places:
- Request inflation: pods request far more CPU and memory than they use, and the scheduler reserves that capacity whether it is used or not.
- Bin-packing inefficiency: node shapes do not match pod shapes, leaving stranded capacity on each node.
- Idle headroom: autoscalers or static node pools keep capacity running for peaks that rarely occur, or for environments nobody uses at night.
- Hidden extras: orphaned persistent volumes, oversized load balancers, cross-zone traffic and logging volumes that grow unchecked.
Decision 1: How Will You Allocate Costs?
You cannot optimize what you cannot attribute. The first decision is how to allocate cluster costs to teams, products and environments.
- Open-source allocation with OpenCost. OpenCost, a CNCF incubating project, allocates node, storage and network costs to namespaces, workloads and labels using cloud pricing data. According to the CNCF’s January 2026 review, the project shipped 11 releases in 2025, added a mode that can run without Prometheus, and included a Model Context Protocol server by default so AI agents can query cost data in natural language. Its 2026 roadmap includes a new data model and AI cost tracking.
- Commercial Kubernetes cost platforms build on similar allocation logic and add recommendations, automation and multi-cluster governance.
- Provider-native split cost allocation features in AWS, Azure and Google Cloud billing can attribute cluster costs to Kubernetes labels within the provider’s billing data, which is useful when you want cluster costs in the same reports as other services.
Whichever you choose, define a labeling standard, at minimum team, product, environment and cost center, and enforce it with admission policies. Decide how to treat shared and idle costs: allocate them proportionally, or show them as a separate platform line so platform teams are accountable for cluster efficiency.
Decision 2: How Will You Rightsize Workloads?
Rightsizing pod requests is usually the largest single saving, because requests determine how many nodes you need. The options form a spectrum:
- Manual recommendations: review usage percentiles and adjust requests in manifests. Low risk, but it does not scale and drifts quickly.
- Vertical Pod Autoscaler in recommendation mode: VPA calculates recommendations continuously; teams apply them through their normal deployment process.
- Automated vertical scaling: VPA or a commercial tool updates requests automatically. Historically this meant recreating pods, which was disruptive for stateful and latency-sensitive services.
- In-place resizing: with in-place pod resize stable since Kubernetes 1.35, CPU and memory for running containers can be changed without recreating the pod. The Kubernetes project notes the feature moved from alpha in 1.27 to beta in 1.33 and GA in 1.35. Autoscalers and rightsizing tools are adopting it, which makes continuous, low-disruption rightsizing realistic for workloads that previously could not tolerate restarts.
Practical guidance: start with recommendation mode everywhere, automate for stateless services first, and adopt in-place resizing for stateful workloads once your cluster version and autoscaler support it and you have tested how each application responds, especially to memory reductions. Do not run Horizontal Pod Autoscaler on CPU and VPA on CPU for the same workload without understanding how they interact.
Decision 3: Which Node Autoscaling Approach?
Node autoscaling determines how quickly unused capacity disappears and how well node shapes fit your pods.
- Cluster Autoscaler scales predefined node groups up and down. It is mature and widely supported but relies on node group design for efficiency.
- Karpenter, originally developed by AWS and now a Kubernetes SIG Autoscaling project with providers for several clouds, provisions nodes directly based on pending pod requirements and can consolidate workloads onto fewer or cheaper nodes. It often improves bin-packing and makes spot and multiple instance types easier to use.
- Managed automatic modes, such as GKE Autopilot and EKS Auto Mode, shift node management to the provider, and in some cases billing moves closer to pod resource requests. They reduce operational effort, but you should compare effective cost per workload carefully.
The key question is whether your team wants to own node strategy. If you have platform engineering capacity and diverse workloads, Karpenter-style provisioning with consolidation usually yields the best efficiency. If you want simplicity, managed modes trade some control for lower operational cost.
Decision 4: How Much Spot or Preemptible Capacity?
Spot capacity on AWS, Spot VMs on Azure and Google Cloud offer steep discounts in exchange for interruption risk. For Kubernetes, the right share depends on workload tolerance:
- Stateless services with multiple replicas, pod disruption budgets and graceful shutdown handling are good candidates.
- Batch jobs, CI runners and data processing with checkpointing are excellent candidates.
- Stateful databases, single-replica services and long-running jobs without checkpointing should stay on on-demand or committed capacity.
Diversify across instance types and zones to reduce interruption impact, and use node affinity and taints to keep sensitive workloads off spot nodes. Cover the remaining steady on-demand floor with commitment discounts.
Decision 5: What Will You Do About Non-Production and Idle Time?
Development, test and preview environments often run around the clock while being used for a fraction of the week. Options include scaling deployments to zero outside working hours, using ephemeral preview environments that are destroyed after merge, consolidating non-production namespaces onto shared clusters, and using virtual clusters to give teams isolation without dedicated nodes. These measures are low risk and often deliver quick wins.
Kubernetes cost is decided in pod specs and paid for in nodes. Allocate first, rightsize continuously, let the node layer consolidate aggressively, and keep humans focused on the trade-offs automation cannot make.
Metrics That Show Whether It Is Working
Kubernetes optimization efforts often stall because teams cannot tell whether changes made a difference. A small set of metrics, reported per cluster and per team, keeps everyone honest:
- Cost per namespace and per workload, including an allocated share of idle and shared costs, trended monthly.
- CPU and memory request efficiency: actual usage divided by requested resources. Low ratios point to request inflation.
- Node allocation efficiency: requested resources divided by node capacity. Low ratios point to bin-packing or scale-down problems rather than workload sizing.
- Idle cost share: the portion of cluster cost not attributable to any workload request.
- Spot and commitment coverage: the share of node hours running on discounted capacity.
- Unit cost: cluster cost per request, per transaction, per active customer or per inference, tied to a business driver.
Separating request efficiency from node allocation efficiency is particularly useful, because the two point to different owners. Request efficiency is mostly a product team responsibility, since teams write the pod specifications. Node efficiency is mostly a platform team responsibility, since the platform controls autoscaling, instance choices and consolidation. Reporting both makes it clear where the next improvement should come from and avoids the familiar argument in which each side blames the other for the bill. Set realistic targets per workload class rather than a single global figure; a latency-critical payment service will justifiably carry more headroom than an overnight batch pipeline.
The Kubernetes Cost Optimization Checklist
Use this checklist to assess a cluster. Each unchecked item is a potential saving or governance gap.
Visibility and Allocation
- Cluster costs are allocated to namespaces and workloads, including shared and idle costs.
- Mandatory labels for team, product and environment are enforced at admission.
- Teams see their Kubernetes costs and efficiency in regular reports or dashboards.
- Kubernetes cost data is joined with the wider cloud bill, ideally in a common format such as FOCUS.
Workload Efficiency
- Every container has CPU and memory requests; limits are set deliberately, not copied from templates.
- Request-to-usage ratios are tracked, with targets per workload class.
- VPA recommendations or equivalent run on all namespaces.
- In-place resize is evaluated or adopted on clusters running Kubernetes 1.35 or later.
- HPA is configured for workloads with variable demand, with sensible minimum replicas.
Node Layer
- Node autoscaling is enabled with consolidation or scale-down tuned for your workloads.
- Multiple instance types and current-generation families, including Arm-based options where compatible, are allowed.
- Spot capacity is used for tolerant workloads with diversification and disruption budgets.
- Steady on-demand capacity is covered by commitments.
Hidden Costs
- Orphaned persistent volumes and snapshots are detected and removed.
- Load balancers and ingress resources are reviewed for duplication.
- Cross-zone and egress traffic is monitored, with topology-aware routing where it helps.
- Logging and metrics volumes have retention and sampling policies.
GPU and AI Workloads
- GPU utilization is measured per workload, not just per node.
- GPU sharing techniques, such as time-slicing or multi-instance GPUs, are considered for small inference workloads.
- Idle GPU nodes scale down promptly, and training jobs use spot capacity with checkpointing where possible.
Hypothetical Worked Example: A Media Company’s Shared Platform
Consider a hypothetical media company with three production clusters and several non-production clusters on a public cloud. Platform costs have grown steadily, and leadership wants to know why. Deploying OpenCost reveals that idle capacity makes up a large share of cluster cost and that most pods request several times the CPU they use.
The platform team runs VPA in recommendation mode for a month and shares results with product teams in their existing cost reviews. Stateless services adopt automated rightsizing, while the team tests in-place resize on a staging copy of a stateful search service after upgrading to Kubernetes 1.35. It replaces fixed node groups with Karpenter-style provisioning, allowing several instance families and spot capacity for stateless and batch workloads. Non-production namespaces scale to zero overnight and at weekends. Finally, it purchases commitments only for the reduced on-demand floor that remains. The outcome is a smaller, better-packed fleet and, just as importantly, a monthly report showing each team its cost and efficiency trend.
Pitfalls to Avoid
- Buying commitments before rightsizing, which locks in the inflated node count.
- Setting CPU limits aggressively, which can cause throttling and performance issues while saving little money.
- Automating rightsizing without guardrails, such as minimum requests and change-rate limits, especially for memory.
- Ignoring cluster sprawl. Many small clusters each carry control-plane, system pod and headroom overhead.
- Treating cost as a platform-only problem. Product teams write the pod specs and need to see the consequences.
Outlook to 2028
Expect Kubernetes cost management to become more autonomous. With in-place resize stable, continuous rightsizing will become a default rather than an advanced practice. AI agents connected to cost tools, through interfaces such as OpenCost’s MCP server, will increasingly propose and apply optimizations within guardrails. AI workloads will push GPU-aware scheduling and sharing into the mainstream. And cost allocation for Kubernetes will continue to converge with wider FinOps standards, so cluster costs appear alongside cloud, SaaS and AI spend in the same reports.
Conclusion
Kubernetes cost optimization comes down to a handful of decisions: how you allocate costs, how you rightsize workloads, how your node layer scales, how much spot capacity you use and how you handle idle environments. The tools for each have improved markedly, with in-place pod resize and mature open-source allocation removing long-standing obstacles. Use the checklist to find your gaps, start with visibility and rightsizing, and let automation handle the routine work so teams can focus on the trade-offs that need judgment.
How Hanoi Technology Can Help
Hanoi Technology helps platform teams allocate Kubernetes costs, implement rightsizing and node autoscaling strategies, and run continuous cluster optimization.