Right-size Kubernetes pods guide: requests, limits, and cost

Quick answer

In Kubernetes, a pod's resource requests reserve CPU and memory on a node whether or not the pod uses them, so over-set requests waste node capacity and force you to run more nodes than necessary. Right-sizing means setting requests close to real usage (with headroom for spikes) and limits to prevent runaway consumption, so the scheduler packs more pods onto fewer nodes. The cluster bill is really the node bill, and node count is driven by the sum of pod requests, so tightening requests directly cuts how many nodes, and how much, you pay for.

Kubernetes cost optimization confuses people because you do not pay for pods, you pay for the nodes they run on. The link between the two is resource requests: the scheduler places pods based on their requested CPU and memory, reserving that capacity on a node whether the pod uses it or not. So over-set requests waste node capacity and inflate node count, which is the real bill.

Requests, limits, and the node bill

Setting	Effect on cost
Requests	Reserve node capacity, drive node count
Limits	Cap usage, prevent runaway consumption
Node count	Sum of requests divided by node capacity

Requests are the cost lever. The scheduler must find a node with enough unreserved capacity for a pod's requests, so the total requested across all pods determines how many nodes the cluster needs. If every pod requests far more than it uses, the cluster runs many half-empty nodes, and you pay for that emptiness. Right-sizing requests packs pods tighter and shrinks the node count.

Over-provisioned requests are the waste

The most common Kubernetes waste is requests set far above actual usage, often copied from a template or set generously to be safe. A pod that requests a full CPU but uses a tenth of it reserves capacity nine other pods could have shared. Multiply that across a cluster and you are running several times the nodes you need. This is the container version of EC2 over-provisioning, just one layer up.

Setting requests and limits right

Measure each workload's real CPU and memory usage over time, then set requests close to typical usage with enough headroom for normal spikes, so pods pack efficiently without being starved. Set limits to cap runaway consumption and protect neighbors, but be careful with tight CPU limits that throttle. Use the vertical pod autoscaler to recommend or apply right-sized requests, and the horizontal pod autoscaler to scale replicas with load rather than over-requesting a few large pods.

Right-sizing the nodes too

Beyond pod requests, choose node types that pack your pods efficiently and enable cluster autoscaling so idle nodes are removed. Consider spot nodes for fault-tolerant workloads to cut node cost further, and reserve the steady baseline like any committed capacity. Right-sizing requests and nodes together is what turns a bloated cluster into an efficient one. Price your node groups against the resource catalog so the cost of the cluster is visible before it grows.

FAQ

How do pod requests affect Kubernetes cost?

A pod's resource requests reserve CPU and memory on a node whether or not the pod uses them, and the scheduler places pods based on requests, so the total requested across all pods determines how many nodes the cluster needs. Since you pay for nodes, over-set requests reserve capacity that goes unused and force you to run more nodes than necessary, directly inflating the bill.

What is the difference between requests and limits?

Requests are the capacity the scheduler reserves for a pod on a node and are what drive node count and cost. Limits cap how much a pod can actually consume, preventing runaway usage that would starve neighbors. Requests determine placement and cost; limits protect stability. Right-sizing focuses on setting requests close to real usage, with limits set to prevent runaway consumption.

How do I right-size Kubernetes pods?

Measure each workload's real CPU and memory usage over time, set requests close to typical usage with headroom for normal spikes so pods pack efficiently, and set limits to cap runaway consumption. Use the vertical pod autoscaler to recommend right-sized requests and the horizontal pod autoscaler to scale replicas with load, rather than over-requesting a few large pods to be safe.

Why does over-requesting waste money in Kubernetes?

Because requests reserve node capacity regardless of use. A pod that requests a full CPU but uses a tenth reserves capacity that nine other pods could have shared, so the scheduler must add nodes to fit everything. Multiplied across a cluster, generous requests force you to run several times the nodes you need, and you pay for all that half-empty node capacity.

Should I use autoscaling to control Kubernetes cost?

Yes. The horizontal pod autoscaler scales replica count with load so you run the right number of pods, the vertical pod autoscaler right-sizes requests to actual usage, and the cluster autoscaler removes idle nodes so you stop paying for empty capacity. Together they keep both pod requests and node count matched to real demand, which is where Kubernetes cost is controlled.

How does C3X help with Kubernetes cost?

C3X prices the node groups and cluster infrastructure in your Terraform before you deploy, so the cost of the nodes backing your cluster is visible in the pull request. That complements pod-level right-sizing by making the node cost of a cluster configuration clear at design time, helping you choose node types and sizes that pack your workloads efficiently before the cluster scales up.

What to do next

Price your cluster node groups before they scale. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.