Docker vs Containerd: Container Runtimes Compared

Containers have taken the technology to another level. Every industry is leveraging container technology to develop and deploy its applications. With containers, you can securely and efficiently package, distribute, and run applications along with their dependencies. In such a way, you do not have to worry about the underlying infrastructure to run your applications.  

Containers have overtaken the VMs as containers are lightweight and do not require abstract physical resources. They can utilize the resources of the underlying system. But how do you manage and run containers?  

For this, you can find many container runtimes available. But the most commonly used are Docker and Containerd. Both runtimes have their pros and cons. Both the runtimes are widely adopted, but some focus on learning Docker online. You might have seen the primary usage of Docker with DevOps.  We have Containerd as the container runtime. In this article, we will discuss containerd vs. Docker. 

A Quick Overview of Docker and containerd’s History 

In 2013, the term container was introduced in the market that was started with Docker. Docker was the first container runtime. While on the other hand, Containerd was introduced as an alternative to Docker with its significant focus on simplicity, robustness, and portability.  

People often use the Docker runtime to pull genuine container images, create containers, manage the data center, and network. In contrast, the containerd uses the low-level engine to carry out similar tasks. In 2016, containerd separated from Docker to support other container ecosystems, such as Kubernetes, AWS Fargate, and Rancher.  

Docker vs containerd (Tabuluar Comparison)  

Comparison in terms of implementations and limits

Item	containerd	Docker	Sandboxed-Container	Description
Cluster type	Managed Kubernetes clusters, dedicated Kubernetes clusters and managed edge Kubernetes clusters	All types	Managed Kubernetes clusters and dedicated Kubernetes clusters	None
Node type	Supports:  ECS  EBM  User-owned nodes (Managed edge Kubernetes cluster)	Supports:	Supports:	None
Node OS	Supports:  CentOS  Alibaba Cloud Linux  ACK v1.20.4 version of Windows (Managed edge Kubernetes cluster)	Supports:  CentOS  Alibaba Cloud Linux  Windows	Supports:	You cannot deploy both Docker and Sandboxed-Container on a node.  To deploy both Docker and Sandboxed-Container in a cluster, you can create node pools of different runtime types.
Container engineer	containerd	Docker Enginer	containerd	None
Monitoring	Supported	Supported	Supported	None
Container log collection	Supported	Supported	Supports log collection by using sidecar containers. Manual configuration is required.	For more information about sidecar configurations, see Use CRDs to collect container text logs in Sidecar mode.
Container stdout collection	Supported	Supported	Supported	None
RuntimeClass	Not supported	Not supported	Supported (runV)	None
Pod scheduling	No configuration is required.	No configuration is required.	You must add configurations based on the following rules:  For Kubernetes 1.14.x, you must add the following configuration to the nodeSelector field.  alibabacloud.com/sandboxed-container: Sandboxed-Container.runv  For Kubernetes V1.16.x and later, no extra configuration is required.	None
HostNetwork	Supported	Supported	Not supported	None
exec/logs	Supported	Supported	Supported	None
Node data disk	Optional	Optional	Required. The data disk must be at least 200 GiB.	None
Network plug-in	Supports:  Flannel  Terway (Excluding managed edge Kubernetes cluster)	Supports:	Supports:  Flannel  Terway: supports only the inclusive ENI mode.	None
kube-proxy mode	Supports:	Supports:	Supports:	None
Volume plug-in	CSI (Excluding managed edge Kubernetes cluster)	CSI	CSI	None
Container root file system	OverlayFS	OverlayFS	DeviceMapper	None

Comparison in Terms of Deployment Architectures

Runtime	Deployment architecture
Docker	kubelet -> dockerd -> containerd -> containerd-shim -> runC containers
containerd	kubelet -> containerd -> containerd-shim -> runC containers
Sandboxed-Container V2	kubelet -> (CRI)containerd                           -> containerd-shim -> runC containers                           -> containerd-shim-rund-v2 -> runV sandboxed containers

Comparison of the commonly used commands provided by Docker Engine and containerd 

Docker uses Docker Engine for container lifecycle management. Sandboxed-Container uses containerd for container lifecycle management. These tools provide different commands that can be used to manage images and containers. The following table describes the commonly used commands provided by Docker Engine and containerd. 

Description	Docker	Containerd
	docker	crictl (recommended)	ctr
