Kubernetes Has Moved On from Docker — Are You Ready?
- Apr 18
- 3 min read
Table of Contents:
Overview
For years, Docker and Kubernetes have been inseparable in most people’s minds — a kind of DevOps power couple. Docker made containerization accessible; Kubernetes made it scalable. But in a move that rattled even seasoned developers, Kubernetes dropped Docker as a container runtime starting in version 1.20. That decision left many asking the same question:
“Wait… how does Kubernetes even work without Docker?”
If that’s your question too, don’t worry — this post will explain what changed, why it changed, and what you need to do to be ready.
First, Let’s Clear This Up: Kubernetes Still Runs Docker Images
Yes — you can still use your Docker images (.dockerfile, docker build, and pushing to Docker Hub). The change affects how Kubernetes runs containers under the hood, not how you build them.
What Kubernetes dropped is Docker as a container runtime, the software that actually runs containers at the node level.
What Replaced Docker? Meet containerd and CRI-O
Kubernetes adopted the Container Runtime Interface (CRI) to standardize how it talks to container runtimes. Docker was never CRI-compliant out of the box — it needed an extra translation layer called dockershim. Maintaining that layer became unsustainable, so the Kubernetes maintainers deprecated dockershim in v1.20 and removed it entirely in v1.24.
Instead, Kubernetes now prefers CRI-compliant runtimes like:
containerd — a core component of Docker, now a standalone runtime.
CRI-O — lightweight, Kubernetes-native runtime optimized for Open Container Initiative (OCI) standards.
These runtimes are built for Kubernetes and offer better performance, lower overhead, and improved security.
Why This Is a Good Thing?
Even though “Docker” is a household name in DevOps, containerd and CRI-O are better suited for Kubernetes for several reasons:
Slimmer & Faster
containerd is stripped of the extra features Docker includes (like building images or CLI tools), making it more efficient for running containers in production.
CRI-Compliant
Direct compatibility with Kubernetes means fewer moving parts, fewer bugs, and easier upgrades.
Built for Scale
With containerd or CRI-O, clusters have faster startup times, better resource management, and are more stable under heavy workloads.
What This Means for You?
If you’re developing apps with Docker and deploying to Kubernetes, you can mostly carry on as usual. But here are a few areas to watch:
Stop Assuming Docker Is the Runtime
If you're building custom Kubernetes nodes, writing low-level tooling, or extending clusters, don’t assume Docker is present. Use tools that work with containerd or CRI-O directly.
Use OCI-Compatible Images
Docker images are OCI-compliant, so you're probably fine. But if you're using exotic image builders, make sure the result works with containerd or CRI-O.
Check Your CI/CD Pipelines
If your deployment process relies on Docker-specific behavior (e.g., Docker-in-Docker), it's worth reviewing your CI/CD pipelines for compatibility with CRI-native environments.
Tools and Ecosystem Are Catching Up
The tooling ecosystem has embraced this change:
Tools like kind (Kubernetes IN Docker) and minikube support containerd.
Container image builders like buildah and kaniko offer Docker-less image builds.
Cloud providers like GKE, EKS, and AKS have standardized on CRI runtimes under the hood.
Docker Isn’t Dead, It Just Moved Up the Stack
Docker is still great for local development and building images. But in production Kubernetes environments, containerd and CRI-O are taking over the actual container runtime responsibilities.
The takeaway? Docker is still in the picture — it’s just not under the hood anymore. Understanding this separation of concerns will help you build more portable, future-ready containerized apps.
Ready for the Future?
This change might feel like a disruption, but it’s actually a sign that the Kubernetes ecosystem is maturing. A leaner, more standardized container runtime landscape is good news for everyone — especially teams running Kubernetes at scale.
So don’t fear the shift — embrace it.
Kubernetes without Docker isn’t the end. It’s the next step.
Want help migrating your Kubernetes workloads to a Docker-less runtime? Or need guidance on debugging containerd-based clusters? Drop a comment or reach out — let’s get your infrastructure future-proofed.
Comments