Containerd node images

This page provides information about node images that use containerd as the container runtime in your Google Kubernetes Engine (GKE) nodes.

About containerd

The container runtime is software that is responsible for running containers, and abstracts container management for Kubernetes. There are a few different container runtimes.

The containerd runtime is an industry-standard container runtime that's supported by Kubernetes, and used by many other projects. The containerd runtime provides the layering abstraction that allows for the implementation of a rich set of features like gVisor and Image streaming to extend GKE functionality.

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

Using containerd images in GKE clusters

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

The following table describes the supported containerd node images based on your cluster mode and node pool OS:

Cluster mode Node pool OS Node image
Autopilot Linux cos_containerd
Standard Linux
  • cos_containerd
  • ubuntu_containerd
Standard Windows Server

These images require GKE version 1.21.1-gke.2200 or later.

Using privileged Pods to access Docker

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

Building container images with containerd

You cannot use containerd to build container images. Linux images with containerd include the Docker binary so that you can use Docker to build and push images. However, we don't recommend using individual containers and local nodes to run commands to build images.

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

Consider accomplishing these tasks using other services outside the scope of the individual container, such as Cloud Build, or use a tool such as kaniko to build images as a Kubernetes workload.

If none of these suggestions work for you, and you understand the risks, you can continue using Docker on the local node to build images. You must push the images 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 with containerd using the portable command-line tool built for Kubernetes container runtimes: crictl. crictl supports common functionalities to view containers and images, read logs, and execute commands in the containers. Refer to the crictl user guide for the complete set of supported features and usage information.

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

Logs are available as follows:

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

You can also view logs for Windows and Linux nodes in Logs Explorer under LOG NAME: "container-runtime".

Known issues and troubleshooting

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

What's next