They have, with 1.24[1], following Kubernetes upstream. If you are an end user nothing is really going to change from this though, because docker produces container images that can be used in other container runtimes (and in fact, containerd is what powers docker underneath today anyway). But that's why it's so important to explain that containers != docker, otherwise "removing docker support" seems really scary.
The question was did they remove support for docker. They have not.
They simply removed dockershim and no longer special case it.
Your point is that we should stop using a brand name to describe OCI open standard containers. However, like aspirin, the names are interchangable for the vast majority of people.
OCI container doesn't really roll off the toung, and container by itself could mean all sorts of things.
Docker is really the best word to describe what people are thinking about it every day conversation. So much so that I think they are at risk of loose their trademark.
> The question was did they remove support for docker. They have not.
Have they not? Note that the GP asked for GKE specifically. The support page I linked to literally says so:
> GKE will stop supporting node images that use Docker as the runtime in GKE version 1.24 and later
Removing dockershim removed the existing support for docker, because docker does not support CRI (Container Runtime Interface), the API required by Kubernetes. You can go through a third-party solution that adds CRI support on top of docker, but most managed Kubernetes offerings simply removed docker support.
I don't see any argument supporting the claim that docker is the "best word" to describe containers. I am also not aware of ambiguity for the term "(Linux) container" when it comes to operating/deploying software. What else does it mean in that context?
Saying "Kubernetes has removed support for Docker" is incredibly misleading at best, and less charitably, is just plainly wrong.
While it's true that 1.24 does not support docker as the specific container runtime that's directly used by Kubernetes itself, this has approximately zero impact on how the vast majority of beginners would use Kubernetes, as out of the box you're still able to run docker containers.
Probably not the kind of confusing detail that needs to be in an intro to Kubernetes article.
> as out of the box you're still able to run docker containers.
No, you're able to run containers from images produced by docker provided it exports them in OCI format. At no point does k8s see anything to do with docker. Saying docker when you mean container or container image is incredibly misleading at best, and less charitably, is just plainly wrong.
For what it’s worth, the subthread you are commenting on specifically talks about GKE. GKE is removing docker support, period. That’s not plainly wrong, it’s in their support document.
For most users, using docker through a CRI compatibility layer is not an option as they use some sort of Managed Kubernetes, and I am curious to hear which of those keeps supporting docker as container runtime.
--
Linux container could be LXC, systemd-nspawn, snap, flatpak, nixos-container, and many many many other things.
That's because Linux containers are built on Linux interfaces, but Linux itself does not have any prescriptive requirements on how to stich them together.
[1] https://cloud.google.com/kubernetes-engine/docs/deprecations...