Kubernetes Cost Optimization: A Practical Playbook for 2026
Most Kubernetes clusters run at 15-25% utilization while their cloud bill grows 40% per year. Here are the seven cost levers that actually move the needle, the order to pull them, and the tools that automate the work.
Why K8s Costs Spiral
Kubernetes clusters are built for elasticity, but they routinely run at 15-25% average utilization. The gap between provisioned capacity and used capacity is the cost optimization opportunity. Three structural reasons drive the gap:
1. Engineers over-request. Resource requests are set when a service is first deployed, often based on a guess. Six months later the actual usage is a fraction of the request, but nobody has gone back to update the manifest. The scheduler treats the request as truth and reserves the over-allocated capacity.
2. Bursty workloads need headroom. Real production traffic has spikes. Conservative engineers add 2-3x headroom on top of average load to be safe during spikes. Most of the time, that headroom is idle.
3. The accounting is opaque. Cluster cost shows up as one line on the cloud bill. Without per-namespace or per-team chargeback, no one team feels the cost impact of their resource choices, so the choices stay sloppy.
The seven levers below address each of these. They are ordered roughly by impact-per-effort: the first three usually deliver 40-60% cost reduction with reasonable effort.
Lever 1: Right-Size Resource Requests
What it is: Set CPU and memory requests to match actual P95 usage rather than aspirational headroom.
Why it works: The Kubernetes scheduler reserves capacity equal to the requests, not actual usage. A pod requesting 1 CPU and using 0.1 CPU on average is wasting 0.9 CPU of cluster capacity. Multiply across hundreds of pods and the waste is enormous.
How to do it: Use the Vertical Pod Autoscaler (VPA) in recommendation mode. It analyzes 7-30 days of actual usage and recommends right-sized requests. Apply the recommendations gradually (start with non-critical services), monitor for performance impact, and repeat.
Typical savings: 30-50% cluster cost reduction just from right-sizing. The work takes 1-2 weeks for a mid-size cluster.
Common gotcha: Setting requests equal to limits removes burst capacity. JVMs and databases need request < limit so they can use available headroom during spikes without triggering the OOM killer.
Lever 2: Spot/Preemptible Instances
What it is: Run stateless and fault-tolerant workloads on cloud spot instances (AWS Spot, GCP Preemptible, Azure Spot) which cost 60-90% less than on-demand instances.
Why it works: Spot capacity is the same hardware as on-demand. The discount comes from the cloud provider's right to reclaim the instance with short notice (60-120 seconds depending on cloud). Workloads that can survive a forced restart can run on this capacity at a fraction of the cost.
How to do it: Create a spot node pool, taint the nodes with spot: true:NoSchedule, and add tolerations to workloads that opt in. Use Cluster Autoscaler or Karpenter to manage capacity. Pair with Pod Disruption Budgets to ensure availability during spot reclaims.
Typical savings: 50-70% on the workloads that move to spot. Works best for stateless web services, batch jobs, CI/CD runners, ML training, and dev/staging clusters.
Common gotcha: Stateful workloads (databases, queues, services with sticky sessions) should not run on spot. The data loss risk during a forced reclaim outweighs the savings.
Lever 3: Bin-Packing the Scheduler
What it is: Configure the scheduler to pack pods densely onto nodes rather than spreading them evenly.
Why it works: The default Kubernetes scheduler uses a least-utilized algorithm: it spreads pods across nodes for failure isolation. This is the right default for availability but bad for cost. A bin-packing scheduler fills nodes one at a time, allowing the cluster autoscaler to remove empty nodes.
How to do it: Use the NodeResourcesFit plugin with the MostAllocated scoring strategy in your scheduler config. For larger clusters, deploy Karpenter, which natively considers cost in its scheduling decisions and continuously consolidates nodes.
Typical savings: 10-20% on top of right-sizing.
Common gotcha: Bin-packing increases blast radius for node failures. If a node dies, more pods go down. Combine with Pod Disruption Budgets and topology spread constraints to keep the failure domain reasonable.
Lever 4: Detect and Kill Idle Workloads
What it is: Find pods that consume CPU and memory but produce no useful work, and shut them down.
Why it works: Every cluster accumulates orphan workloads: dev environments left running, deprecated services nobody removed, jobs that are running but not making progress. They cost money continuously.
How to do it: Run periodic queries to identify pods with very low request rates, low network I/O, and no recent log activity. OpenCost and Kubecost both have built-in idle detection. Tag candidate workloads with their team owner and require a sign-off before shutting them down.
Typical savings: 5-15%, depending on how much sprawl your cluster has accumulated.
Common gotcha: Some workloads are legitimately idle most of the time (cron-style jobs, on-demand processors). Idle detection should consider request rate trends over weeks, not single days.
Lever 5: Autoscale Aggressively
What it is: Use Horizontal Pod Autoscaler (HPA) to scale pods based on actual demand, and Cluster Autoscaler or Karpenter to add/remove nodes based on pod scheduling pressure.
Why it works: Static pod counts and static node pools mean you provision for peak. Autoscaling lets the cluster shrink during off-peak hours, dropping the cost during low-utilization periods.
How to do it: Define HPA on every stateless deployment with conservative scale-down behavior (longer stabilization windows to avoid thrashing). Use Karpenter for node-level autoscaling, it consolidates nodes more aggressively than the legacy Cluster Autoscaler.
Typical savings: 20-40% for workloads with diurnal traffic patterns. Less impact for workloads that are flat 24/7.
Common gotcha: Aggressive scale-in causes performance issues if scale-out cannot keep up with traffic spikes. Tune scale-out to be fast and scale-in to be slow.
Lever 6: Namespace-Level Chargeback
What it is: Allocate cluster cost to specific teams or products based on their resource consumption, and surface the cost to the owning team.
Why it works: When cost is invisible, no one optimizes. When a team sees they spent $40,000 last month on Kubernetes, behavior changes. Chargeback creates the feedback loop that makes the other levers stick.
How to do it: Use OpenCost or Kubecost to allocate cluster cost by namespace, label, or annotation. Send weekly cost reports to engineering managers. Bake cost goals into team OKRs.
Typical savings: 10-30% over 12 months, primarily through behavior change rather than tooling. The savings accrue slowly but compound over time.
Common gotcha: Shared infrastructure costs (control plane, monitoring, ingress) are hard to allocate fairly. Use a simple weighted-share model rather than trying to be perfectly precise.
Lever 7: Storage and Egress
What it is: Right-size persistent volumes, delete orphaned PVCs, use cheaper storage classes for non-hot data, and minimize cross-zone egress traffic.
Why it works: Compute gets the most attention but storage and network can quietly become 30-40% of the cluster bill. PVCs left over from deleted services keep costing money. Cross-zone egress charges add up when chatty services span zones.
How to do it: Audit PVCs monthly and remove orphaned ones. Move infrequently accessed data to cheaper storage classes (gp3 instead of io2, standard instead of premium SSD). Use topology-aware service routing to keep cross-zone traffic minimal.
Typical savings: 10-25% on storage and egress costs.
Tools That Help
Three tool categories worth investing in:
OpenCost (open-source) or Kubecost (commercial): The standard for Kubernetes cost allocation, idle detection, and chargeback reporting. OpenCost is free and covers 80% of needs; Kubecost adds more polish and managed hosting.
Karpenter (AWS, growing on other clouds): Replacement for the legacy Cluster Autoscaler that natively considers cost in scheduling and continuously consolidates underutilized nodes. Most teams that adopt Karpenter see 20-30% cost reduction within the first month.
Vertical Pod Autoscaler (VPA): Free, built-in to Kubernetes. Run in recommender mode to get right-sizing suggestions without disrupting workloads. Apply manually after review.
The Right Order to Apply These
Pull the levers in this order for the best impact-per-effort:
- Week 1-2: Right-size requests using VPA recommender mode. Quick wins, low risk.
- Week 3-4: Move stateless workloads to spot/preemptible. Pair with Pod Disruption Budgets.
- Month 2: Deploy Karpenter and switch to bin-packing scheduling. Continuous consolidation.
- Month 3: Audit idle workloads, set up chargeback reporting, and surface cost to teams.
- Ongoing: Storage audits, egress optimization, and quarterly right-sizing reviews.
Realistic outcome: a typical mid-size Kubernetes cluster running at 18% utilization can reach 50-65% utilization within a quarter, cutting the cluster cost by 40-50% with no impact on workload performance.
For teams that want to automate the entire optimization loop continuously, AI-native platforms like Nova AI Ops include continuous right-sizing recommendations, idle workload detection, and cost-aware scaling decisions out of the box. The platform identifies cost optimization opportunities daily and proposes (or applies) the changes within your defined safety boundaries. Try Nova to see the savings on your real workload.