CostMonStart free

Cloud cost

Requests vs. limits

A request is what the scheduler reserves for a container and determines whether it fits on a node; a limit is just a ceiling the kubelet enforces at runtime.

Cloud cost

Last updated

Definition

A request is the number the Kubernetes scheduler uses to decide whether a pod fits on a given node. It's a reservation, and it's the number that drives cost, because it determines how many nodes a workload needs. A limit is enforced only at runtime: the point where the kubelet throttles CPU or OOM-kills a container that exceeds it. Limits reserve nothing and play no part in scheduling.

It's easy to assume a generous limit is "safe" and stop tuning there, but only the request affects what a node can fit. A limit set high with no corresponding request just makes a manifest look conservative to a human, without changing a single scheduling decision.

Where it shows up

Requests and limits both appear in a pod's manifest under resources.requests and resources.limits, and the same fields show up in the output of kubectl describe pod. Only the request value is read by the scheduler when it decides whether a pod fits onto a candidate node.

What makes it expensive

A generous limit reads as caution on a manifest and changes nothing about what the workload costs. Only the request decides how many nodes it needs, and the request is the field nobody goes back to. Audit the two side by side against real usage, and the manifests that looked most conservative are usually the ones furthest out.

The invoice is a lagging signal.

A monthly invoice tells you what already happened. CostMon builds a daily baseline, so a spike stands out while you can still act on it.

Esc