Differences between Docker, containerd, CRI-O and runc

The advent of Docker led to an explosive growth in the popularity of containers, but other tools have emerged since then. Unfortunately, they can be tricky to figure out. But we’ll try!

And if you think that the only one who does not understand all this yet, do not worry … It is not!

What is Docker?

There is a difference between Docker company, Docker containers, Docker images and Docker tools that we are all used to.

It is important to understand that Docker is only one of the tools for working with containers, there are other tools, some of which are supported by Docker itself.

As you can see, you are not the only one who is confused.

Let’s see how Docker, containerd and CRI-O differ. This is especially important if you are working with Kubernetes.

An overview of the container ecosystem

The container ecosystem is made up of many technologies, technical terminology, and companies competing with each other.

Fortunately, these companies sometimes negotiate a fragile truce to agree on some standards. These standards help to achieve interoperability between different tools and avoid dependence on one company or project.

Basic standards to be aware of:

• Container Runtime Interface (CRI) defines an API between Kubernetes and Container Runtime

• Open Container Initiative (OCI) defines the standard for images and containers

This illustration shows how Docker, Kubernetes, OCI, CRI, containerd, and runc fit into this ecosystem:

Docker

We’ll start with Docker because it is the most popular container tool right now. For many, the very name “Docker” is synonymous with the word “container”.

Docker has created a very handy container tool.

Docker can be installed on a laptop (Docker Desktop) or server (Docker Engine). It contains a set of tools that simplify the work of developers and DevOps engineers. Using the Docker CLI, you can create container images, work with repositories, create, run and manage containers.

Docker consists of three projects:

• docker-cli: This is a command line utility that you interact with using the command docker

• containerd: It is a Linux Daemon that manages and runs containers. It downloads images from the repository, manages storage and networking, and controls the operation of containers.

• runc: It is a low-level container runtime that creates and runs containers.

In fact, when you start a container with docker, you actually start it through the Docker Daemon, containerd, and then runc.

Dockershim: Docker on Kubernetes

It is important to remember that Kubernetes only supports Container Runtime, which works with the Container Runtime Interface (CRI), but Docker does not directly support this standard, so Kubernetes includes a component called dockershim, which is required to work with Docker.

What is shim?

A component that acts as a bridge between various APIs to provide interoperability.

In the future, Kubernetes will drop support for dockershim and, accordingly, Docker and will only work with Container Runtime that support the Container Runtime Interface (CRI) – containerd or CRI-O.

But this does not mean that Kubernetes cannot run containers from Docker images. Both containerd and CRI-O can run images in Docker format (actually in OCI format), they just do it without using the command docker and Docker Daemon.

Docker images

What many people call Docker images are actually Open Container Initiative (OCI) images.

Therefore, if you download an image from Docker Hub or another repository, you can use it using the command docker, or on a Kubernetes cluster, or using the podman utility, or any other tool that supports the OCI image format specification.

Container Runtime Interface (CRI)

CRI is an API that Kubernetes uses to manage the various Container Runtimes that create and manage containers.

CRI makes it easy for Kubernetes to use different Container Runtimes. Instead of including support for each of them in Kubernetes, the CRI standard is used. In this case, the task of managing containers falls entirely on the Container Runtime.

So if you can use containerd to run containers. You can also use CRI-O because they support the CRI standard.

Moreover, if you are an end user, then you do not care which Container Runtime is used.

Remember that Red Hat (the OpenShift project) uses CRI-O and is responsible for maintaining it (security, bug fixes, etc.). Whereas Docker supports containerd.

How which Container Runtime is used in Kubernetes

In the Kubernetes architecture, the Kubelet (an agent running on each node) is responsible for interacting with the Container Runtime.

You can check which Container Runtime you are using by looking at the Kubelet options on each node. The manifest has the –container-runtime and –container-runtime-endpoint options that are used to configure the Container Runtime.

containerd

сontainerd is a Container Runtime that used to be part of Docker. Implements the CRI specification. Knows how to download images from the repository and manage them, and then transfers them to the lower level Container Runtime (we will talk about it later), which actually creates and starts container processes.

сontainerd was spun out of the Docker project to make Docker modular. So Docker itself uses containerd. When you install Docker, it also installs containerd.

сontainerd uses its own plugin to support CRI in Kubernetes.

CRI-O

CRI-O is another Container Runtime that implements the Container Runtime Interface (CRI). It was specially built from the ground up with support from Red Hat, IBM, Intel, SUSE as the Container Runtime for Kubernetes.

It is an alternative to containerd, which also allows you to download, manage, and manage container images from repositories and run a lower-level Container Runtime to start container processes.

Open Container Initiative (OCI)

OCI is a group of companies that maintain a specification for the format of a container image and how containers should run.

The idea behind OCI is that you can choose between different Container Runtime that conforms to this specification. Moreover, each of these can have different lower-level implementations.

For example, you might have one OCI compliant Container Runtime for your Linux hosts and one for your Windows hosts. This is the advantage of standardization.

runc

runc is another OCI compliant container runtime that starts container processes.

runc is called the OCI Reference Implementation.

What is a reference implementation?

A reference implementation is software that implements all the requirements of a specification or standard.

In the case of OCI, the runc provides all the functionality expected from an OCI-compliant runtime.

Here are some alternatives runc:

• crun container runtime written in C (as opposed to runc, which is written in Go)

• kata-runtime from the Katacontainers project, which implements the OCI specification as separate small virtual machines (hardware virtualization)

• gVisor from Google, which creates containers with its own core. It implements OCI in its runtime called runsc

Are there runc counterparts for Windows?

runc is a tool for running containers on Linux.

In Windows, things are a little different. The runc equivalent is the Microsoft Host Compute Service (HCS). It includes a tool called runhcs, which is a fork of runc and also implements the Open Container Initiative specification.

Let’s summarize

In this article, we’ve demonstrated that Docker is just one part of the entire container ecosystem.

There are open standards – CRI and OCI and several Container Runtime with CRI support – containerd, runc, CRI-O and of course Docker itself.

Perhaps soon we will see many new implementations of the Container Runtime with support for the CRI and OCI standards.