The Docker Deprecation Revelation: It Was Always containerd

Level 1: Behind the Curtain

Imagine you’re watching a puppet show. There’s a big friendly puppet on stage, and you think it’s moving and talking all by itself. It’s fun and you love the character. Then someone pulls back the curtain, and you see a person behind the puppet, moving its strings and doing the voice. You realize the puppet wasn’t acting on its own – that hidden puppeteer was making it work all along. You’re surprised, right? But it also suddenly makes sense how the puppet could do all those things. In this meme, Docker is like that puppet you thought was doing everything, and containerd is the puppeteer behind the curtain. The joke is that developers felt the same surprise as you did with the puppet: “Wait, the puppet has someone controlling it?!” And the answer was, “Always has been.” It’s a funny way to say sometimes there’s a helper in the background doing the real work, even if you didn’t know it was there.

Level 2: Docker’s Secret Sauce

This meme uses the popular “Always has been” astronaut format to deliver a tech lesson. In the image, an astronaut looks at the big blue Docker whale logo (with little shipping containers on its back) and says, “WAIT, IT’S ALL CONTAINERD?” The second astronaut behind him, labeled “DEPRECATED”, replies, “Always has been.” Don’t worry if that sounds confusing – let’s break it down. This is referencing how Docker, the famous containerization tool with the whale logo, actually works behind the scenes. Docker is what developers use to package applications into containers (lightweight, isolated environments, a bit like mini-virtual machines). But Docker doesn’t do this all by itself; it has a helper: containerd.

Docker’s architecture is essentially two parts: a client and a server. The client is the docker command you type (CLI – Command Line Interface), and the server is the Docker daemon (a background service often called dockerd, the Docker engine). When you run a command like docker run hello-world, the Docker CLI talks to the Docker daemon. Here’s roughly what happens next in simpler steps:

1. Docker CLI – You type a command (docker run ...). The CLI is just the interface sending instructions.
2. Docker Daemon (dockerd) – The Docker background service receives that instruction. It’s like Docker’s brain, coordinating what to do.
3. containerd – Docker passes the job of actually creating and running the container to containerd. Containerd is another daemon dedicated to managing containers; think of it as Docker’s hard-working assistant.
4. runC – Containerd uses an even lower-level tool called runC to start the container. runC is a tiny program that knows how to set up the Linux features that isolate a process, turning it into a container.
5. Linux Kernel – Finally, the operating system kernel does the heavy lifting: using namespaces to isolate the process (so it can’t see other processes or files) and cgroups to limit resources (like how much memory or CPU it can use). This is what actually makes a container confined and secure on a single machine.

So when the meme says “it’s all containerd,” it means that underneath the Docker whale (steps 1 and 2), the real action of running containers is handled by containerd (step 3 and beyond). The Docker whale logo with containers on its back is ironic – Docker is carrying containers, but containerd is carrying Docker’s workload! Docker’s role is more like an organizer and user-friendly wrapper, while containerd is doing the grunt work of talking to the OS to create containers. In everyday terms, Docker is the boss giving orders, and containerd is the employee who actually gets the work done (with runC and the OS helping).

Now, what about that “DEPRECATED” label and why the second astronaut is pointing a gun? In tech, “deprecated” means something is being phased out or retired. The meme references a specific event: Kubernetes (the popular system for managing containers across lots of machines) announced it would deprecate (remove support for) using Docker as a direct runtime. This doesn’t mean containers or Docker itself went away – it just means Kubernetes would talk to container runtimes (like containerd) more directly, instead of going through Docker. Kubernetes has a plugin interface called CRI (Container Runtime Interface) for connecting to container runtimes. Docker wasn’t natively designed for this interface, so Kubernetes had a bridge component called dockershim to make Docker work with Kubernetes. In late 2020, Kubernetes said “we’re going to drop that shim and use containerd directly.” Many developers were caught off guard, thinking “Wait, does Kubernetes no longer use Docker?!” That confusion is exactly what the astronaut saying “Wait, it’s all containerd?” represents – the realization that Kubernetes was already using containerd under the hood (through Docker). The second astronaut saying “Always has been” (with the gun) represents the Kubernetes team or documentation informing us that this was always true and that the old way (Docker via dockershim) is now deprecated. It’s like saying “Yes, containerd was doing the work all along, and now that you know, we don’t need the old layer.” The gun is just the meme’s exaggerated way to depict the harshness of a deprecation announcement: it forces you to accept reality.

