K8s — Why Deprecating Docker?

Tony on 2022-07-17

K8s — Why Deprecating Docker?

A little K8s knowledge every day!

During my writing of “K8s” article series, lots of readers left me messages asking about K8s abandoning Docker, worrying about whether it is still worthwhile to learn Docker now, and whether it is time to switch to containerd or other runtimes.

There is some truth to these doubts. Two years ago, when K8s released the news to “deprecate Docker”, it really caused a “uproar” in the K8s community, and the impact even spread outside the community, and K8s had to write several blogs to repeat Explain why.

Two years later, although K8s 1.24 has achieved the goal of “deprecation Docker”, many people still don’t seem to have a very clear understanding of this. So let’s talk about this topic today.

Pic from Internet

CRI (Container Runtime Interface)

To understand why K8s “deprecated Docker”, we have to look back at the development history of K8s.

In 2014, Docker was at the height of its power and K8s was just born. Although it was supported by Google and Borg, it was still relatively new and didn’t have a big community.

Therefore, K8s naturally chooses to run on Docker. After all, “it is good to enjoy the shade with the back of a big tree”, and at the same time, it can also take the opportunity to “recharge energy” and gradually develop and strengthen itself.

Fast forward to 2016, CNCF has been established for a year, and K8s has also released version 1.0, which can be officially used in the production environment. These all indicate that K8s has grown up.

So it announced that it had joined CNCF and became the first CNCF hosting project. It wanted to use the power of the foundation to unite with other manufacturers to “bring down” Docker.

In version 1.5 at the end of 2016, K8s introduced a new interface standard: CRI: Container Runtime Interface.

CRI uses ProtoBuffer and gPRC to specify how the kubelet should call the container runtime to manage containers and images, but this is a new set of interfaces that are completely incompatible with previous Docker calls.

Obviously it does not want to be bound to Docker anymore, and allows access to other container technologies (such as rkt, kata, etc.) at the bottom, and can “kick off” Docker at any time.

But at this time, Docker is very mature, and the inertia of the market is also very strong. It is impossible for major cloud manufacturers to replace Docker all at once.

Therefore, K8s can only provide a “compromise” solution at the same time, adding an “adapter” between kubelet and Docker to convert Docker’s interface into a CRI-compliant interface:

Pic from k8s.io

Because this “adapter” is sandwiched between the kubelet and Docker, it is vividly called a “shim”, which means “shim”.

With CRI and shim, although K8s still uses Docker as the underlying runtime, it also has the conditions for decoupling from Docker, which has opened the curtain of the “deprecating Docker” drama.


Facing the challenge, Docker adopted the strategy of “surviving by breaking the arm”, promoting its own reconstruction, and splitting the Docker Engine of the original single architecture into multiple modules, of which the Docker daemon part was donated to CNCF and containerd was formed.

As a hosting project of CNCF, containerd must comply with the CRI standard. However, for many reasons, Docker just calls containerd in Docker Engine, and the external interface remains unchanged, which means that it is not compatible with CRI.

Due to Docker’s “stubbornness”, there are two call chains in K8s at this time:

Obviously, because containerd is used to manage containers, the final effect of these two call chains is exactly the same, but the second method eliminates the two links of dockershim and Docker Engine, which is more concise and clear, with better performance.

When Kubernetes 1.10 was released in 2018, containerd was also updated to version 1.1, officially integrating with Kubernetes, and a blog post was published ( https://kubernetes.io/blog/2018/05/24/kubernetes-containerd- integration-goes-ga/ ), showing some performance test data:

From these data, it can be seen that compared to Docker 18.03 at that time, containerd1.1 reduced Pod startup delay by about 20%, CPU usage by 68%, and memory usage by 12%, which is a considerable performance improvement is very tempting for cloud vendors.

Official Docker Deprecation

Two years later, in 2020, K8s 1.20 finally officially “declared war” on Docker: the kubelet will deprecate Docker support and will be completely removed in a future version.

But since Docker has become almost synonymous with container technology, and K8s has been using Docker for many years, the announcement quickly “smells” as it spreads, and “kubelet will deprecate Docker support” is simplified to something more appealing Eyeball’s “K8s will deprecate Docker”.

This naturally caused panic in the IT world, and “the masses who don’t know the truth” expressed their shock: Docker, which has been used for so long, is suddenly unusable. Why does K8s treat Docker like this? Will the previous investment in Docker go to zero? What to do with the large number of existing mirrors?

In fact, if you understand the two projects CRI and containerd mentioned above, you will know that this move of K8s is not surprising, everything is “natural”: it is actually just “deprecated dockershim”, that is, moving dockershim out of kubelet, is not a software product that “deprecates Docker”.

Therefore, “deprecating Docker” will not have much impact on K8s and Docker, because both of them have already changed the lower layers to open source containerd, and the original Docker images and containers will still run normally. The only change is that K8s bypasses Docker and directly calls containerd inside Docker.

However, there will be some impacts. If K8s uses containerd directly to manipulate containers, then it is a separate working environment from Docker, and neither can access the containers and images managed by the other. In other words, using the command docker ps will not see the containers running in K8s.

This may take a little getting used to for some people and use the new tool crictl , but the subcommands used to view containers and images are still the same, such as ps, images, etc., it is not difficult to adapt (but if we If you have been using kubectl to manage K8s, this has no effect).

K8s originally planned to use a year to complete the work of “deprecating Docker”, but it did underestimate the foundation of Docker. It still failed to remove dockershim in version 1.23, and had to postpone it for half a year. Finally, the 1.24 version released in May this year removed the dockershim code from the kubelet.

Since then, Kubernetes has completely “parted ways” with Docker.

Future of Docker

So, what does the future hold for Docker? Is there no place for it in the cloud native era? The answer to this question is obviously no.

As the founder of container technology, no one can question Docker’s historical status. Although K8s is no longer bound to Docker by default, Docker can still coexist with K8s in other forms.

First of all, because the container image format has been standardized (OCI specification, Open Container Initiative), Docker images can still be used normally in K8s, and the original development testing and CI/CD processes do not need to be changed. We can still pull Docker Hub , or write a Dockerfile to package the application.

Secondly, Docker is a complete software product line, not only containerd, it also includes many services such as image building, distribution, testing, and even K8s is built into Docker Desktop.

As far as the convenience of container development is concerned, Docker is still difficult to be replaced for the time being. The majority of cloud native developers can continue to work in this familiar environment and use Docker to develop applications running in K8s.

Again, although K8s no longer includes dockershim, Docker has taken over this part of the code and built a project called cri-dockerd ( https://github.com/mirantis/cri-dockerd ), which also works likewise, adapt Docker Engine to a CRI interface, so that the kubelet can operate Docker through it again, as if it never happened.

On the whole, although Docker lost in the container orchestration war and was squeezed into the corner by K8s, it still has strong vitality. Many loyal users and a large number of application images accumulated over the years are its biggest capital and backing. Enough to support it on another path that doesn’t go head-to-head with K8s.

For beginners, Docker is easy to use, has a complete tool chain and a friendly interface, and it is difficult to find software comparable to it on the market. It should be said that it is an entry-level learning container technology and cloud native” the best choice”.