Kubernetes Pod Runtime Shape

Kubernetes Pod Runtime Shape is what a Pod actually looks like as running operating system processes and kernel constructs on a node, as distinct from the declarative shape described in its spec — the concrete namespaces, cgroups, and process tree that come into existence once a Pod is scheduled and its containers are started, revealing that a Pod with a seemingly simple spec is, at the kernel level, a more elaborate structure than its manifest alone suggests.

The Sandbox as the Runtime Foundation

The pause Container's Role

At the OS level, a Pod's runtime shape begins with a sandbox, typically realized as a minimal "pause" container whose sole purpose is to hold open the namespaces every other container in the Pod will join; this sandbox process is invisible in the Pod's spec entirely, existing purely as a runtime implementation detail of how the container runtime realizes the Pod abstraction on Linux.

One Sandbox, Multiple Application Containers

Every container declared in the Pod's containers and long-running initContainers list becomes a separate OS-level container process joining this shared sandbox's namespaces, meaning a Pod declaring three containers in its spec corresponds, at runtime, to at least four actual container processes on the node — the sandbox plus the three declared containers — a multiplication factor invisible from the manifest alone.

Namespace Sharing in Practice

Shared Network Namespace

Because every container in the Pod joins the sandbox's network namespace, they share a single network interface, IP address, and port space at the kernel level; a netstat or similar inspection run from within any container in the Pod reveals the exact same network state as any other container in that Pod, since there is genuinely only one network namespace involved regardless of how many containers reference it.

Optional IPC and PID Namespace Sharing

IPC namespace sharing, enabled by default, allows containers within the Pod to communicate via System V IPC or POSIX message queues as if they were separate processes on the same traditional host; PID namespace sharing, which must be explicitly requested via shareProcessNamespace, goes further, making every container's processes visible to every other container's process listing within the Pod, which is not the default precisely because it represents a meaningfully looser isolation boundary between containers than most workloads want.

The Process Tree Within a Pod

PID 1 Per Container by Default

Absent shared process namespace configuration, each container maintains its own independent PID namespace, meaning each container's main process is PID 1 from its own perspective, unaware of and unable to see any process running in a sibling container, even though all of them ultimately descend from the same node-level container runtime's process tree when viewed from the host.

The Host's View Versus the Container's View

From the node's own process listing, every container in a Pod appears as a distinct process tree rooted under the runtime's own supervision structure, while from inside any individual container, only that container's own process namespace is visible — the same underlying runtime processes present two entirely different views depending on which namespace the observer is looking from.

Cgroup Structure

Per-Container and Pod-Level Cgroup Hierarchy

Resource isolation is enforced through a nested cgroup hierarchy: the kubelet typically creates a Pod-level cgroup reflecting the Pod's aggregate resource constraints (particularly relevant for Guaranteed and Burstable QoS classes), with each container's own cgroup nested beneath it, enforcing that container's individually configured requests and limits within the bounds the Pod-level cgroup itself allows.

QoS Class Reflected in Cgroup Placement

The Pod's Quality of Service class additionally determines which top-level QoS cgroup a Pod's own cgroup is nested under, meaning the full cgroup path for any given container reflects three layers — the node's QoS-level grouping, the Pod-level cgroup, and the container's own cgroup — a hierarchy entirely implicit in the spec but concretely realized as actual nested cgroup directories on the node's filesystem at runtime.