There is a Kubernetes cluster in your organization running at fifteen percent utilization, costing as if it ran at eighty. Every workload requests far more CPU and memory than it uses, because the requests were copied from a template nobody questioned, and the scheduler dutifully reserves all of it. Meanwhile a different workload is being throttled against a limit that is too low, and its latency is suffering. The cluster is simultaneously over-provisioned and starving the wrong things.
This is more than a tuning oversight. It is a failure to right-size against real usage.
Right-sizing Kubernetes is more than picking numbers for requests and limits. It is the discipline of grounding those numbers in observed usage, requests that reflect what a workload actually needs, limits that protect without needlessly throttling, so the cluster is neither paying for idle reservations nor starving real demand.
However, many teams set requests and limits by guesswork or copy-paste, and pay for it twice: in wasted capacity and in throttled workloads.
If you are a platform or infrastructure leader responsible for cluster efficiency, the intent of this article is:
- Define what requests and limits actually do and how they drive cost and performance
- Walk through grounding them in real usage
- Lay out the controls a right-sized cluster needs
To do that, let's start with the basics.
EHR Integration Problems Engineers Actually Face
The three gaps between Epic's FHIR R4 documentation and production behavior.
What Is Right-Sizing Kubernetes? The Basic Definition
At a high level, right-sizing Kubernetes is setting each workload's resource requests and limits based on its observed real usage, so requests reserve close to what is needed and limits cap without throttling normal operation.
To compare:
If a workload's request is the table you reserve at a restaurant, over-requesting is booking a table for twenty when four show up: the seats sit empty and unavailable to others. Right-sizing books the table you actually need, so capacity is not wasted and nobody is turned away unnecessarily.
Why Is Right-Sizing Necessary?
Issues that right-sizing addresses or resolves:
- Reclaiming capacity wasted on over-provisioned requests
- Preventing throttling and instability from misconfigured limits
- Grounding resource configuration in data rather than guesswork
Resolved Issues by Right-Sizing
- Cuts cost by reclaiming reserved-but-unused capacity
- Improves performance by removing needless throttling
- Replaces copy-paste resource values with usage-based ones
Core Components of Right-Sizing
- Requests set near real observed usage
- Limits set to protect without throttling normal load
- Usage data over a representative period
- Differentiation between CPU and memory behavior
- Ongoing adjustment as workloads change
Modern Right-Sizing Tools
- Vertical Pod Autoscaler for recommendation and adjustment
- Metrics from Prometheus and the metrics server for real usage
- Goldilocks, Kubecost, and similar for right-sizing recommendations
- Resource quotas and limit ranges for guardrails
- Continuous profiling to track actual consumption
These tools turn right-sizing from a one-time guess into a data-driven, ongoing practice.
Other Core Issues They Will Solve
- Improve scheduler bin-packing and cluster density
- Reduce the node count needed to run the same workloads
- Surface workloads that are mis-sized in either direction
Importance of Right-Sizing in 2026
Right-sizing matters more as Kubernetes footprints and cost scrutiny grow. Four reasons explain why it matters now.
1. Over-provisioning is the default failure mode.
Teams set generous requests to be safe, and the aggregate is a cluster running at a fraction of its reserved capacity. The waste is enormous and invisible per workload.
2. Limits misconfigured cause real harm.
CPU limits that throttle and memory limits that trigger out-of-memory kills degrade performance and stability. Misconfiguration cuts both ways.
3. Cluster cost is now scrutinized.
A cluster running at fifteen percent utilization is the kind of spend that finance now questions. Right-sizing is among the highest-leverage cost levers.
4. CPU and memory behave differently.
CPU is compressible and throttles; memory is not and gets killed. Treating them the same is a common, costly mistake.
Traditional vs. Modern Resource Configuration
- Guess or copy-paste requests vs. requests grounded in real usage
- Generous to be safe vs. sized to need with headroom
- CPU and memory treated alike vs. handled per their behavior
- Set once vs. adjusted as workloads change
In summary: Modern resource configuration is usage-based, behavior-aware, and continuously adjusted, not guessed once.
Details About the Core Components of Right-Sizing: What Are You Designing?
Let's go through each element.
1. Request Layer
What each workload reserves.
Request decisions:
- Requests set near observed real usage plus headroom
- Based on a representative period, not a peak spike
- Reviewed as the workload changes
2. Limit Layer
What caps each workload.
Limit decisions:
- CPU limits set to avoid needless throttling, or omitted deliberately
- Memory limits set to prevent runaway use without premature kills
- Limits informed by real consumption and behavior
3. Data Layer
What grounds the numbers.
Data decisions:
- Usage measured over a representative window
- Percentiles, not just averages or peaks
- Outliers understood, not blindly accommodated
4. Behavior Layer
How CPU and memory differ.
Behavior decisions:
- CPU compressible: throttling, not crashes
- Memory incompressible: out-of-memory kills
- Each configured according to its nature
5. Adjustment Layer
How sizing stays current.
Adjustment decisions:
- Periodic review against fresh usage
- Automation where appropriate
- Mis-sized workloads flagged in both directions
Benefits Gained from Usage-Based Sizing
- Reclaimed capacity and lower cost from accurate requests
- Better performance from limits that protect without throttling
- Resource configuration that reflects reality, not a template
How It All Works Together
Each workload's real usage is measured over a representative period, looking at percentiles rather than averages or one-off peaks. Requests are set near observed usage plus sensible headroom, so the scheduler reserves close to what is actually needed and packs the cluster densely. Limits are set with CPU's compressible, throttling behavior and memory's incompressible, kill behavior in mind, protecting against runaway use without strangling normal load. Usage is reviewed periodically and adjusted as workloads change, with automation flagging workloads mis-sized in either direction. The cluster runs at a healthy utilization, costs less, and performs better.
Common Misconception
Setting generous requests and limits is the safe choice.
Generous requests waste capacity at scale and generous-or-wrong limits cause throttling and out-of-memory kills. "Generous to be safe" produces a cluster that is both expensive and poorly performing. Safety comes from sizing to real usage with deliberate headroom, not from padding.
Key Takeaway: Over-provisioning is not caution, it is waste plus, often, the very instability it was meant to avoid. Size to real usage instead.
Real-World Right-Sizing in Action
Let's take a look at how right-sizing operates with a real-world example.
We worked with a team whose cluster ran at low utilization while some workloads were throttled, with these constraints:
- Reclaim capacity wasted on over-provisioned requests
- Eliminate throttling and out-of-memory kills from bad limits
- Ground all values in real usage
Step 1: Measure Real Usage
Collect what workloads actually consume.
- Usage gathered over a representative window
- Percentiles examined, not just averages
- Outliers understood
Step 2: Right-Size Requests
Set requests near observed need.
- Requests aligned to real usage plus headroom
- Over-provisioned workloads reduced
- Scheduler density improved
Step 3: Configure Limits by Behavior
Treat CPU and memory according to their nature.
- CPU limits set to avoid needless throttling
- Memory limits set to prevent runaway without premature kills
- Limits informed by consumption
Step 4: Add Guardrails
Prevent regressions to bad defaults.
- Limit ranges and quotas as guardrails
- Recommendations surfaced to teams
- Mis-sized workloads flagged
Step 5: Review Continuously
Keep sizing current.
- Periodic review against fresh usage
- Automation where appropriate
- Adjustment as workloads change
Where It Works Well
- Requests grounded in real, percentile-based usage
- Limits configured with CPU and memory behavior in mind
- Continuous review keeping sizing current
Where It Does Not Work Well
- Copy-pasted requests far above real usage
- CPU and memory limits set identically, ignoring their behavior
- Sizing set once and never revisited as workloads change
Key Takeaway: The cluster that is efficient and stable is the one whose requests and limits are grounded in real usage and behavior, not padded by guesswork or frozen at a template's defaults.
Common Pitfalls
i) Over-provisioning to be safe
Generous requests reserve capacity nobody uses, leaving the cluster at low utilization and high cost. Size to real usage with deliberate headroom.
- Measure real usage
- Set requests near need
- Add sensible, not excessive, headroom
ii) Ignoring CPU-versus-memory behavior
CPU throttles; memory gets killed. Setting them the same way causes either wasted CPU caps or out-of-memory crashes. Configure each per its nature.
iii) Sizing by copy-paste
Resource values copied from a template have no relationship to a workload's actual needs. Ground them in its observed usage.
iv) Setting and forgetting
Workloads change, and sizing drifts from reality. Review against fresh usage and adjust.
Takeaway from these lessons: Most cluster waste and instability trace to guessed, padded, or stale resource values, not to Kubernetes itself. Measure usage, respect CPU-versus-memory behavior, and adjust over time.
Right-Sizing Best Practices: What High-Performing Teams Do Differently
1. Ground requests in real usage
Set requests near observed consumption, using percentiles, plus deliberate headroom. Guesswork and copy-paste are the root of cluster waste.
2. Configure limits by behavior
Handle CPU's throttling and memory's kill behavior differently. Identical configuration for both is a common, costly error.
3. Use percentiles, not averages or peaks
Averages hide spikes and peaks over-provision for rare events. Percentiles capture the realistic working range.
4. Add guardrails
Limit ranges and quotas keep teams from regressing to bad defaults, while recommendations guide them to good values.
5. Review and adjust continuously
Workloads evolve; sizing should too. Periodic review against fresh usage, with automation where appropriate, keeps the cluster right-sized.
Logiciel's value add is helping teams measure real usage, right-size requests and limits with CPU and memory behavior in mind, and put guardrails and review in place, so clusters run efficiently and stably rather than over-provisioned and throttled.
Takeaway for High-Performing Teams: Focus on real usage and resource behavior. A cluster sized to data runs denser, cheaper, and more reliably than one padded with generous guesses that waste capacity and still cause instability.
Signals You Are Right-Sizing Correctly
How do you know the right-sizing work is set up to succeed? Not in the generosity of the requests, but in utilization and stability. Below are the signals that distinguish data-driven sizing from guesswork.
Utilization is healthy. The team can show the cluster running at a reasonable fraction of reserved capacity, not fifteen percent.
Throttling and OOM kills are rare. Workloads are not being strangled by CPU limits or killed by memory limits under normal load.
Requests reflect usage. The team can show requests grounded in observed percentiles, not copied from a template.
CPU and memory are handled differently. The team configures each according to its compressible or incompressible behavior.
Sizing is reviewed. The team revisits resource values against fresh usage as workloads change.
Adjacent Capabilities and Connected Work
This work does not exist in isolation. Right-sizing depends on, and feeds into, several adjacent capabilities. Building one without thinking about the others is the most common scoping mistake.
In most enterprise programs, right-sizing shares infrastructure with the metrics and observability stack, the autoscaling configuration, and the cost-management process. It shares team capacity with platform engineering, SRE, and the application teams that own workloads. And it shares leadership attention with whatever the next efficiency initiative is on the roadmap. Naming these adjacencies upfront helps the program scope realistically and helps leadership see the work as a portfolio rather than a one-off project.
The most common mistake in adjacent-capability scoping is treating each adjacency as someone else's problem. The metrics that reveal real usage are your problem. The cluster autoscaling that interacts with requests is your problem. The cost reporting that shows the savings is your problem. Pretending otherwise pushes work to teams that did not plan for it, and the work returns to you later as a wasteful cluster or a throttled service. Own the adjacencies you depend on; partner with the teams that own them; share the timeline.
Conclusion
Right-sizing Kubernetes turns a cluster that is both wasteful and unstable into one that is efficient and reliable, by grounding requests and limits in real usage and resource behavior. The discipline that achieves it is the same discipline behind any tuning: measure reality, configure to it, and keep adjusting.
Key Takeaways:
- Right-sizing grounds requests and limits in real observed usage
- Over-provisioning is waste, and bad limits cause throttling and OOM kills
- CPU and memory behave differently and must be configured differently
Right-sizing well requires usage, behavior, and review discipline. When done correctly, it produces:
- Reclaimed capacity and lower cost
- Better performance from limits that protect without throttling
- A cluster running at healthy utilization
- Resource configuration that reflects reality and stays current
Hidden PHI Exposure Risks in Healthcare AI
Why 90% of healthcare organizations are unknowingly exposing patient data through AI tools.
What Logiciel Does Here
If your cluster runs at low utilization or your workloads are being throttled, measure real usage, right-size requests and limits by behavior, and add guardrails before you add nodes.
Learn More Here:
- Cluster Autoscaling That Doesn't Surprise Your Finance Team
- Kubernetes Security and Cost Hardening
- Capacity vs. Cost: Autoscaling Policies for Spiky AI Traffic
At Logiciel Solutions, we work with platform leaders on Kubernetes right-sizing, autoscaling, and cost efficiency. Our reference patterns come from production clusters at scale.
Explore how to right-size your Kubernetes clusters against real usage.
Frequently Asked Questions
What does right-sizing Kubernetes mean?
Setting each workload's resource requests and limits based on its observed real usage, so requests reserve close to what is actually needed and limits cap without throttling normal operation. It avoids both over-provisioning and resource starvation.
What is the difference between requests and limits?
A request is what the scheduler reserves for a workload and uses for placement; a limit is the ceiling a workload cannot exceed. Over-large requests waste reserved capacity, while badly set limits cause CPU throttling or memory out-of-memory kills.
Why must CPU and memory be configured differently?
Because CPU is compressible, exceeding a CPU limit causes throttling, while memory is incompressible, exceeding a memory limit causes the workload to be killed. Treating them identically leads to either wasted CPU caps or crashes, so each needs configuration suited to its behavior.
Should I use averages or peaks to set requests?
Neither alone. Averages hide spikes and peaks over-provision for rare events. Use percentiles over a representative period to capture the realistic working range, then add deliberate headroom.
What is the biggest mistake in Kubernetes resource configuration?
Over-provisioning generously "to be safe," often by copy-pasting values from a template. It leaves the cluster running at a fraction of its reserved capacity at high cost, and frequently still causes the throttling or OOM instability it was meant to avoid. Size to real usage instead.