So, the humor comes from learning a hidden truth. Docker’s big whale wasn’t the whole story – containerd was quietly doing a lot behind the scenes. DevOps folks find it funny because it’s a classic case of a “behind-the-curtain” helper being revealed. It also pokes fun at those dramatic “Always has been” memes where someone learns something obvious a bit late. In practice, if you’ve only ever used docker commands, you might not have heard of containerd. But if you peek at running processes on your machine, you’ll likely see containerd whenever Docker is running. It was literally there the whole time. The meme uses this moment of “Aha!” for comedic effect.

One more thing: the Docker whale itself (shown in the image) is a fun part of Docker’s branding – a whale carrying shipping containers. It symbolizes shipping your applications in containers. In this meme, that whale being “all containerd” suggests the whale is actually made up of containerd’s work. And the DEPRECATED caption on the second astronaut alludes to that Kubernetes change where Docker’s shim was deprecated. For a newcomer: Kubernetes is just a system that orchestrates containers – i.e., it helps run and manage containers across lots of servers. When it deprecated Docker support, it didn’t mean “no Docker anywhere”; it meant “under the hood we’ll use containerd directly.” So the meme is basically an insider joke: Docker (the tool everyone knows) relies on containerd (the tool fewer people know), and the community had a moment of surprise when this became widely talked about. Now, people also talk about rootless containers – that’s another advanced concept where tools like Docker/containerd can run without needing root (admin privileges). It’s mentioned in context because it’s part of containerd’s capabilities, but the main joke is simply revealing who’s been doing the work. In summary, “When you discover Docker’s whale is powered by containerd underneath” – the meme is saying surprise! the whale has been a puppet, and containerd was pulling the strings the whole time. Always has been.

Level 3: Beneath the Whale

For seasoned DevOps engineers, this meme hits on a “well, of course” moment. The astronaut in front is the surprised developer exclaiming, “Wait, it’s all containerd?” – which perfectly captures the shock newcomers had when they learned that Docker’s iconic whale (the Docker Engine) is really just a facade atop containerd. The second astronaut behind with the gun — tagged DEPRECATED — replies “Always has been.” This is a direct reference to the classic “Always has been” astronaut meme format, and here it’s applied to Docker’s architecture. The humor comes from that big reveal: the tool everyone associates with containers (Docker) was, under the hood, using another program (containerd) to do the actual work. Experienced folks have known this for years, so the punchline is that this was never a secret at all.

The small DEPRECATED label floating by the gun is a tongue-in-cheek nod to a real-life change in the DevOps world around late 2020. Kubernetes announced the deprecation of its Docker integration (the dockershim), meaning Kubernetes would no longer use the Docker Engine directly to run containers in future releases. Many in the community initially freaked out thinking “Kubernetes is dropping Docker support,” not realizing that Kubernetes was already using Docker only as an intermediary to get to containerd. In other words, Kubernetes has always been running containers via containerd – Docker was just along for the ride. The meme portrays this as the astronaut with the gun (the deprecation notice) revealing the truth and “shooting” the misconception. Runtime deprecation here is the catalyst forcing everyone to acknowledge containerd’s role. It’s darkly comedic: the very thing being phased out (Docker as a runtime in K8s) is the one pulling the trigger and saying “Yep, containerd was doing it all, and now I’m out.”

Why is this funny to insiders? It’s that mix of “I can’t believe you didn’t know” and “we’ve all been there”. Many of us remember the moment we learned how Docker actually works under the hood – that oh-so-familiar Docker CLI is really talking to a daemon, which hands off to an even lower-level component (containerd + runC). It’s an open secret in containerization tools. The meme’s scenario is basically a DevOps inside joke: containerization isn’t monolithic. The friendly Docker CLI you type commands into (and the smiling whale mascot) were just the tip of the iceberg. Underneath, there’s a whole crew doing the heavy lifting. When a junior engineer or a team new to Kubernetes finally “discovers” containerd, seniors might chuckle “Always has been.” They’ve known that in production, using Docker often means you have the Docker daemon and behind it containerd running to actually handle containers. In fact, on many Linux systems if you list processes, you’ll literally see a process named containerd whenever Docker is running. It was hiding in plain sight.

