The official Kubernetes developer blog has released news that, at first glance, sounds scary: Kubernetes is abandoning Docker. Kubernetes has a CRI interface that allows you to use different container runtimes, such as Docker, cri-o, or contained.
Docker itself does not support CRI, so the Kubernetes developers created a layer – dockershim; it was conceived only as a temporary solution. Such a layer is a kind of “crutch”; it slows down the development of CRI, does not support cgroups v2 and user namespaces, and has some security problems. Therefore, the Kubernetes developers decided to stop supporting this layer and Docker as a container runtime. “Kubernetes will become safer and more reliable.
Docker was not built with Kubernetes in mind. Now they are removing support for one part of Docker that performs one of the dozens of functions inside a large Kubernetes scheme. It is being replaced by a cloud-native environment better adapted to work in such a complex system.” Docker containers will work as before: what will change for developers, administrators, and KaaS users.
For developers, nothing will change; they will also continue to use Docker containers. It’s just that these containers will run in a different environment. Simplifying, we can say that the mechanism of work changes inside the black box, but the input and output parameters will not change from this. Outside the box, everything will work as before. This is possible because Docker creates images according to the generally accepted OCI standard.
Any OCI-compliant image, no matter how you create it, will work the same in Kubernetes. “The changes only affect the way containers run inside a Kubernetes cluster. Nothing will change for end-users. They will still be able to describe their images with a Dockerfile and build from them with Docker build.”
The changes will affect cluster administrators who run them on-premise when upgrading from an old version to a new one. You will need to switch to one of the compatible runtime environments, such as containers or CRI-O. It’s worth making sure the environment you choose supports your Docker daemon configurations, such as logging.
Users of Kubernetes as a service have nothing to worry about: the provider is responsible for maintaining and updating the cluster; most likely, nothing will have to be done. Our Kubernetes customers don’t need to prepare anything. The Docker images will continue to run inside Kubernetes, and we will be able to run them on our clusters as well.
As a provider, we have to resolve the issue of updating, but this will not affect users. We will try to make the migration as seamless as possible. If some advanced scenarios require changes by users, we will prepare detailed instructions and help. In addition, it’s still a long time before the update – we have the Kubernetes 1.17 version, as proven and stable, and support will be completely removed only in version 1.23. We have enough time to prepare and make the necessary changes fully.” Until the complete cessation of support for another year, in release 1.20, Kubernetes will mark the Docker runtime as deprecated. And finally, it will be removed no earlier than the release of 1.23, which is planned as earlier.
