Demystifying Kubernetes Runtime: From Docker to CRI‑O and Kata

Typical K8s Runtime Architecture

When kubelet needs to create a container it follows these steps:

Kubelet calls dockershim via the CRI gRPC interface, acting as a CRI client.

dockershim translates the request into a Docker Daemon command.

Docker Daemon forwards the request to containerd, which actually creates the container.

containerd spawns a containerd‑shim process to become the container’s parent, preserving state and stdin.

The shim uses the OCI runtime (runC) to set up namespaces, cgroups and mount the root filesystem.

runC launches the container and exits; the shim remains to collect the container’s status and clean up.

The original Docker‑only design was simpler: kubelet called Docker Daemon directly, which used libcontainer. Political and technical pressures led to the Open Container Initiative (OCI) and the Container Runtime Interface (CRI) to avoid vendor lock‑in.

Container History

Early Kubernetes used Docker directly. The desire for a vendor‑neutral runtime spurred the creation of OCI (defining ImageSpec and RuntimeSpec) and CRI (a set of gRPC interfaces for container and image operations and a PodSandbox).

OCI and CRI

OCI specifies how container images are packaged and which runtime commands must be supported. runC is the reference OCI runtime implementation.

CRI defines three core interface groups: container lifecycle, image lifecycle, and PodSandbox management.

containerd and CRI‑O

containerd 1.0 used a separate CRI‑containerd process:

containerd 1.1 integrated the CRI logic as a plugin, removing the extra process:

CRI‑O is a lightweight CRI‑compatible runtime that directly implements OCI without the Docker layer.

Strong‑Isolation Containers

Projects such as Kata Containers, gVisor and Firecracker provide VM‑based isolation. Kata runs each container inside a lightweight VM, preserving OCI compatibility while offering stronger security boundaries.

gVisor implements a user‑space “Sentry” process to handle syscalls, whereas Firecracker is a microVM built in Rust that minimizes virtualization overhead.

These solutions address Kubernetes’ multi‑tenant challenges by isolating workloads at the kernel level rather than sharing the host kernel.