The Kubernetes community took the major step of basically replacing the 1.0 version of its Containerd container runtime interface (CRI) with a completely revamped 1.1 model.

The latest Containerd (pronounced “container-d”) 1.1 specification merges what was an extra step that was required with the 1.0 specification to eliminate a possible stability- and efficiency-impacting “hop.” Specifically, Containerd 1.1 integrates the previously external cri-containerd daemon and allows for the direct use of Kubernetes with Containerd 1.1.

A container runtime provides an API and tools that abstract low-level technical details in the container. A daemon is a program that runs in the background and is activated by a specific event.

In the 1.0 spec, the cri-containerd daemon was required to work with Kubernetes. That daemon was the CRI that dealt with service requests from the kubelet, which is the primary “node agent” that runs on each node, and used Containerd to manage containers and container images.

“The extra daemon in the loop made it more complex for users to understand and deploy, and introduced unnecessary communication overhead,” explained Google software engineer Lantao Liu and IBM open source developer advocate Mike Brown, in a blog post.

The pair stated that the updated platform posted lower pod startup latency and lower CPU and memory usage compared with the current Docker CRI iteration.

Containerd 1.1 does require the latest 1.10 version of Kubernetes that launched in March, and supports all of the container orchestrator’s features. It’s also backward compatible with the 1.0 specification. Both Containerd and Kubernetes are housed within the Cloud Native Computing Foundation (CNCF).

That initial 1.0 specification, coincidently, allowed for the removal of one hop compared with the often-used Docker CRI. The next version of Docker Consumer Edition (CE) will include Containerd 1.1, but users can continue to tap the Docker CRI for use cases not specific to Kubernetes. However, the 1.1 specification and the Docker CRI will be prohibited from accessing containers or images created by the other.

Docker Inc. last year donated Containerd to the CNCF. Containerd is part of the process required to construct a Docker container.

The latest Containerd 1.1 specification is also set as an enhanced alternative to other CRI options.

One of those is CRI-O, an integration path launched last year between Open Containers Initiative (OCI) conformant runtimes and Kubernetes kubelets. It’s designed to be used only by Kubernetes and is a Kubernetes incubator project.

CRI-O was designed as a “slimmer” alternative to other runtime options. Daniel Walsh, a consulting engineer at Red Hat, in a blog post on the CRI-O 1.0 release described it as being different from other runtime options by not attempting to do much.

“We did not want to pull all of the locking and container state into memory like some other container runtimes have, which prevents other processes on the system being able to work with images and storage,” he wrote. Walsh added that the smaller footprint allows for better Kubernetes performance compared with other container runtimes.

Chris Aniszczyk, vice president of developer programs at the Linux Foundation, noted that the development of open source CRIs allow them to “compete on features like performance while making sure everything is compatible. I think it's healthy.”