Container Runtime Technologies Explained: containerd, CRI-O, and Docker

If you’ve ever run docker run or deployed a pod in Kubernetes, you’ve interacted with a container runtime. But behind the scenes, there’s a whole ecosystem of competing tools that handle the actual work of running containers.

Here’s the plain truth: Docker isn’t the only game in town anymore. Kubernetes dropped Docker as its default runtime in 2020. Today, the two heavyweights are containerd and CRI-O, each designed for different expectations.

Let’s cut through the hype and see what each does, how they compare, and why you’d pick one over the other.

What are they, really?

A container runtime is the software that actually creates, starts, and stops containers. It interacts with the Linux kernel’s cgroups and namespaces to isolate processes. That’s the core job. Everything else — building images, managing volumes, logging — is a bonus.

Think of it like a car engine. You can swap engines, but the car (your container orchestration) might need different mounts.

Docker: The familiar giant

You know Docker. You’ve used Docker. But since 2017, Docker itself has been built on containerd. The docker command you type goes through layers: docker CLI → dockerd → containerd → runc.

The good: - Incredible tooling: docker build, docker-compose, docker swarm - Huge ecosystem and documentation - Developer-friendly UX

The bad: - Not designed to plug into Kubernetes directly anymore (requires dockershim, which was removed in K8s 1.24) - Heavier than necessary for production clusters - Slower startup in large-scale deployments compared to lighter runtimes

Docker is still great for development. But in production Kubernetes, it’s often replaced.

containerd: The industrial workhorse

containerd is the core of Docker, extracted and made independent. It’s an industry-standard container runtime graduated by the CNCF (Cloud Native Computing Foundation).

Key features: - Simple, focused: manages container lifecycle, image transfer, snapshots, and networking - Supports Linux, Windows, and macOS - Acts as a daemon with a gRPC API — perfect for Kubernetes

Why it wins: - Lightweight: no Docker daemon overhead - Kubernetes native: can talk CRI (Container Runtime Interface) directly - Mature: powers Docker, Rancher, and many cloud platforms

If you’re running Kubernetes on AWS EKS, Azure AKS, or GKE, you’re likely using containerd.

CRI-O: The Kubernetes-first contender

CRI-O was built from scratch to be only a Kubernetes runtime. No desire to replace Docker for development. Just fast, secure, and compliant with Kubernetes.

Key features: - Implements CRI directly — no shim layer - Supports only OCI-compliant images (no Docker-specific formats) - Can pull images from any registry (Docker Hub, Quay, etc.)

Why it wins: - Even lower overhead than containerd in some benchmarks - Tighter integration with OpenShift (Red Hat’s Kubernetes distribution) - Strong security focus: rootless containers, SELinux support

Where it lags: - Smaller ecosystem than containerd - Less tooling for development — you still need podman or buildah to build images - Slower to adopt new features compared to Docker’s team

Head-to-head: containerd vs CRI-O

In practice, both are similar. The choice often comes down to your orchestration platform: containerd is default on most managed Kubernetes services; CRI-O is default on OpenShift.

So which one should you use?

• For Kubernetes clusters (production): either containerd or CRI-O. Both work. containerd has broader adoption; CRI-O gives tighter OpenShift integration.
• For local development: Docker, because you need docker build and docker-compose. You can still use containerd underneath if you want.
• For building custom runtimes: containerd’s architecture is easier to extend.

The bottom line

Container runtimes are not a sexy topic — until your production cluster hits 1,000 nodes and you realize you’ve left too much overhead on the table. Docker remains king for dev, but containerd and CRI-O are the real production runners. Pick the one that fits your orchestration stack, and don’t overthink it.

The industry has moved past the “Docker vs Kubernetes” debate. Now it’s about choosing the right engine for the job.