Lesson 2: Docker vs ContainerD

In the beginning, there was only Docker back in the day, and other tools like rocket were used to run the containers.

The user experience for Docker was super easy to work with, so Docker became the most dominant container runtime engine.

And then came the kubernetes to orchestrate Docker. So Kubernetes was used to orchestrate Docker in the beginning. So Docker and Kubernetes were tightly coupled, and back then, Kubernetes only worked with Docker and didn't support any other container solutions. So Kubernetes gained popularity as a container orchestration tool. Other container runtimes, like Rocket, were wanted, so Kubernetes workers wanted other solutions to work with it other than Docker.

So Kubernetes introduced an interface called CRI (Container Runtime Interface). CRI allowed any vendor to work as a container runtime for Kubernetes as long as they adhered to OCI standards.

OCI stands for Open Container Initiative, which consists of imagespec and runtimespec.

Imagespec means specifications on how the image should be built.

Runtimespec defines how any container runtime should be developed. So keeping these standards in mind, anybody can build a container runtime that can be used by anybody to work with Kubernetes.

So Rocket and any other container runtime that adheres to OCI standards can now be used with Kubernetes via CRI.

However, Docker wasn't built to support CRI. It was built earlier than CRI came into existence, and Docker was still the dominant container runtime used with Kbernetes. So kubernetes have to continue to support Docker. And so Kubernetes introduced Docker Shim, which is something that can be used instead of Docker temporarily to continue to support Docker outside of CRI.

Most of the container runtimes used to work through the CRI, but Docker continued to work without it.