Kubernetes Cost Optimization in 2026: Where the Waste Actually Comes From

Resource requests in Kubernetes are hard reservations. When a pod requests 2 CPU cores, the scheduler treats those cores as unavailable to other pods, even if the application is using 0.1 cores under normal load. The Cast AI 2026 report found CPU overprovisioning jumped from 40% to 69% year over year, and memory overprovisioning sits at 79%. This is not carelessness. Engineers set generous requests to avoid throttling and OOM evictions, and there is no immediate feedback loop connecting those decisions to the cloud bill. The result is clusters that look full to the scheduler while the underlying nodes run at single-digit CPU utilization.

The Cluster Autoscaler provisions nodes to satisfy pending pod requests. When those requests are inflated, it provisions more and larger nodes than workloads need, and waste compounds upward from pod to node level. Most clusters waste 20 to 45% of requested CPU and memory, and the Cluster Autoscaler’s reactive, request-based provisioning is one of the structural reasons. Fix request sizing before tuning the autoscaler: accurate inputs produce far better results than a sophisticated autoscaler working from inflated ones.

Development and staging clusters that run around the clock are one of the most consistent sources of avoidable spend. A staging environment used during a 40-hour work week but running for 168 hours pays for 128 hours of idle compute per week. Multiply that across multiple clusters and the savings from scheduled scale-down become significant quickly. The fix is operational, not architectural: a CronJob or cluster scheduler that scales non-production node pools to zero outside working hours, and a process for ensuring feature-branch clusters are deleted when branches are merged.

Persistent Volumes, load balancers, static IP addresses, and snapshots created for workloads that have since been deleted or scaled down continue to accrue charges. These resources are invisible in most cost dashboards because they are not associated with a running pod. A periodic audit using cloud provider cost tools or OpenCost to identify unattached storage and networking resources typically surfaces meaningful savings with no performance impact.

Fault-tolerant workloads on on-demand instances when Spot capacity is available is straightforward overspend. Spot instances are 60 to 90% cheaper than on-demand for equivalent compute. Stateless web services, batch jobs, CI runners, and ML training workloads with checkpointing are all candidates. Pod Disruption Budgets, readiness probes, and retry logic are prerequisites, not afterthoughts.

Pull 30-day actual utilization for every workload and compare it to current requests. The ratio of P95 actual usage to requested resources is the key figure: any workload above 3x overprovisioned is a candidate for rightsizing; above 5x is severely overprovisioned and should be addressed first. Tools for collecting this data include Prometheus with kube-state-metrics, Kubecost, OpenCost, and cloud-native monitoring (CloudWatch Container Insights, Google Cloud Monitoring, Azure Monitor). The friction is acting on the data: most teams have dashboards and lack the operational cadence to rightsize top offenders each month.

VPA observes actual resource usage and recommends, or automatically applies, adjusted requests and limits. Recommend mode surfaces data without making changes, the right starting point before enabling automatic updates. In Auto mode, VPA can restart pods to apply new requests, which introduces disruption for stateful or latency-sensitive workloads. The practical pattern for production: run VPA in Recommend mode, review recommendations weekly, and apply them manually or through a GitOps workflow that creates an audit trail. Auto mode works well for stateless, horizontally-scaled services where a pod restart is low-risk.

Goldilocks, from FairwindsOps, runs VPA in Recommend mode across all workloads and presents the recommendations through a dashboard that is readable by application teams, not just platform engineers. It answers the question “what should this deployment’s requests actually be?” in a format that does not require deep Kubernetes expertise to act on. For organizations where application teams own their own resource configurations, Goldilocks is an effective way to give those teams accurate data without centralizing every rightsizing decision in the platform team.

Limits define the maximum resources a container can use. Setting CPU limits too low causes throttling without any visible error; the application just runs slower. Setting memory limits too low causes OOM kills. The common mistake is setting limits equal to requests, which means any workload that briefly spikes above its baseline request gets throttled or killed. A reasonable starting point is limits at 1.5 to 2x of the P99 actual usage, with requests set at P95 plus 20 to 30% headroom. This gives workloads room to absorb traffic spikes without reserving permanent capacity for worst-case scenarios that happen rarely.

HPA scales pod replicas based on CPU utilization, memory, or custom metrics. It works for stateless, horizontally-scalable services where adding replicas reduces per-pod load. Setting target utilization too low (scaling out when any pod exceeds 50% CPU) keeps replica counts inflated and blocks node consolidation. A target utilization of 70 to 80% is more appropriate for most workloads and allows the cluster to run pods more densely before triggering scale-out.

