Docker is known worldwide to be the one-stop solution and the first container runtime engine for running on Kubernetes. The extent and reach of Docker are everywhere in the software industry. As Docker kept infiltrating developers’ and operational experts’ hearts, Kubernetes propelled its journey by being the far most superior orchestration tool of the decade at supporting it. The inception and intelligent functionalities of Kubernetes empowered Docker from being a developer’s friend to something that large businesses were using in staging and production environments. Together they have been ruling our hearts and managing our containerized systems.
Despite this vast usage, the orchestration support community had to decide on deprecating support for Docker Container Runtime from the v1.24 release.
Since its inception, Docker was inbuilt as a part of a kubelet called Dockershim. Docker allowed cluster operators to continue using Docker Engine seamlessly. With time, increased container technologies have spun up in the market, and Kubernetes improvised with time to support them all.
It started getting difficult for the CNCF community. The maintenance cost for Dockershim started to show us as quite an extra cost for the community in addition to existing support for all runtimes. Docker not implementing a container runtime interface is where this decision roots from. The decision of Kubernetes Docker deprecation has forced users and enterprises to go through small and substantial changes that are costly.
Over time, container technologies gained popularity in the industry. Increasingly, these container technologies started to gain popularity among developers and the open-source community for the specific use cases they were solving. There were options in the market and engineers and architects started picking the best fit. As a result, Kubernetes added support for these newer runtimes by implementing a container runtime interface, or a CRI.
Having Dockershim integrated into the system is now an antipattern. It goes against the design of CRI where CRI implementations are capable of being run as a separate binary. Docker CRI or the Dockershim is tightly coupled with the kubelet. Learn more about this change with Docker Kubernetes training.
Additionally, the dependencies that come with Docker and their vulnerabilities have crept into all systems that have been solely operating with Docker. Any issues in the Docker container runtime now affects the kubelet. The isolation of responsibilities and ownership is getting violated by a setup like this. Cluster administrators are getting disrupted by every critical issue in the container runtime.
There is something new on the way, keeping a few of the old concepts intact.
You will keep writing and using Dockerfiles as you have been. We will continue to build images using the Docker build command. The shift will take some time, and a bit of a learning curve is expected to come your way.
Our suggestion would be to take a breath and plan it out. As seen over the years, large enterprise clusters have the highest toll to take. There will be weeks of analysis, planning, change management, deploying, testing-retesting and architecture changes coming your way. The change not only has to be carefully injected into the system, but there will also be a lot of monitoring to check how well the system is absorbing and adapting to this change. Every small break has the potential to impact thousands of end users and devices. This makes it immensely necessary for architects to mindfully incorporate everything into their SDLC. Also, this should be perceived as an opportunity to fix neglected bits like security loopholes. We know this is something that was not asked for, but we must live with it. Change comes at a cost but is the necessary way forward.
Kubelet with in-tree Dockershim is now in maintenance mode. Announcements of Dockershim deprecation were made as a part of the Kubernetes v1.20 release. Due to the large scale usage of Dockershim across enterprises and open-source communities, the deprecation date was extended. Support for Dockershim will be available till release v1.22, implying that it is only onwards v1.23 that the change will start to impact your Kubernetes environments. This was their original plan.
The CNCF community plans to completely remove Dockershim from Kubernetes and roll-out these changes in a phased manner. During this process, they are not going to make changes or redesign the shim in any capacity. There are some things already in place while a good portion of their code base is going to see a surge in commits.
There are these existing system advantages that are helping accelerate the deprecation. Some of them being:
As we look forward to how well v1.25 will be able to jell into a Docker-smothered Kubernetes world, it is particularly important for all developers and enterprises to prepare for the same. Check out the latest new release for v1.25.
The trajectory, as seen with the CNCF community and business needs across the world, has encouraged software engineers to look out for alternate options. We will briefly discuss some of the famous alternatives to Docker.
Although Docker support will be available till v1.24 as announced, we need to keep in mind that the CNCF community will start diverting resources away from Docker runtime support and concentrate more on a consolidated product which means you should plan the migration of your stacks off Docker and do that as soon as possible so that by the time this change reaches production, you’re not meeting the deprecation timeline head-on. Change is the universal constant to progress, and so should be your learning. Explore KnowledgeHut’s Docker Kubernetes training for a better understanding of these technologies.
Getting rid of Docker would not be the right way to frame it, nor is it what they are doing. Dockershim will be removed as a kubelet component.
The Kubernetes community wants to avoid overhead maintenance of Dockershim as a part of the kubelet. Also, removing Dockershim from the kubelet will expose the system to vulnerabilities that Docker brought with it.
Docker Swarm is lightweight compared to Kubernetes which also means that Swarm is not as powerful an orchestration tool as Kubernetes. Which container orchestration to use is dependent on your business use case and has less to do with the container runtimes it supports.
| Name | Date | Fee | Know more |
|---|
