Kubernetes 1.24 landed on the third of May, and the line everybody quoted was that dockershim had been removed from the kubelet. The version of that sentence which reached most people, including a couple of the developers I work with, was "Kubernetes is dropping Docker".

I do not run Kubernetes. I run containers on ECS and on machines, and Kubernetes sits on my list of things I read about deliberately so that when it does turn up I am not learning it under pressure. This release was worth an afternoon precisely because the confusion around it is a good lesson in what a container actually is.

Four things wearing the same name

"Docker" means at least four separate things, and the removal touches exactly one of them.

There is the image format — the layered filesystem and manifest you build with a Dockerfile. There is the registry protocol that ships those images around. There is the Docker Engine, the daemon that runs containers on a machine. And there is the docker CLI that most people actually mean when they say the word.

The image format and the registry protocol are standardised. They are OCI specifications, and every runtime in this ecosystem reads them. That is the reason the Kubernetes announcement is able to say, flatly, that images which ran before will run unchanged afterwards. Nothing about what you build changed.

What was actually removed

Kubelet talks to a container runtime through the Container Runtime Interface. The Docker Engine does not speak CRI — it predates it — so the Kubernetes project maintained a shim called dockershim that translated between the two.

That meant the kubelet codebase carried two paths: one for every CRI runtime, and one special case for Docker. Deprecated in 1.20, removed in 1.24. The clusters that are affected are the ones whose nodes were configured to use Docker Engine as the runtime; they need containerd, or CRI-O, or cri-dockerd if they really want to keep Docker Engine underneath.

That is the whole change. It is a node-level configuration concern for cluster operators, and it is invisible to anybody writing a Dockerfile.

The detail I enjoyed is that containerd was inside Docker all along. Docker Engine uses containerd to run containers; the removal takes out the layer above it and lets the kubelet talk to containerd directly. Fewer moving parts doing the same job.

The part that does change for a developer

One thing genuinely goes away on nodes that switch: docker ps on the node no longer shows you the containers Kubernetes is running, because Kubernetes is not using Docker Engine to run them. The equivalents are crictl, or the cluster's own tooling.

That matters more than it sounds like. Every debugging habit built on "SSH to the node and run docker logs" stops working, and the muscle memory is the expensive part of the migration rather than the configuration.

Why I read a release for software I do not run

Two reasons, and the second is the one I would defend.

The first is that this is the clearest example I have seen of an interface doing its job. The OCI image spec meant a runtime could be swapped underneath an entire ecosystem and the artefacts kept working. If images had been a Docker implementation detail rather than a specification, this release would have been a migration for everybody instead of a configuration change for cluster operators.

The second is that I would rather learn a system's shape while nothing is on fire. I have spent enough time on the other version of that — reading documentation at speed because something is down — to think that an afternoon spent on a release note for a tool you might use later is cheap.

And the misreading is instructive on its own. "Kubernetes drops Docker" was technically wrong and socially inevitable, because the word covers four things and the sentence only meant one of them. That is not really a Kubernetes problem. It is what happens when a product name becomes the name of a category.