KEDA (Kubernetes Event-Driven Autoscaling) extends HPA to scale based on external event sources: queue depth, message lag, database query counts, HTTP request rate, and dozens of other sources through its connector ecosystem. For batch processing, message queue consumers, and scheduled jobs, KEDA enables scaling to zero when there is no work to do, which HPA alone cannot accomplish. Scaling to zero for appropriate workloads is one of the highest-impact changes available for non-production and event-driven workloads, because it eliminates the idle baseline entirely.

The Cluster Autoscaler is reactive by design: it watches for pending pods and provisions new nodes to satisfy them, selecting from predefined node groups. Karpenter provisions right-sized instances based on the actual requirements of pending pods, choosing from thousands of instance types rather than a predefined set, and can consolidate underutilized nodes more aggressively. The practical advantage is that Karpenter avoids the over-provisioning that comes from selecting the next-largest node group size when a smaller instance type would suffice. Karpenter is AWS-native; GKE Autopilot provides similar behavior natively on Google Cloud, and Node Autoprovision (NAP) brings Karpenter-style provisioning to GKE standard clusters.

Running HPA and VPA simultaneously on the same workload causes conflicts: HPA scales out based on CPU percentage, while VPA adjusts CPU requests, which changes the denominator HPA uses to calculate utilization. The practical resolution is to run HPA on custom metrics (queue depth, request rate) rather than CPU when VPA is also active, so the two controllers are not competing for the same signal. GKE’s Multidimensional Pod Autoscaling handles this natively; on other platforms it requires explicit configuration to avoid instability.

OpenCost is the CNCF-maintained open-source standard for Kubernetes cost allocation. It attributes cloud costs to namespaces, deployments, pods, and labels in real time, using actual cloud provider pricing. For teams that want cost visibility without a commercial tool, OpenCost is the baseline: it installs as a Prometheus exporter and integrates with Grafana for dashboarding. It does not make optimization recommendations or take automated action; it shows you what things cost so you can decide what to do about it.

Kubecost builds on OpenCost with a richer UI, rightsizing recommendations, and multi-cluster support. The free tier covers a single cluster; enterprise features include cost governance policies, SAML/SSO, and deeper multi-cloud support. For teams that want recommendations alongside visibility without moving to a fully automated platform, Kubecost is the most commonly deployed tool in this space. The limitation is the same as any recommendation-based system: the recommendations do not implement themselves, and most teams find their savings drift back as workloads change and the recommendations go unreviewed.

Karpenter is AWS-native, open-source, and focused specifically on node provisioning. It selects the right instance type and size for each batch of pending pods, consolidates underutilized nodes, and supports Spot interruption handling natively. For EKS clusters, Karpenter is the most impactful single tool for reducing node-level waste, and it requires no commercial license. GKE Autopilot provides equivalent behavior natively; AKS Node Autoprovision (NAP) brings Karpenter to Azure in preview as of 2026.

Autonomous platforms go beyond recommendations: they continuously rightsize pod requests, manage node provisioning, automate Spot adoption, and handle commitment purchasing, without manual intervention between the dashboard and the savings. These platforms commonly report 50 to 75% cost reductions on clusters they manage autonomously. The trade-off is that they require granting write access to the cluster, which raises governance questions for security-sensitive environments. PerfectScale, acquired by DoiT International, is positioned as the reliability-aware option: its optimization is calibrated to avoid configurations that are cost-efficient but operationally fragile. Cast AI and ScaleOps are more aggressive on automation. The right choice depends on risk tolerance and how much the team wants to own the optimization logic versus delegate it.

A cost optimization platform working from inflated requests will provision better-sized nodes to serve those inflated requests, and report savings against a baseline that was itself wasteful. The sequence matters: measure actual utilization, rightsize requests, then evaluate whether an optimization platform adds further value. Skipping the first two steps means paying for a tool to manage waste rather than eliminate it.

CPU limits that are lower than actual peak usage cause throttling, not OOM kills: the application keeps running but processes requests more slowly. This is invisible in most monitoring unless CPU throttle rate is explicitly tracked. Teams that aggressively cut CPU limits to reduce request size often create latency problems that get attributed to application code rather than resource configuration.

Spot instances can be interrupted with two minutes notice. Applications holding in-flight transactions at interruption time, or running without replicas to absorb traffic during a drain, will produce reliability incidents. Pod Disruption Budgets, readiness probes, and graceful shutdown handling are prerequisites for Spot adoption.

Development and staging clusters are often the easiest savings available because the workloads running on them have no SLA requirements. A scheduled scale-to-zero for non-production node pools outside working hours, combined with a process for deleting feature-branch clusters after merge, can reduce non-production spend by 60 to 70% with no impact on development velocity.

Platform teams that rightsize workloads owned by application teams create friction and often see their changes reverted at the next deployment, because the application team’s Helm values still contain the original inflated requests. Durable cost optimization requires application teams to own their resource configurations: give them accurate utilization data and clear targets.