Docker, Podman, containerd: what's the difference?

When people say "container", they often mean "Docker". But Docker is just one tool in a stack of layers, and in many places, Kubernetes included, Docker isn't involved at all anymore.

Understanding what's actually running your containers helps when debugging, choosing tools, and making sense of headlines like "Kubernetes removes Docker support" (which sounded scary in 2020 and turned out to be mostly harmless).

The container stack

From bottom to top:

1. The Linux kernel. Containers aren't a kernel feature called "container". They're a combination of namespaces (isolating what a process can see: processes, network, files, users) and cgroups (limiting what it can use: CPU, memory, I/O). Every container runtime uses these.

2. Low-level runtime (OCI runtime). A small program that actually creates the container process with the right namespaces and cgroups. The standard one is runc. Alternatives include crun (faster, written in C), gVisor (extra isolation with a user-space kernel) and Kata Containers (each container in a lightweight VM).

3. High-level runtime. Manages images, storage, networking and the lifecycle of containers, and calls the low-level runtime. The main ones are containerd (a CNCF graduated project) and CRI-O (built specifically for Kubernetes).

4. Tools and interfaces. What humans and platforms talk to: the Docker CLI and engine, Podman, nerdctl, and Kubernetes' kubelet (through the Container Runtime Interface, CRI).

All of this is held together by OCI standards (Open Container Initiative): a standard image format and a standard runtime specification. That's why an image built with Docker runs with Podman, containerd or CRI-O.

A container is just a Linux process with blinkers on and a budget. Everything else is tooling around that idea.

What Kubernetes actually uses

Kubernetes talks to runtimes through the CRI. Docker Engine never implemented CRI directly, so Kubernetes used an adapter called dockershim. In Kubernetes 1.24 (2022), dockershim was removed.

What that meant in practice:

• Clusters now use containerd or CRI-O directly. Most managed Kubernetes services (EKS, AKS, GKE) use containerd.
• Images built with Docker still work everywhere, because they're standard OCI images.
• What stopped working: things that relied on the Docker socket on nodes, like some old monitoring tools or "Docker-in-Docker" builds in CI.

On a node, use crictl to inspect containers instead of docker ps:

crictl ps
crictl logs <container-id>
crictl images

Docker

Docker made containers popular and remains the most widely used developer tool for them: building images, running containers locally, Docker Compose for multi-container setups. Docker Engine itself uses containerd underneath.

Docker Desktop is the packaged app for macOS and Windows, which runs a Linux VM in the background. Since 2021, it requires a paid subscription for larger companies (more than 250 employees or more than $10 million in annual revenue). That pushed many organisations to look at alternatives.

Rootless with Podman

Podman, from Red Hat, is a Docker-compatible alternative with a few important differences:

• Daemonless: no long-running background service with root privileges. Each container is a child process of the command that started it.
• Rootless by default: containers run as your normal user, which reduces the risk if a container is compromised.
• Docker-compatible CLI: alias docker=podman works for most commands.
• Pods: can group containers like Kubernetes pods, and generate Kubernetes YAML from running containers (podman kube generate).
• Quadlet: run containers as systemd services, nicely integrated with Linux servers.
• Podman Desktop: a free GUI for macOS, Windows and Linux.

podman run --rm -p 8080:80 docker.io/library/nginx:1.27

Docker Desktop alternatives on the Mac

If you need containers on macOS without Docker Desktop:

• OrbStack: fast, lightweight, very popular with Mac developers. Commercial for business use, but often cheaper than Docker Desktop.
• Colima: open source, command-line, based on Lima. Works with the Docker CLI or containerd/nerdctl.
• Rancher Desktop: open source (SUSE), includes a local Kubernetes (k3s) and lets you choose containerd or Docker Engine.
• Podman Desktop: open source, with Podman underneath.
• Apple has also introduced its own open-source container tool for running Linux containers on Apple silicon Macs.

All of them run a small Linux VM, because containers need a Linux kernel.

Which should you use?

• Developer laptop: Docker Desktop if licensing is fine for you; otherwise OrbStack, Colima, Rancher Desktop or Podman Desktop.
• Linux servers running containers directly: Podman with Quadlet is very nice, especially for rootless setups. Docker Engine also works well.
• Kubernetes nodes: containerd (or CRI-O). You usually don't choose this on managed services.
• CI image builds: BuildKit (via Docker or standalone), Buildah, or Kaniko-style tools for building without a privileged daemon.

So, what's the takeaway?

"Docker" is a brand, a tool and a company. Containers are a Linux feature plus open standards. Once you see the layers, the choices become simpler: use whatever tool you like to build OCI images, and know that Kubernetes will run them with containerd or CRI-O regardless.

My take: learn the layers once, and you'll never be confused by a "Docker is dead" headline again.

— Desly