Queries containers.	docker ps	crictl ps	ctr -n k8s.io c ls
Queries information about one or more containers.	docker inspect	crictl inspect	ctr -n k8s.io c info
Queries container logs.	docker logs	crictl logs	N/A
Runs a command in a container.	docker exec	crictl exec	N/A
Attaches to a container.	docker attach	crictl attach	N/A
Queries resource usage statistics.	docker stats	crictl stats	N/A
Creates a container.	docker create	crictl create
Starts one or more containers.	docker start	crictl start
Stops one or more containers.	docker stop	crictl stop	N/A
Removes one or more containers.	docker rm	crictl rm
Queries images.	docker images	crictl images
Queries information about one or more images.	docker inspect	crictl inspecti	N/A
Pulls an image.	docker pull	crictl pull
Pushes an image.	docker push	N/A
Removes one or more images.	docker rmi	crictl rmi
Queries pods.	N/A	crictl pods	N/A
Queries information about one or more pods.	N/A	crictl inspectp	N/A
Starts a new pod.	N/A	crictl runp	N/A
Stops one or more pods	N/A	crictl stopp	N/A

A Deep Dive Into containerd

Docker consists of several different features that build up the container environment. Where the containerd is at its core, allowing you to allocate resources.

Containerd can do the following tasks. 

• It takes a tap on the resources being allocated to the containers. 
• It is capable of isolating the processes within containers from the host processes. 
• You can extract any container image into any host, processing them within an isolated space so there will be no interference with any other container file.  
• It lets you create a UID namespace within containers that can easily be mapped to different UID on the host system. 
• It lets you set up environmental variables in any specific container.  
• You can even add or delete any Linux capabilities while starting a container. 

However, the usage of Containerd is not limited to the above points. Once you start using it, you will get a chance to explore. 

CRI, runc, and CRI-O

CRI stands for container runtime interface, allowing and supporting Kubernetes to run containers efficiently using various types of runtime, but that runtime should be able to support CRI. It is the standard protocol that Kubernetes use for controlling or managing the different runtimes for creating and managing containers. 

CRI acts as an abstraction for another container runtime. Thus, CRI makes it easier for Kubernetes to use any type of container runtimes.  

CRI uses runc (low-level runtime) for implementing the interface. It is beneficial for providing all the low-level functionalities required by the containers to work with the Linux operating system. 

CRI-O is a high-level container runtime that implements the CRI, making it suitable to be used by Kubernetes. You can use CRI-O as an alternative to containerd. It lets the developers pull the desired container images from registries, manage them on disk, and allow you to launch a lower-level runtime for executing the container processes. 

runc is a container runtime that is compatible with OCI. It implements the OCI specification. 

runc is also referred to as reference implementation of OCI. 

It offers all the low-level functionality you can do with the containers. Not only this, it lets you interact with existing low-level Linux features, such as namespaces and control groups. It uses these essential features for developing and executing container processes. 

Below are some alternatives to runc- 

• crun is a container runtime written in C. 
• kata-runtime implements the OCI specification as individual lightweight VMs. 
• gVisor from Google lets you create containers with a dedicated kernel.  

Networking

The significant difference between Docker and containerd is that containerd cannot manage complex networking configurations.  

But, if you want to manage simple networking, you need to tell the containerd for using the host networking. So, for managing more challenging container networking business requirements, you need to create the network namespace using the Container Network Interface (CNI) and link that to your containers. 

To get in-depth knowledge of how both works together, you must go through the best DevOps courses online. 

Calling containerd Directly

You can simply call the containerd directly. You should use the “ctr” command from the command line tool. This command helps you to pull and push the required images from the OCI-compliant repositories, such as Docker Hub. 

You can run commands that follow. 

ctr image pull Docker.io/library/nginx:latest 

The above command will help you to extract the NGINX image and put it into an isolated part of the host file system.  

Then you can run the following command to create and attach the required namespaces to begin the process. 

ctr run --net-host Docker.io/library/nginx:latest Nginx 

After running it, you will get the following page.  

A Deep Dive Into Docker

Docker is another popular container runtime that uses containerd as an internal runtime. But, the Docker container is easier to manage and run the same tasks as the containerd to get better and more efficient results.  

Docker has made it easier for developers to create, run, test, and deploy applications. It lets you build images as well. In the next section, we will see how you can run containers on the Docker server and create images using Docker CLI.

You can install Docker on any system with different tools for building and running containers. docker comes with a CLI where you can run simple commands for creating container images, pulling images from the repo, and managing containers.  

