Deciphering containerd
Ever since the ascent of containers, Docker has been valued as the most preferred container management tool. But as the technology evolved, the industry players realized that there was a need for customization in the Docker architecture to allow vendors to build things their way. The Docker team has been constantly trying to evolve its offerings to make the platform more composable so that individual components can be spun off and used by other vendors developing alternative solutions. As a part of this initiative, Docker donated their core container runtime - containerd to CNCF and made it open source with the sole objective that it would get adopted by cloud service providers and container orchestrators as their default runtime. Now, this has helped improve the compatibility between Docker and the ecosystem of other container vendors as it allowed them to just take the core functionality of the Docker engine and then freely go on to build and manage the higher-level tasks as per their custom design.
The container runtime facilitates core primitives to manage containers such as container supervision and execution, image transfers, network interface management, native plumbing level API, complete storage, and distribution system for supporting OCI & Docker image formats, event management, and snapshot model to manage container file systems.
Containerd is one such OCI compliant core container runtime which is designed specifically to be embedded independently into larger systems as it provides the minimum set of functionalities (lightweight) necessary to execute containers and manage images on a node as compared to a full-featured Docker-based deployment. The smaller set of features and slower feature velocity results in a smaller codebase for the container runtime and that makes it easier to maintain and support over time.
Containerd was introduced as a component of Docker 1.11 and is used to manage runC containers on the node. It creates a containerd-shim for each container which manages the lifecycle of its corresponding container, as shown in the following image -
Some of the key features of containerd which make it irreplaceable for container aficionados are:
- Runc Integration
- Multiple runtime support
- Execution v2
- Decoupled Execution from Filesystem
- Daemonless containers
- Cleaner Development
- Support for OCI Runtime Spec and Image Spec.
Containerd for Kubernetes:
Pluggability has played a major part in Kubernetes' successful journey so far, and the Kubenauts community has ensured that many layers, including storage, networking, and schedulers can be replaced with custom implementations without hampering the user experience. In December 2016, the Kubernetes team launched the API for the Container Runtime Interface (CRI), which changed the way a container is run on Kubernetes drastically and made it customizable, rather than having users continue using Docker or rkt with Kubernetes in a non-customizable manner. CRI consists of protocol buffers and gRPC API, and libraries, with additional specifications and tools under active development. The CRI exposes an interface that lets any container runtime to plug into the Kubernetes system without the need to re-compile. This allows users to select Kubernetes as an orchestrator for their non-Docker or non-rkt infrastructure, too thus freeing the users from depending on traditional tie-ins on Docker/rkt.
CRI-containerd is an implementation of CRI for containerd for its integration with Kubernetes. It works on the same node along with the Kubelet and containerd. Positioned between Kubernetes and containerd, CRI-containerd handles all CRI service requests from the Kubelet and uses containerd to manage containers and container images. CRI-containerd creates containerd service requests for every service request coming from the Kubelet while adding additional functions to support the CRI requirements.
In comparison with the latest Docker CRI implementation ( target="_blank">dockershim), cri-containerd eliminates the additional hop in the stack, thus making the stack even more stable and efficient. Currently, though, the standalone cri-containerd binary is at end-of-life and has transitioned from a standalone binary that talks to containerd to a plugin contained within containerd in the latest release of containerd 1.1.0.
Containerd 1.1.0 introduced on April 24, which is the second major release, has many enhancements other than the CRI plugin. These include improvements to the ctr tool, support for multiple platforms, cross namespace content sharing, ZFS, AUFS, a native snapshotter tool, and many more. Apart from these enhancements, v1.1.0 offers significantly improved pod start latency and CPU/memory usage of the CRI plugin in terms of performance.
As of today, containerd usage continues to grow to find applications in many upstream projects like Moby, Linux Kit, Kubernetes, etc. and with the increased interest from many container orchestration platforms, we can expect lots of developments around containerd. But for now, we can surely say that containerd is here to stay and will continue to provide stiff competition to other technologies in the same space.
