Kubernetes Resource Requests and Limits, Without the Guesswork

Requests guide scheduling

The scheduler uses resource requests when deciding whether a node has room for a pod. A container may use more CPU or memory than requested when capacity and limits allow, but the request is the amount Kubernetes accounts for during placement. If requests are far above realistic use, pods can remain Pending while nodes appear lightly utilized.

If requests are too low, the scheduler can pack workloads densely. Real simultaneous demand may then create contention or memory pressure. The right value comes from measurements and service requirements, not a universal ratio.

CPU limits throttle

CPU is measured in cores or millicores; 500m is half a CPU core. When a container reaches its CPU limit, the runtime can throttle it. The process usually stays alive, but latency rises and work takes longer. That can trigger timeouts and probe failures even though the pod does not show a crash.

Compare CPU usage, throttling metrics, request rate, and latency. A low-looking average can hide short bursts that matter. Before raising a limit, check for busy loops, unexpectedly expensive queries, or concurrency changes.

Memory limits can end the process

Memory cannot be throttled in the same way. When a container exceeds its memory limit, it may be terminated and show OOMKilled in the last container state. Kubernetes can then restart it according to the pod restart policy, producing a crash loop.

Inspect working-set history, heap behaviour, cache bounds, concurrency, and recent changes. Raising the limit can be a valid capacity change, but it may only postpone a leak. Also check node memory pressure; not every memory-related eviction is a container limit breach.

Read quantities carefully

CPU and memory use different units. CPU 100m means one tenth of a core. Memory 100Mi means 100 mebibytes. A lowercase m on memory means milli-bytes and is almost never intended. Review rendered manifests, not only template values.

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: "1"
    memory: 512Mi

Every container counts

Pod resource demand includes application containers and sidecars. A service mesh proxy, log shipper, or security agent may have its own requests and limits. Init containers follow special effective-request rules because they run sequentially before normal containers. Inspect the complete pod, not only the main container block.

Namespace LimitRanges can provide defaults or enforce minimums and maximums. ResourceQuotas can reject new pods even when nodes have capacity. Admission policies may mutate or validate values as well.

A practical sizing loop

1. Collect representative CPU, memory, latency, throughput, restart, and throttling data over normal and peak periods.
2. Separate baseline use from workload-dependent growth and one-time startup peaks.
3. Set requests that support scheduling and expected service quality.
4. Set limits according to isolation policy and application behaviour.
5. Load test or canary the change.
6. Watch pending pods, OOM kills, throttling, latency, and node pressure after rollout.

Vertical Pod Autoscaler recommendations can provide another signal, but they still need review against application behaviour and operational policy. Horizontal scaling also depends on sensible requests when utilization percentages are used.

Investigate before editing

When a pod is unhealthy, compare its configured request and limit with actual usage, exit reason, events, node conditions, and workload revision. Clusterdeck shows CPU and memory alongside pod state and provides quick access to resource YAML, descriptions, logs, and the owning workload. Use that joined view to form a hypothesis, then change the version-controlled configuration and watch the rollout.