Docker vs Containerd: Understanding the Differences and Choosing the Right Containerization Tool

What's the Difference Between Docker and ContainerD?

In this video, the speaker explains the difference between Docker and ContainerD, as well as the history behind Kubernetes and these container tools.

The Beginning of the Container Era

• Docker became the dominant container tool due to its user-friendly experience.

• Kubernetes was introduced to orchestrate Docker specifically.

• Initially, Kubernetes only worked with Docker and did not support other container solutions.

Introduction of Container Runtime Interface (CRI)

• As Kubernetes grew in popularity, other container runtimes like Rocket wanted to be supported.

• Kubernetes introduced CRI as an interface for different container runtimes.

• CRI allowed any vendor to work as a container runtime for Kubernetes if they adhered to OCI standards.

Docker's Role in CRI

• Docker was not built to support CRI standards since it predates them.

• However, Kubernetes had to continue supporting Docker due to its widespread use.

• A temporary solution called "Docker shim" was introduced to maintain compatibility with Docker outside of CRI.

Evolution of ContainerD

• ContainerD is a separate project within Docker that is now a member of CNCF with graduated status.

• It can be installed independently without installing full-fledged Docker.

Running Containers with ContainerD

• Once ContainerD is installed, it comes with a command-line tool called CTR for debugging purposes.

Removal of Docker from Kubernetes Support

This section explains why support for Docker was removed from Kubernetes and how existing images built by Docker still work with ContainerD.

Removing Support for Docker Shim

• Maintaining the docker shim added unnecessary effort and complications for Kubernetes.

• In version 1.24 release of Kubernetes, support for the docker shim was completely removed.

• Docker was no longer a supported runtime for Kubernetes.

Compatibility of Docker Images with ContainerD

• All images built by Docker follow the OCI image spec, allowing them to work with ContainerD.

• Existing Docker images continue to function with ContainerD even after Docker support is removed.

Understanding ContainerD

This section provides more details about ContainerD and its standalone capabilities.

Standalone Installation of ContainerD

• ContainerD can be installed separately without installing the full Docker package.

• If you don't require other features of Docker, you can choose to install only ContainerD.

Running Containers with CTR

• Once ContainerD is installed, it comes with a command-line tool called CTR for running containers and debugging purposes.

The transcript has been summarized in a clear and concise manner using timestamps when available.

Introduction to CTR and Nerd Control Tool

In this section, the speaker introduces the CTR (Containerd) command and the Nerd Control tool as alternatives to directly making API calls for container-related activities.

CTR Command

• The CTR command is used for basic container-related activities in Containerd.

• Examples include pulling images using CTR images pull.

• To run a container, use the CTR run command followed by the image address.

Nerd Control Tool

• The Nerd Control tool is recommended as a better alternative for running and managing containers on a production environment.

• It is similar to Docker CLI but specifically designed for Containerd.

• Supports most Docker commands and provides access to new features implemented into Containerd.

• Features include encrypted container images, lazy pulling of images, P2P image distribution, image signing and verifying, and namespaces in Kubernetes.

Introduction to CRI CTL

This section introduces CRI CTL (Container Runtime Interface Control), a command-line utility used to interact with CRI-compatible container runtimes from a Kubernetes perspective.

CRI CTL Utility

• CRI CTL is developed and maintained by the Kubernetes community.

• It works across different container runtimes such as Containerd, Rocket, etc.

• Used for inspecting and debugging container runtime from a Kubernetes perspective.

• Not intended for creating containers but mainly used as a debugging tool.

• Can perform basic container-related activities like pulling images or listing existing images using commands such as CRI CTL PS.

Comparison between Docker and CRI CTL

This section provides a comparison between Docker commands and their equivalents in the CRI CTL utility.

| Docker Command | Equivalent CRI CTL Command |

| --- | --- |

| attach | attach |

| exec | exec |

| images | images |

| info | info |

| inspect | inspect |

| logs | logs |

| PS | PS |

| stats | stats |

| version | version |

Many other commands work similarly in both Docker and CRI CTL utilities.

Overview of Runtimes and Control Utilities

In this section, the speaker discusses different runtimes and control utilities used in container management.

Runtimes and Control Utilities

• Container runtime control allows interaction with specific runtimes.

• By default, it connects to sockets in a specific order: Docker shim, containerd, cryo, and cryo Docker D.

• To override the default order and set a specific endpoint:

• Use the runtime endpoint option with the ctr command line.

• Set the container runtime endpoint environment variable to the desired endpoint.

Control Utilities for Container Management

• CTR command line utility:

• Comes with containerd.

• Used for debugging purposes only with limited features.

• Nerd control CLI:

• From the containerd community.

• Docker-like CLI for general-purpose container creation.

• Supports same or more features than local CLI.

• Cry control utility:

• From the Kubernetes community.

• Mainly used to interact with CRI-compatible runtimes (not just containerd).

• Comparison of utilities:

• CTR and cry control are mainly used for debugging purposes.

• Nerd control is used for general-purpose container management.

• CTR and nerd control are from the containerd community and work with containerd.

• Cry control is from the Kubernetes community and works across all CRI-compatible runtimes.

Usage in Labs

• Originally, Docker was installed on all nodes in our labs.