2.9 Kubernetes Runtime Architecture

Kubernetes Runtime Architecture is the specific internal structure of the container runtime layer as it relates to Kubernetes, describing how the Container Runtime Interface, the higher-level runtime daemon, and the lower-level runtime responsible for actual process creation are arranged into distinct layers, each handling a narrower part of the overall task of turning a container specification into a running process.

The Container Runtime Interface as a Boundary Layer

Defining, Not Implementing, Runtime Behavior

The Container Runtime Interface (CRI) is architected as a gRPC-based contract specifying the operations the kubelet needs, such as creating a Pod sandbox or pulling an image, without itself implementing any of those operations; it exists purely as the boundary across which the kubelet and the runtime communicate.

Runtime Independence from the kubelet

Because this interface is architected as a stable contract, any runtime implementing it correctly can be substituted for another without requiring changes to the kubelet itself, structurally decoupling Kubernetes's node-level logic from any specific runtime implementation.

High-Level Runtime Layer

Managing Images and Sandboxes

The high-level runtime, such as containerd or CRI-O, is architected to handle image pulling and storage, Pod sandbox lifecycle, and coordination among the containers within a single Pod, serving as the component that directly implements the CRI contract that the kubelet speaks to.

Delegating Execution Further Down

Rather than creating containers itself at the lowest level, the high-level runtime is architected to delegate the actual creation of isolated processes to a separate, lower-level runtime component, keeping image and sandbox management logically distinct from raw process creation.

Low-Level Runtime Layer

Direct Interaction with Kernel Primitives

Beneath the high-level runtime sits a low-level runtime, responsible for directly invoking the kernel primitives, namespaces, cgroups, and related mechanisms, needed to actually create an isolated container process according to a standardized runtime specification.

A Narrow, Single-Purpose Component

This low-level runtime is architected to do one thing precisely: given a bundle describing a container's root filesystem and configuration, create and manage the lifecycle of a single container process, without concerning itself with image pulling or multi-container Pod coordination.

Sandbox Isolation Architecture

The Pod Sandbox as a Shared Namespace Anchor

A Pod's sandbox is architected as the entity that first establishes the shared network and IPC namespaces used by every container within that Pod, created once per Pod and then joined by each of its individual containers as they are subsequently started.

Runtime Layering Diagram