What Does Kubernetes’ Docker Deprecation Mean for Users

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.

Why is Kubernetes Moving Away from Dockershim?

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.

What Does This Change Mean for Developers?

There is something new on the way, keeping a few of the old concepts intact.

• Docker images will continue to work as they are in the existing and new Kubernetes clusters.
• You can continue to use Docker to test on your less critical stacks and on your personal machines to make sure everything works functionally.
• Images built with Docker build will also keep working across clusters.
• Public Cloud solutions like AKS from Azure & EKS/ECS from AWS will need to migrate to a supported container runtime before Kubernetes removes support for Docker.
• Systems using Docker sockets in their workflow will break so it is essential to migrate to other options like kaniko, buildah or img. 

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.

What Does This Change Mean for Enterprises?  

• The open-source community aims to simplify and deliver fast. For companies that have large-scale systems deployed with Docker are going to have a tough time re-architecting.
• Cloud operation engineering, Site Reliability Engineers, and Cloud Architects are not happy, to put it mildly. Although the migration process is going to be a tough journey, it is for a better and cleaner future for the kubelet.
• Also, this move ensures Kubernetes stays compliant with the CNCF methods. There is no doubt that this community is a conglomerate of bright minds, who gave a lot of thought to the breaking changes.
• They had it all considered and concluded that this temporary pain would be worth how much more Kubernetes has to offer eventually.

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.

Deprecation Timelines (Versions)

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.

As per recent updates from the community, the timelines have been further extended, and it is only onwards v1.24 that kubelet will lose support for Dockershim. The estimated date of release for v1.24 is expected to be a year after April 2022, as stated in the Kubernetes GitHub project release timeline. Learn more with DevOps Certification course.

Next Steps by Kubernetes  

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:

• The container runtime interface (CRI) being in its alpha stage will take time to graduate and be available via CRI APIs.
• Kubelet is already available independent of the Dockershim/Docker and is available with the ‘Dockerless’ tag.
• Kubernetes nodes related features have no direct dependencies on Dockershim/Docker.
• The test framework for Kubernetes has already been developed to fully support out-of-tree CRI container runtime.

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.

Docker Alternatives: Containerd, CRI-O, Buildah  

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. 

1. Containerd: This project gained immense popularity since it graduated as a project within the CNCF. It allows Kubernetes the capacity to super-wise low-level Docker components they need with an easy-to-access interface to the container runtime. It is available as a daemon for both Windows and Linux. Amazon EKS and Fargate are some of its early adopters. 
2. CRI-O: This container runtime is quite similar to Containerd. It is a high-level container runtime interface used as an alternative to Containerd. CRI-O was specifically built to be Kubernetes compatible. 
3. Buildah: This is an open-source tool that can be used across any Linux distribution. The uniqueness of buildah comes from the number of controls programmers can have on the image and layers of the image. They also enable building custom blank images from scratch. 

Conclusion  

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.