One of the features that makes Kubernetes flexible and powerful is its support for multiple container runtimes. Instead of forcing you to use a specific runtime, Kubernetes gives you options.

However, this flexibility can also make Kubernetes feel complicated, especially if you are new to the platform. Understanding the differences between Kubernetes container runtimes, and determining which runtime is best for your needs, requires familiarity with runtimes that you may not have if you haven’t worked with containers or Kubernetes before.

If you’re struggling to wrap your mind around Kubernetes runtimes, this article explains what container runtimes do, how they work in Kubernetes and what the main runtime options are for Kubernetes.

What is a container runtime?

Put simply, a runtime is the software that executes individual containers.

To understand exactly what this means, you need to recognize the difference between a container image and a container. A container image is essentially the blueprint for a container: It defines which resources the container needs in order to host a given application or service. You don’t need a container runtime to create or manage a container image.

But when you actually execute the instructions inside a container image in order to start your application or service, you get a container. This is where container runtimes come in. A container runtime is the software that takes container images and turns them into containers.

What is OCI?

The Open Container Initiative, or OCI, is a community-driven project that defines standards for how container runtimes should work.

The OCI was created in 2015 to address what was becoming a challenge for developers: An increasing number of container runtimes were available, and not all were compatible with each other. That made it hard to develop and package containerized applications that would work with all available runtimes.

The OCI resolved this issue by creating a standard that all runtimes could follow, even if the runtimes are not identical. Today, any container runtime that conforms with the OCI’s runtime specification will work with any container management platform (such as Kubernetes) that also supports the OCI specifications.

In this sense, the OCI’s runtime specification is similar to the specification for a technology like USB. Even though there are numerous vendors who sell devices with USB connections, and numerous PCs and operating systems that can connect to those devices, they all work with each other because they adhere to the common USB standards. The OCI runtime specification does the same thing for container runtimes.

Popular Kubernetes container runtimes

Kubernetes is a container orchestrator. That means it manages containers once they are running, but it doesn’t execute the containers itself. To do that, it needs a container runtime.

Again, Kubernetes doesn’t force you to use a specific runtime. Instead, it offers what it calls a Container Runtime Interface, or CRI. The Kubernetes CRI is an interface that allows Kubernetes to integrate with various container runtimes, including but not limited to those that support the OCI specification.

To put this another way: You can use OCI-compliant container runtimes in Kubernetes, but you can use other runtimes as well.

Today, the two most popular runtimes for Kubernetes include:

• CRI-O: CRI-O can run any OCI-compliant container image on Kubernetes. Note that other container images that are OCI-compliant can also run on Kubernetes without using CRI-O, as long as the images support another runtime that is CRI-compliant (which most are today). But because CRI-O was designed originally as an alternative to Docker’s own runtimes, it has become popular as a way to run containers without relying on Docker’s technology.
• Containerd: Containerd is Docker’s modern runtime, and it was developed primarily by Docker. For organizations that are heavily invested in the Docker software stack, containerd is a popular runtime.

What about Docker as a Kubernetes runtime?

As noted above, containerd is the modern runtime used by Docker. You can use containerd on its own, and use other tools to handle container image management.

However, matters are a little complicated here, because Docker is more than just containerd. It’s a complete platform for building and managing container images. Some people want to use the full stack of Docker tools to manage container images, then deploy them on Kubernetes. This requires Kubernetes to integrate with more than just containerd.

Because Kubernetes doesn’t directly support the full stack of Docker technology, it has historically provided a special interface, Dockershim, to enable full Docker runtime support on Kubernetes. In early 2020, however, Kubernetes announced plans to deprecate Dockershim, most likely starting with the Kubernetes 1.23 release in late 2021. When that happens, Kubernetes will no longer support Docker as a runtime, and Kubernetes users will have to use a different option (like CRI-O or containerd).

This means that, although you may hear people talk about using Docker (and not just containerd) as a Kubernetes runtime, this approach is likely to become less and less common in the future. Kubernetes is moving away from full integration with Docker tooling, and is encouraging developers to rely on alternative solutions even if they stick to the containerd runtime.

Which container runtime should you choose?

If all of the above seems a bit confusing, the good news is that all of the mainstream Kubernetes container runtimes available today do more or less the same thing: They run container images that comply with OCI specifications.

Unless you have special use cases (like tight security, in which case the Kata runtime may be a better option, or keeping your stack extremely lightweight, which crun helps to do), you are best off sticking with either CRI-O or containerd as your Kubernetes container runtime.

Kubernetes gives you many options when it comes to container runtimes, but for the vast majority of users, the most popular runtimes are the simplest and best option.