What do I need to do to prepare for Kubernetes Docker deprecation?


#1

First of all, don’t panic.

Secondly, this only affects Kubernetes nodes that currently use Docker. Docker itself is not going away, so non-Kubernetes developer workflows will be fine. If you are just an end user of applications running on Kubernetes, you should not notice any differences.

Lastly, there is plenty of time to prepare for the change. During the next few releases, you will receive a deprecation warning when using the Docker container runtime. This will begin with v1.20.

The complete removal of Docker runtime support is currently planned for the 1.22 release, which will drop in late 2021. Even when that happens, you do not have to upgrade until you are ready.

Why is this happening?

Docker itself is a bunch of different technologies bundled together, and this stack includes some heavyweight features meant for actual people.

Kubernetes doesn’t need that extra baggage and created a specification called the Container Runtime Interface for a lightweight API used to pull, run, and destroy containers (among other things).

Since Docker isn’t currently compliant with the CRI, using Docker in a Kubernetes cluster is a bit of a hack. In fact, Kubernetes needs something called Dockershim to even be able to use Docker in a cluster. Eventually Docker (officially the Mirantis Container Runtime) will be compliant with CRI and released as an open source project here.

Who might this affect?

This might affect you if:

  • you are running containers to build other containers (DinD) . Since removing Docker will remove /var/run/docker.sock , you will want to switch to a non-docker build tool like kaniko, img, or buildah.

  • you aren’t running managed Kubernetes, or you build your own custom Kubernetes nodes.
    You will have to build new nodes using one of the other compliant container runtimes, like containerd or CRI-O. Just make sure that the runtime you choose supports the docker daemon configurations you currently use (like logging).

What will change with kurl.sh embedded clusters?

Currently containerd is a supported kurl.sh container runtime option for embedded clusters, and it will eventually become the default option to replace Docker.

NOTE: Google has already adopted containerd as the default runtime starting with GKE node version 1.19 and has released a migration guide to containerd for GKE users.

How will I upgrade my current cluster?

Replicated will be releasing tutorials to help customers upgrade their current workloads as the Kubernetes v1.22 release gets closer.

The short version is to add new CRI-based nodes to the existing embedded cluster, migrate pod workloads to those nodes, then cordon and remove the older Docker-based nodes.

Further reading: