Kubernetes Pod Resource Configuration

Kubernetes Pod Resource Configuration is the aggregate view of how a Pod's total resource footprint is computed from its individual containers' requests and limits, covering the specific arithmetic the scheduler and kubelet apply across init containers and main containers together, the Quality of Service classification that arithmetic produces, and the additional Pod-level overhead some runtimes introduce beyond what any individual container declares.

Aggregating Requests Across Containers

Summing Main Container Requests

A Pod's effective resource request for scheduling purposes is computed as the sum of every main container's individual requests — three containers each requesting 100m CPU together contribute 300m CPU to the Pod's total request the scheduler considers when evaluating node fit.

Init Containers and the Max-Not-Sum Rule

Because init containers run sequentially and never execute concurrently with each other, their resource requests are not summed together the way main container requests are; instead, the Pod's effective request accounts for the highest individual init container's request (or the sum of main containers, whichever is greater for a given resource), reflecting that only one init container's resource consumption needs to be provisioned for at any given moment during startup.

Why This Distinction Matters for Capacity Planning

A Pod with a single resource-intensive init container performing a one-time data download, followed by lightweight main containers, has a peak resource requirement driven by that init container alone, not by adding its request on top of the main containers' — understanding this max-versus-sum distinction prevents overestimating a Pod's actual aggregate resource footprint when init containers are involved.

Quality of Service Classification

Guaranteed

A Pod receives Guaranteed QoS when every container (main and init) specifies both requests and limits for CPU and memory, with requests exactly equal to limits, giving the Pod the strongest protection against eviction under resource pressure, reflecting that its resource consumption is fully bounded and predictable.

Burstable

A Pod receives Burstable QoS when at least one container specifies a CPU or memory request or limit, but the Pod does not meet the stricter Guaranteed criteria — the common case for workloads that request a baseline but allow some burst capacity above it, subject to being evicted ahead of Guaranteed Pods but after BestEffort ones under pressure.

BestEffort

A Pod receives BestEffort QoS when no container specifies any resource requests or limits at all, making it the first class of Pod evicted under node resource pressure, since it carries no declared claim on the node's capacity that the kubelet is obligated to protect.

Pod-Level Overhead

The overhead Field From RuntimeClass

Certain container runtimes, particularly those providing stronger isolation through lightweight virtual machines, incur a fixed resource cost beyond what any individual container consumes — memory for a guest kernel, CPU for hypervisor overhead — captured through a RuntimeClass's overhead field, which the scheduler adds on top of the summed container requests when evaluating whether a Pod using that RuntimeClass fits on a candidate node.

Why Overhead Is Tracked Separately

Tracking this overhead as a distinct value rather than folding it into container-level requests keeps the accounting honest: the overhead reflects a cost of the isolation mechanism itself, not of any application code, and separating it allows operators to understand exactly how much of a Pod's total footprint is attributable to its runtime choice versus its actual workload.

Ephemeral Storage at the Pod Level

Aggregate Ephemeral Storage Accounting

Similar to CPU and memory, ephemeral storage requests and limits are aggregated across a Pod's containers, and the kubelet additionally tracks actual ephemeral storage usage — including emptyDir volumes without a dedicated size limit, and container writable layers — against this aggregate, evicting a Pod that exceeds its computed ephemeral storage limit even if no single container individually exceeded its own declared portion.