Docker probably didn’t expect that in 2020, it will become the focus of (public opinion) twice in the technology circle because of poor information (it’s not too much to say “title party”).
Docker was first officially announced on pycon in 2013. It brings an advanced software delivery method, that is, software delivery through container image. Engineers just need a simple
docker buildCommand to create your own image, and
docker pushPublish it to dockerhub. Through simple
docker runCommand can quickly start your own service using the specified image.
This method can effectively solve the problems caused by the difference of software runtime environment and achieve the goal of build once, run anywhere.
Since then, docker has basically become synonymous with container and the leader of the container era.
In 2014, Google launched kubernetes to solve the problem of docker container arrangement in large-scale scenarios.
This is a logical choice. Docker was the most popular and only runtime at that time. Kubernetes has welcomed a large number of users through its support for docker container runtime.
At the same time, Google and kubernetes communities are also working closely with docker. On their official blog, there are the following contents:
We’ll continue to build out the feature set, while collaborating with the Docker community to incorporate the best ideas from Kubernetes into Docker.
An update on container support on Google Cloud Platform
Kubernetes is an open source manager for Docker containers, based on Google’s years of experience using containers at Internet scale. Docker is delivering the full container stack that Kubernetes schedules into, and is looking to move critical capabilities upstream and align the Kubernetes framework with Libswarm.
Welcome Microsoft, RedHat, IBM, Docker and more to the Kubernetes community
He delivered a speech on dockercon in the same month, introducing kubernetes, which attracted extensive attention.
At this time, docker Inc. also released its container choreography tool, libswarm (later swarmkit).
In 2015, OCI (open container initiative) was jointly established by docker and other container industry leaders (it is also a project of the Linux foundation)
OCI mainly includes two specifications:
Runtime spec: how to run packages on the specified file system when the container runs
Container mirroring specification (image spec): how to create a package on a file system that can be run when OCI runs
Docker donated its own container image format and runtime (now runc) to OCI for initial work.
In June 2016, docker v1.12 was released, bringing docker’s multi host and multi container orchestration solution, docker swarm. It should also be noted that the design principle of docker v1.12:
Simple yet powerful
Optional features and backward compatibility
Therefore, you can choose whether to use docker swarm through configuration without worrying about any side effects.
In December 2016, kubernetes released CRI (container runtime interface), partly because kubernetes tried to support another container runtime project led by coreos, but needed to write a lot of compatible code. In order to avoid subsequent maintenance work caused by compatibility with other runtime, kubernetes released a unified CRI interface, Any runtime that supports CRI can be directly used as the underlying runtime of kubernetes;
Of course, kubernetes gradually won the war in 2016.
In 2017, docker donated the container runtime containerd  introduced since v1.11 to CNCF 
In 2017, docker’s network component libnetwork added CNI support; At the same time, by using the IPVS related code  provided by docker for docker swarm, service load balancing based on IPVS is also realized in kubernetes. However, in v1.18, the related dependencies began to be removed.
In November of the same year, kubernetes added containerd support 
In 2018, kubernetes’ containerd integration was officially GA 
Schema from previous versions:
containerd 1.0 cri-containerd
containerd 1.1 cri-containerd
In 2019, another container runtime project RKT mentioned above was archived by CNCF and terminated the mission; Mirantis acquired docker’s enterprise services in 2019.
Back this year, docker was misunderstood about two things:
Docker Inc. modifies the pricing and TOS of dockerhub. The most controversial issues in China are mainly about compliance (but it is led astray by the title party, so it is inevitable to panic);
Kubernetes announced that it began to enter the countdown of abandoned dockershim support, which was mistakenly thought that docker could no longer be used;
We won’t say more about dockerhub’s modification of pricing and TOS here. After all, dockerhub is still used happily, far from what the title party claimed at the beginning.
Let’s focus on the second thing.
Kubernetes chose docker as its container to run because it had no other choice at that time, and choosing docker could bring many users to it. Therefore, at the beginning, it provides built-in support for docker runtime.
At the beginning of docker’s creation, it didn’t consider the function of “choreography”, and of course, it didn’t consider the existence of kubernetes (because it didn’t exist at that time).
Dockershim has always been a compatible program maintained by the kubernetes community in order to make docker its supported container runtime. The so-called abandonment this time is just that kubernetes wants to give up the maintenance support for dockership in kubernetes code warehouse. So that it can only maintain its CRI as planned at the beginning, and any CRI compatible runtime can be used as the runtime of kubernetes.
When kubernetes proposed CRI, it was suggested to implement it in docker. However, this method will also bring a problem. Even if docker implements CRI, it is still not a simple container runtime. It itself contains a large number of functions that are not “pure bottom container runtime”.
Therefore, the containerd project separated from docker emerged as an underlying container runtime, which is a better choice for kubernetes container runtime.
Docker uses containerd as its underlying container runtime and many cloud manufacturers and companies use containerd as its kubernetes runtime in the production environment, which also verifies the stability of containerd from the side.
Now both kubernetes and docker communities believe that containerd is mature enough to directly serve as the runtime of kubernetes without using docker as the runtime of kubernetes through dockershim. This also marks that docker’s promise to provide kubernetes with a modern container runtime has finally been fulfilled.
In this event, what is the direction after the dockershim? The dockership in kubernetes code warehouse will be removed in future versions, but mirantis has reached a cooperation with docker and will jointly maintain a dockership component in the future to support docker as the container runtime of kubernetes.
Otherwise, if you’re using the open source Docker Engine, the dockershim project will be available as an open source component, and you will be able to continue to use it with Kubernetes; it will just require a small configuration change, which we will document.
Mirantis announces that it will maintain dockershim 
Q: What is the impact of kubernetes abandoning the maintenance of dockershim this time?
A: For ordinary users, there is no impact; It doesn’t have much impact on engineers developing on kubernetes; For cluster administrators, you need to consider whether to upgrade the container runtime to a CRI supported runtime in a future version, such as containerd. Of course, it doesn’t matter if you don’t want to switch the container runtime. Mirantis will jointly maintain dockershim with docker in the future and provide it as an open source component.
Q: Can’t docker work?
A: Docker is still the best container tool for local development or stand-alone deployment. It provides a more humanized user experience and rich features. At present, docker has reached cooperation with AWS, which can be directly integrated with AWS through docker cli. In addition, docker can still run as a container of kubernetes without immediately suspending its support.
Q: I heard podman can get on the computer?
A: Think too much. Podman is also not CRI compliant, and it is not qualified to run as a kubernetes container. Personally, I occasionally use podman, and we also provide support for podman in the kind project, but to be honest, it is just a cli tool, which will play a role in some cases. For example, if your kubernetes container uses cri-o when running, it can be used for local debugging.
This paper mainly introduces the development of docker and kubernetes, and explains that kubernetes only gives up its support for dockership components this time. The more recommended kubernetes runtime in the future is the underlying runtime such as container D compatible with CRI.
Mirantis and docker will jointly maintain dockershim and provide it as an open source component.
Docker is still the best tool for local development, testing and deployment.
An update on container support on Google Cloud Platform: cloudplatform.googleblog.com/2014/…
Welcome Microsoft, RedHat, IBM, Docker and more to the Kubernetes community: cloudplatform.googleblog.com/2014/…
CNCF website: www.cncf.io/
Add load balancing of IPVS in k8s:github.com/kubernetes/kubernetes/p…
Containerd Brings More Container Runtime Options for Kubernetes: kubernetes.io/blog/2017/11/contain…
Kubernetes Containerd Integration Goes GA: kubernetes.io/blog/2018/05/24/kube…
Mirantis to take over support of Kubernetes dockershim: www.mirantis.com/blog/mirantis-to-…
This work adoptsCC agreement, reprint must indicate the author and the link to this article