Kubernetes rightsizing is the practice of setting resource requests and limits to reflect what workloads actually need. It centers on CPU and memory, and it affects how efficiently Kubernetes schedules workloads and how much capacity the cluster requires. Workloads with insufficient CPU or memory configuration can experience CPU throttling, memory pressure, or restarts. Pods can remain pending when their resource requests or other scheduling constraints cannot be satisfied by available Nodes. Those conditions can affect response times, error rates, and reliability.
As Kubernetes environments grow across teams and clusters, resource requests and limits have a direct effect on capacity, application performance, and cloud costs. Rightsizing gives teams a practical way to review those settings against actual workload behavior instead of relying on conservative defaults.
To do Kubernetes rightsizing right, you need to understand a few key things:
The following tools can provide some of the usage and cluster-state data needed for a rightsizing review:
Cloud spend is a significant cost for many organizations, so it makes sense to ensure that resources are allocated as efficiently as possible. Still, it can be challenging to get all the data needed to make informed decisions. It’s often a real challenge to get visibility into your Kubernetes environment at this level, particularly if you have multiple teams, multiple clusters, and multiple clouds at play. That’s why we created Goldilocks. It creates Vertical Pod Autoscaler resources in recommendation mode for workloads in a namespace and surfaces the resulting recommendations in a dashboard. By default, those VPAs report recommendations but do not automatically change Pods.
Resource requests communicate the CPU and memory a workload needs for scheduling. Limits set an upper bound on the CPU or memory available to a container. Together, they give teams a baseline for balancing workload performance, node utilization, and cost. You should also use monitoring tools on an ongoing basis to track resource usage over time so you can identify workloads that are over- or under-provisioned. Review rightsizing alongside cluster autoscaling. Overstated resource requests can make Pods harder to place on existing Nodes and can prevent Node consolidation, even when actual workload usage is low.
Accurate usage data is central to ongoing rightsizing decisions. In Kubernetes 1.37, the metrics.k8s.io API graduated to stable, providing a standard way to retrieve CPU and memory usage for Pods and Nodes. Components including the Horizontal Pod Autoscaler and kubectl top use this API.
Goldilocks provides a starting point for setting resource requests and limits. Teams still need to validate recommendations against each workload’s performance, reliability, and operational requirements.
Here’s how to get started:
Rightsizing depends on teams setting resource requests and limits consistently. Polaris can help validate whether Kubernetes workloads meet configuration standards, including checks for missing resource requests and limits. These guardrails do not replace usage analysis, but they can prevent workloads from bypassing the baseline configuration needed for a rightsizing program.
Policy automation can enforce the configuration standards that make rightsizing possible at scale. Usage analysis remains necessary to identify whether individual workload requests and limits are too high or too low. When resource requests are too high, Pods can be harder to place efficiently and Nodes may be harder to consolidate. When requests or limits do not reflect workload needs, teams may see scheduling pressure, CPU throttling, or memory-related failures. Monitor resource usage over time and revisit workload configuration as workloads and clusters change.
Rightsizing can help reduce Kubernetes compute costs by ensuring that each workload has the resources it needs, but not more. Rightsizing is most effective when teams treat it as an ongoing review of workload behavior, resource configuration, and cluster capacity. That discipline can reduce unused capacity while helping teams identify configurations that create performance or reliability risk.
Originally published 14 November, 2023 and updated 30 September, 2026.
