Docker isn’t dead, but Kubernetes definitely stopped texting back.

Introduction: The Runtime Plot Twist Nobody Told You About

So, imagine this:
You’re vibing in your CLI, firing off kubectl apply -f something.yaml, thinking life is good. Docker’s humming in the background. Everything just... works.

Then one day, Kubernetes walks into the room like:

“Hey, Docker. It’s not you, it’s your shim. We’re done here.”

Boom.
The internet explodes. Twitter threads. Hacker News wars. Devs panicking. Memes flying.

And if you missed the memo (because you were too busy debugging a 500 error that turned out to be a missing colon), here’s the tea:
As of Kubernetes v1.24, Docker is no longer the default container runtime.

But before you scream into the void or uninstall Docker out of pure spite, let’s get one thing clear:

Kubernetes still loves Docker images.
It just doesn’t run them using Docker anymore.

Yep. It’s like Kubernetes still listens to your mixtapes, but now it’s dating someone named containerd.

In this article, we’re going to break it all down what happened, why it matters, what to do next — without sounding like a corporate whitepaper written by a boardroom AI. This is for the devs. The sysadmins. The SREs who live in Grafana dashboards. The cloud engineers who haven’t seen sunlight since Helm v3 dropped.

Section 2: The Breakup Kubernetes & Docker, It’s Complicated

Once upon a time in DevOps Land, Kubernetes and Docker were the power couple. The Batman and Robin of container orchestration. The Mario and Luigi of your deployment dreams.

But then Kubernetes looked Docker in the eyes and said:

“Hey… we need to talk. I’m switching to someone else to run my containers.”

And thus began the runtime soap opera that brought us here.

So… What Actually Happened?

Okay, let’s clear up the confusion that’s been haunting dev forums and Reddit threads like a ghost in your microservice.

• Kubernetes didn’t “drop Docker support” entirely.
• It dropped Docker as a container runtime specifically, the thing called dockershim.
• Your Docker-built images? Still work.
• Your Dockerfile? Still valid.
• Your sanity? Questionable, but intact.

The real issue was that Docker wasn’t built to be used inside Kubernetes. It’s like trying to use a full IDE just to run hello-world.py. Too much baggage, not enough chill.

Kubernetes wanted something leaner, meaner, and more compliant with its own CRI (Container Runtime Interface). Enter:

• containerd — Docker’s slimmed-down, no-BS cousin.
• CRI-O — Lightweight, purpose-built for Kubernetes, no emotional attachment to Docker.

What’s dockershim, and why is it cursed?

dockershim was like that weird adapter you bought off AliExpress that somehow made USB-C work with HDMI and Ethernet at the same time. It got the job done — but no one really trusted it.

Kubernetes was using dockershim to translate its CRI calls into something Docker understood. But maintaining that shim was a pain, and the Kubernetes maintainers finally said, “Yeah, we’re done babysitting this.”

So in Kubernetes v1.24, they officially removed dockershim, which means:

• No more using Docker as the runtime engine.
• Still fine to use Docker to build, tag, and push images.
• Just use containerd, CRI-O, or something else under the hood when actually running the containers in Kubernetes.

TL;DR for Busy Devs Who Scrolled Too Fast:

And no this isn’t the end of Docker. You can still use it for local dev, CI, even running containers on its own. Just don’t expect Kubernetes to be calling it on weekends anymore.

Section 3: Container Runtimes 101 Or, What the Heck Is Actually Running Your Containers?

If containers were magic, then the container runtime is the grumpy wizard behind the curtain who actually casts the spell.

So here’s the tea:
When you kubectl run a pod, Kubernetes doesn’t run your container directly. It talks to a container runtime like a middleman who handles the actual low-level container creation, process isolation, and all that glorious namespace/cgroups wizardry.

For a long time, that runtime was Docker (via dockershim), but now it’s mostly containerd, CRI-O, or if you’re feeling adventurous, stuff like gVisor or WasmEdge (yes, WebAssembly is coming for your YAML).

