Komodor is an autonomous AI SRE platform for Kubernetes. Powered by Klaudia, it’s an agentic AI solution for visualizing, troubleshooting and optimizing cloud-native infrastructure, allowing enterprises to operate Kubernetes at scale.
Proactively detect & remediate issues in your clusters & workloads.
Easily operate & manage K8s clusters at scale.
Reduce costs without compromising on performance.
Guides, blogs, webinars & tools to help you troubleshoot and scale Kubernetes.
Tips, trends, and lessons from the field.
Practical guides for real-world K8s ops.
How it works, how to run it, and how not to break it.
Short, clear articles on Kubernetes concepts, best practices, and troubleshooting.
Infra stories from teams like yours, brief, honest, and right to the point.
Product-focused clips showing Komodor in action, from drift detection to add‑on support.
Live demos, real use cases, and expert Q&A, all up-to-date.
The missing UI for Helm – a simplified way of working with Helm.
Visualize Crossplane resources and speed up troubleshooting.
Validate, clean & secure your K8s YAMLs.
Navigate the community-driven K8s ecosystem map.
Who we are, and our promise for the future of K8s.
Have a question for us? Write us.
Come aboard the K8s ship – we’re hiring!
Discover our events, webinars and other ways to connect.
Here’s what they’re saying about Komodor in the news.
Join the Komodor partner program and accelerate growth.
Most teams discover they have a Kubernetes rightsizing problem when a senior glances at the cloud bill, says something unprintable, and suddenly there’s a Slack thread with twenty people arguing about CPU limits.
The frustrating part is that Kubernetes gives you every tool you need to fix it, and those tools will absolutely break your production environment if you apply them without thinking.
The cost problem and the reliability problem are entwined: inaccurate resource configurations hurt your bill and your uptime simultaneously.
This article is about implementing Kubernetes rightsizing correctly at scale, across hundreds of workloads, multiple teams, and environments where an OOMKill at 2 am is a real professional consequence.
Rightsizing k8s sounds easy: look at what pods actually use, set requests and limits to match, reclaim the wasted compute. In practice, you’re operating against three problems at once.
First, your observability is probably lying to you. P99 CPU consumption over 7 days doesn’t capture a workload that spikes to 4x average every Tuesday during batch jobs.
Second, your teams have learned to pad requests because they’ve been burned before, and that institutional knowledge is now baked into hundreds of Helm values files nobody wants to touch.
Third, the tools designed to automate this require more configuration care than most platform teams have the time or expertise to give them.
CPU requests in Kubernetes determine scheduling. CPU limits determine throttling. Memory requests determine scheduling. Memory limits determine OOMKills. These four levers interact in ways that make naive rightsizing genuinely dangerous.
A workload running at 200m CPU actual usage with a 2000m CPU request is wasting 1800m of schedulable capacity on every node it lands on. That’s real money and real density loss.
But set that limit too low and you’ll throttle a Java service during GC, watch latency spike, and spend three hours in a post-mortem explaining why saving $400/month in compute triggered an incident that took eight engineers half a day to resolve.
The goal of Kubernetes workload rightsizing is to set requests and limits accurately, with enough headroom to absorb real traffic variation without padding for events that will never happen.
Let’s take a Node.js API service running in a mid-size e-commerce platform. At deployment, the team set 1000m CPU request and 2000m CPU limit, a reasonable guess at the time, never revisited.
Two weeks of Prometheus data shows P50 consumption at 80m, P95 at 210m, and a single weekly spike to 480m during a scheduled email campaign. The right configuration isn’t 1000m/2000m, and it isn’t 80m/80m either. It’s 250m request and 600m limit: enough headroom to absorb the spike without throttling, sized to actual behavior rather than imagined worst-case scenarios.
The result on a cluster running 200 similar workloads is a meaningful improvement in scheduling density, which means fewer nodes needed for the same workload, compounding across every service you touch.
The memory side of the equation follows the same logic. A Java service with a 4 Gi memory request and 1 Gi average actual consumption is blocking four times the capacity it needs on every node it lands on.
Set memory limits just above the realistic P99 with a small burst buffer, and watch the bin-packing math improve immediately.
The Vertical Pod Autoscaler exists specifically for kubernetes pod rightsizing. In Auto mode, it will evict pods and restart them with new resource configurations, which is exactly what you don’t want happening to a stateful workload during peak traffic.
In Off or Initial mode, it generates recommendations without applying them, which is safer but means someone still has to review and apply those recommendations across potentially thousands of workloads.
VPA also doesn’t understand your deployment context. It doesn’t know that a particular service is in a revenue-critical path, that another service is a dev environment nobody’s looked at in three months, or that your kubernetes resize policy should treat your data pipeline pods differently from your API pods.
Scale breaks that strategy regardless of how well you execute it. The manual oversight that riskier workloads require doesn’t get cheaper as you add more of them.
The teams that do this well slow down before they speed up. They invest time in understanding actual consumption patterns before they touch a single YAML file.
They build rollback paths before they optimize. And they start with low-risk workloads before they get anywhere near stateful services or tier-one applications.
You cannot rightsize what you cannot measure. Before any change to resource configurations, you need per-pod CPU and memory consumption metrics with enough historical depth to capture your traffic patterns, at a minimum of two weeks, ideally a full monthly cycle.
Prometheus with kube-state-metrics and node-exporter gives you what you need if you don’t already have it.
If you’re on a managed service like GKE or EKS, the platform’s native metrics can supplement this, though vendor tooling often lacks the granularity needed for accurately rightsizing EKS workloads at the pod level.
The questions you’re trying to answer are: what does this workload actually use at P50, P95, and P99? How much does that vary by time of day, day of week, or deployment event? And what happens to this workload under load, not just at idle?
A kubernetes resize policy is a decision framework, not just a Kubernetes API field. Before you apply recommendations, you need to decide: which workload categories get VPA in Auto mode and which get manual review by a human who understands the service.
Stateless, horizontally scaled workloads with HPA already configured are relatively safe candidates for automated rightsizing. They can absorb pod restarts through the HPA’s replica management.
Stateful services, anything with a PDB that limits disruption, or workloads in critical paths should go through a slower cycle of recommendation review, staged rollout, and canary comparison before any resource change sticks.
Dev and staging namespaces are where you run the experiment, get comfortable with the tooling, and collect the before/after data that will make your case to leadership when it’s time to touch production.
The table below captures the decision logic most platform teams converge on after a few cycles of trial and error. Use it as a starting point, not a rigid rule.
The sequencing matters as much as the classification. Starting with dev namespaces and batch jobs gives you real data on how your recommendations perform before you’re anywhere near a tier-one service.
By the time you reach stateful workloads, you should have a validated toolchain, a track record of successful changes, and application teams who’ve seen the process work without an incident.
Without that trust built up through earlier wins, every recommendation for a critical service will face an uphill battle regardless of how accurate it is.
The coordination problem at scale is organizational. When you have 200 engineers deploying to a shared cluster, kubernetes pod rightsizing isn’t something the platform team can do unilaterally.
Application teams own their workload behavior. Only they know which services are latency-sensitive, which ones have compliance constraints on restart frequency, and which ones are genuinely overprovisioned versus strategically padded to handle unpredictable traffic.
The most effective model is a shared responsibility approach. The platform team provides the tooling, the recommendations, and the guardrails. Application teams own the decision to apply them, with a clear SLA.
That last clause is important. Without it, the recommendations accumulate in a dashboard nobody looks at, the cost problem continues, and the only thing that changes is the length of your Jira backlog.
Kubernetes cost optimization and reliability are not inherently in conflict, but they are in tension. Every resource change is a potential incident if it’s applied carelessly. Managing that tension is the actual job.
Let’s say a platform engineer runs a rightsizing analysis, finds $80,000/year in wasted compute, presents the findings, gets approval to proceed, reduces limits across 40 services, and three weeks later half of those changes have been silently reverted by application teams who saw a latency blip and panicked.
The reverts are a rational response to uncertainty. The problem is that the teams don’t trust the recommendations because they don’t understand how they were generated, they can’t see the impact of a change before it’s applied, and they have no fast rollback path if something goes wrong at 3 am.
The fix is transparency and tooling, not enforcement. When application teams can see exactly what a resource change will do to their scheduling footprint, understand the recommendation confidence level, and know they can roll back in under five minutes if needed, the revert rate drops significantly.
One of the more common failure modes in rightsizing k8s workloads is conflicting signals between VPA and HPA. VPA recommends reducing a CPU request; HPA is using CPU utilization as a scaling metric; you reduce the request, utilization percentage spikes against the new lower baseline, HPA scales out aggressively, your node count doubles, and you’ve spent more than you saved.
The Kubernetes MutatingAdmissionWebhook that VPA uses can be configured to avoid this, but it requires coordination and testing that most teams skip because it sounds boring until it isn’t.
If you’re running HPA on CPU metrics, set VPA to Off or Initial mode for those workloads and use VPA’s recommendations as input to a manual right sizing kubernetes pods process rather than an automated one.
If you’re using custom metrics or request-count-based HPA scaling, the risk is lower and you have more room to automate.
Before automating resource changes, map every autoscaling signal that touches the affected workloads and verify they won’t interact in unexpected ways under load.
A resource misconfiguration on one workload in a single cluster is an incident. The same misconfiguration pattern applied systematically across 800 workloads in six clusters is a crisis, and it’s exactly the failure mode that automation without guardrails produces.
At scale, the reliability risk of rightsizing is about blast radius: how many services are affected if a recommendation turns out to be wrong, how quickly you can detect the impact, and how fast you can reverse it before users notice.
Teams that skip the staged rollout discipline because it feels slow are the ones who end up doing emergency rollbacks across dozens of namespaces at the same time, which is considerably slower.
The other scale-specific reliability risk is configuration drift. You rightsize 400 workloads, reclaim significant compute capacity, close the project, and six months later half those workloads have drifted back to overprovisioned states because new deployments came in with the old values, nobody reviewed the Helm defaults, and the teams that owned those services turned over.
Rightsizing at scale requires a feedback loop that catches drift continuously, not a periodic audit that rediscovers the same problem every year.
Without that loop, you’re running a recurring Kubernetes cost optimization event, which is a meaningfully less efficient use of your platform team’s time.
Running a rightsizing exercise for 10 workloads is a weekend project. Running one for 1,000 workloads across 15 teams and 4 clusters is an operational capability that requires tooling, process, and ongoing maintenance.
The difference between teams that make progress here and teams that stay stuck is whether they’ve built systems around the work or are still relying on individuals to carry the weight.
The operational pattern that works at scale looks like this.
This is just what a mature internal toolchain for Kubernetes workload rightsizing looks like. Some organizations build it entirely in-house. Many try, get 60% of the way there, and then discover that maintaining it is its own full-time job.
The problem with rightsizing at scale is a decision-making problem: translating noisy, multi-dimensional consumption data into accurate recommendations, routing those recommendations to the right people, managing the coordination across teams, and detecting when a change has caused a regression before the on-call engineer’s phone lights up at midnight.
An AI SRE platform handles the decision-making layer, not by replacing engineering judgment, but by processing signal at a scale and speed that human engineers can’t match manually.
That means surfacing k8s pod rightsizing recommendations ranked by confidence and savings impact, flagging workloads where a resource change carries elevated reliability risk, and detecting post-change regressions automatically rather than waiting for a user to report latency degradation.
The outcome is a reduction in the toil required to do the work correctly, meaning fewer tickets, fewer war rooms, fewer 3 am pages that turn out to be an OOMKill that a better memory limit would have prevented.
Kubernetes rightsizing at scale is solvable, but it needs to be treated as an operational discipline rather than a one-time cleanup project.
The teams that get it right build continuous observability into their foundations, define a kubernetes resize policy that respects workload criticality, coordinate with application teams rather than overriding them. Most critically, they invest in autonomous tooling that makes the ongoing work sustainable, even across the most sizable environments.
The teams that struggle are usually trying to manage resources manually, at scale, with insufficient data and no rollback path, and then wondering why nobody trusts the recommendations.
The outcome worth pursuing is one where resource accuracy is built into the system, so platform teams can stop fielding tickets every time someone wants to change a resource limit. It’s application engineers who can ship without waiting on infrastructure approval for routine configuration changes. It’s an on-call rotation getting fewer pages for OOMKills that a correct memory limit would have prevented six months ago.
Komodor’s Autonomous AI SRE platform is built specifically for the operational complexity that large engineering organizations face when managing Kubernetes at scale.
Komodor eliminates operational toil for platform teams and SREs by leveraging agentic AI (Klaudia) to continuously analyze workloads against the context of historical data, safely automating the identification, validation and execution of rightsizing optimizations across cloud and on-prem clusters.
Make safe, reliable Kubernetes rightsizing a feature of your system, not a task on someone’s backlog.
Kubernetes rightsizing is the process of setting CPU and memory requests and limits on workloads to accurately reflect their actual consumption patterns, rather than what was guessed at deployment time.
It matters because overprovisioned workloads waste compute capacity on every node they’re scheduled on, directly inflating cloud costs. Underprovisioned workloads cause throttling, OOMKills, and latency problems that generate incidents.
Getting it right is one of the highest-return activities available to a platform team from a pure cost-to-impact ratio.
The Vertical Pod Autoscaler automates the recommendation and application of resource adjustments based on historical consumption data. Manual rightsizing means a human reviews consumption metrics and updates resource configurations directly.
VPA in Auto mode applies changes by evicting and restarting pods, which is disruptive to stateful or latency-sensitive workloads.
Manual rightsizing is slower but gives application teams full control over when and how changes are applied. In practice, most mature teams use VPA in recommendation-only mode as a data source and manage the application process through a controlled workflow.
You need at minimum two weeks of per-pod CPU and memory consumption data, capturing both typical operation and any known traffic peaks. Apply changes in non-production environments first and monitor for a soak period before promoting to production.
Set a clear Kubernetes resize policy that categorizes workloads by criticality and autoscaling behavior before any change is made. You should be able to revert a resource configuration change in under five minutes without opening a ticket.
Prioritize stateless, horizontally scaled workloads first, and keep stateful services and critical-path applications in a manual review category until you have confidence in your process.
HPA scales the number of pod replicas based on a metric, usually CPU utilization. CPU utilization is calculated as actual consumption divided by the CPU request.
If you reduce a workload’s CPU request through rightsizing, the utilization percentage increases for the same actual consumption, which can trigger HPA scale-out.
This means rightsizing a workload without accounting for its HPA configuration can cause unexpected scaling behavior that costs more than it saves.
EKS environments often involve more node heterogeneity, and the cost impact of a resource change depends on which node class a pod actually lands on.
With Karpenter as the node autoscaler, overprovisioned CPU or memory requests cause Karpenter to provision larger or more nodes than necessary, directly increasing cost and reducing autoscaling efficiency.
Rightsizing EKS workloads accurately is therefore a prerequisite for Karpenter to function as designed, not just a nice-to-have optimization.
A focused rightsizing exercise for a single cluster with clear ownership can produce initial recommendations within a week and measurable cost reduction within 30 days.
At enterprise scale, expect the initial cycle to take two to three months if done properly, with ongoing work thereafter.
Organizations that treat rightsizing as a continuous operational capability rather than a project see compounding returns; those that treat it as a one-time effort find the gains erode within six months.
Run a two-week consumption analysis against your current resource requests and you’ll almost certainly find enough waste to make the numbers compelling. Most enterprise Kubernetes environments run at 20-40% actual CPU utilization relative to requested capacity.
Convert that gap into node-hours at your current cloud unit cost, and you have a number leadership will pay attention to. The harder sell is that any engineer who’s been through a bad rightsizing incident will push back on automation, and that pushback is legitimate.
The business case needs to address both sides: here’s the cost opportunity, here’s the risk profile, and here’s the process that captures the savings without generating the incidents.
Share:
Gain instant visibility into your clusters and resolve issues faster.
May 12 · 9:00EST / 15:00 CET · Live & Online
🎯 8+ Sessions 🎙️ 10+ Speakers ⚡ 100% Free
By registering you agree to our Privacy Policy. No spam. Unsubscribe anytime.
Check your inbox for a confirmation. We'll send session links closer to May 12.
