Red Hat contributes CRI-O to the Cloud Native Computing Foundation

The kubelet talks to CRI-O using the CRI gRPC API. The CRI has an image service and a runtime service. The image service is responsible for pulling down images on the node as needed to run containers in a pod. CRI-O uses the containers/image library to pull images to the node. The runtime service is responsible for running the containers. The runtime service uses the containers/storage library to create Copy-On-Write based root filesystems for the containers.

In our development of the coming OpenShift 4, it configures CRI-O with overlayfs as the Copy-On-Write storage driver. CRI-O uses the runtime-tools OCI-generated library to create an OCI configuration that runc can understand. Finally, it launches the containers using runc or any OCI-compatible runtime like kata containers along with a monitoring process called conmon. conmon is a small monitoring process for containers. It is responsible for monitoring a container to record its exit code, writing logs, handling tty for the containers, service attach clients, reaping processes as well as reporting Out of Memory (OOM) conditions. CRI-O utilizes the container networking interface (CNI) for setting up networking for the containers so CNI plugins such as flannel, Cilium, weave or OpenShift-SDN are supported.

CRI-O for Kubernetes users

CRI-O provides a lightweight runtime for Kubernetes. It is focused on managing and running containers in Kubernetes. This supports the security principle of separation of concerns.

CRI-O aims to be Kubernetes first and CRI-O releases follow Kubernetes in lock-step. Each Pull Request to CRI-O has to pass the Kubernetes e2e test before it is merged. CRI-O releases packages for various Linux distributions, supported by tools such as minikube and kubeadm to setup Kubernetes clusters using CRI-O as the runtime. CRI-O releases support all the Kubernetes supported versions, matching their most recent three minor releases.

The same unmodified CRI-O is supported in Red Hat OpenShift as well. It has been offered as an option to customers since OpenShift 3.9 and is planned as an option in the upcoming OpenShift 4 releases.

Differences between CRI-O and other runtimes

CRI-O limits its scope to that of Kubernetes and focuses on only adding features that are needed by Kubernetes and nothing more. This narrow focus drives stability, performance and security features down the stack, allowing the cloud native ecosystem to reliably focus at the Kubernetes layer and above.

There are other projects such as containerd, Docker daemon, Pouch Container, or Singularity that can provide a CRI socket, but they also accommodate additional use-cases. For example, the docker daemon differs from CRI-O in that it is one large tool that is used for many purposes and by many roles. The docker daemon is used to build containers, manage containers, run containers, and inspect containers. While a developer needs to do all these tasks while developing a containerized application on their laptop, security principles of least privilege are better achieved in production environments by using different tools for different purposes.

CRI-O does include some trouble shooting capabilities, but intentionally does not include container build APIs, instead relying on the Kubernetes CRI-API. For interacting with CRI-O (and similar runtimes) there are tools like the Kubernetes-SIGs `crictl`.

Get involved