Containerd: Container Runtime

5 min readJan 12, 2021

During this past December 2020, many k8’s users faced issues when DockerHub registry rate limits started to kick in. Around the same time kubernetes v.1.20 became GA and officially announced deprecation for docker container runtimes scheduled for on v.1.22.

This leaves us with 2 options: Containerd and CRI-O. For now we will focus on containerd, because of its popularity, maturity, and it’s actually used inside of Docker to do all the “runtime” jobs.

By the end of this post you should get a good idea of what containerd is and how to install a k8’s master on a CentOS or Ubuntu system

What part of docker was deprecated ?

Basically, everything outside of the red box got deprecated.

More about it here: Don’t Panic: Kubernetes and Docker

Let’s zoom into Containerd

The below showcases the architecture of Containerd. Notice the Container Runtime Interface (CRI), Container Registries (Dockerhub, Quay, etc.) and Runc.

Overview:

Source: CNCF [Cloud Native Computing Foundation]

As a reminder, the CRI (plugin) will get merged into core in version 1.5

Lets zoom in again into the CRI

Source: CNCF

Notice that each container is running within a namespace and a group. To me, it is useful to think of containers as linux programs enveloped with permissions and resource managers.

Namespaces = linux namespaces provide isolated workspaces.
Cgroups = linux control groups used to allocate actual resources (memory, cpu, etc.)

Here are the man pages for the previous technologies:

Also notice how containerd is a process within systemd.

Some good and complete explanations of Containerd, namespaces and cgroups can be found in the below links:

How does this connect to Kubernetes ?

The below image shows why we need a kubelet on every host. We need to run programs, with namespace isolation, and controlled resources on each host.

The Kubelet is the main agent that runs on each worker node and ensures that containers are running in a pod. When it comes alive, the kubelet uses CRI to work with whatever runtime is present on that specific node. Kubelet fundamentally needs the runtime to:

Provide image management
Prepare the environment to instantiate the container
Prepare the network for the pod

CRI has standardized expectations of a compatible runtime. Three of these fundamental expectations are that the runtime:

Can both start and stop pods
Can support operation calls — Start, Stop, Kill, Delete
Provides image management from the registry

Source: Diving Deeper Into Runtimes: Kubernetes, CRI, and Shims

While not a runtime, The Shim sits between the container manager and a runtime, it is used to facilitate communications, and eliminates the long running runtime processes for containers.