This page provides additional information about using
Container-Optimized OS with containerd (cos_containerd
)
and
Ubuntu with containerd (ubuntu_containerd
)
on Google Kubernetes Engine (GKE) nodes. The cos_containerd
and ubuntu_containerd
images let you to use containerd
as the container
runtime in your GKE cluster.
Using containerd images in GKE clusters
You can select cos_containerd
or ubuntu_containerd
as the image type when
you create a new GKE cluster, create a new Node Pool in
an existing cluster, or when you upgrade an existing GKE
cluster. Both containerd images require v1.14.3 or higher.
Running docker
commands on containerd nodes
Docker is still available on each containerd Node, but Kubernetes uses containerd as the container runtime. 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 containerd 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. 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.