Understanding why Kubernetes removed Docker

Kubernetes removed all support for Docker in version 1.24 as a supported container runtime. While it has been removed as a runtime engine option, you can create new containers using Docker and they will run on any runtime that supports the Open Container Initiative (OCI) specification. OCI is a set of standards for containers and their runtimes. These standards ensure that containers remain portable, regardless of the container platform or the runtime used to execute them.

When you create a container using Docker, you are creating a container that is fully OCI compliant, so it will still run on Kubernetes clusters that are running any Kubernetes-compatible container runtime.

To fully explain the impact and the supported alternatives, we need to understand what a container runtime is. A high-level definition would be that a container runtime is the software layer that runs and manages containers. Like many components that make up a Kubernetes cluster, the runtime is not included as part of Kubernetes – it is a pluggable module that needs to be supplied by a vendor, or by you, to create a functioning cluster.

There are many technical reasons that led to the decision to deprecate and remove Docker, but at a high level, the main concerns were as follows:

• Docker contains multiple pieces inside of the Docker runtime to support its own remote API and user experience (UX). Kubernetes only requires one component in the executable, dockerd, which is the runtime process that manages containers. All other pieces of the executable contribute nothing to using Docker in a Kubernetes cluster. These extra components make the binary bloated and can lead to additional bugs, security, or performance issues.
• Docker does not conform to the Container Runtime Interface (CRI) standard, which was introduced to create a set of standards to easily integrate container runtimes in Kubernetes. Since it doesn’t comply, the Kubernetes team has had extra work that only caters to supporting Docker.

When it comes to local container testing and development, you can still use Docker on your workstation or server. Considering the previous statement, if you build a container on Docker and the container successfully runs on your Docker runtime system, it will run on a Kubernetes cluster that does not use Docker as the runtime.

Removing Docker will have very little impact on most users of Kubernetes in new clusters. Containers will still run using any standard method, as they would with Docker as the container runtime. If you happen to manage a cluster, you may need to learn new commands when you troubleshoot a Kubernetes node – you will not have a Docker command on the node to look at running containers, clean up volumes, and so on.

Kubernetes supports a number of runtimes in place of Docker. Two of the most commonly used runtimes are as follows:

• containerd
• CRI-O

While these are the two commonly used runtimes, there are a number of other compatible runtimes available. You can always view the latest supported runtimes on the Kubernetes GitHub page at https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md.

Introducing Docker

Both the industry and end users were seeking a solution that was both convenient and affordable, and this is where Docker containers came in. While containers have been utilized in different ways over time, Docker has brought about a transformation by providing a runtime and tools for everyday users and developers.

Docker brought an abstraction layer to the masses. It was easy to use and didn’t require a clean PC for every application before creating a package, thus offering a solution for dependency issues, but most attractive of all, it was free. Docker became a standard for many projects on GitHub, where teams would often create a Docker container and distribute the Docker image or Dockerfile to team members, providing a standard testing or development environment. This adoption by end users is what eventually brought Docker to the enterprise and, ultimately, what made it the standard it has become today.

Within the scope of this book, we will be focusing on what you will need to know when trying to use a local Kubernetes environment. Docker has a long and interesting history of how it evolved into the standard container image format that we use today. We encourage you to read about the company and how they ushered in the container world we know today.

While our focus is not to teach Docker inside out, we feel that those of you who are new to Docker would benefit from a quick primer on general container concepts.

If you have some Docker experience and understand terminology such as ephemeral and stateless, you can jump to the Installing Docker section.

Docker versus Moby

When the Docker runtime was developed, it was a single code base. The single code base contained every function that Docker offered, whether you have used them or not. This led to inefficiencies, and it started to hinder the progression of Docker and containers in general.

The following table shows the differences between the Docker and Moby projects.

Table 1.1: Docker versus Moby features

To recap – Moby is a project that was started by Docker, but it is not the complete Docker runtime. The Docker runtime uses the components from Moby to create the Docker runtime, which includes the Moby open-source components and Docker’s own open-sourced components.

Now, let’s move on to understanding Docker a little more and how you can use it to create and manage containers.