Kubernetes resource requests help the scheduler place a workload against available capacity. Limits constrain resource use at runtime. For ordinary Linux containers, a CPU limit can cause throttling, while a memory limit can lead to an out-of-memory termination. These mechanisms answer different questions, so copying the same value into every field is not a sizing method.
The practical starting point is to identify the symptom: a Pod cannot be scheduled, a running application is slow, or a process is being terminated. Then inspect the relevant control and the workload evidence. Increasing all four CPU and memory values may hide the distinction without explaining the problem.
This article uses illustrative resource declarations. It does not report a running Kubernetes experiment or prescribe production values.
Read a declaration as four separate decisions
Consider this fragment for one ordinary application container:
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "1"
memory: "512Mi"
The request declares 0.25 CPU and 256 MiB for placement accounting. The limits specify 1 CPU and 512 MiB as runtime boundaries. A CPU quantity is not a percentage of whichever machine happens to host the Pod. A memory quantity is not a rate.
The Kubernetes resource-management documentation explains the scheduling/runtime distinction and the different enforcement mechanisms. A container can use more than its request when resources are available; a request is not an upper bound on consumption.
For a review, annotate why each value exists. “The service needs this amount to maintain the intended response time under representative load” is a hypothesis to test. “Copied from another service” is provenance for the configuration, not evidence of its suitability.
A Pending Pod needs a placement explanation
Suppose a node has 2 CPUs of allocatable capacity, and existing workload requests account for 1.8 CPUs. A new 250m request exceeds the remaining 200m. The simplified CPU arithmetic says that this Pod cannot fit there, even if a utilization chart shows little current CPU activity.
That example isolates one resource constraint. Real placement also depends on memory, affinity, taints, topology and other scheduling conditions. Read the scheduling event before concluding that CPU requests are the cause. A Pod whose constraints cannot be satisfied is not fixed by changing an unrelated runtime limit.
The useful distinction is between capacity already committed through requests and capacity currently being consumed. Lowering requests may allow more Pods to be placed, but it also changes the assumptions under which they compete when load rises. Validate that decision with representative workload behavior instead of using placement success as its only acceptance criterion.
Slow execution is a different investigation
Suppose the same Pod runs but becomes slow during bursts. A CPU limit may be relevant if the workload reaches its allowed CPU bandwidth, yet a slow response can also come from an external dependency, lock contention or queueing.
Compare request latency, completed work, CPU consumption and available throttling evidence over the same interval. If you test a different limit, hold the workload and surrounding capacity as stable as practical. A lower latency after a change is useful evidence, but the test still needs enough context to distinguish the changed control from a quieter node or warmer cache.
Changing a memory limit will not directly resolve CPU throttling. Likewise, allocating more CPU does not repair an unbounded memory retention problem. The purpose of the four-field model is to avoid treating every resource symptom as the same knob.
Distinguish OOM termination from node-pressure eviction
A container terminated for exceeding a memory boundary and a Pod evicted because its node is under pressure require different evidence. Inspect the container's last termination state, restart count, Pod events and node conditions. Preserve logs from the failed attempt when they are available.
Kubernetes documents node-pressure eviction separately. Requests, priority and usage influence eviction decisions; a resource declaration is not an unconditional promise that a Pod can never be evicted.
For an application that grows over time, raising the memory limit may extend the interval before failure without addressing the cause. Compare a bounded cache filling toward a stable plateau with a process whose retained memory continues to grow. Those patterns support different follow-up work, even if both initially trigger the same operational alert.
Do not treat every exit code or restart as proof of OOM. Confirm the reason reported by the runtime and correlate it with the available resource evidence. Our guide to logs, metrics and traces explains how to connect symptoms with a narrower investigation.
Inspect the admitted object, not only the file in Git
Namespace policy can affect an incoming workload. A LimitRange can supply defaults and enforce resource bounds. Therefore, the manifest submitted by a developer and the Pod admitted by the API server may not express the same final values.
During review, compare the intended configuration with the admitted object and any relevant policy. Check all application containers and account for sidecars and initialization behavior. This article's one-container example does not cover every Pod-level resource feature or scheduling rule.
Record cluster version, operating system, runtime and applicable policies when testing. The linked documentation changes over time, and newer resource features should not be assumed to exist on an older cluster. A Linux explanation of CPU throttling is also not a complete description of every supported operating system.
Make sizing a repeatable decision
Choose an acceptance condition before a sizing experiment: for example, sustain the intended throughput while meeting a response-time objective, with tolerable restart behavior and capacity cost. Include startup, steady load and an appropriate burst scenario.
Keep the workload artifact stable during that comparison. Reproducible builds and artifact identity help distinguish a resource-setting change from a different application build.
Record the observed result with the exact configuration. Revisit it when traffic, dependencies, runtime or application behavior changes. A request or limit is a maintained operational decision, not a permanent property of the service name.
Research note: Kubernetes documentation reviewed October 28, 2026. Scope is the ordinary per-container CPU/memory model, primarily on Linux; advanced Pod-level and platform-specific behavior requires separate review. The manifest and capacity arithmetic are illustrative and were not applied to a cluster.
