Docker probably didn’t think it would be in the spotlight twice in the tech world in 2020, both because of information gaps (aka “clickbait”).

An overview of

In 2013,

Docker was first officially announced at PyCon 2013. It brings an advanced method of software delivery, that is, software delivery through container image. Engineers only need a simple Docker build command to make their own images and publish them to DockerHub through Docker push. The simple Docker run command enables you to quickly start your own service with a specified image.

Through this method, the problems caused by the differences of software runtime environment can be effectively solved, and the goal of building once and running anywhere can be achieved.

Since then, Docker has basically become a synonym for container and a leader in the container age.

In 2014,

In 2014, Google launched Kubernetes to solve the problem of Docker container choreography in large-scale scenarios.

It was a logical choice at a time when Docker was the most popular and only runtime. Kubernetes has gained a large number of users with support for the Docker container runtime.

Meanwhile, Google and the Kubernetes community are working closely with Docker, as described on their official blog:

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 gave a talk at DockerCon that same month, introducing Kubernetes and getting a lot of attention.

At the same time, Docker Inc. released its container choreography tool, Libswarm (later Swarmkit).

In 2015,

In 2015, OCI (Open Container Initiative) was founded by Docker and other Container industry leaders (it is also a Linux Foundation project).

OCI consists of two main specifications:

  • Run-time spec: How does the package on the specified file system run when the container runs

  • Image-spec: How do I create a package on the file system that can be run at OCI runtime

Docker donated its own container image format and Runtime (now RUNC) to OCI for initial work.

In 2016,

In June 2016, Docker V1.12 was released, bringing Docker in multi-host multi-container choreography solution, Docker Swarm. It’s also important to note here that Docker V1.12’s design principles:

  • Simple Yet Powerful
  • Resilient
  • Secure (Secure)
  • Optional Features and Backward Compatibility

So you can configure yourself to use Docker Swarm without worrying about side effects.

In December 2016, Kubernetes released the Container Runtime Interface (CRI), in part because Kubernetes was trying to support another Container Runtime project led by CoreOS, RKT. In order to avoid the maintenance of compatibility with other runtimes, we released a unified CRI interface. Any runtimes that support CRI can be directly used as the underlying Kubernetes runtimes.

Of course, Kubernetes gradually won the war of container arrangement in 2016.

In 2017,

In 2017, Docker donated its container runtime containerd, which was introduced in V1.11, to CNCF

In 2017, Docker added CNI support to libNetwork, its networking component; At the same time, by using the IpvS-related code provided by Docker for Docker Swarm, ipvS-based service load balancing is also implemented in Kubernetes. In V1.18, however, we started removing the dependencies.

In November of that year, Kubernetes added containerd support

In 2018,

2018, Kubernetes containerd integration, official GA

Previous versions of the architecture:

New architecture:

In 2019,

In 2019, RKT, another container runtime project mentioned above, was archived by CNCF and terminated its mission; Mirantis acquired Docker’s enterprise services in 2019.

In 2020,

Back this year, Docker was mainly misunderstood for two things:

  • Docker Inc. has modified DockerHub’s pricing and TOS. Much of the debate at home is about compliance (but it’s been skewered by headlines and panic);
  • Kubernetes announced the countdown to the end of Dockershim support after it was mistakenly believed that Docker was no longer available;

instructions

No more on DockerHub pricing and TOS changes, because DockerHub is still being used happily, far less than the headlines claimed.

Let’s focus on the second thing.

When Kubernetes chose Docker as its container to run at first, it was because it had no other choice at that time, and choosing Docker could bring it a large number of users. So, to begin with, it provides built-in support for the Docker runtime.

When Docker was created, it didn’t really have “choreography” in mind, and certainly didn’t have Kubernetes in mind (because it didn’t exist at the time).

Dockershim has always been a compatible program maintained by the Kubernetes community in order to make Docker a supported container runtime. In this case, Kubernetes is simply abandoning maintenance support for dockershim in the Kubernetes repository. So that it is only responsible for maintaining its CRI, as originally planned, and any CRI compatible runtime will act as the Kubernetes Runtime.

When Kubernetes proposed CRI, it was suggested to implement it in Docker. However, this approach also brings a problem. Even if Docker implements CRI, it is still not a pure container runtime. It contains a large number of functions that are not “pure underlying container runtime”.

So the Containerd project, which was spun out of Docker, emerged as an underlying container runtime that was a better choice for the Kubernetes container runtime.

Docker uses Containerd as its underlying container runtime, and many cloud vendors and companies use containerd as their Kubernetes runtime in production environments, which also proves the stability of Containerd.

Now both the Kubernetes and Docker communities believe that ContainerD is mature enough to be used directly as the Kubernetes runtime, rather than using Docker as the Kubernetes runtime through Dockershim. It also marks the end of Docker’s promise to provide a modern container runtime for Kubernetes.

And in this event, the focus of dockershim after the direction of what? The Kubernetes repository of Dockershim will be removed in future releases, but Mirantis has partnered with Docker to maintain a dockershim component in the future. To enable Docker to run as a container for 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 announced that it will maintain Dockershim

Q&A

Q: What impact will Kubernetes have on Dockershim? A: For ordinary users, there is no impact; For engineers working on top of Kubernetes, it doesn’t matter; For cluster administrators, consider whether to upgrade the container runtime to a CRI supported runtime, such as Containerd, in future releases. Of course, if you don’t want to switch the container runtime, that’s fine, Mirantis will work with Docker to maintain Dockershim in the future and offer it as an open source component.

Q: Docker doesn’t work anymore? A: Docker is still the best container tool for local development or stand-alone deployment. It provides A more user-friendly user experience and also has rich features. At present, Docker has reached cooperation with AWS, and can directly integrate with AWS through Docker CLI. In addition, Docker can still be run as a Kubernetes container, and support for it has not been immediately discontinued.

Q: It is said that Podman can use the computer to host? A: Too much thinking. Podman is also not CRI compatible, and it does not have the conditions to run as a Kubernetes container. I personally use Podman occasionally, and we have support for it in the KIND project, but to be honest, it’s just a CLI tool that can be useful in certain situations, such as if your Kubernetes container is running with Cri-O. Can be used to do local debugging.

conclusion

This article mainly introduces the development history of Docker and Kubernetes, and explains that Kubernetes only dropped its support for Dockershim components. A more recommended future Kubernetes runtime is an underlying runtime like the CRI-compatible Containerd.

Mirantis will work with Docker to maintain Dockershim and provide it as an open source component.

Docker remains one of the best tools for local development, testing, and deployment.

Welcome to subscribe to my article public account [MoeLove]