Developer perspective into OCI, CRI, runc and cri-o.
Recently I came across cri-o when I was setting up some docker build tasks and was planning to integrate it with OpenShift pipeline. My primary task was to build my Spring boot application but was introduced to a new term cri-o. I try to understand how cri-o will impact me as a developer but got me super confused with so many terms and so many integration points. This motivated me to come up with this blog post to explain these terms from a developer viewpoint.
NOTE: This is just a developer perspective. I will not be digging into infrastructure level details. The intention here is just to make sure that as developers of business applications we are aware of the latest changes in our containers and their orchestrator.
What is OCI?
Open Container Initiative (OCI) is a Linux project which aims at designing standards for Linux Containers formats and runtimes. Try to understand in this way we have Rx-Java specification and then we have Jersey as its default implementation. Similarly OCI is a specification for containers runtime. This was required to make sure every other container implementer is following same principles and thus to standardise the container space.
What is runc?
runc is container format and runtime donated to OCI by docker. This is the first OCI compatible runtime. This means if we are using runc with Kubernetes our application will be running inside a runc container and not a docker container.
What is CRI?
Kubernetes is a container orchestrator which at a much lower level has ‘Container Runtime’ which among other thing manages container startup and shutdown. The most popular runtime which we have seen is docker and this is the one which I have used in all my previous demos. However recently we had many new runtimes like rkt, kataContainers. This resulted in a problem for Kubernetes as they need to support multiple implementations of runtime. “Container Runtime Interface (CRI)” was introduced to solve this problem.It allows a runtime provider to implement the interface for its runtime which will then be used by Kubernetes. You can think of CRI like a plugin API whose client is Kubernetes(Kubelet) and server is the container runtime provider(must be OCI compliant). The onus of implementing the server side lies with the runtime provider and frees Kubernetes from implementing interfaces for different runtimes.
What is cri-o?
Finally cri-o is nothing but the default implementation of CRI which by default uses runc as the container runtime but we can use any OCI compliant runtime in principle. If we are using cri-o we are actually using all the above concepts we have mentioned so far in this blog. The main objective of cri-o is to provide a light weight and optimised runtime for Kubernetes. If we are using cri-o our applications will be running inside runc containers and we can reach our containers either by using kubectl or by using runc cli.
To summarise take a look at the below diagram to understand what component fits where
Pulkit Gupta 