The container runtime space gained a slimmer member with the initial 1.0 release of CRI-O. The runtime provides an integration path between Open Containers Initiative (OCI) conformant runtimes and Kubernetes kubelets.

CRI-O, which combines container runtime interface (CRI) with the “O” in OCI, is focused exclusively on the Kubernetes environment. A container runtime provides an application programming interface (API) and tools that abstract low-level technical details in the container.

The CRI-O runtime allows for a container to be run directly from Kubernetes without any changes to code or tooling. Those containers do need to be OCI compliant.

The OCI in July released the first version of its open-source container runtime and image format specification. The specifications support container portability across different implementations, including compliant operating systems and platforms.

Kubernetes was previously tied to specific container runtimes through an interface that required maintenance overhead for the upstream Kubernetes community and vendors building on the platform.

CRI-O works with other OCI-based runtimes like runC and Clear Containers’ runV. Joe Brockmeier, senior evangelist for Linux Containers at Red Hat, said CRI-O should support any OCI-conformant runtime.

CRI-O also uses already established container libraries like containers/storage and containers/image, with networking through the Container Network Interface (CNI) standard.

The initial version is based on the Kubernetes 1.7 release, which was unveiled in late June. CRI-O support was included in the latest Kubernetes 1.8 update late last month. A 1.8 version of the runtime is scheduled to be “released soon” so as to link up numerically with Kubernetes.

Daniel Walsh, a consulting engineer at Red Hat, in a blog post on the 1.0 release described CRI-O as being different from other runtime options by not attempting to do much.

“We did not want to pull all of the locking and container state into memory like some other container runtimes have, which prevents other processes on the system being able to work with images and storage,” he wrote. Walsh added the smaller footprint allows for better Kubernetes performance compared with other container runtimes.

The runtime supports OCI container images and is an alternative to Docker’s Moby or containerd, though the CRI-O community plans to contribute to the Moby project.

"CRI-O uses OCI technology, both in terms of the runtime spec and image spec," explained OCI Director Chris Aniszczyk. "This is similar to what containerd does, it embeds OCI technology and essentially containerd/CRI-O are competitive OCI implementations."

Containerd is an open source project developed by Docker Inc. and donated to the Cloud Native Compute Foundation (CNCF). CRI-O is also a CNCF project, and is part of the Kubernetes incubator.

CRI-O is open to all via GitHub, with Red Hat’s OpenShift set to be one of the early adopters of the new release. The upcoming OpenShift 3.7 platform is using the release, with plans to move some of its larger user base off of upstream Docker and to CRI-O over the next month.

Work on CRI-O began more than a year ago under the guise of the Open Container Initiative Daemon (OCID). The initial focus was to develop a dedicated Kubernetes CRI to run OCI-compliant containers.

“We felt at the time that the upstream Docker project was changing too quickly and was making Kubernetes unstable,” Walsh wrote. “We felt that perhaps by simplifying the container runtime we could do better.”

The Cloud Foundry Foundation last week updated its Kubo project into the new Cloud Foundry Container Runtime (CFCR), which is the standard CFF approach for deploying containers using Bosh and Kubernetes.