8.16 Kubernetes Pod Resource Configuration

Kubernetes Pod Resource Configuration is the specification of CPU, memory, and other compute resource requests and limits for the containers within a Pod, used by the scheduler to place the Pod and by the container runtime to enforce boundaries on its actual resource consumption.

Requests and Limits

Requests

A resource request declares the minimum amount of CPU or memory a container is expected to need. The scheduler uses the sum of all container requests in a Pod to decide which node has enough allocatable capacity to host it. A node will not be selected unless its unreserved capacity meets or exceeds the Pod's total requests.

Limits

A resource limit declares the maximum amount of CPU or memory a container may consume. The container runtime enforces limits directly: exceeding a memory limit results in the process being killed by the kernel's out-of-memory killer, while exceeding a CPU limit results in the container being throttled rather than terminated.

Units of Measurement

CPU is measured in cores, where 1 represents one full CPU core and 500m represents half a core. Memory is measured in bytes, typically expressed with suffixes such as Mi (mebibytes) or Gi (gibibytes).

Quality of Service Classes

Guaranteed

A Pod is classified Guaranteed when every container specifies both CPU and memory requests and limits, and each container's requests are equal to its limits. Guaranteed Pods receive the strongest protection against eviction under node resource pressure.

Burstable

A Pod is classified Burstable when at least one container defines a request or limit, but the Pod does not meet the stricter equality requirements of Guaranteed. Burstable Pods can consume resources beyond their requests up to their limits when the node has spare capacity.

BestEffort

A Pod is classified BestEffort when no container defines any resource requests or limits. These Pods are the first to be evicted when a node runs low on memory, since the scheduler has no guarantee about how much capacity they actually require.

Namespace-Level Controls

ResourceQuota

A ResourceQuota object constrains the total amount of CPU, memory, or object count that can be consumed across all Pods within a namespace, preventing any single team or application from exhausting cluster-wide capacity.

LimitRange

A LimitRange object sets default, minimum, and maximum resource values for containers within a namespace. When a Pod is created without explicit requests or limits, the LimitRange's defaults are applied automatically, ensuring that every container has some resource boundary even if the author omitted one.

Practical Considerations

Overcommitment

Because requests, not limits, are used for scheduling decisions, a node can be legally overcommitted on CPU: the sum of all container limits on a node may exceed the node's actual CPU capacity, relying on the assumption that not every container will burst to its limit simultaneously. Memory limits are treated more conservatively since memory cannot be compressed or throttled the way CPU can.

Vertical Pod Autoscaling

Resource requests and limits can be adjusted automatically over time based on observed usage through a Vertical Pod Autoscaler, which analyzes historical consumption and recommends or applies updated values, reducing the need for manual tuning as workload behavior changes.

Setting Requests Close to Actual Usage

Setting requests significantly higher than actual usage wastes cluster capacity by reserving resources that are never consumed, while setting requests too low risks the scheduler placing more Pods on a node than it can sustain under real load, leading to throttling or eviction.