CRI-O Support for Kubernetes
A customer of ours asked me the other day about support for CRI-O and how it maps to different releases of Kubernetes. That question is difficult to answer because the context of the question really matters. Let me walk you through a couple of support scenarios to illustrate this.
Upstream Support.
CRI-O lives and breathes Kubernetes.
Because of this, we plan on supporting every CRI-O version as long as the kubernetes version is supported. For example CRI-O 1.8 will be supported as long as Kubernetes 1.8. CRI-O 1.9 support ends when Kubernetes support 1.9 ends. We have set up different branches on https://github.com/kubernetes-incubator/cri-o for each CRI-O Release, and PRs for each release will run the appropriate End-to-End Kubernetes test suite before ever getting merged. Currently in CRI-O the master branch is Kubernetes 1.9.
Our number 1 goal for CRI-O, unlike other container runtimes, is to never break Kubernetes. Providing a stable and rock-solid container runtime for Kubernetes is CRI-O’s only mission in life.
Community Distribution Support.
We currently create CRI-O packages for Fedora, Ubuntu, Centos. (If others want to help package up for other distros, we would welcome them.) These packages are tied to the latest supported version of Kubernetes. Since Kubernetes 1.8 is the current supported version of Kubernetes, we are building CRI-O 1.8 versions for each distribution. Any fixes required will be backported to this version. When Kubernetes moves to 1.9 as the latest supported version, we will build new packages for all of the community distributions of CRI-O 1.9.
Enterprise Distribution Support.
We intend to ship CRI-O as part of OpenShift as a Technology Preview in OpenShift Container Platform 3.7 release, along with the existing RHEL docker 1.12 default runtime, which is the default for Kubernetes 1.7. CRI-O will also be deployed in OpenShift Online. When CRI-O is part of an OpenShift release, it will be supported for the length of that release by Red Hat, just as any other component in the release. We do not currently plan to ship CRI-O as standard part of RHEL, as CRI-O is meant to run with Kubernetes and not as a standalone container runtime.
Support Matrix.
CRI-O is an active community driven Open Source project on GitHub with contributors from many different companies. Any problems found can be raised as issues within the project. Working with the community, the CRI-O team will prioritize and respond to these issues in a timely manner for all supported versions as pertinent. Red Hat is very committed to the CRI-O project and plans to further increase its commitment to this project. Stay tuned for upcoming announcements!
Wrapping up.
CRI-O has the same release cycle as Kubernetes because CRI-O is built specifically for Kubernetes. We plan to ship new fully tested CRI-O versions within a week of any Kubernetes release, matching the exact same version. At Red Hat we live by the dogma: “Tried. Tested. Trusted”. That’s what we’re applying to our work on the CRI-O project, I hope you’ll come join us.
