Kubernetes Resource Request Management

Kubernetes Resource Request Management is the practice of declaring, sizing, and maintaining the resources.requests field on container specifications — the value the scheduler uses to determine whether a node has sufficient capacity to host a Pod, and the value the kubelet uses as the baseline for quality-of-service classification and eviction ordering. A request represents a guaranteed reservation: Kubernetes commits to ensuring at least this much capacity is available to the container, and no other Pod's requests will cause that reserved amount to be double-booked on the same node.

Unlike limits, which bound how much a container may actually consume, requests exist primarily to inform placement and guarantee a baseline — get requests wrong, and the consequences show up as either wasted cluster capacity (requests set too high) or contention and instability (requests set too low), long before any limit is ever reached.

What Requests Actually Do

Scheduling Input

The scheduler sums the requests of a candidate Pod together with every already-scheduled Pod on a node and compares that total against the node's allocatable capacity — a node whose remaining allocatable capacity cannot accommodate the new Pod's request is filtered out of the candidate set entirely, regardless of how much the container might actually end up using at runtime.

The Baseline for QoS

A container's request, compared against its own limit, is the primary input to Kubernetes' automatic QoS classification (Guaranteed when requests equal limits for every resource and container; Burstable when requests are set but differ from limits; BestEffort when neither is set) — this classification in turn determines eviction priority under node resource pressure.

Not a Ceiling

Critically, a request is not a cap — a container is free to consume more than its request (up to its limit, if one is set, or without bound if no limit exists) whenever the node has spare capacity available; the request only guarantees a minimum, not a maximum.

Sizing Requests Correctly

Basing Requests on Observed Steady-State Usage

The most reliable approach to sizing requests is measuring actual steady-state resource consumption under representative load, rather than guessing or copying a value from an unrelated workload — tools like the Vertical Pod Autoscaler in recommendation-only mode, or simply reviewing kubectl top data over time, provide the empirical basis for a defensible request value.

kubectl top pods -l app=codartium-api --containers

Avoiding Over-Provisioning

Requests set significantly higher than actual usage waste cluster capacity — that headroom is reserved and unavailable to any other Pod, even though the container never actually uses it, directly inflating the node count (and cost) needed to run a given workload fleet.

Avoiding Under-Provisioning

Requests set too low relative to actual usage allow the scheduler to over-pack a node relative to what it can genuinely sustain once every Pod's actual consumption is considered together, increasing the risk of node-level resource contention and, in the case of memory, correlated OOM kills across multiple co-located Pods during a shared load spike.

Requests Across Multiple Containers

Effective Pod Request Is the Sum

For Pods with multiple containers, the Pod's effective resource request for scheduling purposes is the sum of every container's individual request — a Pod with a 200m-CPU main container and a 50m-CPU sidecar has an effective 250m-CPU request that the scheduler evaluates as a whole.

Init Containers and Request Calculation

Because init containers run sequentially before the main containers start and do not run concurrently with them, the scheduler uses the maximum of (the largest single init container's request) and (the sum of all main container requests) rather than simply adding init container requests on top — reflecting that init container resource needs do not persist once the main containers are running.

Default Requests via LimitRange

Ensuring Every Container Has a Request

A LimitRange object can supply a defaultRequest value applied automatically to any container in its namespace that omits an explicit request, ensuring no container ends up with an implicit BestEffort classification purely by oversight rather than deliberate choice.

apiVersion: v1
kind: LimitRange
metadata:
  name: codartium-default-requests
spec:
  limits:
    - defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      type: Container

Adjusting Requests Over Time

Requests Are Immutable on Running Pods (Mostly)

For most Kubernetes versions, a Pod's resource requests cannot be changed after creation without recreating the Pod — an update to a Deployment's Pod template resource requests triggers a rolling update, replacing Pods rather than patching the field on running instances in place, since resource requests are foundational to the scheduling decision already made for existing Pods.

In-Place Resize (Newer Kubernetes Versions)

More recent Kubernetes releases have introduced in-place Pod resource resizing for select resize policies, allowing certain request/limit adjustments without a full Pod restart — this remains a more specialized capability, and most resource request changes in practice still flow through the standard rolling-update mechanism.

Example

apiVersion: v1
kind: Pod
metadata:
  name: codartium-request-example
spec:
  containers:
    - name: app
      image: codartium/app:latest
      resources:
        requests:
          cpu: "250m"
          memory: "256Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"