When we talk about container runtime, we immediately think about Docker. Docker was the original container runtime; at the very least, it was the runtime that triggered the cloud boom that we are experiencing today. Docker allows virtualization to be far more robust and scalable by running containers and freeing developers from conventional cloud infrastructure limitations.
Docker also allows for the entire cloud architecture to be managed in a seamless way. It automates a lot of things about deploying cloud-native applications, from configuring the shared operating system components to making it straightforward for developers to package applications with all of its dependencies and libraries for smooth and universal deployment.
Docker, however, is a container runtime, which means it is complex by nature. To stay true to its mission to simplify cloud architecture management, Docker started separating components and functions. Containerd was introduced in Docker 1.11, and the container runtime—or container tool, to be precise—has now matured to stand on its own.
Getting to Know Containerd
As mentioned before, Containerd started life as a tool that is a part of the Docker open source project. Containerd works really well with components such Kubelet. In fact, Containerd handles image management and worked alongside runc to construct the container runtime that we are so used to using.
Containerd, however, has graduated into its own high-level container runtime. On February 28, 2019, Containerd graduated as a project within the Cloud Native Computing Foundation, which placed this tool alongside Kubernetes, CoreDNS, and Prometheus. The support of thousands of developers behind Containerd made it possible.
As a high-level container runtime, Containerd no longer requires Docker to run properly. It can now run on its own, with runc being its low-level container runtime. When used to deploy and manage Kubernetes, you can see Containerd as replacing Docker and Docker-shim with CRI-Containerd. Containerd has a few tricks up its sleeve too.
For starters, the high-level runtime is compatible with other low-level runtimes. You are not limited to using runc as your container runtime. You can also opt for tools such as kata-runtime to run containers. Containerd even supports running multiple container runtimes within the same environment.
Containerd works with both Linux and Windows and can handle on-premise and cloud hardware without a problem. Since Containerd completely abstracts syscalls or OS specific functionality, it is the perfect solution for running containers on top of any OSes it supports. Everything, from service discovery to netlink calls, is made simple.
What Makes Containerd Different
To really understand how Containerd has become an efficient tool and a capable container runtime that it is, we have to compare it against Docker. While Docker offers additional features through multiple components, Containerd is now a tool that specializes in three things: running images in containers, pushing and pulling images to the registry, and managing the images themselves.
Docker, on the other hand, handles building images and creating volumes. It also takes care of network plugins and overlay networks. Containerd simply abstracts all of those functionalities away, resulting in a very simple container runtime that gets you to the state that you want faster.
Containerd does offer some advantages. Since containers are almost entirely independent, you can upgrade and reboot the Docker daemon without restarting containers or bringing them down. The API offered by Containerd also makes managing the environment using Containerd a lot easier. You basically have control over everything through API calls.
Not having to work with syscalls is a benefit of its own. Also, the presence of runc is so that Containerd can still run Linux commands and processes, mainly for the purpose of supporting the containers running on top of it.
Complete Container Lifecycle Management
OCI image spec support and OCI runtime spec support—apparent from the use of runc—both make Containerd straightforward to work with. You know immediately that you can manage the lifecycle of containers from end to end without having to integrate additional tools or gain access to features you don’t really need.
Support for image push and pull is a useful tool. Everything you can do with Containerd can be done in a simple way. For, example, pulling an image is a simple cli “$ ctr image pull”.
There are plenty of ways to optimize your use of Containerd too, starting with making sure that a minimalist host operating system is in use. Containerd doesn’t add bulk to the underlying operating system—since it runs as a daemon—but you can boost the performance of the overall cloud environment by optimizing the ecosystem from the ground up.
Your choice of container runtime (low-level) is also important. Runc runs containers for you by default, but there are other container runtimes to choose from. With the client layer supporting Docker or Kubernetes, you will never have to go into kernel details. With Kubernetes specifically, Containerd can also be used as CRI runtime.
What must not be forgotten is the additional projects that can enhance Containerd and the environment it supports further. Containerd has a distribution controller, bundle controller, and runtime controller.
It is clear that Containerd is set up this way so the tool can offer maximum scalability without making running apps and microservices in containers too complicated.
Caylent provides a critical DevOps-as-a-Service function to high growth companies looking for expert support with Kubernetes, cloud security, cloud infrastructure, and CI/CD pipelines. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases, learn how we work with clients, and read more about our DevOps-as-a-Service offering.
