About the container runtime

Your clusters use a container runtime to create and run Kubernetes Pods. Before version 1.13 of Google Distributed Cloud, your container runtime could be either Docker Engine or containerd. However, your container runtime can only be containerd starting from version 1.13 of Google Distributed Cloud.

Before version 1.13 of Google Distributed Cloud, you chose your container runtime by specifying a value in the spec.nodeConfig.containerRuntime field in your cluster configuration file. Starting from version 1.13 of Google Distributed Cloud, the containerRuntime field is no longer included in cluster configuration files generated by bmctl.

Kubernetes 1.24 ends support of Docker Engine

The dockershim component in Kubernetes enables cluster nodes to use the Docker Engine container runtime. However, Kubernetes 1.24 removed the dockershim component. Since Google Distributed Cloud version 1.13 will run on Kubernetes 1.24, version 1.13 and higher clusters can no longer use Docker Engine.

Whether creating a version 1.13 cluster or upgrading a version 1.12 cluster to version 1.13, containerd is the default and is the only supported container runtime. You aren't required to specify the container runtime in the cluster configuration file. If you try to specify anything but containerd for the container runtime, the cluster upgrade or create operation will fail.

The Docker installation that you use in development to create images is unrelated to the Docker Engine container runtime inside your Kubernetes cluster. You can still use Docker to create images and build application containers. Those containers will still work inside your cluster.

You must continue to install Docker on your admin workstation because the bmctl command requires Docker for operations, such as cluster creation. This use of Docker is also unaffected by the dockershim deprecation.

Check the status of the container runtime

To check the status of the container runtime, run the following command:

systemctl status containerd