CRI-O 1.0 is here

This is a very exciting day for the CRI-O Engineering team. Just over a year ago, back in September 2016, Mrunal Patel and Antonio Murdaca of my engineering team created a skunkworks project named OCID, that was later renamed CRI-O. The goal was to figure out if we could build a simple daemon that could support and be dedicated to the Kubernetes Container Runtime Interface (CRI) and be able to run Open Container Initiative (OCI) containers. Thus the name, CRI-O.

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

We owe a great deal of thanks to contributors from companies like Intel, SUSE, Hyper, IBM, as well as general contributors from the internet. We also had great help and guidance from Google and the Kubernetes community, for placing the project under the Kubernetes-incubator.

Our #1 goal for the CRI-O project has always been stability for Kubernetes. We set up a CI/CD system on github in such a way that all pull requests have to pass the entire Kubernetes End-to-End test suite before being committed into the repo. Over time we plan on expanding this to adding additional tests suites like the crictl test suite and the OpenShift test suite. While the engineering team working on this sometimes finds it a hardship, our confidence in shipping a stable product has grown considerably.

Our first version of CRI-O v1.0 is based on the Kubernetes 1.7 release. The engineering team wanted to have a 1.0 release. This is the version that OpenShift 3.7 is being built on. We plan on releasing CRI-O 1.8 very shortly and all future versions of CRI-O will match the version number of the Kubernetes version they support.

Another goal for the CRI-O project is to share technologies with other projects. We knew we could not build everything ourselves. First and foremost, we needed to to be able to work with OCI Based Runtimes like runc, and Intel’s Clear Containers.

We also wanted to use libraries like containers/storage and containers/image so we could take advantage of advances in these libraries. 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. Because of this CRI-O works well with tools like Skopeo and Buildah. Going forward, we would love to see other projects be able to share this content as well.

Other goals of the project are to be lighter weight than other container runtimes. To be able to have a smaller footprint, and have better performance for Kubernetes than other container runtimes.

CRI-O owes a great deal of gratitude to the upstream Docker project. As Isaac Newton said “If I have seen further, it is by standing on the shoulders of giants.” Similarly, CRI-O engineers have learned from the great technology of the Docker Project. We also believe we have also learned from their mistakes. Because of Open Source they have even been able to borrow some of the technologies. Our engineers plan on continuing to contribute to the Moby (Formerly Docker) project, and hope that all container projects continue to thrive.

The OpenShift project has lots of plans for using CRI-O. OpenShift online is moving some of its huge user base to CRI-O, off of upstream Docker, over the next month. OpenShift 3.7 plans on supporting CRI-O in Tech Preview mode.

V1.0 is just the beginning. We have big plans for the future of CRI-O. Try it out, and as always contributors welcome.