[embik]

> Kubernetes x Docker: Best Friends Forever

> Whenever you hear Kubernetes, you’re probably going to hear Docker in the same sentence. Kubernetes and Docker are like peanut butter and jelly—they’re a perfect pair.

For what it's worth, this article was originally written in October 2021, but even at that point it was clear that Kubernetes would remove support for docker. In fact it has already with Kubernetes 1.24. Not exactly "Best Friends Forever". I wish people writing this kind of introductory blog posts would take the time and just quickly explain container runtimes instead of just mentioning docker and be done with it.

[gerwim]

While you are technically correct, kubernetes removed the Dockershim. Docker is often used as a synonym for containers. However, most of the things should still work [1].

[1]: https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-...

[embik]

I am very much aware of this, but that's exactly what I am arguing. Articles setting out to explain Kubernetes should not perpetuate the false equality of docker and containers.

[yonixw]

If you use `docker build/run` in your bash, it will actually be more confusing IMO saying k8s "dropped docker(shim) support". This fact should be a footnote for the curious reader, surely on an introduction article.

[xyzzy_plugh]

It would do the industry a world of good to move past conflating Docker with Linux containers, containerization, images, etc.

There are tons of ways to build containers without Docker. You're effectively encouraging propagating confusion.

[zekrioca]

Indeed, and I have zero idea why people don’t use something like LXC and still prefer Docker. Marketing is hell sometimes.

[stetrain]

> remove support for docker

So I can't use Dockerfiles and `docker build` to build things for k8s?

[vbezhenar]

This is not correct.

Kubernetes used docker engine under the hood in the past. Now they abstracted useful part of this engine into API. There's implementation from the docker (containerd), there's implementation from Redhat (CRI-O), may be others. Docker don't have to be installed for Kubernetes to work anymore.

Building container images is a different topic. Kubernetes does not have anything to offer here. So you probably still need docker in your development machine and in your CI pipeline to build those images. There are plenty of alternatives rised in recent years, most prominent ones are kaniko, buildah/podman, but they're far from docker in their maturity.

That actually makes a problem. It's hard to run docker and kubernetes side-by-side. Or docker inside kubernetes. So if you want to run your CI jobs inside Kubernetes, there's no good solutions right now.

I think people will eventually migrate to Kaniko. It's from Google, it seems to be a sane approach. But right now it's a mess.

[urthor]

This is correct.

K8s abstracted out containerization in preparation for the anticipated long term migration of the ecosystem to Podman et al (lots and lots of people are invested in moving "containers" away from "Docker").

[moondev]

I don't think podman is designed or supported as a CRI. It's for local development. You can create local "pods" without an API server, but not running containers on a real Kubernetes node. That would be containerd, crio, or cri-dockerd.

With that said I still prefer docker for local development by creating real ephemeral clusters with kind

[endingwithali]

Author here! Yeah, the article is out of date but thats okay -

honestly, your suggestion for container runtimes is a great idea - it's now on my list of blog posts to write! I'll be sure to credit you :)

[altdataseller]

Does this apply to GKE? Are they going to remove support for Docker as well (or did they?)

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

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