Kubernetes Pod Resource Calculation

Kubernetes Pod Resource Calculation is the complete formula Kubernetes applies to derive a Pod's single, effective resource request and limit from its potentially many constituent parts — main containers, init containers, and any RuntimeClass overhead — which is the actual number used by the scheduler for fit evaluation and by the kubelet for node-level accounting, as opposed to any single container's request read in isolation. While container-level resource management addresses how individual containers within a Pod are sized and aggregated, Pod resource calculation is the final, authoritative arithmetic that produces the one number that actually matters for scheduling and enforcement purposes.

Understanding this full calculation — not just the common case of summing ordinary containers — is necessary to correctly predict how a Pod with init containers, native sidecars, or a sandboxed runtime will actually be evaluated against node capacity.

The Full Calculation

Combining Containers and Overhead

The complete effective Pod request is the sum of concurrently running containers (ordinary containers plus any native sidecars), compared against the largest single non-restarting init container, with the result increased by any RuntimeClass overhead declared for the Pod.

This single value is what the scheduler compares against a node's allocatable capacity during the candidate filtering phase — every other detail (which specific container requested what) is only relevant insofar as it feeds into this final aggregate.

RuntimeClass Overhead

Why Overhead Exists

Sandboxed runtimes (gVisor, Kata Containers) introduce an additional isolation layer that itself consumes CPU and memory beyond what the Pod's own containers request — without accounting for this, the scheduler could over-pack a node believing it has more free capacity than it actually does once the runtime's own overhead is factored in.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
overhead:
  podFixed:
    cpu: "250m"
    memory: "128Mi"

Applying Overhead in Practice

A Pod referencing this RuntimeClass, with a single container requesting 500m CPU and 512Mi memory, has an effective Pod-level request of 750m CPU and 640Mi memory once overhead is added — the scheduler evaluates node fit against this combined figure, not the container's request alone.

Limits Follow the Same Structure

Aggregate Limit Calculation

The same combination logic (max of init containers, sum of concurrent containers, plus overhead) applies analogously to limits, determining the Pod's effective ceiling for enforcement purposes, though limits are enforced per-container at the cgroup level rather than as a single Pod-wide cgroup ceiling in most configurations — the Pod-level aggregate limit is primarily a conceptual and accounting figure rather than a single enforced boundary.

Deriving QoS from the Pod-Level Picture

Guaranteed Requires Uniformity Across Every Container

A Pod is Guaranteed QoS only if every container (main and init) has both CPU and memory limits set, and those limits equal the corresponding requests for every one of them — a single container within an otherwise uniformly Guaranteed-looking Pod that omits a limit, or sets a differing request/limit pair, demotes the entire Pod to Burstable.

BestEffort Requires Total Absence

A Pod qualifies as BestEffort only if no container specifies any request or limit at all, for any resource — a Pod with even one container declaring a single resource request (while every other container and resource is unset) is Burstable, not BestEffort.

kubectl get pod codartium-app -o jsonpath='{.status.qosClass}'

Observing the Effective Calculation

Comparing Declared vs. Effective Values

kubectl get pod codartium-app -o json | jq '[.spec.containers[].resources.requests.cpu]'
kubectl describe node node-worker-05 | grep -A 10 "Allocated resources"

Cross-referencing individual container declarations against a node's Allocated resources summary (which reflects the true effective Pod-level totals for every scheduled Pod) is the most reliable way to confirm the full calculation, including any init container or overhead effects, matches expectations.

Example

apiVersion: v1
kind: Pod
metadata:
  name: codartium-pod-calculation-example
spec:
  runtimeClassName: gvisor
  initContainers:
    - name: setup
      image: codartium/setup:latest
      resources:
        requests:
          cpu: "1"
          memory: "512Mi"
  containers:
    - name: app
      image: codartium/app:latest
      resources:
        requests:
          cpu: "500m"
          memory: "512Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"