What is CRI-O?

CRI-O is an im­ple­men­ta­tion of the Container Runtime Interface (CRI) for Ku­ber­netes, using “Open Container Ini­tia­tive” (OCI) images and runtime en­vi­ron­ments. The project was launched in 2016 by the company Red Hat and handed over to the “Cloud Native Computing Foun­da­tion” (CNCF) in spring 2019.

To un­der­stand how CRI-O works and how it interacts with related tech­nolo­gies, it is worth looking at the his­tor­i­cal de­vel­op­ment of container-based vir­tu­al­iza­tion. The basis for its creation was the Docker software which made the vir­tu­al­iza­tion of in­di­vid­ual apps based on light­weight con­tain­ers main­stream. Be­fore­hand, vir­tu­al­iza­tion was primarily un­der­stood as the use of virtual machines. A virtual machine contains an entire operating system, whereas several con­tain­ers access a shared operating system kernel.

A container usually contains a single app which often provides a micro-service. In practical use, several con­tain­ers are usually con­trolled together to implement an ap­pli­ca­tion. The co­or­di­nat­ed man­age­ment of entire groups of con­tain­ers is known as or­ches­tra­tion.

Even if or­ches­tra­tion with Docker and tools like Docker Swarm is feasible, Ku­ber­netes has prevailed as an al­ter­na­tive to Docker. Ku­ber­netes combines several con­tain­ers in a so-called pod. The pods in turn run on so-called nodes – these can be both physical and virtual machines.

One of the main problems with Docker was its mono­lith­ic ar­chi­tec­ture. The Docker daemon ran with root rights and was re­spon­si­ble for a multitude of different tasks: from down­load­ing the container images to executing them in the runtime en­vi­ron­ment to creating new images. This merging of in­de­pen­dent areas violates the software de­vel­op­ment principle “Sep­a­ra­tion of concerns” and leads to security issues in practice. Therefore, efforts were made to decouple the in­di­vid­ual com­po­nents.

When Ku­ber­netes was released, the Ku­ber­netes daemon kubelet contained a hard-coded Docker runtime en­vi­ron­ment. However, the need to support other runtimes soon became apparent. Mod­u­lar­iza­tion of the in­di­vid­ual aspects promised a sim­pli­fied de­vel­op­ment and higher security. To make various runtimes com­pat­i­ble with Ku­ber­netes, an interface was defined: the Container Runtime Interface (CRI). CRI-O is a specific im­ple­men­ta­tion of this interface.

In principle, using CRI-O consists of the following steps:

1. Download an OCI container image
2. Extract the image into an OCI runtime file system bundle
3. Execution of the container by an OCI runtime

Currently, CRI-O is primarily used as part of Red Hat’s OpenShift product line. OpenShift im­ple­men­ta­tions exist for cloud platforms from all major providers. Fur­ther­more, the software can be operated as part of the OpenShift Container Platform in public or private data centers. Here is an overview of the various OpenShift products:

CRI-O is a rel­a­tive­ly new de­vel­op­ment in container vir­tu­al­iza­tion. His­tor­i­cal­ly, there are several al­ter­na­tive container runtimes. Perhaps the most unique selling point of CRI-O is its singular focus on Ku­ber­netes as the en­vi­ron­ment. With CRI-O, Ku­ber­netes can execute con­tain­ers directly without ad­di­tion­al tools or special code ad­just­ments. CRI-O directly supports the existing, OCI-com­pat­i­ble runtimes. Here is an overview of actively developed and fre­quent­ly used runtimes: