What is containerd? Comparison with Docker

Docker and its History

Offered as a PaaS solution, Docker came into being in 2013 as an all-inclusive resource that developers must refer to while building and running containers. Its main job was to bring containers into action using OS-level virtualization.

After the initial release, Docker launched its first version in 2014. However, it was reported that end-users weren’t happy with its security that was bogged down because of Docker daemon. 

Container orchestration on the cloud with Docker was also a major issue to deal with. The alternative solution showed up in the form of Kubernetes which was created by a few skilled Google developers. K8s simplified the containerized workload across the huge machine network.

Kubernetes also needed Docker-container interactions and depended on functional containers to deliver its operations. Later, a few additions were made in Docker. For instance, Dockershim was launched to overcome the less friendliness of Kubernetes. Going ahead, we received Swarm as a Kubernetes substitute making container orchestration possible.

Considering the surged market penetration and demand, Docker released Docker Enterprise Edition (EE). This edition was targeting organizations seeking flexible deployment. As a growth strategy, Docker then released Containerd, a container-runtime resource, and donated to CNCF that further opened it up for the entire developer community. 

What is containerd? 

To begin with, it was developed by Docker as a container runtime. It’s responsible for handling the container life cycle in both virtual and physical environments. Everything related to containers’ existence like their construction, functionality starting or stopping, and construction is handled by it.

Its functionality extends with:

• Fetching the relevant container images from relevant registries
• Mounting container storage as demand increases or decreases
• Adding networking efficiency to the respective container

As explained previously in the post, containerd become a part of CNCF and become a peer of CoreDNS, Envoy, and other resources.

The advent of containerd was a game-changer for k8s as it permits them to have a hold over mission-critical low-level Docker elements. With k8s containerd, it doesn’t require the use of Docker for container-runtime.

‍

Containerd vs Docker

You may be confused about Docker containerd as these 2 terms are closely-linked. So, let us clarify.

• Docker is a means to run or manage containers. It supplies every possible technical aid or required resource for this task.  
• Containerd is Docker-based. In Docker’s case, it’s the runtime of a container. However, it can also be used independently.

‍

Role of the Containerd

In Kubernetes and otherwise, containerd is not more than a crisp abstraction of multiple Linux kernel features demanding syscalls for the set-up.

As a container resource, it drops at the low-level wiring level and works as a client layer. While working as a client layer, it allows container software to build over it.    

Its use simplifies Kubernetes' use. In the beginning stage, Kubernetes development was mainly relying upon two choices. The first one was constant shim writing in and around the Docker interface. The second approach we had was constantly interacting with relevant Linux kernel features. 

Both these approaches were too confusing and tedious. When Docker disintegrated containerd, the development world had a new k8s development approach that was using containerd shim at a system abstraction layer. This approach, by adding kubernetes containerd to the process, kept Docker's involvement as less as possible.

‍

The OCI 

The acronym of Open Container Initiative, OCI is the governing body handling everything related to defining the container standards and deciding how a container must look and behave in real life. The globally-recognized specifications define a highly functional interface for the effective working of containers.

Containerd is mainly based on OCI as it follows the OCI specifications rigorously. The key purpose of OCI here is to support container usage. It makes sure that the concerned images are accessible by any concerned platform with any contradictory disagreements.

‍

Containerd vs CRI vs CRIO vs RUNC 

Containerd is not the only container element to be concerned about. There are other closely-knit elements as well. Next, we’re going to provide you with a close comparison of a few key container terms.

CRI-O: Though a container runtime just like containerd, it doesn’t have complex Linux capabilities. Hence, its attack surface is reduced. Also, containerd is OS-level based while CRI-O is OCI compatible implementation of CRI.

CRI or Container Runtime Interface: It is the API that helps k8s gain full control over container runtimes. It’s the containerd CRI that enables Kubernetes to communicate with all the possible runtimes. Unlike Containerd, CRI will need additional support in order to behave like an actual container runtime.

Runs: Contrary to containerd, which is a high-level runtime, runs at low-level and acts like a resource offering functional capabilities. For instance, namespace management or communicating with Linux kernel features.

containerd Features 

• The client deploys containerd in the desired ecosystem. This library can run on the cloud or locally.
• Use namespaces to separate the container groups that are hosted on one host to avoid overlapping and confusion. It makes using two containerd containers having identical names.
• Containers, the most important feature, is the metadata object that permits filesystems, container images, and OCI runtimes to pair with it for further processing.
• Useful to expand the capabilities of containerd, the snapshot plugin feature takes the help of GRPC to add any external plugin.
• OCI runtime specification feature is used to have standardized mannerism that every container runtime has to behave.

‍

containerd Security Best Practices

As cloud deployment increases, the risks involved have also swelled up. The use of containers has increased the security complexity of the cloud ecosystem. Those who’re planning to use K8 containerd must play extra smart and adopt the security strategy for their product.    

Even if containerd doesn’t use SSH or containerd CLI interface, it bears high-security risk as anyone can gain access to (or control over) containerd socket file. After this, it is very easy to download elements like nerdctl or crictl for the threat actor.

Containerd has a wide attack surface because of 

• Its Linux abilities 
• The Use of Docker Engine (For instance, non-protected or authorized container images might feature malicious elements or hackers can easily reveal the hard-coded secrets that image might feature.)

Thankfully, there are ways to shrink the containerd attack surface. Let’s have a look at the best options. 

• Avoid running containers as root
• Keep the containerd privilege as minimum as possible
• Scan images prior to using them
• Check the image security & integrity before you use them
• It’s wise to use a secured container image version
• Never leave image secrets without any encryption  
• Constantly update the containerd version to avoid security flaws

Conclusion  

With containerd, Docker's capabilities are simplified, Kubernetes is empowered, and containers are empowered. However, it has a vast attack surface and prospective users must learn to deal with them. Practices like verifying image secrets, updating containerd, and others that we've shared are of great help.