Containerd is an industry-standard container runtime and Docker’s core runtime component. Under the auspices of the Cloud Native Computing Foundation (CNCF), the Kubernetes and Docker communities began integrating the containerd project directly with Kubernetes in early 2017, and the effort was declared “ready for production use” earlier this year. Today, we are excited to announce the beta launch of containerd on Container-Optimized OS for Kubernetes Engine 1.11.
Containerd has several key qualities that make it a great fit for Kubernetes. First, containerd is designed to be embedded into a larger system, and has a small resource footprint, including a core feature set that can power a higher-level orchestration layer. The reduced surface also enhances its reliability and performance. Second, containerd’s modular architecture and plugin mechanisms make it easy to experiment with. We anticipate that many projects will be built on containerd, for example runtimes providing strong isolation boundary between pods. Last but not least, containerd enjoys a strong user base from Docker, and a healthy, diverse community of contributors from Docker, Google, IBM, as well as individuals.
Swapping out the container runtime in Google Kubernetes Engine (GKE) for containerd is largely painless because users interact with Kubernetes through its declarative API—the container runtime is simply one of the many building blocks. However, from time to time, developers or cluster administrators need lower-level container debugging tools. Previously, users would need to rely on container runtime-specific utilities for troubleshooting purposes. This is no longer the case. The Kubernetes community has a lightweight command-line tool,
crictl, that offers common functionality such as viewing and executing commands in containers.
crictlis built on top of Kubernetes’s Container Runtime Interface (CRI), and is portable across CRI-compatible runtimes. Starting with GKE 1.11, every new cluster launched or upgraded to 1.11 or newer will have nodes pre-installed with
crictl. We hope this will help ensure a consistent user experience regardless of the underlying container runtime that Kubernetes is using.
Going forward, the containerd integration will replace the existing Docker integration in both Container-Optimized OS and Ubuntu images in GKE. We encourage you to try out containerd and give us feedback!
Trying out containerd in GKE
Containerd on GKE is available as a new node image cos_containerd. The image is based on the Container-Optimized OS and enjoys the same security and performance benefits. Similar to any other image types, you can create a cluster or a node pool in an existing cluster using the new image type. Here’s a brief overview.
Warning: If your workload accesses Docker Engine on the Node directly, you may need to update it, or consult with the provider to ensure it is compatible with containerd. Please see the documentation for more information.
1. Create a GKE cluster with cos_containerd nodes
Here’s how to create a cluster with containerd as the container runtime for GKE 1.11 and above:
Alternatively, you can create a
cos_containerd node pool in an existing cluster:
2. Check if containerd is running on your nodes
First, you may need to get the cluster credential before using kubectl:
gcloud container clusters get-credentials CLUSTER_NAME
Then, once the cluster is up, you can run kubectl to view the nodes and see the containerd version reported in the output.
3. View containers on the node using crictl
To see the container close-up in action, SSH into the node and run the following command: