Is Kubernetes replacing Docker? A clear answer for platform teams

No. Kubernetes is not replacing Docker because they solve different problems: Docker is a container runtime and developer tooling for building and running containers, while Kubernetes is an orchestrator that schedules and operates containers across a cluster. The two are complements. What did change is that Kubernetes removed direct support for the Docker daemon as a runtime in version 1.24 (April 2022), but the underlying engine (containerd, which was extracted from Docker) is still what runs the containers on most clusters.

Define the terms

Docker is best understood as several things bundled together: a developer CLI (docker build, docker run), the Docker Engine which historically used the dockerd daemon, and an image format that became standardised as the OCI image specification. The container runtime inside Docker was eventually extracted into a separate project called containerd, which is now a CNCF graduated project.

Kubernetes is a container orchestration platform. It schedules workloads across nodes, handles networking and service discovery, restarts failed containers, rolls out new versions, and provides primitives for storage, secrets, and configuration. Kubernetes itself does not build containers and does not run them directly; it talks to a container runtime through the Container Runtime Interface (CRI).

What actually changed in Kubernetes 1.24

Before 1.24, Kubernetes used a shim called dockershim to talk to the Docker daemon, which then talked to containerd, which then ran the container. Two layers of indirection for no real benefit. Kubernetes deprecated dockershim in 1.20 and removed it in 1.24.

The practical effect:

Images built with docker build still run on Kubernetes today because they conform to the OCI image format. Almost no developer workflow changed; the change was an internal cleanup of the kubelet.

Practical guidance

What this means for your team:

• Keep using Docker for local development, building images, and CI image builds. Most engineers will never touch the cluster runtime directly.
• Expect containerd or CRI-O as the runtime on your Kubernetes nodes. Managed Kubernetes services (EKS, AKS, GKE) made this transition for you years ago.
• Alternatives to the Docker CLI exist if you want them, including Podman (daemonless, rootless), nerdctl (a Docker-compatible CLI for containerd), and BuildKit (the modern image builder, which Docker itself uses).
• For very small workloads, you may not need Kubernetes at all. Docker Compose, AWS Fargate, Azure Container Apps, or Cloud Run can be a better fit than running a full cluster.

Common misconceptions: "Kubernetes killed Docker" (it did not, it only stopped using the Docker daemon as a runtime); "My Docker images will not work on Kubernetes anymore" (they will, they are OCI images); "I should learn Kubernetes instead of Docker" (you should learn both, starting with containers and Docker, then moving up to orchestration).

For deeper background see our Kubernetes overview and containerisation and orchestration.

How Opsio helps

Opsio designs and operates Kubernetes platforms on EKS, AKS, GKE, and on-premise for European and Indian enterprises, and we still build container images with Docker and BuildKit every day. We help teams pick the right level of abstraction (Kubernetes, managed container service, or plain VMs) and avoid taking on cluster complexity they do not need. See our DevOps services or contact us for a working session on your container strategy.

Frequently Asked Questions

Will my Docker images still run on Kubernetes?

Yes. Docker images conform to the OCI image specification, which is what Kubernetes expects. The deprecation of dockershim in Kubernetes 1.24 affected the runtime on the node, not the image format. You do not need to rebuild images.

What is containerd and how is it related to Docker?

containerd is a lightweight container runtime that Docker extracted and donated to the CNCF in 2017. It now runs underneath both Docker and most Kubernetes distributions. When you run a container on Kubernetes today, containerd (or CRI-O) is almost certainly doing the actual work.

Should developers stop learning Docker?

No. Docker remains the dominant local-development experience for containers. Learning Docker first (images, Dockerfiles, networking, volumes) gives you the foundation to use Kubernetes later. Skipping straight to Kubernetes without understanding containers is a common source of pain.

Do I need Kubernetes if I use Docker?

Only if you need orchestration. If you are running a small number of containers on one or two hosts, Docker Compose or a managed container service like AWS Fargate, Azure Container Apps, or Google Cloud Run is usually simpler and cheaper. Kubernetes earns its complexity when you have many services, multiple environments, autoscaling needs, or compliance requirements that benefit from its primitives.

What are the main alternatives to Docker today?

Podman (daemonless, rootless, Docker-compatible CLI), nerdctl (Docker-compatible CLI for containerd), BuildKit (modern image builder, also used by Docker itself), and Finch (an open-source client from AWS that wraps nerdctl). All produce OCI-compliant images that run on Kubernetes.