Container runtime

"Container runtime" names two layers that are easy to confuse. A low-level (OCI) runtime implements the OCI Runtime Specification: given a bundle - a root filesystem plus config.json - it performs the create, start, kill and delete operations by calling clone/unshare for namespaces, writing cgroup limits, pivoting into the root filesystem, dropping capabilities, installing the seccomp filter and applying the AppArmor or SELinux profile before exec'ing the entrypoint. runc (written in Go, originally Docker's libcontainer donated to the OCI in 2015) is the reference implementation; crun (C) and youki (Rust) are faster or smaller alternatives. A high-level runtime such as containerd or CRI-O manages everything around that: pulling and unpacking images into snapshots, preparing the bundle, attaching networking via CNI plugins, streaming logs and exec sessions, and supervising each container through a small shim process so that the container survives a restart of the daemon.

Kubernetes talks to the high-level runtime over the Container Runtime Interface (CRI), a gRPC API with a RuntimeService (pod sandboxes and containers) and an ImageService, introduced in Kubernetes 1.5. Docker Engine never implemented CRI itself; the kubelet's built-in adapter, dockershim, was removed in Kubernetes 1.24, after which clusters use containerd or CRI-O directly (images built by Docker still run unchanged because they are OCI images). The call chain on a node is therefore kubelet → CRI → containerd or CRI-O → shim → runc → kernel.

Sandboxed runtimes plug into the same interface but change the isolation model. gVisor's runsc intercepts system calls in a user-space kernel (the Sentry) so the workload touches only a narrow slice of the host kernel; Kata Containers boots each pod in a lightweight VM with its own guest kernel under a hypervisor such as QEMU or Cloud Hypervisor. Kubernetes selects between handlers per pod with a RuntimeClass object, so one cluster can run trusted workloads on runc and untrusted ones on gVisor or Kata at the cost of some performance and compatibility.

The runtime is part of the trusted computing base: it runs as root on the host and parses attacker-influenced input (image layers, config, exec requests). runc CVE-2019-5736 and CVE-2024-21626 both became host-level escapes, which is why runtime patching belongs in routine vulnerability management alongside kernel patching. Hardening options include rootless mode, enabling user namespaces for pods, restricting access to the runtime socket (/run/containerd/containerd.sock) and default seccomp profiles. Unlike the orchestrator, the runtime has no notion of desired state across the cluster; it only does what its local agent asks.