[embik]

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.

[1] https://cloud.google.com/kubernetes-engine/docs/deprecations...

[georgyo]

> They have

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.

[embik]

> 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?

[boloust]

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.

[yjftsjthsd-h]

> 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.

Edit: Actually, it looks like if you want to add docker it's easy - https://kubernetes.io/docs/setup/production-environment/cont... - but you would have to install that support since it is not included out of the box.

[boloust]

It seems like your view is informed from a cursory reading of the docs, rather than any first-hand experience.

Docker produces OCI images, there's no need to "export them" in that format.

So since Kubernetes can run any OCI image, and Docker images are OCI, Kubernetes supports running Docker images out of the box.

The documentation you linked to is if you wanted to swap out the container runtime Kubernetes is using, not if you just want to run a Docker image.

[yjftsjthsd-h]

> It seems like your view is informed from a cursory reading of the docs, rather than any first-hand experience.

Fun though personal attacks are, you would be wrong; I have done all of this, including using docker to build images and k8s to run them.

> Docker produces OCI images, there's no need to "export them" in that format.

Sure.

> So since Kubernetes can run any OCI image, and Docker images are OCI, Kubernetes supports running Docker images out of the box.

...Kubernetes supports running OCI images out of the box. That they were built by docker does not make them docker images, any more than building a Windows program with MinGW creates a "Linux program" just because it was compiled on Linux. If you use docker to build an OCI image and then create a container from that image in a stock k8s cluster, you are not creating a docker container, you are creating a (most likely) containerd container from an OCI image.

> The documentation you linked to is if you wanted to swap out the container runtime Kubernetes is using, not if you just want to run a Docker image.

Yes, I was attempting to charitably include the case where your claim could still be correct. (Since by adding the docker runtime you can create a k8s cluster that creates docker containers.)

[embik]

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.

[georgyo]

The install instructions still explicitly lists docker engine as container runtime.

https://kubernetes.io/docs/setup/production-environment/cont...

The dockershim removal FAQ says how to continue to use docker engine.

https://kubernetes.io/blog/2022/02/17/dockershim-faq/

-- 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.