So What Exactly Is a Container Runtime?

In gamer terms:

• Docker is like a modded Minecraft launcher lots of features, nice UX, but heavy.
• containerd is vanilla Minecraft on Linux lean, stable, does exactly what it needs to.
• CRI-O is the minimalist pixel-art clone optimized for one job only: Kubernetes.

Let’s break it down like a stat sheet:

Why So Many Runtimes?

Because not all clusters are created equal. Some want speed. Some want security. Some just want to be different (you know the type).

Here’s how they stack up in gamer mode:

• containerd: The Elden Ring of runtimes. Deep, elegant, hardcore.
• CRI-O: The Hollow Knight. Sleek, no bloat, perfect for speedrunners.
• gVisor: The Sekiro punishes anything unsafe.
• Docker: The Skyrim modded edition. Great until it crashes.
• WasmEdge: The experimental alpha build you swear is the future.

So What Do You Need?

• Running Kubernetes on the cloud? You’re already using containerd, probably without knowing.
• Running on bare metal or your own VMs? Time to choose your fighter.
• Still using Docker Desktop for local dev? No shame, but maybe test with containerd + nerdctl so prod doesn’t slap you.

Section 4: Why Developers Should Actually Care (Yes, Even You, Frontend Folks)

Look, I get it. You’re thinking:

“I don’t care what runtime Kubernetes uses. My YAMLs are working, my pods are green, and my coffee is hot.”

But here’s the thing that’s exactly what 2020-me said before a seemingly minor kubectl apply turned into a 2-hour debugging session involving logs that didn’t exist, containers that wouldn’t start, and documentation that was last updated when JavaScript didn’t suck (so… never?).

So What Changes for Developers?

Let’s break it down like you’re explaining it to your sleep-deprived teammate on a 3 AM PagerDuty call:

1. Your Docker CLI Isn’t the Boss Anymore

Docker CLI is still cool. You can still use docker build, docker push, and docker run just don’t expect Kubernetes to care. It now talks directly to containerd or CRI-O, and those tools have their own ecosystems (e.g., nerdctl, crictl, or podman).

Translation: If you’re debugging issues inside a pod, using docker ps is as useful as using git push in a directory with no .git.

2. Debugging Feels Slightly… Different

With Docker, you might’ve used docker logs, docker exec, or docker inspect like your holy trinity. Now?

• You’ll be using kubectl logs and kubectl exec more religiously.
• Or tools like crictl, which has the ergonomics of Vim but the personality of a toaster.

Also, runtime-specific quirks now matter more. For example:

• Some logs might not show properly in certain setups unless you configure log drivers right.
• Some monitoring tools expect Docker. containerd might give them… existential dread.

3. Your Local Dev Doesn’t Match Prod (Surprise!)

• You’re building and testing with Docker on your machine.
• But prod runs on containerd or CRI-O.
• And that tiny difference can hit like a zero-day bug when something goes wrong.

Ever had a pod work perfectly locally but crashloop in staging for “no reason”? Yeah, sometimes that’s runtime behavior, especially with image caching, volume mounts, or how networking is handled.

Docker lies. containerd is brutally honest.

4. Multi-Stage Builds, Distroless Images, Rootless Containers Runtime Affects It All

Modern runtimes push best practices that Docker didn’t care about:

• Run as non-root? containerd says “yes please.”
• Use distroless images? You better understand how they behave without /bin/sh.
• Trying to copy files into a running container like it’s 2017? containerd says “no soup for you.”

You don’t have to change, but understanding this stuff makes you a better dev, and gets you bonus points in code review when you explain why your image is 70% smaller now.

5. It’s Not Just About Ops Anymore

Runtime decisions now shape:

