An introduction to one of the most popular container runtimes
Containerd - An industry-standard container runtime with an emphasis on simplicity, robustness and portability
The article covers the following topics:
- What is a Container?
- What is Conatinerd?
- History of Containerd
- Why do we need Containerd?
- Architecture of Containerd
- Is Containerd OS Specific?
- When to use Containerd versus a Virtual Machine?
- When to use Containerd versus Kubeadm?
Before understanding what Containerd is, how it started, why we need it, we must understand what a container is.
What is a Container?
If you have ever run into compatibility issues when running someone else's code or been unable to work with a specific github repository because you do not have the required dependencies, then a container is exactly what you need. It is basically a full-fledged unit of software that combines all of the code and required dependencies into one neat little package so that it may work reliably on any OS and environment, independent of the system itself. It is similar to a virtual machine in the tasks that it does, but it is a much better alternative due to its smaller hardware utilization (as it does not include operating system images) and its increased simplicity in the whole development process in DevOps.
Containers are defined as the follows:
"A container is a standard unit of software that packages up code and all its dependencies, so the application runs quickly and reliably from one computing environment to another."
Reference: virtual machine vs containers - Search (bing.com)
What is Containerd:
Now that we understand what a container is, let's begin our discussion about Containerd. Simply put, it is a container runtime. A container runtime is essentially a component that mounts the container and interacts with the OS Kernel to begin the 'containerization process'.
"Containerization is the packaging together of software code with all its necessary components like libraries, frameworks, and other dependencies so that they are isolated in their own container".
Reference: bing.com/images/search?view=detailV2&cc..
Containerd can be considered the middleman that runs below platforms such as Docker and Kubernetes, and runs above virtualization technologies such as runc, gVisor, and Firecracker. Containerd is an example of a resource manager that deals with artifacts that you would need to start a container. Its primary workings include talking to a registry, pulling the manifest, getting the configuration and the layers, unpacking, to name a few. Containerd supports several file systems. Containerd works by pulling in an image that needs to turn into a file system snapshot that can be used by the driver that you are using. All these resources mentioned, have metadata and dependencies, and containerd handles these for you.
It is open-source software present on GitHub that has 250 contributors and supports linux and windows and many other architectures (which we will discuss moving forward).
History of Conainterd:
Containerd was initially built up alongside Docker as a process supervisor that sat between the full docker runtime and runc, basically acting as a middle layer of abstraction between the two. Over the years, it has evolved from a simple container supervisor to a full-fledged runtime. While it does share ideas with Docker, the goal was to create a new codebase to come up with a cleaner API and better separation for the management of containers and images. Today conatinerd has registry interaction, container lifecycle management and more.
Why do we need Containerd:
Containerd is the most stable, best supported runtime for Kubernetes and most major cloud providers. For development, Docker and buildkit are highly integrated with containerd and use it to run containers and runtimes. Containerd is also the most memory efficient and stable, and it is being used in projects such as FAASD and IBM Cloud Functions for their kubernete offerings.
Containerd is an extremely stable runtime. For usage in processes, such as daemon and kubernetes, containerd ensures that those processes do not crash, and no data ever lost. It uses a very low amount of runtime resources, with a small container overhead and CPU usage. Finally, all files used by the system are accounted for and cleaned up by the garbage collector which means there are no leaking image artifacts or runaway processes.
Architecture of Containerd:
Reference: bing.com/images/search?view=detailV2&cc..
As a user of contained, the client is the first place as a user you will interact with, if you are building a system on top of containerd, the client is what you will be working with. Some of the core functionality that is associated with container runtime is implemented in the client. An example of this would be container management. Which prepares the container snapshots as well as starting individual container tasks. Image pulling is also completely implemented inside the client.
Is Containerd OS Specific?
Containerd is OS specific, or more accurately it is architecture specific so a containerd made in windows should technically not run on Linux, however due to the fact that Linux, Mac OS X (excluding the new M1 and M2 series), and Windows all run on x86 architecture, the containers will work due to the fact that it is a "simulated" cross platform.
When to use Containerd versus a Virtual Machine?
Virtual Machines:
They have been used for a long time, so a huge set of VM management and security tools are available which means that they are more well supported.
If we need to run multiple applications on a specific OS, multiple containers will have to be made, whilst on a VM one container will run all of the applications.
VMs emulate an entire OS environment, which is better for runtime tests and resource usage tests.
Containerd:
Contianerd is more lightweight than VMS, by an order of magnitude of almost 103 which allow for more efficient usage of storage resources
Containers are much faster, and they boot up in milliseconds as compared to VMs which take a long time to boot up and are much slower.
A single system cannot host many VMs at the same time as they are simulating a complete OS environment, whilst many containers can be run on the same system.
Summary and Key takeaways:
To conclude, Containerd is a versatile and well supported containerization solution for easy building, testing, and deployment of projects in DevOps, however it is not a one size fits all solution. Whether or not VMs will be better suited than Containerd is entirely up to our usage. If our goal is to for example deploy machine learning and AI applications into enterprises, these applications are very resource heavy and will favor VMS. However, if the goal is to deploy consumer side applications that require speed and scalability, Containerd is the clear winner.
Some key points for Containerd are:
Near instantaneous start-up time
Very nature of Containerd makes transient between hardware setups.
Makes it possible to create a snapshot of a filesystem to use in a container
Contains a client library that can run on both local or cloud systems
Subset of the original Docker system that has grown into a full fledge software with enough capabilities to be used on its own.
A powerful containerization software that manages the lifecycle of a container, a daemon process that creates, starts, stops, and destroys conatiners, is definitely a beloved within the CNCF (Cloud Native Computing Foundation) and Cloud Native communities.
Learning Resources:
youtube.com/channel/UC7B9fl8jQ8TEdOCypF4g3Wg
github.com/containerd/containerd
aquasec.com/cloud-native-academy/container-..
kubernetes.io/docs/setup/production-environ..
References:
containerd - An industry-standard container runtime with an emphasis on simplicity, robustness and portability
What is containerd? (aquasec.com)
Kaniko Dethroning Docker?. For the past couple of weeks, I have… | by Saif Sadiq | Sep, 2022 | Medium