Responses (5)

You have 2 free member-only stories left this month.

Kubernetes and Docker will part ways; what does that mean to you?

This moment was long in coming; Kubernetes is deprecating Docker as a container runtime after version 1.20, in favor of runtimes that use the Container Runtime Interface(CRI) created for Kubernetes. However, this does not mean Docker's death, and it does not mean that you should also abandon your favorite containerization tool.

As a matter of fact, not a whole lot will be changing for you, as an end-user of Kubernetes; you will still be able to build your containers using docker and the images produced by running docker build will still run in your Kubernetes cluster.

Then, why all this fuss? What is changing, and why Docker seems like the black-sheep out of a sudden? Should we continue writing Dockerfiles?

Learning Rate is a newsletter for those who are curious about the world of AI and MLOps. You’ll hear from me every Friday with updates and thoughts on the latest AI news and articles. Subscribe here!

Don’t panic

The source of confusion here is that we are talking about two different things. Inside the Kubernetes cluster nodes, a container runtime daemon manages the complete container lifecycle: image pulling and storage, container execution and supervision, network attachments, and many more.

Docker is arguably the most popular choice; however, Docker was not designed to be embedded inside Kubernetes. That is the root of all problems. Docker is not just a container runtime; it is an entire tech stack with many UX enhancements that make it easy for us to interact with it. Indeed, Docker contains a high-level container runtime in itself: contrainerd. And containerd will be a container runtime option for you moving forward.

Moreover, these UX enhancements are not necessary for Kubernetes. If anything, they are obstacles that Kubernetes must workaround to get what it really needs. This means that the Kubernetes cluster has to use another tool called Dockershim, which is containerd. That adds a level of complexity and another tool that the team should maintain. Another source that could produce bugs and problems.

So, what is really happening here is that Kubernetes will remove Dockershim in version 1.23, which will break Docker support.

Should you care?

So, what is changing for you as a developer? Not that much. If you are using Docker in your development process, you will continue to do that, and you will not notice any differences. When you build an image using Docker, the result is not a Docker-specific thing. It’s an OCI (Open Container Initiative) image. Kubernetes and its compliant container runtimes (e.g., containerd or CRI-O) know how to pull and work with those images. This is why we have a standard for what containers should look like in the first place.

On the other hand, if you are using a managed Kubernetes service, like GKE or EKS, you will need to make sure that your nodes are running a supported container runtime before Docker support is removed re-apply or update your custom configurations if you use any. If you are running Kubernetes on-premise, you should also need to make changes to avoid unwanted problems and surprises.

Conclusion

At version 1.20, you will get a deprecation warning for Docker. This change is coming, and like any other, it will likely cause some issues at first. But it isn’t catastrophic, and in the long run, it’s going to make things easier.

I hope this article made some things clearer and relieved some anxieties. At the end of the day, these changes will probably mean nothing to you as a developer.

About the Author

My name is Dimitris Poulopoulos, and I’m a machine learning engineer working for Arrikto. I have designed and implemented AI and software solutions for major clients such as the European Commission, Eurostat, IMF, the European Central Bank, OECD, and IKEA.

If you are interested in reading more posts about Machine Learning, Deep Learning, Data Science, and DataOps, follow me on Medium, LinkedIn, or @james2pl on Twitter.

Opinions expressed are solely my own and do not express the views or opinions of my employer.