Kubernetes requests and limits: how they set your cluster cost

Quick answer

Node cost is driven by requests, not actual usage: the scheduler reserves capacity by requests and packs pods until requests fill the node. Over-request and you pay for idle reserved capacity; under-request and pods get throttled or OOM-killed. Set requests near real peak usage plus margin, and use limits to cap blast radius, not to size the cluster.

A Kubernetes bill is mostly node cost, and node count is decided by a number many teams set by guesswork: the pod resource request. The scheduler does not look at how much CPU or memory a pod uses; it looks at what the pod requests, reserves that, and packs pods until requests fill the node. Get requests wrong and you either buy idle nodes or destabilize the ones you have.

Requests reserve capacity you pay for

If every pod requests one CPU but uses a tenth of one, the scheduler still reserves a full CPU per pod, so a node holds a tenth of the pods it could, and you run ten times the nodes you need. Over-requesting is the most common source of Kubernetes waste, and it is invisible in usage dashboards because the nodes look busy holding reservations that are never used.

Limits protect stability, they do not size the cluster

Limits cap what a pod may consume. A CPU limit throttles the pod when exceeded; a memory limit gets the pod OOM-killed when exceeded, which is a restart and a latency event, not a slowdown. Limits do not affect scheduling or node count, so they are a blast-radius control, not a cost lever. Set memory limits with more margin than CPU limits, for the reason in rightsizing without hurting performance.

Size requests to real peak, plus margin

Set CPU and memory requests near the pod's real peak usage plus a margin for spikes, using observed p95 or p99 rather than averages. Too low and pods get throttled or evicted under load; too high and you pay for reserved idle. The gap between request and actual usage across the cluster is your rightsizing opportunity, and it is usually large.

Autoscaling amplifies the request choice

The Horizontal Pod Autoscaler and Cluster Autoscaler both act on requests, so a bad request value scales badly: over-requested pods trigger new nodes early and you pay for headroom you do not use. Tune requests first, then autoscaling, so you are scaling right-sized pods. The same cost-versus- headroom tradeoff applies as in autoscaling cost vs performance.

FAQ

Do Kubernetes requests or limits drive node cost?

Requests. The scheduler reserves capacity by requests and packs pods until requests fill a node, so requests decide how many nodes you run and pay for. Limits cap consumption but do not affect scheduling or node count.

What happens if I over-request resources?

The scheduler reserves capacity the pod never uses, so each node holds fewer pods than it could and you run more nodes than you need. Over-requesting is the most common cause of Kubernetes waste and is hidden in usage dashboards.

What happens if I under-request?

Pods can be scheduled onto nodes that are actually oversubscribed, leading to CPU throttling and, if memory is exceeded, OOM kills that restart the pod. Under-requesting trades cost for instability and latency.

How should I set requests and limits?

Set requests near the pod's real peak usage (observed p95 or p99) plus margin, so the scheduler packs efficiently without starving pods. Use limits to cap blast radius, with more margin on memory than CPU, since exceeding a memory limit is an OOM kill.

Do requests affect autoscaling cost?

Yes. The Horizontal and Cluster Autoscalers act on requests, so over-requested pods trigger new nodes early and you pay for unused headroom. Right-size requests first, then tune autoscaling, so you scale efficiently packed pods.

Does C3X estimate Kubernetes cost?

C3X prices the node groups and managed cluster resources in your Terraform, so the infrastructure cost is visible before deploy. The efficiency of your requests determines how many of those nodes you actually need, which you tune from usage data.

What to do next

Price the node groups behind your cluster before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart, and for the EKS-specific picture see the EKS cost breakdown.