It’s Time to Migrate your Container Runtime, Kubernetes 1.24 is coming

With another Kubernetes release upon us, there are, as ever, a load of new features to consider. Undoubtedly, the most significant change in this release of Kubernetes is the removal of the Dockershim. I added, “understanding Container Runtime Interface (CRI)” into my TO-DO list when Kubernetes made a announcement on abandoning Docker.

In this post I will examine the terminology and tooling around container runtimes. By the end, you’ll have a better idea of what a container runtime is, how the container landscape has evolved over time, and how we got to where we are today.

Container Runtime History

It has been enlarging its capability, including isolating runtime env, allocating computing resources, organizing hardware, managing images, starting and stopping programs, etc.

However, before version 1.5, there were only two built-in container runtimes, Docker and rkt, which failed in meeting all users’ demands. For example, Kubernetes allocates CPU and memory resources for Linux machines’ apps using systemd and Cgroup. Then what about the Windows machines? Cgroup doesn’t work anymore, and a container runtime for Windows systems is needed. You were facing the same predicament in OS like Centos, macOS, Debian, etc.

Furthermore, the code by then obviously did not meet the Kubernetes’ principle of flexibility.

Then came the abstract OCI design, overcoming these two shortcomings and bringing significant changes to the container runtime development.

  • Decouple kubelet and actual container runtime implementation, accelerating iteration
  • Give community developers the right to customize implementations. This culminated in the implementation of the container runtime interface (CRI), letting system components (like the kubelet) talk to container runtimes in a standardized way.

As Docker is not CRI compliant, dockershim acts as a translation layer between kubelet and Docker. Kubernetes is removing dockershim in the upcoming v1.24 release.The dockershim component of Kubernetes allows to use Docker as a Kubernetes's container runtime. Kubernetes' built-in dockershim component was removed in release v1.24. If you are using Docker Engine as a container runtime for your Kubernetes cluster, get ready to migrate in 1.24.

Container Runtime Comparison

We will review different types of container runtimes. Generally, they fall into two main categories: Open Container Initiative (OCI) runtimes/Low-Level Container Runtimes and Container Runtime Interface (CRI)/ High Level Runtime.

Low-Level Container Runtimes/ OCI Runtimes

Native runtimes

  • runC — created by Docker and the OCI. It is now the de-facto standard low-level container runtime. runC is written in Go. It is maintained under moby — Docker’s open source project.
  • crun — an OCI implementation led by Redhat. crun is written in C. It is designed to be lightweight and performant, and was among the first runtimes to support cgroups v2.

Sandboxed and virtualized runtimes

gVisor is sandboxed runtime which provide further isolation of the host from the containerized process. Instead of sharing the host kernel, the containerized process runs on a unikernel or kernel proxy layer, which then interacts with the host kernel on the container’s behalf. Because of this increased isolation, these runtimes have a reduced attack surface and make it less likely that a containerized process can have a maleffect on the host.

Kata is virtualized runtime as it is an implementations of the OCI Runtime spec that are backed by a virtual machine interface rather than the host kernel. It start a lightweight virtual machine with a standard Linux kernel image and run the “containerized” process in that virtual machine.

In contrast to native runtimes, sandboxed and virtualized runtimes have performance impacts through the entire life of a containerized process.

CRI/High Level Runtime

As the CRI has additional concerns over an OCI Runtime including image management and distribution, storage, snapshotting, networking ,CRIs usually delegate to an OCI Runtime for the actual container execution.

The first CRI implementation was the dockershim, which provided the agreed-upon layer of abstraction in front of the Docker engine.

There are two main players in the CRI space at present:

  • containerd — Extracted from the early docker source code, it is also the current industry-standard container runtime.
  • CRI-O — an open-source implementation of Kubernetes’ container runtime interface (CRI), offering a lightweight alternative to rkt and Docker.



Container Engines

Docker calls their product the “Docker Engine”, and generically these full container tools suites may be referred to as Container Engines. No one except Docker provides such a full featured single executable, but we can piece a comparable suite of tools together from the Containers Tools project.

The Container Tools project follows the UNIX philosophy of small tools which do one thing well:

  • podman — image running
  • buildah — image building
  • skopeo — image distribution




Enterprise Modernization, Platforms & Cloud | CKA | CKS | 3*AWS | GCP | Vault | Istio | EFK | CICD |

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Inder Singh

Enterprise Modernization, Platforms & Cloud | CKA | CKS | 3*AWS | GCP | Vault | Istio | EFK | CICD |