Kubernetes Pod Sandbox Execution

Kubernetes Pod Sandbox Execution is the process by which a node's container runtime, acting under instruction from the kubelet, constructs and starts the isolated execution environment that underlies a Pod before any of the Pod's actual containers are created inside it. This environment, called the PodSandbox, provides the shared kernel namespaces — most importantly the network namespace, and optionally the IPC and PID namespaces — that all containers belonging to the same Pod run within, which is what gives containers in a Pod their shared localhost, shared IP address, and shared port space.

The Purpose of the Sandbox Layer

Why Pods Need a Shared Environment

A Pod is defined as a group of one or more containers that are meant to be co-located and to share certain aspects of their execution context. Without a common namespace to anchor them, containers created independently would each receive their own network stack and would be unable to communicate over localhost or share a single IP, which is a foundational assumption of the Pod abstraction. Pod Sandbox Execution solves this by creating that shared context first.

The pause Container Pattern

In most CRI implementations, the sandbox is realized concretely as a minimal "pause" container, whose only job is to hold open the namespaces it creates and to do essentially nothing else. It is typically the first process (PID 1 within the Pod's PID namespace, when that namespace is shared) and it remains running for the entire lifetime of the Pod, even as application containers within it are restarted individually.

The Execution Sequence

RunPodSandbox

The kubelet initiates sandbox execution by issuing a RunPodSandbox call through the Container Runtime Interface, passing a PodSandboxConfig that includes metadata such as the Pod's name, namespace, and UID, along with networking configuration, security context, and any Pod-level resource constraints such as cgroup parent settings.

Network Namespace Setup and CNI Invocation

As part of creating the sandbox, the runtime sets up a new network namespace and invokes the configured CNI (Container Network Interface) plugin, which allocates an IP address, configures routes, and attaches the sandbox's network namespace to the cluster's pod network. Only once this step completes successfully does the sandbox report itself as ready for containers.

Container Attachment

After the sandbox is running, the kubelet issues subsequent CreateContainer and StartContainer calls for each container defined in the Pod spec, each of these containers being explicitly configured to join the sandbox's namespaces rather than creating their own, which is what produces the shared-network, shared-IPC behavior characteristic of a Pod.

Sandbox Lifecycle and State

Independence from Application Container Restarts

Because the sandbox is created once and application containers are created and destroyed independently within it, a container crash and restart — governed by the Pod's restartPolicy — does not require tearing down or recreating the sandbox itself; the shared namespaces and the Pod's IP address remain stable across such restarts.

Sandbox Recreation

The sandbox itself is only recreated when it is lost entirely, such as after a node reboot, a container runtime restart that fails to preserve sandbox state, or an explicit removal via RemovePodSandbox; in these cases the Pod effectively receives a new sandbox and, in most CNI configurations, a new IP address, since the previous IP allocation is released.

PodSandboxStatus

The kubelet periodically queries PodSandboxStatus to determine whether the sandbox is still healthy and whether its network configuration remains valid, using this information as part of its broader reconciliation of the Pod's overall status.

Isolation and Security Considerations

Sandbox-Level Security Context

Pod-level security settings, such as those configured under a Pod's securityContext — including seccomp profiles, SELinux options, and user namespace configuration where supported — are applied at the sandbox level and inherited by the containers running within it, establishing a consistent isolation boundary for the whole Pod rather than requiring each container to configure it independently.

Sandboxed Runtimes

Some runtime implementations extend the sandbox concept further by running the entire Pod inside a lightweight virtual machine or a user-space kernel, rather than relying solely on Linux namespaces; in these implementations, Pod Sandbox Execution still follows the same CRI-driven sequence, but the isolation boundary enforced around the sandbox is substantially stronger than namespace isolation alone.