Beyond Docker: Exploring Modern Container Runtimes and Alternatives

Foundations of Linux Containers

Containers are built on three kernel primitives:

chroot – changes the apparent root directory for a process, providing filesystem isolation.

cgroups – groups processes to limit, isolate, and measure resource usage (CPU, memory, I/O, network).

namespaces – create separate views of system resources (PID, mount, network, IPC, UTS, user, cgroup) so that processes in one namespace cannot see or affect those in another.

Combining these primitives yields lightweight, secure execution environments that are distinct from full virtual machines.

Docker’s Role and Legacy

Docker was released in 2013 and popularized the container model. It introduced a de‑facto image format, a public registry (Docker Hub), and a command‑line interface ( docker) that abstracted the underlying kernel features. Docker’s success forced subsequent tools to adopt the same image format and to interoperate with its stack.

Standardization: OCI and CRI

The Open Container Initiative (OCI) defines two specifications:

Image Specification – describes the layout and metadata of container images.

Runtime Specification – defines how a runtime must create, start, and stop a container using the kernel primitives.

OCI was initiated by Docker in 2015 and is now backed by major vendors (Microsoft, Facebook, Intel, VMware, Oracle, etc.).

The Container Runtime Interface (CRI) is a Kubernetes API that standardizes how the orchestrator talks to any OCI‑compliant runtime (e.g., containerd, CRI‑O). This enables interchangeable runtimes without changing the Kubernetes control plane.

Docker Software Stack

docker-cli

– developer‑facing command‑line client. containerd – daemon that manages image storage, distribution, and container lifecycle; implements the CRI. runc – reference OCI runtime that creates and runs containers using cgroups and namespaces.

Container – the actual isolated process tree built on chroot, cgroups, and namespaces.

Kubernetes uses a similar stack, typically swapping containerd for CRI‑O (a CRI‑only implementation).

Alternative Runtimes and Projects

containerd

Runs as a daemon on Linux and Windows. It pulls images, stores them in a content‑addressable store, and hands off execution to an OCI runtime. Originated inside Docker (2014), graduated to a CNCF project in 2017, and reached stable status in 2019.

runc

Reference implementation of the OCI Runtime Specification. It directly invokes low‑level kernel calls to set up namespaces, cgroups, and the root filesystem.

Alternative OCI runtimes include:

Kata‑Runtime – uses hardware virtualization (lightweight VMs) to run containers with an additional security boundary.

gVisor – implements a user‑space kernel; containers run with the runsc runtime, offering stronger isolation at the cost of performance.

CRI‑O – a minimal CRI implementation that pulls OCI images and runs them with any OCI‑compatible runtime (default runc).

Podman

Daemon‑less container engine that mimics the Docker CLI ( podman run, podman build, etc.). It supports rootless operation, pulls images from Docker Hub, and can manage pods (groups of containers) similar to Kubernetes pods.

LXC / LXD

LXC (Linux Containers) is the original upstream kernel container solution (introduced in 2008). It provides system‑level containers that share the host kernel but isolate resources via cgroups and namespaces.

LXD builds on LXC by adding a privileged daemon that exposes a REST API, supports image‑based deployment, and integrates with OpenStack and OpenNebula. LXD retains LXC’s low‑overhead isolation while offering a more user‑friendly management layer.

Comparison of Docker and LXC/LXD

Portability – Docker images conform to the OCI image spec and run on any OCI‑compatible host.

Versioning – Docker layers are immutable and can be version‑controlled similarly to Git.

Component reuse – Layers enable rapid composition of new images from existing ones.

Ecosystem – Hundreds of thousands of public Docker images are available in registries.

LXC/LXD target system administrators who need fine‑grained control over the host kernel, whereas Docker is developer‑centric, which explains its broader adoption.

Current Landscape

While Docker remains widely used (millions of developers, billions of image pulls per month), many projects replace individual components of Docker’s stack with alternatives that prioritize security or modularity. For example, a Kubernetes cluster may run containerd + runc, CRI‑O + Kata‑Runtime, or Podman in rootless mode without breaking compatibility with OCI images.