CostMonStart free

Cloud cost

Requests vs. limits

A request is what the scheduler reserves for a container. It decides whether the container fits on a node. A limit is a ceiling that the kubelet enforces at runtime.

Cloud cost

Last updated

Definition

The Kubernetes scheduler uses the request to decide whether a pod fits on a node. A request is a reservation. It drives cost, because it decides how many nodes a workload needs. A limit applies only at runtime. The kubelet throttles CPU, or OOM-kills a container, when the container goes over it. A limit reserves nothing and plays no part in scheduling.

It is easy to assume that a generous limit is safe and to stop tuning there. But only the request affects what a node can fit. A high limit with no matching request makes a manifest look careful to a human. It changes no scheduling decision.

Where it shows up

Requests and limits both appear in a pod's manifest, under resources.requests and resources.limits. The same fields show in the output of kubectl describe pod. The scheduler reads only the request value when it decides whether a pod fits on a candidate node.

What makes it expensive

A generous limit looks careful in a manifest. It changes nothing about what the workload costs. Only the request decides how many nodes the workload needs, and nobody goes back to that field. Audit the two side by side against real usage. The manifests that looked most conservative are usually the 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