TL;DR: Docker remains the primary tool for developing and building Dockerfiles locally and in CI/CD, while containerd and CRI-O are the preferred, lightweight runtimes for production Kubernetes clusters.

Containers is the term used to categorize software that runs in self-contained environments. While Docker is the most established tool of this kind, other common runtimes and management tools include Podman, containerd, and CRI-O

In the early days of container orchestration, Docker was the default runtime for Kubernetes. However, as the ecosystem matured, Kubernetes introduced the Container Runtime Interface (CRI); a standardized gRPC interface allowing any container runtime to plug into Kubernetes nodes seamlessly.

Because Docker predated CRI and was built as a full developer suite rather than a dedicated runtime, it did not natively support CRI. Kubernetes temporarily solved this using dockershim; an internal adapter that translated CRI requests into commands Docker Engine could process.

To eliminate this translation layer and reduce system overhead, the core container execution engine was extracted from Docker into a separate, lightweight project called containerd. Docker donated containerd to the Cloud Native Computing Foundation (CNCF).

When Kubernetes removed dockershim in version 1.24, containerd became the primary CRI-compliant successor, allowing Kubernetes to manage containers directly without needing the full Docker Engine.

What is CRI-O?

CRI-O is a lightweight, purpose-built container runtime designed exclusively for Kubernetes.

Unlike traditional container tools that include build engines, storage managers, and separate CLI utilities, CRI-O strips away all non-essential administrative functions. Its sole responsibility is to fulfill the Kubernetes Container Runtime Interface (CRI) specification with minimal overhead and no redundant features.

Key characteristics of CRI-O include:

  • Kubernetes-Native: Designed from day one specifically as an execution interface for kubelet.
  • Minimalist Design: It focuses strictly on pulling images and running OCI-compliant containers, leaving orchestration and policy decisions entirely to Kubernetes.
  • 1:1 Release Alignment: CRI-O versioning mirrors Kubernetes release cycles, ensuring direct compatibility and thorough integration testing.

Docker and Kubernetes Today

Even though modern Kubernetes no longer uses Docker Engine directly on worker nodes, Docker images run without issue in Kubernetes.

Because Docker images follow the Open Container Initiative (OCI) image specification, Kubernetes can seamlessly run them via CRI-compliant runtimes like containerd or CRI-O. From a developer’s perspective, nothing changes: you can still build your images using Docker on your local workstation and deploy them to production.

What About Podman?

There is a common misconception about Podman: Podman itself does not implement the Kubernetes Container Runtime Interface (CRI).

Unlike Docker or containerd, Podman was built as a daemonless CLI tool designed for single-node container management on developer workstations or standalone servers. Because Kubernetes expects a background daemon or service that strictly implements CRI gRPC endpoints, Podman is not used directly as a node runtime in Kubernetes.

Instead, the Red Hat container ecosystem splits these roles intentionally:

  • Podman (Developer Tooling): Used on your local machine or build servers to build, run, test, and manage containers without needing a background daemon.
  • CRI-O (Cluster Node Runtime): Used on production Kubernetes nodes as the lightweight daemon that accepts CRI commands from kubelet and runs the containers.

CI/CD and Docker

While Kubernetes worker nodes have moved on to lightweight runtimes like containerd and CRI-O, Docker remains extremely useful in CI/CD pipelines and developer testing loops.

During the development and testing phases, developers rely on Docker for more than just running process boundaries—they use Docker’s rich tooling ecosystem to build, examine, and diagnose container behavior:

  • Interactive Troubleshooting: Commands like docker exec, docker logs, docker inspect, and docker stats provide instant visibility when debugging failing test suites or inspecting container network states.
  • Simplified Multi-Container Setups: Tools like docker compose allow developers and integration test runners to spin up full microservice stacks—along with databases and caches—using a single command.
  • Widespread Runner Support: Most CI/CD platforms (such as GitHub Actions, GitLab CI, and Jenkins) natively integrate with Docker daemons, making Docker the standard tool for executing CI steps in isolated containers.

Modern Alternatives in CI/CD

While Docker remains the standard, modern CI/CD security practices are gradually shifting toward daemonless and rootless tools:

  • Image Building: Tools like Buildah or Kaniko are increasingly preferred in secure CI pipelines to build images without needing a privileged Docker daemon running in the background.
  • Inspection & Delivery: Utilities like Skopeo allow pipelines to inspect image metadata and copy images between registries without pulling whole layer sets to disk.

Back to Certified Cloud Native Platform Engineering Associate Preparation