Docker vs Containerd Understanding: the Shift in Kubernetes 1.24+
If you're working with containers and Kubernetes, you've probably heard about Docker and containerd. In older blogs and documentation, Docker is often mentioned alongside Kubernetes. However, in newer content, you'll see containerd. So, what's the difference? And what tools should you be using? Let's dive into the history, differences, and the command-line tools associated with these container runtimes.
A Quick and Small History
In the early days of containers, Docker made it easy to work with containers. It became the go-to tool because it was simple and user-friendly. Kubernetes, which helps manage and orchestrate containers, was initially built to work specifically with Docker.
How Kubernetes use Docker
As Kubernetes became more popular, there was a need to support other container runtimes. To solve this, Kubernetes introduced the Container Runtime Interface (CRI). This interface allowed different container runtimes to work with Kubernetes as long as they followed the Open Container Initiative (OCI) standards. These standards define how container images should be built and how container runtimes should operate.
Docker, being older, wasn't designed to support CRI. To keep Docker working with Kubernetes, a temporary solution called Docker shim was introduced. This made things more complex, and maintaining it became a hassle.
Why Containerd for Kubernetes
Docker is more than just a container runtime; it includes various tools like the Docker CLI, Docker API, build tools, and more. Among these, containerd is the component that manages containers and follows CRI standards, making it compatible with Kubernetes.
With Kubernetes 1.24, the Docker shim was removed, ending direct support for Docker as a runtime. However, containerd continued to thrive as a standalone project and is now part of the CNCF (Cloud Native Computing Foundation).
Command-Line Tools for containerd
With Docker no longer directly supported, you need to get familiar with new command-line tools for managing containers. Here are the key tools:
1. ctr
The ctr
command-line tool comes with containerd. It's mainly for debugging and supports a limited set of features.
Basic ctr
Commands:
- List Containers:
ctr containers list
- List Images:
ctr images list
- Pull an Image:
ctr images pull docker.io/library/nginx:latest
- Run a Container:
ctr run -t --rm docker.io/library/nginx:latest mynginx
For more ctr
commands, check out the official containerd documentation.
2. nerdctl
nerdctl
is a Docker-like CLI for containerd, offering a user-friendly experience and supporting most Docker commands.
Basic nerdctl
Commands:
- Run a Container:
nerdctl run -d --name mynginx nginx
- List Containers:
nerdctl ps
- Pull an Image:
nerdctl pull redis
- View Logs:
nerdctl logs mynginx
You can learn more about nerdctl
on their GitHub page.
3. crictl
crictl
is a tool maintained by the Kubernetes community for interacting with CRI-compatible container runtimes. It's mainly for debugging and inspecting containers.
Basic crictl
Commands:
- List Containers:
crictl ps
- Pull an Image:
crictl pull redis
- Run a Command in a Container:
crictl exec -it <container-id> sh
- View Logs:
crictl logs <container-id>
- List Pods:
crictl pods
For more details, visit the CRI tools GitHub repository.
Transitioning from Docker to containerd
Here's a quick comparison of Docker commands with their nerdctl
and crictl
equivalents:
Docker Command | nerdctl Equivalent | crictl Equivalent |
---|---|---|
docker run |
nerdctl run |
crictl run |
docker ps |
nerdctl ps |
crictl ps |
docker pull |
nerdctl pull |
crictl pull |
docker exec |
nerdctl exec |
crictl exec |
docker logs |
nerdctl logs |
crictl logs |
docker stop |
nerdctl stop |
crictl stop |
docker rm |
nerdctl rm |
crictl rm |
Conclusion
Understanding the shift from Docker to containerd and learning new command-line tools is crucial for managing containers in Kubernetes 1.24 and beyond. While ctr
is mainly for debugging, nerdctl
offers a familiar Docker-like experience, and crictl
is tailored for CRI-compatible runtimes.