For a Docker to complete all these tasks successfully, it consists of- 

• Docker-cli is a command line utility allowing you to interact with Docker. 
• containerd, docker daemon process that manages the containers to run efficiently.  
• runc is a low-level runtime. 

Using Docker CLI to Run Containers and Build Images

Unlike containerd, Docker can automatically download the required images from its repo if the command does not find the image locally.  

Another important thing to notice is that Docker names all the containers uniquely at startup, making it easier for everyone to locate a specific container.  

In the case of Docker, you can run the following command from the command-line tool to run the Nginx container.  

For creating new images using Docker, you need to use the Dockerfile. To create a customized image for the NGINX web server, create an index.html file with the following code.  

<!DOCTYPE html> 
<html> 
  <head> 
    <title>My Welcome page!</title> 
  <style> 
html { color-scheme: light dark; } 
body { width: 35em; margin: 0 auto; 
font-family: Tahoma, Verdana, Arial, sans-serif; } 
    </style> 
  </head> 
  <body> 
    <h1>My welcome page!</h1> 
    <p>successfully updated the nginx welcome page.</p> 
  </body> 
</html> 

Now, create a Dockerfile as follows. 

COPY index.html /usr/share/nginx/html/index.html 

Docker build -t mynginx:latest. 

Docker run -p 80:80 mynginx: latest 

You will get the following page. 

Docker Networking H3 

Docker has built-in drivers for offering network functionality. 

• A bridge (default network driver) allows you to access the host network without any ingress access from outside. 

• Host- specifies the host’s networking configuration. 

• Overlay- it connects several hosts in a Docker swarm allowing different containers to communicate with each other while running on different hosts. 

• Macvlan- it assigns a MAC address to a container. 

Docker Compose  

It lets you create and run applications in multiple containers. With Docker Compose, you must create a YAML file to define the containers. 

Below is a simple Compose file for a LAMP stack: 

services: 

  apache: 
    build: './apache' 
    restart: always 
    ports: 
      - 80:80 
      - 443:443 
    networks: 
      - frontend 
      - backend 
    volumes: 
      - ./public_html:/usr/local/apache2/htdocs 
      - ./cert/:/usr/local/apache2/cert/ 
    depends_on: 
      - php 
      - mysql 
  php: 
    build: './php' 
    restart: always 
    networks: 
      - backend 
    volumes: 
      - ./public_html:/usr/local/apache2/htdocs 
      - ./tmp:/usr/local/tmp 
  mysql: 
    build: './mysql' 
    restart: always 
    networks: 
      - backend 
    volumes: 
      - ./database:/var/lib/mysql 

Think Complementary, Not Competitive

A Docker is more suitable for a production setup from the developer’s perspective. Docker is easier to learn and get along even with beginners. With Docker, you can leverage many features and functionalities that will make your work easier.  

If you are managing production workload, you might require Docker over containerd.  

Conclusion

Today, Docker runtime vs containerd is a great debate. But now you know which one wins the developer’s heart and trust. 

Choosing the right runtime environment for managing containers can be challenging. But it is up to you and your business requirements, which runtime suits well.  

Both Docker and containerd have their standards and way of using them. The containerd is a lightweight container runtime for catering to limited-resource computing environments. But, it is considered less as it does not have an intuitive interface allowing users to create images, making it less suitable for the development process. 

There is a significant difference between Docker and containerd, so you cannot use one another as an alternative to each other. 

Thus, people use Docker to create, test, and execute their containers. If you want to learn more about Docker, you can go for the best way to learn Docker and Kubernetes.  

Frequently Asked Questions (FAQs) 

1. Does containerd replace Docker?

It might not be possible as containerd cannot suffice your requirements to build images that you can do with Docker. If you want to use containerd, you still have to use Docker for some tasks, which is impossible with containerd. 

2. Is containerd required for Docker?

Docker uses containerd as its runtime, so it is required for Docker. 

3. Is Kubernetes dropping Docker?

Kubernetes can efficiently and quickly work with any container runtimes with a standard known as the Container Runtime Interface (CRI). It ensures a standard communication between Kubernetes and the container runtime. 

But, Docker did not implement the CRI. earlier due to the shortage of genuine options Kubenernetes was using Docker. But, as the number of runtime options is increasing in implementing the CRI, Kubernetes is dropping support for Docker.