Jan 22, 2018
A Foray into the World of Containerd
Overview
Docker announced the separation of Containerd from Docker Engine on December 14, 2016, and donated Containerd to a new open-source community for independent development and operation. This announcement took place in a globally publicized event that focused on the industry-standard container designed for simplicity, robustness, and portability during runtime.
After this move, Containerd can run as a daemon on Linux and Windows to manage the lifecycle of all containers on the machine. Alibaba Cloud, AWS, Google, IBM, and Microsoft, as initial members, will contribute to the project and provide maintenance personnel.
While Containerd may sound a little unfamiliar to many people, Docker announced this open-sourcing project with great fanfare. This announcement received an overwhelmingly positive response from the industry.
In fact, Docker 1.11 Docker Engine contained Containerd as early as March 2016. At that time, Containerd completely divested from the Docker Engine as an independent open-source project for independent development. The goal was to provide more open and stable infrastructure to run containers. Compared to its original version within the Docker Engine, the independent Containerd will have more functionalities to cover all management needs throughout the container runtime.
Containerd is not oriented to the end user directly but exists for integration into upper systems such as Swarm, Kubernetes, Mesos, and other container orchestration systems. Containerd runs on the system in the form of a daemon and exposes the low-layer gRPC APIs through the UNIX domain docket. Upper systems can manage containers on the machine through these APIs. Each Containerd is responsible for one machine. Containerd performs Image pulls, operations on containers (start, stop), networks, and storage. Specific running containers are the responsibility of runC. In fact, it comprehensively supports all OCI-compliant containers.
This is a step ahead for the community and the Docker ecosystem. For Docker community developers, the independent Containerd is simpler and clearer, and it is easier to add new features based on Containerd.
For the container orchestration service, runtime only requires Containerd + runC, which is more lightweight and easier to manage. The feature evolution of the independent Containerd can be separated from the Docker Engine to focus on the runtime container management, making it more stable. The future compatibility can be also be improved since it provides one year of support after the first official version of Containerd, 1.0 Release. It includes security updates and bug fixes, and a small version will be compatible with each upgrade.
To show its sincerity for the community and ecosystem, Docker specifically stressed the neutral status of Containerd, which is in line with the interests of all parties. The community envisions Containerd as an important component of the Docker platform. Alibaba Cloud, AWS, Google, IBM, and Microsoft will be involved in the development of Containerd.
To better understand the functionality and architecture of Containerd, let us explore it from a more detailed point of view.
Architecture
The image above is the Containerd architecture chart. The middle layer contains three subsystems where we see the capabilities that Containerd supports.
● Distribution: The subsystem that interacts with Docker Registry to pull images.
● Bundle: The subsystem that manages images on ephemeral disks.
● Runtime: The subsystem that creates and manages containers.
We can see that container is clean and only provides features needed during the runtime.
Features and Route Map
● Support OCI images
● Support OCI running (runC)
● Support image pulls/pushes
● Container runtime and lifecycle management
● Network primitives: create/edit/delete interfaces
● Add containers into existing network namespaces
● Support global multi-tenant sharing of images using “content addressable” storage
The current version of Containerd is 0.2.4, a subset of features stripped from Docker Engine. When the updated features cover the previous list of features, the Containerd version updates to 1.0. It ensures API stability with the provision of one year of LTS.
Relationship between Containerd and Docker Engine
Docker Engine includes Containerd, which is focused on runtime container management. In addition to container management, Docker can complete image build and other features.
The APIs provided by Containerd are present on the bottom layer and not intended for direct use by general users, as general users can continue using Docker. Developers of the container orchestration system need Containerd, such as the Alibaba Cloud Container Service team.
Relationship between Containerd, OCI, and runC
OCI is a standardized container specification, which includes runtime specifications and image specifications. runC is a reference implementation based on this specification and Docker contributes the main code for runC.
From the technical stack perspective, the level of Containerd is higher than that of runC. Containerd can use runC to start the container, as well as to download the image and manage the network.
Relationship between Containerd and the Container Orchestration System
In the figure below we can see the position of Containerd in the container technology ecology. For the open-source orchestration systems, Kubernetes now adopts Docker directly, and future versions may switch to using Containerd. Mesos and other orchestration engines can use Containerd instead of using Docker directly.
For cloud computing developers, it is very convenient to provide customized container networks, container storage and orchestration solutions based on Containerd.
Conclusion
Containerd aims to provide a more open and stable running infrastructure for containers. It allows the end-users to enjoy benefits from a stable and well-supported container infrastructure. Additionally, several vendors can utilize Containerd as a standardized, flexible container-operating layer, to provide customized network, storage, and container orchestration solutions conveniently. This constitutes the significance of building an open and healthy container ecosystem.
Reference:
