There is a widespread panic all over the internet lately with regards to the last move of Kubernetes to shun Docker from its platform.
Sparkling headlines like “The End of a Docker”, “Kubernetes Killed Docker” and an infinite amount of click baits are scattered all across the web discussing this issue.
The truth is that those claims are not that dramatic and certainly not accurate.
In this short article, I will spare you the unnecessary superlatives and excessive data and simply explain to you what is going to happen with Docker and Kubernetes in the near future.
Spoiler — not that much ;)
Definition of Docker
Docker is a set of “platform as a service” products that use OS-level virtualization to deliver software in packages called containers- wikipeida
My favorite way of explaining Docker to my customers and students in a one-liner sentence:
“Overall, Docker is a very comfortable wrapper for containers.”
What is the problem of Kubernetes with Docker?
Most of the confusion regarding this topic stems from the lack of understanding of Docker’s functionality as a product.
By and large, Docker as a product fulfills three main functions:
- Development environment for images
- UX management interface for containers
- Runtime environment for containers
Kubernetes is essentially a container orchestrator, meaning its job or designation if you will is mainly to run containers in a redundant and efficient manner, therefor all Kubernetes “needs” from Docker at the end of the day is only his “Runtime environment” functionality.
Thus the other functionalities burdening on the Kubernetes ecosystem and reducing its performance.
Moreover, the Docker’s Runtime environment is not compatible with the component responsible for running containers in Kubernetes named CRI.
Thus a special interfacing abstraction layer named Dockershim was introduced and caused problems like:
Compatibility issues, development overhead, and inferior performance.
Therefore the Kubernetes team took a just but hard decision to remove Dockershim from the newer versions of Kubernetes starting from version 1.22
Impacts on end-users
The effects on end-users are almost non-existent as images built by Docker would still work properly as well as images built by other tools like Kaniko, IMG, and Buildah.
Impacts on cloud managed services
The impact on managed Kubernetes services is quite minor and it will be easy to upgrade the nodes to work with a different Runtime environment in no time.
At the moment most of the providers are working on a comfortable transition for older clusters.
For example,
In Google this feature already built-in
https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd.On in AKS, “Containerd” is already installed automatically.
Impacts on On-prem clusters
Kubernetes On-prem has more impact, as you will need to replace your Runtime environment for all the clusters’ servers with a new container runtime CRI approved components like:
- Contained
- CRI-O
This conversion process will indeed take more time than the managed services (depending on the size and complexity of your cluster) but still not much more complicated.
Conclusion
You have nothing to be worried about!
- You can proceed using Docker as your main Image building tool.
2. You have more than a year until the Kubernetes version deprecates the Docker container engine, so there is enough time for you to prepare for this minor change.
3. Ultimately this is a minor change in the Kubernetes ecosystem that will lead to higher performance and prevent future malfunctions.
Do not worry everything is fine :)
Hope it was helpful,
Or Maman
www.linkedin.com/in/ormaman
Orm@sela.co.il
