CRI & containerd Explained

Have you ever wondered what container technologies are being used for Kubernetes?

Is it Docker? Well, in this article, I’ walk you through how kubernetes and docker try to standardize container technologies and grow together. More specifically, I will answer the question, what is CRI or containerd and how they communicate with each other.

Proliferation of container technologies

10 years ago, Docker had dominated a container field, and there was no option that you could choose apart from Docker. If you use container, it was Docker. the most obvious choice.

But few years later, other container runtimes started appearing such as cri-O and rkt.

Standardization of the interface (CRI)

As an container industory, they wanted to standardize the interface so that Kubernetes or other container orchastration tools (e.g. Apache Mesos) doesn’t have to worry about how each container technologies create a container or pull an image. As a Kubernetes, they just want to call the same request and get the same response regardless of the underlying technologies.

That is where CRI (Container Runtime Interface) comes in. CRI itself is just a Protocol Buffer in gRPC. You can find the actual “.proto” files here.

If you are not familar with gRPC, you can think of it as a model in any Backend frameworks (e.g. Entity in Spring, Model in Django), but it can be universally used across multiple languages.

So all the container technologies tried to implement this to accept the request from Kubernetes, except for one.

It was Docker. Docker has its own defined interface and didn’t adopt the interface for some reasons.

The first solution: docker-shim

To make docker compatible with Kubernetes, Kubernetes maintained something called “docker-shim”. It was a kind of translator between CRI and Docker, simply converting the request from Kubernetes to docker-specified request and vice versa.

But it was against standardization and Kubernetes needed to maintain 2 interfaces which was the opposite from the initial purpose.

[Kubernetes support for Docker via dockershim is now removed.](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/)*

The second solution: containerd

To overcome this challenge, Docker took an action. They thought why don’t we create the CRI-compatible underlying software and create Docker on the top of it.

One of the reasons why it was difficult for Docker to adopt CRI was because they have many features as a container service beyond a container runtime. So they created containerd to follow CRI, not Docker itself.

https://blog.purestorage.com/purely-educational/containerd-vs-docker-whats-the-difference/

Now, Kubernetes and Docker shares common container runtime and containerd would be the most prominent runtime nowadays.

You can find the implementation of CRI in containerd in the following url.

• [pkg/cri/server/sandbox_run.go:61](https://github.com/containerd/containerd/blob/release/1.6/pkg/cri/server/sandbox_run.go#L61)
• [pkg/cri/server/sandbox_run.go:422](https://github.com/containerd/containerd/blob/release/1.6/pkg/cri/server/sandbox_run.go#L422)

ref: https://addozhang.medium.com/source-code-analysis-understanding-cnis-usage-from-kubelet-container-runtime-24d72f29466b

Deep Dive: containerd

We understand what contained is and the history behind it. Now let’s unerstand containerd itself. There are a few components you should know.

• containerd daemon
• containerd-shim
• runc

containerd daemon

This is the main part of containerd. (It is usually just called containerd). This handles all gRPC requests/response from Kubernetes and delegate tasks to containerd-shim per container/pod.

https://github.com/containerd/containerd/blob/main/docs/historical/design/lifecycle.md

containerd-shim

This is a process to handle one pod by default. It takes care of creating/stopping “container” using runc or mounting the filesystem and more. This also communicates with containerd daemon via gRPC (ttrpc).

runc

This is another big topic of container, but it is essentially the core of container technologies. This will make system calls to kernel, manipulating Linux namespace, cgroup, Seccomp and more to make a process segregated from other resources (aka container). What we discussed earlier is management of containers including containerd daemon, but runc is an actual juicy part of container magic.

We can summarize these components as the following diagram.

https://github.com/containerd/containerd/blob/main/docs/cri/architecture.md

More specifically, the flow looks like this from kubelet to an actual container.

Conclusion

This time, I focused on container runtime, I hope it helps you undersntand docker or kubernetes better.

But This is one aspect of container, and there are also Container Network Interface (CNI), and Container Storage Interface (CSI).

So stay tuned for them. Good bye 👋

Reference

https://iximiuz.com/en/posts/container-learning-path/

which file being executed for containerd gRPC

containerd-shim

github — Architecture of CRI

The tool that really runs your containers: deep dive into runc and OCI specifications

[embed]cri-api/pkg/apis/runtime/v1/api.proto at c75ef5b473bbe2d0a4fc92f82235efd665ea8e9f ·… Container Runtime Interface (CRI) - a plugin interface which enables kubelet to use a wide variety of container…github.com

https://addozhang.medium.com/source-code-analysis-understanding-cnis-usage-from-kubelet-container-runtime-24d72f29466b