In this episode of TFiR: Newsroom, Peter Hunt, CRI-O maintainer and Senior Software Engineer at Red Hat, talks about the project, from its roots in Red Hat to its graduation from CNCF, and where it’s headed now.
- In early 2014, Red Hat saw the promise of Docker and Kubernetes. They jumped on it early and contributed to Docker. However, there were differing opinions regarding the way the tools should be specialized in the container ecosystem.
- Red Hat thought that it might be useful to break apart the use cases (e.g., the end user who is debugging their containers, a cluster admin who’s deploying containers in production, etc.) and have separate projects for each of them.
- It started a set of projects that included Skopeo, CRI-O, Podman, and Buildah. By breaking them up, they can each have different configurations by default and cater to specialized needs.
- CRI-O took some of the work that Scopia had begun (i.e., moving images between registries) and extended it to being able to run containers in production, specifically for Kubernetes. It also fixed the version matching challenge with Docker, i.e., figuring out which version of the Docker server was compatible with which version of the Kubernetes Kubelet client. CRI-O matches directly with the version of Kubernetes. It aims to be as secure as possible by default, so it drops capabilities and disables some things and enables some of the things that didn’t come out of the box in Docker.
- In 2019, Docker and containerd were considered the industry standard for container runtimes, including in Kubernetes. As a team, they wanted to demonstrate CRI-O’s stability and viability in that space, so they chose CNCF as the avenue to make that claim. The project was accepted in April 2019 at the Incubating maturity level.
- Four years later in July 2023, it moved to the graduated maturity level. Graduation is definitely not a symbolic gesture; there’s a lot of work that goes into it. CNCF wants to be very rigorous about what they consider to be a “graduated” project. Their standards are very high for all the documentation needed in the security audit, the due diligence process to verify stability, etc.
- Red Hat OpenShift is one of the larger end-users of CRI-O, because it’s a platform that provides it as the container runtime by default, the only one that’s supported on Linux nodes.
- Other end-users include Reddit, Lyft, and Adobe who see the value in having a container runtime interface implementation that’s built strictly for Kubernetes.
- IBM and Oracle both provide CRI-O as an option or as the default runtime in their cloud environments.
- A large portion of the contributors are from Red Hat. Intel is another large contributor and partner.
- Even though CNCF and the Kubernetes ecosystems are having a maintainer shortage right now, the CRI-O still has a pretty good investment from enough people to keep the community going. Of course, they are always looking for more help.
- Continue working in Kubernetes Special Interest Group (SIG) Node, along with the containerd community to define the CRI spec.
- Sigstore integration.
- Container monitor (conmon), which is being rewritten in Rust from C.
- Work on general stability and bug fixes.
- Be the most performant and reliable container runtime for Kubernetes.
This summary was written by Camille Gregory.