Kubernetes and Docker Fiasco…

This has been something that's exploding all over the internet. I'm primarily on Twitter from a social media perspective, and I've seen it a lot. There's a lot of scared folks that have simply put in SO many hours with Docker and learning it. Now they're nervous that the time they put in won't pan out.

The time, hours, and passion you put into learning Docker is STILL very much going to be useful. The simple fact is, the whole "runtime not being supported thing" isn't that big of a deal. In fact, some say it was even planned.

Let's start with one key component - Docker is a full stack of tools and isn't just a runtime. Also, Docker != containers.

Docker has so many factors:

1. Dockerhub
2. Docker images
3. Dockerfiles
4. Docker compose
5. And many others...

Everything I listed above is still very much going to be used. Docker images can still be created the way they always have been. Dockerfiles can still be used to create those images. The only thing that won't be used is the Docker runtime.

Let's break that down a bit.

Kubernetes uses container runtimes, which include:

1. CRI-O
2. containerd
3. Docker

Starting at Kubernetes API version 1.20, Docker won't be part of that list anymore. However, Docker has put a TON of time into containerd, which will still very much be used. In fact, Docker created the containerd project for a clean break-away from the core Docker engine.

Really, the only thing that's changing is that middle layer:

Kubernetes <-- Docker <-- containerd Take out "Docker" and you still have everything else. Using the Docker runtime was always a "means to an end" with the growing support of containerd and CRI-O. So, TLDR? The Docker runtime being removed isn't a big deal. In fact, a lot of us probably won't even tell the difference.

15 thoughts on “Kubernetes and Docker Fiasco…”

  1. v1.20 will still work with Docker, Dockershim won’t be removed until at least v1.23 so you have until around October 2021 to switch to Containerd or CRI-O and that’s if you keep up with latest.

    \> What’s actually happening here is that Dockershim is being removed from Kubelet as early as v1.23 release, which removes support for Docker as a container runtime as a result.
    \> Ref: [https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/)

  2. I’m out of the loop… Can anyone provide some links.. I mean it’s well introduced here.. But I wanted to have some deeper look into that and try to get the why behind that decision… Maybe there’s already some people (some DevOps YT channels) explaining that?

    Edit: very well explained here BTW (the title was misleading for me). Thanks OP..

  3. If container runtime changes does it change the underlying architecture of container engine or does it follow a standard? For example the main app/process in container cannot be killed and needs dumbinit if it has to happen and docker dameon would replace it. What set of architectural changes that CRI-O brings to table ?

    [OOMyPod: Nothin’ To CRI-O-bout • Capsule8](https://capsule8.com/blog/oomypod-nothin-to-cri-o-bout/)

  4. > Starting at Kubernetes API version 1.20, Docker won’t be part of that list anymore.

    [1.22 or 1.23, late 2021, is when they are expecting to fully drop dockershim.](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/)

    They are working closely with stakeholders to deal with things that are still dependant on dockershim. From what I’ve seen the gorilla in the room is nVidia who needs to create a proper device plugin.
    Frankly most CNCF distributions are using containerd on the backend since it’s lighter and simpler to manage.

  5. Maybe people who do not understand that shouldn’t be setting up production servers / services but instead study a bit of documentation and get a real understanding of the technologies they use?


Leave a Comment