Question 194377 in Docker Question posted in
The official documentation can be found here.

What is the history of using dockershim with containerd in Kubernetes?

I’m currently studying the Container Runtime Interface (CRI) in Kubernetes and have a question that came up during my studies.

Since version 1.20, Kubernetes has discontinued support for Dockershim, which means Docker cannot be used as a CRI anymore.

However, I discovered that Docker internally relies on containerd, and when setting up a cluster using kubeadm and installing Docker Daemon, the Kubernetes cluster initialization worked smoothly without any issues.

So, does this mean that Kubernetes can function properly even without support for Dockershim?

The scenario I have in mind is as follows: Initially, Kubernetes was built with a dependency on Docker and managed containers through an interface called Dockershim.

However, Docker internally used the CRI called containerd, and since Kubernetes no longer needed Dockershim, it discontinued support for it.

Is my understanding correct?

Tags:

2

Answers


  1. 0

    Dockershim is also a CRI and it was, in fact, the first one ever supported with Kubernetes. Over time they have adopted more and more CRIs with the most significant one being containerd back in 2018: read more here — and containerd is still supported to this day along with other CRIs as you can see here

    Even though dockershim is no longer supported there are still plugins/adapters to offer support for Docker Engine. There are also initiatives that run DinD (docker in docker) images on containerd to support building docker images (CI context) inside k8s clusters for example.

    To answer your question:

    So, does this mean that Kubernetes can function properly even without support for Dockershim?

    Dockershim is just a small part of Docker itself and it represents only the runtime — which is in fact an "adaptation" of sorts to make Docker work with K8s in the first place. Everything else is still very much in support. To quote their viewpoint from back when they announced dropping dockershim:

    You see, the thing we call “Docker” isn’t actually one thing—it’s an entire tech stack, and one part of it is a thing called “containerd,” which is a high-level container runtime by itself. Docker is cool and useful because it has a lot of UX enhancements that make it really easy for humans to interact with while we’re doing development work, but those UX enhancements aren’t necessary for Kubernetes, because it isn’t a human.

    You can read more about it from the post where that quote was extracted from here

    I really hope this helps your studies!

    Login or Signup to reply.
  2. 0

    Since version 1.20, Kubernetes has discontinued support for Dockershim…

    Should be 1.24.

    Kubernetes can function properly even without support for Dockershim?

    Yes and the opposite is equally true with docker adapter for K8s.

    …Docker internally used the CRI called containerd,

    No. CRI is K8s API standard for integration with any container engine (e.g containerd) that implemented the interface. Docker engine is not CRI compliant. Docker integration with containerd is native.

    …Kubernetes no longer needed Dockershim, it discontinued support for it.

    This was well explained here. It’s worth mention that docker has support to many other features (eg. build, swarm etc) that are not required by an container orchestrator like K8s.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search