This meme also pokes fun at how technology moves on. Docker was revolutionary for devs, but in large-scale systems (like cloud and orchestration), it’s been somewhat unbundled. Container orchestration platforms (like Kubernetes) prefer lightweight runtimes. Docker’s extra features (CLI, image building, volume management, etc.) aren’t needed on a node just to start a container. Kubernetes only needs a container runtime that implements its API – and containerd fits that perfectly without the rest of Docker. So when Kubernetes deprecated Dockershim, seasoned SREs weren’t surprised: they knew it was containerd (or similar) under the hood all along. It’s a bit of “industry history”: Docker the company popularized containers, but the industry carved out the runtime piece (containerd) as infrastructure plumbing. The meme’s “Always has been” punchline lands because it’s literally true – from Docker version 1.11+ onward, Docker has always had containerd inside. The whale has always been riding on this smaller dolphin, so to speak.

One more layer of humor is the absurdity of the classic meme imagery: an astronaut discovering an Earth-shattering truth, only to be met with a gun-toting accomplice confirming it was obvious. Here the deprecated Docker shim is that gunman. It’s as if the Kubernetes community is saying, “Yes, Docker was just a frontend. We’re removing it now.” The shared trauma (or relief) among DevOps folks is real – we've all dealt with sudden deprecations and had to adapt. But we also appreciate the irony: the tool that everyone associates with containers was never the whole story. In true DevOps humor fashion, the meme turns a potentially alarming change (Docker being dropped from K8s) into a laugh about how container tech actually works. It’s a gentle ribbing: “Did you think the whale itself runs containers? Nah, mate, there’s a little runtime under the hood – always has been.”

Level 4: Containers All The Way Down

Under Docker’s friendly blue whale logo lies a layered container runtime architecture that goes deep into the operating system. Docker isn’t a standalone magic box – it’s more like a wrapper around lower-level components. At the core, containerd (Docker’s default runtime daemon) orchestrates container processes using runC, which in turn leverages Linux kernel features like namespaces (isolating processes, file systems, etc.) and cgroups (limiting resources). It’s a stack of technologies, each layer relying on the one below – containers all the way down. Docker’s docker CLI and daemon (dockerd) sit at the top, providing a user-friendly interface. But when you run a container, the Docker daemon hands off the heavy lifting to containerd, which launches the container via runC and those kernel isolation primitives. This design follows a classic systems architecture pattern: high-level tools delegating to specialized lower-level components for actual execution.

Originally, Docker itself included all the container management logic internally (using LXC in very early versions, then its own library). Around 2016, Docker spun out containerd as a separate daemon to modularize responsibilities. Containerd became the container runtime responsible for managing the container lifecycle (pulling images, creating containers, snapshotting filesystems), while Docker’s daemon became more of an orchestrator and UX layer. In fact, the “d” in containerd stands for “daemon,” indicating it’s a background service. This architectural decoupling made it possible for other systems to reuse containerd independently of Docker’s CLI. The Cloud Native Computing Foundation (CNCF) later accepted containerd as a project, signifying its importance beyond just Docker itself.

This layered approach is also the backbone of Kubernetes and other orchestration systems. Kubernetes uses a standardized Container Runtime Interface (CRI) to talk to any container runtime. Dockershim (now deprecated) was a Kubernetes component acting as a translator between Kubernetes and the Docker Engine. But since containerd was always doing the actual container ops under Docker’s hood, Kubernetes eventually evolved to cut out the middle layer. Instead of going Kubernetes -> Docker -> containerd -> Linux, it can go Kubernetes -> containerd -> Linux directly via CRI. Fewer layers mean less overhead and fewer failure points – a very “unix philosophy” style simplification. The Always has been meme humorously captures this truth: the ubiquitous Docker whale was always powered by containerd underneath. The astronaut with the gun labeled DEPRECATED is essentially Kubernetes telling us that the older Docker shim layer is going away, revealing that containerd was the real workhorse all along.

The meme’s punchline also hints at progress in container tech, like rootless container runtime modes. Traditionally, container daemons had to run as root (the admin user) because creating namespaces and cgroups required privileges. Recently, both Docker and containerd introduced rootless modes – meaning containers can be launched without full root privileges by using user namespaces and other clever kernel features. This improves security by running the container engine as a non-root user. It’s a nuanced detail (and a bit of an advanced trick), but it reflects how the container ecosystem is maturing behind the scenes. In essence, the image’s revelation (“Wait, it’s all containerd?”) is a nod to the sophistication beneath Docker’s simple UX – a reminder that even in DevOps and containerization, there’s an entire universe of lower-level engineering making the easy things possible. It’s container stacks and abstractions all the way down, and the whale was just the tip of the iceberg.