This page provides information aboutcontainerd, whichis used by all node images as the container runtime in yourGoogle Kubernetes Engine (GKE) nodes.

About containerd

Thecontainer runtimeis software that is responsible for running containers, and abstractscontainer management for Kubernetes. There are a few different containerruntimes.

Thecontainerd runtime is an industry-standardcontainer runtime that's supported by Kubernetes, and used by manyother projects. The containerd runtime provides the layering abstraction thatallows for the implementation of a rich set of features likegVisor andImage streamingto extend GKE functionality.

The containerd runtime is considered more resource efficient and secure than theDocker runtime.

Using containerd images in GKE clusters

When you create a new GKE cluster, a new node pool in an existingcluster, or when you upgrade an existing cluster, you can choose to use acontainerd node image. GKE Autopilot clusters always useContainer-Optimized OS with containerd.

The following table describes the supported containerd node images based on yourcluster mode and nodepool OS:

Using privileged Pods to access Docker

If your users access Docker Engine on a node using a privileged Pod, you shouldupdate those workloads so that there's no direct reliance on Docker. Forexample, consider migrating your logging and monitoring extraction process fromDocker Engine to GKE system add-ons.

Building container images with containerd

Youcannot use containerd to build container images. Linux images withcontainerd include the Docker binary so that you can use Docker to build andpush images. However, we don't recommend using individual containers and localnodes to run commands to build images.

Kubernetes is not aware of system resources used by local processes outside thescope of Kubernetes, and the Kubernetes control plane cannot account for thoseprocesses when allocating resources. This can starve your GKEworkloads of resources or cause instability on the node.

Consider accomplishing these tasks using other services outside the scope of theindividual container, such asCloud Build, or use a tool such askanikoto build images as a Kubernetes workload.

If none of these suggestions work for you, and you understand the risks, you cancontinue using Docker on the local node to build images. You must push theimages to a registry before you can use them in a GKE cluster.Kubernetes with containerd is unaware of images locally-built using Docker.

Debugging containers on containerd nodes

For debugging or troubleshooting on Linux nodes, you can interact withcontainerd using the portable command-line tool built for Kubernetes containerruntimes:crictl.crictl supports common functionalities to view containersand images, read logs, and execute commands in the containers. Refer to thecrictl user guidefor the complete set of supported features and usage information.

For Windows Server nodes, the containerd daemon runs as a Windows servicenamedcontainerd.

Logs are available as follows:

• Windows:C:\etc\kubernetes\logs\containerd.log
• Linux: runjournalctl -u containerd

You can also view logs for Windows and Linux nodes inLogs ExplorerunderLOG NAME: "container-runtime".

Known issues and troubleshooting

For troubleshooting and for known issues with workarounds, refer toTroubleshooting the container runtime.

What's next

• Learn more about the containerd integration in theKubernetes 1.11 announcement.For even more information, visit the documentation forcontainerdand theCRI plugins.
• Review the migration from Dockershim information onkubernetes.io.
• Read aboutDockershim deprecation by Kubernetes.
• Learn how you can secure your apps withgVisoron containerd.
• Read about the benefits of usingCloud Build to buildimages securely and reliably on Google Cloud to replace a custom solutionthat might require Docker.
• Customize your containerd configuration in GKE nodes.