Docker vs Containerd: Container Runtimes Compared

Read it in 14 Mins

Published
25th Jan, 2023
Views
11,793
Docker vs Containerd: Container Runtimes Compared

Containers have taken cloud 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 these are lightweight and do not require abstract physical resources. They can utilize the resources of the underlying system. But to choose the right container for your business needs, you need to conduct a comparative study of Docker vs containerd, and this blog does exactly the same for you.

Just like Docker and Containerd, there are many container runtimes available. But the most commonly used are Docker and Containerd. Both runtimes have their pros and cons and are widely adopted. As a result, businesses today encourage their IT engineers and developers for learning Docker online. In this article, we will discuss containerd vs Docker based on factors like cluster, Node type, monitoring, pos scheduling, plug-ins, and more. Let us start with a head-to-head comparison of the best container runtimes available today.

Docker and containerd: Quick Overview of Their 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 Head-to-head Comparison

Comparison in terms of implementations and limits

ItemcontainerdDockerSandboxed-ContainerDescription
Cluster typeManaged Kubernetes clusters, dedicated Kubernetes clusters and managed edge Kubernetes clustersAll typesManaged Kubernetes clusters and dedicated Kubernetes clustersNone
Node type

Supports: 


Supports: 

  • ECS 
  • EBM

Supports: 

  • EBM 


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: 

  • Alibaba Cloud Linux Customized Edition 


  • 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 engineercontainerdDocker EngineercontainerdNone
MonitoringSupportedSupportedSupportedNone
Container log collectionSupportedSupportedSupports 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 collectionSupportedSupportedSupportedNone
RuntimeClassNot supportedNot supportedSupported (runV)None
Pod schedulingNo 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
HostNetworkSupportedSupportedNot supportedNone
exec/logsSupportedSupportedSupportedNone
Node data diskOptionalOptionalRequired. The data disk must be at least 200 GiB.None
Network plug-in

Supports: 


Supports: 

  • Flannel 
  • Terway

Supports: 

  • Flannel 
  • Terway: supports only the inclusive ENI mode. 

None
kube-proxy mode

Supports: 

  • Iptables 
  • IPVS

Supports: 

  • Iptables 
  • IPVS 

Supports: 

  • Iptables 
  • IPVS 

None
Volume plug-inCSI (Excluding managed edge Kubernetes cluster)CSICSINone
Container root file systemOverlayFSOverlayFSDeviceMapperNone

Comparison in Terms of Deployment Architectures

RuntimeDeployment architecture
Dockerkubelet -> dockerd -> containerd -> containerd-shim -> runC containers
containerdkubelet -> containerd -> containerd-shim -> runC containers
Sandboxed-Container V2kubelet -> (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. 

DescriptionDockerContainerd

dockercrictl (recommended)
ctr
Queries containers.docker pscrictl psctr -n k8s.io c ls
Queries information about one or more containers.docker inspectcrictl inspectctr -n k8s.io c info
Queries container logs.docker logscrictl logsN/A
Runs a command in a container.docker execcrictl execN/A
Attaches to a container.docker attachcrictl attachN/A
Queries resource usage statistics.docker statscrictl statsN/A
Creates a container.docker createcrictl create
Starts one or more containers.docker startcrictl start
Stops one or more containers.docker stopcrictl stopN/A
Removes one or more containers.docker rmcrictl rm
Queries images.docker imagescrictl images
Queries information about one or more images.docker inspectcrictl inspectiN/A
Pulls an image.docker pullcrictl pull
Pushes an image.docker pushN/A
Removes one or more images.docker rmicrictl rmi
Queries pods.N/Acrictl podsN/A
Queries information about one or more pods.N/Acrictl inspectpN/A
Starts a new pod.N/Acrictl runpN/A
Stops one or more podsN/Acrictl stoppN/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. 

  • FROM nginx:latest 

COPY index.html /usr/share/nginx/html/index.html 
  • For creating the Docker image, use the following command 

Docker build -t mynginx:latest. 
  • For running the locally built container image, hit the following command. 

Docker run -p 80:80 mynginx: latest 

You will get the following page. 

Docker Networking

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 a production workload, you might require Docker over containerd.  The containerd runtime is suitable for limited-resource computing environments or for use with container management systems like Kubernetes. You may not be able to use it for development purposes because of its basic interface and lack of ability to build images.

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 

Profile

Aashiya Mittal

Author

Aashiya has worked as a freelancer for multiple online platforms and clients across the globe. She has almost 4 years of experience in content creation and is known to deliver quality content. She is versed in SEO and relies heavily on her research capabilities.

Ready to Master the Skills that Drive Your Career?

Avail your free 1:1 mentorship session.

Select
Your Message (Optional)

Frequently Asked Questions (FAQs)

1Does 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. 

2Is containerd required for Docker?

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

3Is 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 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.