Using Container-Optimized OS with containerd

This page provides additional information about using Container-Optimized OS with containerd (cos_containerd) on Google Kubernetes Engine (GKE) Nodes. The cos_containerd image provides access to the containerd CRI runtime environment.

Using cos_containerd images in GKE clusters

cos_containerd OS images are available as a Beta feature in GKE v1.11 and higher. You can select cos_containerd as the image type when creating a new GKE cluster, when creating a new Node Pool in an existing cluster, or when you upgrade an existing GKE cluster to v1.11 or higher.

During the beta period, we are gathering feedback from the customers.

Currently, cos_containerd is only available with Container-Optimized OS (COS) images.

Running docker commands on GKE Nodes

In GKE v1.11 and higher, Docker is a available on each Node, but containerd is the default runtime. However, since Docker does not manage Kubernetes containers on the Nodes, you cannot view or interact with your containers using Docker commands or the Docker API.

Troubleshooting containers on GKE Nodes

To inspect or troubleshoot your containers, use the pre-installed crictl instead.crictl is portable across all runtimes compliant with the Container Runtime Interface (CRI) specification. For GKE v1.11 and higher, crictl is the recommended tool to interact withcontainerd and Docker Engine. Visit the crictl user guide for more information.

Accessing Docker Engine from privileged Pods

Some users currently access Docker Engine on a Node from within privileged Pods. It is recommended that you update your workloads so that they do not rely on Docker directly. For example, if you currently extract application logs or monitoring data from Docker Engine, consider using GKE system add-ons for logging and monitoring instead.

Building images

containerd does not support building images, because the feature is not supported by Kubernetes itself.

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. For this reason, it is not recommended to run commands on local Nodes. Instead, 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 to build images. You need to push the images to a registry before attempting to use them in a GKE cluster. Kubernetes is not aware of locally-built images.

What's next?

You can learn more about the containerd integration in the Kubernetes 1.11 announcement. For even more information, visit the documentation for containerd and the CRI plugins.

Was this page helpful? Let us know how we did:

Send feedback about...

Kubernetes Engine