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.
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.
| 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:
| Supports:
| Supports:
| None |
| Node OS | Supports:
| Supports:
| Supports:
|
|
| Container engineer | containerd | Docker Engineer | 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:
| 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:
| Supports:
| Supports:
| 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 |
| 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 |
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 |
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.
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 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-
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.
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.
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-
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 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.
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
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.
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.
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.
Docker uses containerd as its runtime, so it is required for 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.
| Name | Date | Fee | Know more |
|---|
