Today, the Cloud Native Computing Foundation (CNCF) Technical Oversight Committee (TOC) voted to accept CRI-O as an incubation-level hosted project. CRI-O, created by Red Hat, is an implementation of the Kubernetes Container Runtime Interface (CRI) designed to enable the use of Open Container Initiative (OCI) compatible runtime.

“A founding principal of CRI-O was to ‘not reinvent the wheel’ but to use shared components and refine approaches tested in production, and existing, battle tested code,” said Brendan Burns, TOC representative and project sponsor, Kubernetes cofounder. “As CRI-O is specifically tailored for Kubernetes, it is tuned for performance, stability, compatibility, and adherence to standards, particularly the Kubernetes Conformance tests. CRI-O is a building block of any Kubernetes cluster, and facilitates the life cycle of containers as required by the Kubernetes CRI.”

In 2016, the Kubernetes project introduced CRI — a plugin interface that gives kubelet (a cluster node agent used to create pods and start containers) the ability to use different container runtimes, without needing to recompile Kubernetes. Building on that work, the CRI-O project (originally known as OCID) was developed to provide a lightweight runtime for Kubernetes.

CRI-O was designed in the Kubernetes incubator, originally between developers from Red Hat and Google to provide an integration path between OCI conformant runtimes and the kubelet. It is now maintained by individuals from Red Hat, Intel, and SUSE, and is used by companies including Lyft, Red Hat, SUSE and more.

“CNCF hosts a variety of container runtimes and we’re excited to have CRI-O join them as an incubation level project, choice and competition benefit end users,” said Chris Aniszczyk, CTO/COO of CNCF. “We look forward to supporting and cultivating the CRI-O community as a top-level project.”

Main CRI-O Features:

Storage – The github.com/containers/storage library is used for managing layers and creating root file-systems for the containers in a pod: Overlayfs, devicemapper, AUFS and btrfs are implemented, with Overlayfs as the default driver.
Container images – The github.com/containers/image library is used for pulling images from registries. Currently, it supports Docker schema 2/version 1 as well as schema 2/version 2. It also passes all Docker and Kubernetes tests.
Networking – The Container Network Interface (CNI) is used for setting up networking for the pods. Various CNI plugins such as Flannel, Weave, Cilium and OpenShift-SDN have been tested with CRI-O and are working as expected.
Monitoring – github.com/containers/conmon is a utility within CRI-O that is used to monitor the containers, handle logging from the container process, serve attach clients and detecting and reporting Out Of Memory (OOM) situations.
Security – Container security separation policies are provided by a series of tools including SELinux, Capabilities, seccomp, and other security separation policies as specified in the OCI Specification.

As a CNCF hosted project, joining Incubated technologies like OpenTracing, Fluentd, Linkerd, gRPC, rkt, CNI, Jaeger, Notary, TUF, Vitess, NATS, Linkerd, Helm, Rook, Harbor, and etcd, CRI-O is part of a neutral foundation aligned with its technical interests, as well as the larger Linux Foundation, which provide governance, marketing support, and community outreach.

Every CNCF project has an associated maturity level: sandbox, incubating, or graduated project. For more information on what qualifies a technology for each level, please visit the CNCF Graduation Criteria v.1.1.

For more on CRI-O, please visit github.com/cri-o/cri-o. You can also watch this session from KubeCon + CloudNativeCon 2017, or read this article from The New Stack about CRI-O’s 1.0 launch.