Will the deprecated Docker be replaced by Podman?

The Kubernetes team recently announced that it will deprecate features supported by Docker in the latest version, and these features will be removed in subsequent versions.

Recently, the Kubernetes team released the latest version 1.20, which updated many contents:

The storage volume snapshot function has become stable; Kubectl Debug has entered Beta; Beta: API priority and fairness; IPV4/IPV6 Alpha function update; GA: limit process PID; Dockershim is deprecated; Exec probe timeout processing, etc. (For details, please see: https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/ )

Among them, there is an update that is undoubtedly a bombshell for the developer community: the official announcement of the deprecation of features supported by Docker. So, why does Kubernetes do this and what impact will it have?

Docker is a way to package, distribute, and deploy applications in a containerized manner. Since its initial release on March 13, 2013, Docker has become the de facto standard in the container industry. Kubernetes is an open source container orchestration system developed by Google.

Kubernetes architecture diagram, from Wikipedia

Docker and OpenShift

At the 2015 summit, Red Hat released OpenShift V3.0. This new version of OpenShift uses Docker containers at the bottom layer and begins to use Kubernetes to orchestrate images. However, during the 2016 Red Hat Summit, Docker launched a sharp attack on Red Hat's OpenShift. Not only did they post the following tweet, they also distributed T-shirts to attendees that read “We don’t accept imitations”:

Obviously the imitation whale on the left is mocking Red Hat's OpenShift. At the time, OpenShift used Docker-based containers. The Docker released by Red Hat is generally a little behind the original version, and in order to provide so-called "enterprise support", Red Hat has adopted the behavior of patching the old version of Docker. But in contrast, Docker is always releasing the latest version.

Of course, there are still different opinions on whether to maintain enterprise applications by upgrading or porting patches, so I will not comment on this point here, but Docker's behavior at Red Hat's own summit is indeed a bit unexpected. I have to admit that Docker was a great technology before that, after all, it was an important part of RedShift, but from that day on, things started to go wrong.

Platform Wars

Early PaaS platforms were mainly OpenShift, as well as two competitors Docker and Pivotal. Docker is well known to everyone, so there is no need to say more. Pivotal is a company founded by EMC and VMware in 2013, focusing on open source PaaS solutions. Their enterprise solution has been very successful for one simple reason: the user experience is great, especially when combined with Pivotal Labs.

Docker is a rising star in enterprise solutions. Its advantage is that developers are already familiar with the Docker engine. At that time, Kubernetes was nowhere to be found. However, Docker's attack on OpenShift forced Red Hat to invest resources in Kubernetes. Everyone has seen the results later. Kubernetes has been a huge success and has won the support of the entire industry.

At this time, Docker launched Docker Swarm to save the situation, but it was too late. In the second half of 2016, Kubernetes surpassed Docker Swarm and became the de facto standard in the industry. Ultimately, Docker Swarm didn't make any dent in Kubernetes. This can be considered the first death of Docker. From then on, Docker is no longer an enterprise-level PaaS solution and can only exist as a part of the cloud-native system. Fortunately, it has always been an important part of Kubernetes.

Kubernetes announces deprecation of Docker

Recently, Kubernetes announced that it would deprecate Docker.

(Official blog link: https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/):

This is undoubtedly the second announcement of the death of Docker. According to Kubernetes itself, Docker is no longer a necessary technology, but has become a technical debt. Kubernetes versions prior to 1.19 needed to connect to Docker through a module called Dockershim, and then Docker connected to Containerd to create containers. Technically, the actual container runtime is Containerd, not Docker. The role of Docker is just to create containers on Containerd. As a human user, it is very convenient to create a container by just running a Docker run; however, while it is convenient, Docker also brings a lot of useless operations and technical debt, which is a burden for Kubernetes. Kubernetes can completely bypass Docker and create containers on Containerd to achieve the same effect. This approach was adopted in Kubernetes 1.20.

Although Docker's business model failed, we must acknowledge the great contribution Docker has made to the entire industry. The technology that Docker brings is the best in the industry. To this day, our CI/CD system relies heavily on Docker. Without Docker, there would be no success of Kubernetes, and Kubernetes still has the shadow of Docker.

But don't worry, the Kubernetes team has done a lot of work to make the upgrade process as smooth as possible. Even if you upgrade to 1.20, you will only get a warning about Docker being deprecated. The current plan for Kubernetes is to completely remove Docker support in 1.22, which will be released at the end of 2021, so developers must switch to other container runtimes, such as Containerd or CRI-O, before then.

Alternatives to Docker

After Docker was abandoned, developers began to discuss its alternatives, among which Containerd and Podman were highly anticipated.

Containerd is an industry-standard container runtime that emphasizes simplicity, robustness, and portability. It can manage the lifecycle of containers, can be used by projects such as Kubernets CRI, and lay the foundation for extensive industry cooperation.

Podman was originally part of the CRI-O project, but was later separated into a separate project called libpod. The user experience of Podman is similar to that of Docker, except that Podman does not have a daemon. The container is started directly through the OCI runtime (also runc by default), so the container process is a child process of Podman. This is more like the Linux fork/exec model, while Docker uses the C/S (client/server) model.

Although Docker still occupies a large proportion of the current container market, its fate of being abandoned is certain. During this transition period, you might as well embrace Containerd and Podman!

This concludes this article about Will the deprecated Docker be replaced by Podman? This is the end of the article. For more information about Docker replacing Podman, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!