Kubernetes Container Runtime Execution

Kubernetes Container Runtime Execution is the layer of activity in which a node's container runtime, driven by CRI calls issued from the kubelet, actually creates, starts, and supervises the individual container processes that make up a Pod's workload once the Pod's sandbox has already been established. Where sandbox execution is concerned with setting up the shared environment a Pod lives in, container runtime execution is concerned with the lifecycle of the application containers themselves — pulling the correct image, configuring the container's isolation and resource limits, launching its process, and reporting its ongoing state back to the kubelet.

From Sandbox to Running Container

Prerequisite: An Established Sandbox

Container runtime execution for a given container never begins until the Pod's sandbox is already running, since every container is created to join the namespaces the sandbox provides. The kubelet's SyncPod logic enforces this ordering explicitly, ensuring RunPodSandbox always precedes any CreateContainer call for that Pod.

Image Resolution

Before a container can be created, the runtime must resolve the specified image, which involves checking local image storage for a cached copy, applying the Pod's imagePullPolicy, and, when necessary, contacting a container registry through the ImageService's PullImage method, using any registry credentials supplied through imagePullSecrets.

The CreateContainer and StartContainer Calls

Container Configuration

The kubelet builds a ContainerConfig for each container in the Pod spec, translating fields such as command, arguments, environment variables, volume mounts, resource requests and limits, and security context into the structure the CRI expects, and passes this configuration to the runtime's CreateContainer method along with a reference to the already-running sandbox.

Resource Enforcement at Creation Time

Resource requests and limits declared in the Pod spec are translated into cgroup constraints at this stage — CPU shares or quota, memory limits, and, where applicable, hugepage or extended resource allocations — with the runtime responsible for applying these constraints through the underlying cgroup driver, whether cgroupfs or systemd.

Starting the Process

Once the container object exists, the kubelet issues StartContainer, at which point the runtime forks and execs the container's entrypoint process inside the namespaces and cgroup already prepared for it, and the container transitions into a running state that the runtime begins tracking.

Ongoing Supervision During Execution

Status Polling and Events

While a container is running, the kubelet periodically calls ListContainers and ContainerStatus against the runtime to detect state changes — a container exiting, crashing, or being OOM-killed — and reconciles these observations into the Pod's status, generating Kubernetes events that explain why a state transition occurred.

Probes as Execution-Time Checks

Liveness, readiness, and startup probes are executed against the running container — either by executing a command inside it via the runtime's exec mechanism, issuing an HTTP request to it, or opening a TCP connection — and their results feed directly back into container runtime execution decisions, such as the kubelet issuing a StopContainer followed by a fresh CreateContainer/StartContainer cycle when a liveness probe fails repeatedly.

restartPolicy Enforcement

When a container exits, whether cleanly or due to failure, the kubelet consults the Pod's restartPolicy (Always, OnFailure, or Never) to decide whether to execute the container again, applying an exponential backoff delay between successive restarts of a persistently crashing container to avoid overwhelming the node.

Termination and Cleanup

Graceful Shutdown Sequence

When a container needs to stop — due to Pod deletion, an update, or eviction — the runtime first sends the configured termination signal (SIGTERM by default, or a custom PreStop hook is invoked first if defined), then waits up to the Pod's terminationGracePeriodSeconds before forcibly sending SIGKILL if the process has not exited.

Container and Sandbox Removal

After all containers in a Pod have stopped and the Pod itself has been deleted from the API server, the kubelet issues RemoveContainer for each container and eventually RemovePodSandbox, after which the runtime's garbage collector may reclaim the associated storage and log files according to its retention configuration.

Runtime-Specific Execution Details

OCI Runtime Delegation

Most CRI-compliant runtimes such as containerd and CRI-O do not implement low-level process execution themselves; instead, they delegate the actual namespace and cgroup setup, and the final exec of the container process, to an OCI-compliant low-level runtime such as runc, which container runtime execution ultimately invokes as its last step.

Logging During Execution

Standard output and standard error from the container process are captured by the runtime and written to log files on the node in a format the kubelet knows how to read, which is what allows kubectl logs to retrieve container output without the API server needing direct access to the container process itself.