Let's look at one of the newer and Kubernetes-specific OCI-based initiatives, CRI-O. CRI-O is currently part of the Kubernetes incubator, but it may move out to its own project as it matures. One of the compelling parts of the CRI-O design is that it never breaks Kubernetes. This is different because other runtimes are designed to do many things, such as building images, managing security, orchestration, and inspecting images. CRI-O is only designed to help Kubernetes orchestrate and schedule containers.
To this end, CRI-O is developed congruently with the CRI itself, and aligns itself with upstream releases of the Kubernetes system. The following diagram shows how the CRI-O works with the OCI:
In order to achieve this workflow, the following happens:
- The operator decides to start a pod, which causes Kubernetes to use the kubelet to start a pod. That kubelet talks through the CRI to the CRI-O daemon.
- CRI-O then uses several libraries, built with the OCI standard, to pull and unpack the given container image from a registry. From these operations, CRI-O generates a JSON blob that is used in the next step to run the container.
- CRI-O kicks off an OCI-compatible runtime, which then runs the container process. This could be runc or the new Kata Container runtime (which has absorbed Intel's clear containers initiative).
You'll notice here that the CRI-O is acting as an interleaving layer between the libraries and runtimes, such that it's using standard formats to accomplish most its goals. This ensures the goal is making Kubernetes work at all times. Here's a diagram showing the system of the flow that was described in this section:
For networking, CRI-O would leverage the Container Networking Interface (CNI), which is similar to the CRI, but deals with the networking stack. You should begin to see a pattern emerge here.
CRI-O is an implementation that helps to implement the OCI specification. This allows users to take for granted the container runtime being used as an implementation detail, and to focus instead on how the application is interacting with the objects and abstractions of the Kubernetes system.