Requests guide placement and resource sharing; limits constrain runtime consumption. They are related inputs, not a universal floor-and-ceiling guarantee for application performance. Choose them from workload behavior, contention risk and recovery requirements. Inspect the admitted Pod because defaults and policy can change the resource values submitted in a manifest.
Defaults are part of the contract
If a resource has a limit but no request, Kubernetes copies that limit into its request unless admission has supplied a different request. Limits-only therefore does not normally mean zero scheduling cost. LimitRange defaults and ResourceQuota checks can also affect admission. Read the stored request and limit maps before explaining why a Pod is Pending.
A request does not preallocate an application’s physical memory or necessarily assign exclusive CPU cores. CPU requests affect scheduling and relative sharing under contention. A container without a CPU limit may use spare CPU beyond its request, but node capacity, ancestor constraints and competing work remain boundaries. Omitting a limit can be intentional; it needs an explicit capacity and contention policy.
A CPU limit generally enforces bandwidth through throttling on Linux. That mechanism does not directly kill a process merely for exhausting its quota. It can still increase latency, trigger application deadlines or interact with probes. A low host-wide CPU average does not rule out a tightly capped container spending substantial time throttled.
Memory has different failure behavior
Memory limits are not CPU-style periodic allowances. The kernel can reclaim accounted memory and trigger cgroup OOM when the constraint cannot be satisfied; enforcement is reactive rather than an instantaneous kill at a dashboard crossing. Node pressure and application failure are additional mechanisms. Separate container OOM evidence from node eviction and ordinary process termination.
Container-accounted memory includes more than one managed heap. Native allocations, stacks, file-backed memory and memory-backed volumes can matter. Process RSS and application heap metrics are useful views, but neither alone equals every byte charged to the cgroup. Examine the accounting relevant to the runtime and kernel, including short peaks that a sampling interval can miss.
Exit code 137 means a shell-style report of SIGKILL, not proof of OOM. Correlate the terminated container’s reason, controller counters, node events and workload metrics. An operator or another mechanism can also send KILL. Logs may be incomplete after abrupt termination, but they can still reveal a leak, oversized input or changed workload.
Size from evidence, not fixed ratios
Collect representative usage across normal traffic, deployments, batch work and recovery. Historical monitoring is needed for percentiles; metrics-server and kubectl top provide recent resource metrics, not a built-in week’s p95 archive. Choose headroom from the cost and variability of the workload instead of a universal twenty-percent rule.
Raising only a limit does not normally reserve extra scheduler capacity when an explicit smaller request stays unchanged. Raising requests can reduce placement headroom. Distinguish those changes when interpreting Pending Pods, and include HPA utilization targets because changing CPU requests changes their denominator even when actual usage stays the same.
Under conventional per-container QoS rules, Guaranteed requires every relevant container to have equal CPU requests and limits and equal memory requests and limits. Equal memory alone is insufficient. The class is not immunity from resource failure, and fixed request-to-limit ratios are not substitutes for measured demand and failure testing.
Kubernetes 1.34 also has beta PodLevelResources, enabled by default. With supported Pod-level CPU and memory budgets, QoS classification considers those fields; the conventional per-container rule above is not a complete test for every configuration. Inspect admitted Pod-level fields as well.
When it breaks
OOM loops can reflect insufficient headroom, leaks, unsuitable heap configuration or unexpected input. Throttling can reflect a restrictive quota, but also needs interpretation alongside request latency and demand. Neither observation automatically authorizes increasing limits: doing so may shift pressure to other workloads or conceal a real application problem.
Likewise, no throttling does not prove requests should shrink. Requests also determine sharing during contention and may be sized for demand absent from the observed interval. Alerts should use workload-specific warning windows; a usage threshold cannot promise several days of notice before a sudden allocation spike.
Check it quickly
These retained read-only commands were not rerun in this review. Select an authorized test context and a namespace actually named prod; the label is an example, not permission to inspect an unknown production cluster. They offer a starting snapshot rather than a complete per-container comparison.
kubectl top pods -n prod --sort-by=memory | head
kubectl get pods -n prod -o custom-columns=NAME:.metadata.name,REQ:.spec.containers[*].resources.requests.memory,LIM:.spec.containers[*].resources.limits.memory --no-headers | head -n 15
kubectl get events -n prod --field-selector reason=OOMKilling --sort-by=.lastTimestamp | tail -n 5
The top command reports Pod totals unless container output is requested. The custom columns list container values without their names, and OOMKilling events are not guaranteed to exist or remain retained. Empty event output is no negative control for OOM. Compare admitted resources, container termination reasons and cgroup counters with historical usage before drawing a conclusion; a successful listing alone does not validate enforcement.
Sources
Kubernetes resource management, Official doc describing how requests and limits are interpreted by the scheduler, checked 2026-10-15.
Kubernetes QoS classes, explains Guaranteed, Burstable, and BestEffort behavior, checked 2026-10-15.
Primary reference, CPU counters and memory controller accounting, checked 2026-10-15.
Primary reference, resource-metrics scope, checked 2026-10-15.
Kubernetes 1.34 Pod-level resources, Pod-level feature state and QoS precedence, checked 2026-10-18.
