Kubernetes container runtime containerd replaces Docker
For IBM Cloud Kubernetes Service clusters that run version 1.11 or later, containerd replaces Docker as the container runtime for Kubernetes. Clusters running version 1.10 and earlier continue using Docker. This change to containerd provides enhanced performance and a simplified container runtime environment. For more information related to this transition, see the following blogs:
Action is required for apps that depend on Docker
As with most architecture changes, you may also be required to make changes. In particular, if your Kubernetes app relies on Docker as the Kubernetes container runtime, you must update the app to handle containerd as the container runtime. Examples of such dependencies include the following:
Your app pod mounts the Docker socket /var/run/docker.sock. The UNIX socket for containerd is /var/run/containerd/containerd.sock. It is important to note that the containerd socket does not provide the Docker HTTP API, but it has a gRPC listener for its own API as well as the Kubernetes CRI API.
Your app pod runs with host privileges and accesses the Docker CLI on the host. The common CLI for all CRI compliant Kubernetes runtimes is crictl. While crictl is the preferred host CLI for CRI runtimes, containerd also has an administrative/debug CLI, ctr.
Your app pod mounts /var/lib/docker/containers to access Docker container logs. The container logs for containerd are available under /var/log/pods.
In addition to your apps, you may also rely on vendor apps that need to change. The good news is that, in general, your container development processes do not change. You can still use a Dockerfile to define a Docker image and build a container for your apps. If you use Docker commands to build and push images to a registry, you may continue to do so.
Many apps already support containerd
You are not alone in this journey to a world with container runtimes other than Docker. IBM, the Kubernetes and containerd communities, and many others are working to make this a smooth transition for you and your favorite Kubernetes apps. For example, go to IBM Cloud helm charts catalog and select IBM Cloud Kubernetes Service for a list of IBM charts that already support containerd. In addition, there are numerous external and IBM catalog services that already support containerd, such as logging with LogDNA, security with Aqua or Twistlock, and, coming soon, monitoring with Sysdig.
Prepare for the transition to containerd
Since migrating apps will take some time, IBM Cloud Kubernetes Service has kept version 1.10 as the default cluster version longer than normal. However, the default cluster version will soon change to 1.11. After the change, you will still be able to create version 1.10 clusters, but you should start planning your upgrade now.
Open an IBM support ticket if you require assistance preparing for the upgrade to Kubernetes 1.11 or later with containerd.