While Docker had been for the longest time the name you are most probably to hear when ever the discussion of containers run time come up, lately containerd has becoming so popular that you are hearing it just as often. The fun part which confuse many people is that containerd is used by Docker. The code that makes up containerd was originally part of the Docker Daemon but was abstracted from it to provide a more modular approach.

containerd is an OCI compliant core container runtime designed to be embedded into larger systems such as Kubernetes. It provides the minimum set of functionality to execute containers and manages images on a node. It was initiated by Docker Inc. and donated later to CNCF. The Docker engine itself is built on top of containerd.

It is important to note though that Docker includes many more projects than just containerd, which is the reason behind it providing many features beyond what containerd provider on it’s own. For example containerd doesn’t have Docker’s network management features, it lack the management capabilities for volumes for persistent data, nor the capabilities to interact/customize container logging among other features that Docker provides.

I am sure by now you have the question running through your  head, if it’s missing all of these nice and important features, why it is becoming popular. Why many companies are adopting it and why it’s all over the internet. In short, thanks to Kubernetes popularity!  As the idea for Kubernetes is that the container runtime doesn’t need all of the features of Docker, as Kubernetes or other components (like the CNI) provide it. Hence it makes sense to just use the required features, which containerd can provide. Not to mention the smaller scope of containerd in this case make it a lighter option that save you quite a bit on resources, while getting all the features to run an efficient Kubernetes environment.