• Your image build strategy
• How you run integration tests
• How you secure your pipeline
• Even how you deploy functions (hello, Wasm!

It’s no longer just an SRE or platform team concern. This stuff touches your code and if you’re in a startup, you are the platform team.

🎯 TL;DR for Lazy Engineers (No Judgment):

Section 5: Tooling Showdown containerd vs Docker vs Podman vs nerdctl

Look, nobody wants to learn yet another CLI tool. But once Kubernetes stopped using Docker as its runtime, a new generation of tools stepped in like:

“Step aside, Grandpa Docker. We got this.”

And honestly? Some of these tools slap. Others feel like your least favorite Linux distro’s package manager: powerful but only if you read the entire man page.

Let’s break it all down, dev-to-dev.

The Roster

1. Docker The OG. The one that started it all. Now semi-retired like a washed-up rockstar still doing local gigs.

2. containerd The lean backend Docker secretly used all along. Now out of the shadows and running production workloads like a boss.

3. Podman Docker’s minimalist sibling who uses fewer resources, runs rootless, and lowkey hates Docker Desktop.

4. nerdctl The Docker CLI skin for containerd. If docker and containerd had a baby raised on Arch Linux.

Feature Faceoff

Dev Notes From the Field

• Docker: Still your go-to for local development unless you’re allergic to GUIs or license terms.
• containerd: Default runtime in EKS, GKE, AKS. You’re already using it in prod. You just didn’t know.
• Podman: Runs rootless by design, which makes security folks weep with joy. Works great on Linux. On Mac/Windows? Meh.
• nerdctl: Lowkey MVP. If you want to test containerd locally but still want your muscle memory to work, this is your tool.

Real-Life Scenarios

Dev-to-Dev Hot Take

If you’re a developer:

Start learning nerdctl or podman alongside Docker. Your future self the one debugging weird image bugs in staging will high-five you across time.

If you’re DevOps or SRE:

containerd is your new bestie. Learn to monitor it, love it, and treat it to some good logs and observability tools.

Section 6: Real-World Use Cases Which Runtime You Should Use (and Why)

Okay, theory is cool. But what about actual dev setups? Here’s how things shake out in real-world environments, from cloud to localhost:

1. Local Development

Scenario: You’re building microservices, testing APIs, running tests, and maybe pretending you’ll write docs later.

• ✅ Still fine to use Docker Desktop, but it’s resource-hungry and getting pricey.
• 🔥 Try Podman or nerdctl with containerd for lighter, native-like experience.
• 🧠 Pro tip: Use the same runtime locally as your production cluster to avoid “works on my machine” syndrome.

Bonus points: Podman runs rootless by default. Perfect for devs who accidentally sudo rm -rf things.

2. Cloud Managed Kubernetes (EKS, GKE, AKS, etc.)

You don’t even get to choose the runtime here. AWS, Google, Azure they’ve already ghosted Docker for containerd.

• If you’re using these: your runtime is already containerd. You just didn’t know it because your Terraform did the talking.
• Want to debug or peek inside? Use crictl, nerdctl, or cry.

3. CI/CD Pipelines

GitHub Actions, GitLab CI, and most modern runners are migrating away from Docker-in-Docker because… yeah, it’s cursed.

• Use BuildKit, Kaniko, or img if you need to build inside pipelines.
• Lighter images = faster builds = less waiting = happier devs.

If your CI still uses Docker in Docker… blink twice if you need help.

4. Bare-Metal or On-Prem K8s

You’re brave. You run your own clusters. You have logs, metrics, and tears to prove it.

• containerd or CRI-O are your best friends. Lightweight, fast, zero fluff.
• Tools like K3s, MicroK8s, or k0s use containerd by default.
• Want extra security? Add gVisor or Kata Containers and sleep better.

5. Experimental / Next-Gen Stuff

• WebAssembly (via WasmEdge) is coming for your containers. Super lightweight and sandboxed.
• Great for edge computing, IoT, serverless, or just flexing in your conference talks.

TL;DR: Use Case Matching

Section 7: Pricing & Platform Breakdown Or, Why Docker Desktop Costs More Than Your Indie Game Library

Let’s talk numbers. Because while your runtime choice might feel like a technical decision, sometimes it’s actually a budgeting one and nothing wakes up a DevOps lead faster than the words “licensing change.”

Docker Desktop: From Free to “Enterprise-ish”

In August 2021, Docker said:

“Yo developers, we love you… but also, pay us.”

They introduced a paid subscription model for Docker Desktop which is still free for personal use, education, and small businesses, but costs money for larger companies.

⚠️ Got more than 250 employees or $10M+ in revenue? You’re legally required to get a paid plan.

TL;DR: Your laptop might still be hot from building containers, but now your wallet is too.

Podman, containerd, nerdctl: Open-Source & Free Like Beer (and Freedom)

Here’s where things get spicy most Docker alternatives are 100% free. As in, actual open source. No surprise licensing, no “click here to accept billing,” just vibes.

And it’s not just about cost these tools are:

• Lighter on resources
• Easier to sandbox
• Rootless by default in many setups

In short: they’re optimized for modern container-native workloads without the “please sign in to Docker Hub” popup every five minutes.

Cloud Providers: What They Use (and What They Charge)

All major managed Kubernetes services have already ghosted Docker. Here’s who’s using what:

You’re not paying extra for containerd it’s bundled. But if you’re still using Docker as your dev base, expect minor frictions (and maybe minor breakdowns).

Bottom Line: Who’s Paying What?

If you’re paying more for Docker than your Netflix subscription, it might be time to make the switch.

Section 8: The Future of Container Runtimes WebAssembly, gVisor, and the Rise of the Sidecar Avengers

Alright, fellow container wizards we’ve come a long way from docker run ubuntu days. The landscape is evolving faster than JavaScript frameworks, and that’s saying something.

So, what’s next? Is it still containerd forever? Or are we heading into a post-container world?

Spoiler: the answer is yes. Let’s unpack it.

1. WebAssembly (Wasm): The Cool New Kid in the Runtime Cafeteria

If containers are virtual machines on a diet, WebAssembly is a CrossFit monk with a six-pack and no OS baggage.

Why devs love Wasm:

• Lightning fast cold starts
• Sandboxed by design (no escaping the container prison)
• Platform-independent (run the same module on server, browser, edge, fridge, Roomba, whatever)

Use Cases:

• Edge computing (latency = death)
• Serverless (cold start = death)
• IoT (resources = LOL)

Say hello to WasmEdge and Spin (from Fermyon), tools that are bringing Wasm to production-level apps.

TL;DR: It’s like running containers… without containers. Wrap your head around that.

2. gVisor, Kata Containers: Security’s Finally Getting Buff

We’ve all ignored that warning about root access in containers. It’s fine. Until it’s not.

Enter:

• gVisor by Google: a user-space kernel that acts like a bodyguard between your app and the host OS.
• Kata Containers: basically a tiny VM per container. Paranoid? Good. This one’s for you.

Use these if:

• You deal with multi-tenant clusters.
• You’re building fintech, gov, or anything where “oops” is unacceptable.
• You like sleeping at night.

3. Mixing Runtimes Because One Is Never Enough

Yeah, here’s where it gets wild:

• You might run your frontend in Wasm.
• Your backend in containerd.
• Your logging sidecar in gVisor.
• And your database in a VM because of course.

Welcome to the Polyglot Runtime Future™ where Kubernetes won’t just schedule containers, it’ll juggle Wasm, microVMs, and whatever alien runtime Elon invents next.

4. What Devs Should Start Doing Now (Before the Future Eats You)

• Experiment with nerdctl, Podman, and WasmEdge locally
• Set up CI pipelines that don’t assume Docker
• Try running your most vulnerable microservice with gVisor or Kata
• Actually read the CRI docs for once (yes, all the way down)

Pro tip: “It worked in Docker” is not a valid excuse in 2025. You gotta know what’s running under the hood, or Kubernetes will politely eat your lunch.

The Future Is Modular, Secure, and Fast AF

Containers are not dead. But they’re evolving. And if you’re still building, shipping, and debugging like it’s 2019, you’re not just behind you’re potentially creating technical debt that’ll slap you in the face later.

So yeah. Learn your runtime. Master the CLI. And maybe, just maybe… give Wasm a chance.

Section 9: Conclusion What We Learned & Why You Should Still Care (Even If Everything “Still Works”)

So, to recap this beautifully chaotic runtime saga:

• Kubernetes didn’t kill Docker it just swiped left on dockershim and moved in with containerd.
• Your Docker images? Still cool. Your Docker CLI? Still vibing. But Kubernetes? It’s speaking a new runtime language now.
• If you’re running prod clusters, you’re already using containerd whether you knew it or not. Surprise 🎉
• Tools like Podman and nerdctl are stepping up as Docker alternatives that won’t charge your company $24/month/user just to run docker ps.
• The future is multi-runtime, with WasmEdge for edge/IoT/serverless madness, and gVisor/Kata for when you want your containers to wear metaphorical armor.
• You, dear dev, don’t need to become a container runtime wizard overnight. But you do need to know what’s under the hood because when stuff breaks, the logs won’t fix themselves.

TL;DR Dev Manifesto:

Docker is not dead.
But it’s no longer the default.
And in the runtime world, “default” is everything.

So what now?

• Switch your local dev to Podman or nerdctl, and test your builds like prod.
• Use containerd in your Kubernetes homelab or side hustle app.
• Bookmark WasmEdge, because you know the CTO will ask about “that WebAssembly thing” in the next meeting.
• Stop relying on docker ps to tell you what’s happening inside Kubernetes. Start learning crictl like a grown-up.

Final Thought (aka the Pep Talk)

You don’t have to rewrite your workflow from scratch tomorrow. But don’t wait until your cluster is screaming and your containers are ghosting you to learn this stuff either.

This isn’t a war. It’s a graduation.

Docker was your high school sweetheart.
containerd is your stable long-term partner.
Wasm is the mysterious stranger you meet in a coffee shop and might runaway with in two years.

Make peace with the past. Embrace the runtime future.

Section 10: Helpful Resources & Real Links (Because Googling in Panic Sucks)

Official Docs & Deep Dives

• Kubernetes: Dockershim Removal Announcement
  Read this before someone from your team files a bug titled “Why did Kubernetes stop loving me?”
• containerd Official Site
  The runtime powering most cloud K8s clusters and your future mental breakdowns.
• nerdctl CLI for containerd (Docker replacement)
  Feels like Docker. But lighter. And hipster-approved.
• Podman (aka: “We have Docker at home”)
  Docker CLI compatibility. Rootless. No daemon. No drama.
• gVisor: Sandboxed Container Runtime by Google
  For when your security team actually audits things.
• Kata Containers
  Containers in VMs, because sometimes isolation means business.
• WasmEdge: The Future of Serverless Runtimes
  If you’re building for the edge or hate cold starts, start here.

Tools to Try in Your Dev Lab

• crictl Container Runtime Interface CLI
  Because sometimes, kubectl logs just won’t cut it.
• BuildKit Faster Docker Builds
  Build speed + cache control = win.
• Kaniko Build Images in Kubernetes Without Docker
  For secure image builds inside CI/CD pipelines.
• Distroless Images by Google
  “No OS for you!” = fewer vulnerabilities, smaller images.

Community Threads & Nerd Reads

• The Great Dockershim Purge Reddit r/kubernetes
  Come for the advice, stay for the snark.
• Comparing Container Runtimes (by CNCF)
  For the visual learners with too many tabs open.
• WebAssembly vs Containers Do You Even Need Linux Anymore?
  For those already planning to replace their microservices with Wasm modules and vibes.

Blog Sponsor of the Month: UpCloud

UpCloud is a Finland-based developer and European cloud hosting provider known for its exceptional reliability, speed, and performance. Built for developers who demand control and efficiency, UpCloud offers robust infrastructure with transparent pricing and global data centres.

For our readers, UpCloud is offering €50 in free credits for an extended 30-day trial. Test the platform using this signup link or apply promo code DEVLINK50 at signup.

Tried it out? Drop a comment below, we’d love to hear your feedback and experiences.