The Evolution of Container Runtimes: From Docker to CRI‑O and containerd after Mirantis’ Acquisition

The article begins by noting that Mirantis acquired Docker and highlights Mirantis' relatively modest contribution to the OpenStack community compared with Red Hat, while Red Hat dominates both OpenStack and Kubernetes code contributions.

It then traces the history of container runtimes: the earliest runtime LXC, Docker’s shift from LXC to its own libcontainer which became runc, and the subsequent rise of Kubernetes, which initially adopted Docker because it was the only mature runtime at the time.

The narrative continues with the emergence of alternative runtimes such as CoreOS’s rkt, the creation of the OCI (Open Container Initiative) standard, and the definition of the CRI (Container Runtime Interface) by Kubernetes to decouple the platform from any specific runtime.

Red Hat’s response to these standards was the development of CRI‑O, a lightweight runtime that reuses runc components and implements the minimal CRI required for Kubernetes. Simultaneously, Docker’s own research produced containerd, a daemon extracted from the Docker engine that later became part of the Kubernetes CRI ecosystem via cri‑containerd.

The article compares the container stack in OpenShift 3 (Kubernetes Master → Kubelet → Docker Engine → containerd → runc → Linux kernel) with OpenShift 4’s architecture (Kubernetes Master → Kubelet → CRI‑O → runc → Linux kernel), and mentions alternative developer‑proposed stacks involving cri‑containerd.

In the concluding summary, it states that LXC is largely obsolete, runc is the preferred runtime, Docker Engine is being phased out in favor of containerd (driven by Google and Red Hat), rkt still lacks full OCI certification, and Red Hat’s OpenShift now dominates the enterprise container market with CRI‑O as its default runtime.