What Is a Container Runtime? The Software That Runs Containers
A container runtime is the software that actually starts and runs containers from images - the layer beneath higher-level tools like Docker and Kubernetes.
When you run a container, something has to set up the namespaces and cgroups, unpack the image, and launch the process. That something is the container runtime. There are two levels - high-level runtimes that manage images and lifecycle, and low-level runtimes that do the kernel-level work - and knowing the split clears up a lot of confusion.
High-level vs low-level runtimes
A high-level runtime like containerd or CRI-O manages images, storage, and container lifecycle. It then calls a low-level runtime like runc to do the actual syscalls that create the isolated process. Docker uses containerd under the hood.
Where Docker fits
Docker is not itself the runtime in the strict sense - it is a higher-level platform that delegates to containerd, which delegates to runc. This layering is why the same containerd can serve both Docker and Kubernetes.
The CRI in Kubernetes
Kubernetes talks to runtimes through the Container Runtime Interface (CRI). This is why Kubernetes dropped its built-in Docker shim - it speaks CRI to containerd or CRI-O directly, with no Docker needed on the node.
Alternative runtimes
- runc - the standard OCI low-level runtime.
- gVisor and Kata - stronger isolation via a sandbox or microVM.
- CRI-O - a lightweight CRI runtime built for Kubernetes.
Runtimes and CI
CI runners use a container runtime to execute jobs and build images. You rarely interact with it directly, but it is the engine doing the work - and a well-managed runner keeps it healthy so jobs start reliably.
Key takeaways
- A container runtime starts and runs containers from images.
- High-level runtimes (containerd, CRI-O) call low-level ones (runc) for kernel work.
- Kubernetes talks to runtimes via the CRI - no Docker required on the node.