Choosing a Container Runtime for Kubernetes: Docker, containerd, or CRI-O?
If you’re setting up a Kubernetes cluster, one important decision is which container runtime to use. Kubernetes works through the Container Runtime Interface (CRI), and you typically see three options: Docker, containerd, and CRI-O. Let’s break down what to choose—and why.
Docker
Docker is the classic container engine that was the default choice for Kubernetes for a long time. But starting with Kubernetes 1.20, dockershim began its deprecation path, and by 1.24 Docker support via dockershim was officially removed. That said, Docker didn’t disappear—it simply runs via containerd under the hood.
Pros:
- Excellent for local development.
- Huge community and rich tooling ecosystem.
- Universal image format and broad compatibility.
Cons:
- In Kubernetes, it runs through containerd, adding an extra layer.
- Dockershim is gone, so additional configuration may be required in older setups.
containerd
containerd is the core runtime behind Docker—without the extra layers. Today it’s a standalone project and is widely used in Kubernetes directly, without any intermediary shims.
Pros:
- Native Kubernetes support.
- Minimal dependencies and strong stability.
- Typically more lightweight and efficient than a full Docker stack.
Cons:
- No built-in image build workflow like Docker (though tooling exists).
- You may rely on external utilities for image management and troubleshooting.
CRI-O
CRI-O is a runtime built specifically for Kubernetes. It’s lightweight, fast, and tightly aligned with the CRI specification.
Pros:
- Minimal overhead.
- Supports Docker and OCI images.
- Lightweight, secure, and purpose-built for Kubernetes.
Cons:
- Smaller ecosystem compared to Docker or containerd.
- Less tooling outside Kubernetes-centric workflows.
What should you choose?
If you rely on familiar Docker workflows for local development, containerd is a great production runtime—it’s essentially the Docker core without the extra components. If Kubernetes is your primary platform and you want a runtime purpose-built for it, CRI-O is often a strong choice thanks to its simplicity and security focus. In practice, most modern clusters run on containerd or CRI-O because they’re stable, efficient, and designed for production use. Docker remains an excellent developer tool—but for production Kubernetes, it’s usually best not to depend on the full Docker stack.
Choose wisely. Oberset.