Introduction
Kubernetes rightsizing is the practice of continuously matching a workload’s CPU and memory requests to what it actually uses, rather than to a number someone guessed at deploy time. That gap between requested and used compute is where most compute waste in Kubernetes clusters actually accumulates, and it’s rarely a small gap. Most teams don’t lack the ability to rightsize; they lack a process that keeps doing it as workloads change week over week.
Rightsizing maturity isn’t binary. Some teams have never touched a request value since the day it was written into a YAML file. Others run recommendation tools that surface the right numbers but still depend on someone applying them by hand. A small few have removed the human step entirely. This article lays out a four-level maturity model for where a team’s rightsizing practice actually sits today, what caps each level, and what it takes to move to the next one.
The value of thinking in levels rather than a single pass/fail state is that it gives a team an honest starting point. A cluster doesn’t move from chaos to fully automated in one step, and treating it as if it should tends to produce automation nobody trusts, because it was layered on top of data nobody had validated first.
Why Kubernetes Rightsizing Is Still a Problem in 2026
Why is your Kubernetes cluster so expensive when everything looks like it’s running fine? Because “running fine” and “efficiently sized” are two different things, and kubernetes cost optimization depends on closing the gap between them. A pod requesting 2 CPU cores and using 300 millicores looks completely healthy on every dashboard that only tracks whether the pod is up. The 1.7 cores it never touches are reserved, billed, and unavailable to anything else, whether or not the pod ever needs them.
The problem sits specifically at the resource requests layer, not at the node layer, which is why node autoscalers can’t fix it on their own. A node autoscaler adds or removes nodes based on whether pending pods can be scheduled, and scheduling decisions are made against requested values, not real usage. If every pod in a cluster requests double what it needs, the autoscaler will faithfully provision double the nodes required, doing its job correctly while the underlying waste stays completely invisible to it.
Most Kubernetes clusters run at single-digit average CPU utilization, a figure consistent with widely published industry benchmarks across platform teams of very different sizes. That gap exists because resource values are typically set once, by whoever deployed the service, based on a guess about peak load that erred generously on the side of caution, and then never looked at again. Zesty’s Multi-Dimensional Autoscaling (MDA) exists specifically to close that gap on an ongoing basis, adjusting requests continuously as real usage data comes in instead of leaving the original guess in place indefinitely.
The Kubernetes Rightsizing Maturity Model
Rightsizing maturity isn’t a single decision a team makes once. It’s a curve, and most teams can place themselves on it accurately by asking what actually happens to a request value after it’s first deployed. The four levels below aren’t meant as a checklist to complete in order and move past. They’re a description of where a team’s actual practice sits today, since most organizations have some services stuck at Level 0 and others further along, all inside the same cluster.
Level 0: No Rightsizing (Gut-Feel Provisioning)
At Level 0, requests and limits are set once, at deployment, based on a rough guess, and never touched again regardless of what real usage looks like afterward. There’s no process for adjusting values later, no alert when usage drifts far from what was requested, and no owner responsible for cluster-wide efficiency.
Ceiling: Teams stay here indefinitely because nothing forces a change. As long as the cluster doesn’t fall over, gut-feel values look “good enough.”
Trigger to move up: Usually a large, unexplained cloud bill, or a new FinOps mandate that finally puts someone in charge of asking where the compute spend is actually going.
Level 1: Manual, Point-in-Time Rightsizing
At Level 1, engineers periodically check real usage with kubectl top or ad-hoc Prometheus queries, then manually adjust the YAML for whatever service prompted the review. Pod rightsizing happens, but only in short bursts tied to a specific incident, migration, or cost review, not as an ongoing practice.
Ceiling: This approach doesn’t scale past a handful of services. The moment a cluster has more than a few dozen workloads, manual point-in-time checks can’t keep pace with how often usage patterns actually shift.
Trigger to move up: The team gets tired of repeating the same manual review every quarter and starts looking for a tool that surfaces the numbers automatically instead of requiring someone to run the queries by hand.
Level 2: Recommendation Tools (VPA, Goldilocks, KRR)
At Level 2, a dedicated tool takes over the analysis. VPA, Goldilocks, or KRR continuously observe real usage and surface pod rightsizing suggestions, removing the manual data-gathering step from Level 1. This is usually the point where a team first sees the actual scale of the waste, since a recommendation tool applied across an entire cluster tends to surface far more oversized requests than the handful anyone had been manually reviewing before. The gap that remains is application: a human still has to review each recommendation and decide whether to apply it.
Ceiling: VPA’s default history window retains roughly eight days of data, which limits how accurately it can characterize workloads with longer or more irregular usage cycles, and applying its recommendations in production still typically requires a pod restart unless in-place resizing is separately configured. Recommendation backlogs also tend to accumulate faster than they get cleared, since reviewing and applying suggestions competes with every other item on an engineer’s plate.
Trigger to move up: The backlog of unapplied recommendations becomes its own visible cost, and the team starts asking why a tool that already knows the right values still needs a human in the loop to act on them.
Level 3: Continuous, Automated Rightsizing
At Level 3, recommendations regenerate continuously, apply automatically, including in-place resizing without a pod restart, and adapt to Out of Memory (OOM) events without a person reviewing each change. This is the top of the rightsizing maturity model, and very few teams reach it by building the automation themselves, since doing so safely means solving the same in-place resizing and OOM-awareness problems VPA itself hasn’t fully solved.
Ceiling: None, by design. This is the level where rightsizing stops being a periodic task and becomes a property of the cluster.
Trigger to move up: There isn’t one. Level 3 is the goal, not a stage to graduate out of. Zesty’s Multi-Dimensional Autoscaling (MDA) reaches this level at the pod layer, continuously resizing requests in place as usage changes. At the node layer, Zesty’s Adaptive Pod Placement (APP) handles bin packing, continuously consolidating workloads onto a more efficient node footprint so capacity isn’t left stranded across more nodes than the workloads actually need.
Resource Requests and Limits: Why CPU and Memory Fail Differently
Resource requests and limits don’t fail the same way when they’re wrong, and that asymmetry is the reason CPU and memory need different sizing approaches. What’s the difference between CPU and memory limits in Kubernetes? CPU is compressible: a pod that hits its CPU limit gets throttled, slows down, and keeps running. Memory is incompressible: a pod that hits its memory limit gets an Out of Memory (OOM) kill, exits with code 137, and restarts visibly.
That difference in failure mode changes how mistakes get noticed. CPU throttling degrades performance gradually, often without triggering any alert, which means a poorly sized CPU limit can persist for months as a slow, unexplained latency problem. An OOM kill is loud and immediate: the pod restarts, the exit code is unambiguous, and monitoring tools flag it right away.
| CPU | Memory | |
| Failure mode | Throttling (compressible) | OOM kill (incompressible) |
| Visibility | Low, degrades performance without an alert | High, visible restart and exit code 137 |
| Detection method | Latency and throughput monitoring | Restart count and OOM event logs |
| Safe limit strategy | Percentile-based requests with headroom in the limit | Guaranteed QoS for memory-sensitive workloads, conservative limit ratios |
Because memory failures are so visible and CPU failures aren’t, teams tend to over-correct on memory limits (setting them generously to avoid restarts) while leaving CPU limits under-examined for far longer. A percentile-based approach to CPU requests, sized against the 95th or 99th percentile of real usage rather than peak, tends to strike a better balance than either a flat guess or a limit copied from a similar-looking service.
This is also why Quality of Service (QoS) class matters more for memory than for CPU. A workload set to Guaranteed QoS, where requests equal limits for both CPU and memory, gets priority protection from the node’s eviction logic when the node itself comes under memory pressure. Burstable QoS, where limits exceed requests, offers more flexibility for CPU-bound workloads that occasionally need headroom, but leaves memory-sensitive workloads more exposed if that pressure situation ever arises. Zesty’s Multi-Dimensional Autoscaling (MDA) detects both throttling and OOM signals automatically as part of its continuous adjustment logic, folding the CPU and memory sizing problem into a single ongoing process instead of two separately-managed concerns.
VPA vs. Automated Rightsizing: Comparing the Tools
VPA vs automated rightsizing is really a question of where the human step sits, and the table below lays out where each common approach actually stands.
| Approach | Detection Method | Application Method | Downtime Risk | Accuracy | Ops Burden |
| Manual | Ad-hoc kubectl top / Prometheus checks | Manual YAML edit | Low, but infrequent and inconsistent | Low, based on point-in-time snapshots | High, entirely person-hours |
| VPA | Continuous, ~8-day retention window | Manual apply, or auto-apply with a pod restart | Moderate, restarts required for most configurations | Moderate, limited by short history window | Moderate, review still required |
| Goldilocks | Continuous, built on VPA data | Manual, dashboard-driven review | Low, since nothing applies automatically | Moderate, same VPA data underneath | Moderate, easier to review, still manual |
| KRR | Point-in-time analysis of historical Prometheus data | Manual, output is a report | None, agentless and read-only | Moderate, depends on available history | Moderate, still requires manual follow-through |
| Zesty | Continuous, real-time usage tracking | Automatic, in-place resizing | Low, designed for zero-downtime application | High, continuously updated against current usage | Low, no manual review step required |
The pattern across every row above the last one is the same: something reviews or recommends, and a person still has to act. See why teams move to Zesty for automated rightsizing: it’s the only approach here that combines continuous detection, automatic application, and zero-downtime resizing in one system, rather than splitting those steps across a tool and an engineer’s queue. That combination is what actually closes the gap between Level 2 and Level 3 of the maturity model.
How to Move Up the Maturity Curve
Moving up the rightsizing maturity model looks different at each level, since the bottleneck at Level 0 isn’t the same bottleneck holding a team back at Level 2. Trying to skip a level, adopting an automation platform before a team has ever looked at real usage data, tends to produce less trust in the results than working through each step and seeing the waste firsthand first.
- Level 0 to Level 1: Start by collecting at least two to three weeks of real usage data with Prometheus or a similar metrics pipeline before changing anything. Sizing decisions made without this baseline just replace one guess with another.
- Level 1 to Level 2: Deploy a recommendation tool (VPA, Goldilocks, or KRR) so that identifying the right request and limit values stops depending on someone remembering to run a manual check. This step alone typically surfaces more waste than most teams expect, simply because it’s the first time anyone has looked systematically rather than reactively.
- Level 2 to Level 3: Remove the human approval step. This means adopting continuous automated application, including in-place resizing, and treating Pod Disruption Budgets (PDBs) as the safety net that keeps automated changes from disrupting availability, rather than treating manual review as that safety net instead. Building this in-house means solving the same in-place resizing and OOM-awareness problems VPA hasn’t fully solved on its own, which is why most teams that reach Level 3 do it with a platform built for exactly that job, like Zesty’s Multi-Dimensional Autoscaling (MDA) and Adaptive Pod Placement (APP), rather than by extending a recommendation tool themselves.
Day to day, Level 3 looks like nothing happening that anyone notices: requests adjust, nodes consolidate, and the cluster stays efficiently sized without a ticket, a review meeting, or an engineer opening a YAML file to do it.
Conclusion
Rightsizing isn’t a one-time task you complete during a migration or a cost-cutting sprint. It’s a maturity curve, and the gap between a cluster sized correctly today and the same cluster three months from now widens continuously unless something is actively closing it. Most teams plateau at Level 1 or Level 2, not because they don’t understand the problem, but because manual review, even with a good recommendation tool underneath it, doesn’t scale at the rate workloads actually change.
Every level in this model is a legitimate place to be. A team at Level 1 that’s actively working toward Level 2 is in a healthier position than a team that skipped straight to buying an automation tool without ever validating what real usage looks like. The point of the curve isn’t to shame anyone for where they currently sit, it’s to make the next step clear.
Zesty’s continuous, automated approach to Kubernetes rightsizing gets teams to Level 3 without requiring them to build and maintain that automation in-house, combining continuous pod-level rightsizing through MDA with continuous node-level placement through APP. The teams that reach the top of the curve aren’t the ones reviewing recommendations fastest. They’re the ones who removed the review step entirely. Book a demo with Zesty to see what that looks like on your own clusters.
FAQs
What is Kubernetes rightsizing?
Kubernetes rightsizing is the practice of matching a workload’s CPU and memory requests and limits to its actual usage, on an ongoing basis, rather than to a one-time estimate made at deployment. The goal is to close the gap between what’s requested and what’s actually used, since that gap is where most Kubernetes compute waste accumulates.
