Kubernetes container run-time, what is it for ? What are the options ?
Once you deploy your primary Kubernetes cluster, you can install the Kubernetes application. The first Kubernetes application is not a Kubernetes application; it’s not even a component. The container runtime.
This post is about the need for container runtime, what it is for, and what CRI is — the container runtime interface. On every Kubernetes node, there must be a container runtime, as Kubernetes run containers. Not only applications or data-based run on containers but also the Kubernetes processes themselves, such as API server, Scheduler, controller manager, etcd, and others. So a container runtime must run on the primary node and worker nodes.
How to choose a container runtime?
There are several container runtimes you can choose from; Kubernetes doesn’t care about the container runtime you plan to use, and this provides the flexibility of any container runtime we want. When Kubernetes started, there needed to be more flexibility. It supported Docker runtime as it was the first container runtime by having code to talk to Docker directly into the kubelet code. As you already know, Kubelet runs on every node, master, and node and talks to Docker to make it a scheduled containers. That code that communicates with Docker was inside the Kubelet code. As more container runtime emerged, Kubernetes made it more flexible and allowed other container runtime usage with Kubernetes. But, walking the same path as Docker and integrating it into Kubelet code will be time-consuming and increase the code maintenance effort for Kubernetes developers as you will need different code for each container runtime. The solution was to create a generic interface, and any container runtime that implements that interface could be plugged into. That’s CRI- Container Runtime Interface.
What is CRI?
The CRI is a set of rules that defines what container runtime must implement and how to allow pluggable to Kubernetes as the container runtime. Using this interface, Kubelet can talk to it, schedule containers, pull images, etc. Docker did not implement a container runtime Interface (I assume, as they were the first in the industry, they saw it as cannibalizing their business). At this point, Kubernetes developers had to integrate Docker into CRI. What they have done is develop a DockerShim, which is a layer in their code for Docker specifically. The DockerShim is a bridge and part of Kubernetes code that allows Kubelet to talk to Docker to talk to container runtime API.
What’s wrong with Docker container runtime?
Docker was the first and most popular container runtime and critical to support, but Docker is more than just a container runtime. It is also part of building the images; whenever a developer writes an application that needs to be deployed as a container, you create a docker image. It also has its own CLI and UI. It is more apparent now that container runtime is just one part of Docker technology, but Kubernetes needs only the container runtime to operate and not all Docker components. As time passed and more container runtime lightweight technology was introduced. The new container runtime had only some extra details that Kubernetes didn’t need. Two of the most popular container runtime emerged are container d and Cri-o. As a result, Kubernetes decided to deprecate the DockerShim as it’s not compatible with CRI and altogether remove it. Does it mean that you will not be able to use DockerShim? No, Docker is supporting it. However, it is better to use a lightweight container runtime, especially since Docker images are compatible with other container runtimes, so there is no problem creating Docker images for your app and running them in container.d, and that will work just fine. What do cloud platforms do? AWS, AZURE, GCP, and others use the container.d runtime. I use container.d as I find it easy to install as Docker. The only disadvantage I see is you will not have Docker commands anymore. Still, you should be fine if you worked at the Kubernetes level using Kubernetes tools to troubleshoot apps.
The CRI is a set of rules that defines what container run-time must implement and how to allow pluggable to Kubernetes as container run-time. Using this interface Kubelet will be able to talk to it, schedule containers, pull images, etc. Docker did not implement a container run-time Interface (I assume as they were the first one in the industry they saw it as cannibalizing their business). At this point Kubernetes developers had to integrate Docker into CRI, what they have done is develop a DockerShim which is a layer in their code for Docker specifically. The DockerShim is a bridge and is a part of Kubernetes code that allow Kubelet to talk to Docker to talk to container run-time API.
What’s wrong with Docker container run-time?
Docker was the first and most popular container runtime and critical to supporting, but docker is more than just a container run-time, it is also part of building the images whenever a developer writes an application that needs to be deployed as a container you build a docker image out of it. It also has its own CLI and UI. It is more clear now that container run-time is just one part of Docker technology, but Kubernetes needs only the container run-time to operate and not all Docker components. As time passed and more container run-time lightweight technology was introduced. The new container run-time didn’t have all the extra components that Kubernetes doesn’t need. Two of the most popular container run-time that emerged are container d and Cri-o. As a result, Kubernetes decided to deprecate the DockerShim as it’s not compatible with CRI and completely remove it. Does it mean that you will not be able to use DockerShim? No, Docker is supporting it. However I think it better to use a lightweight container run-time especially since Docker images are compatible with other container run-times, so no problem with creating Docker images for your app and running them container.d and that will work just fine. What do cloud platforms do? AWS, AZURE,GCP, and others use the container.d run-time. I use container.d as I find it easy to install as Docker, the only disadvantage I see is you will not have Docker commands anymore, but if you working at Kubernetes level using Kubernetes tools to troubleshoot apps you should be fine.
Join my Linkedin