CRI-O
By the CRI-O project (CNCF)
CRI-O is a lightweight, open-source container runtime built specifically to implement Kubernetes' Container Runtime Interface (CRI), with no functionality beyond what Kubernetes needs to run OCI-compliant containers. It was created as a…
Definition
CRI-O is a lightweight, open-source container runtime built specifically to implement Kubernetes' Container Runtime Interface (CRI), with no functionality beyond what Kubernetes needs to run OCI-compliant containers. It was created as a minimal alternative to using a general-purpose container engine as a Kubernetes node's runtime, and is a Cloud Native Computing Foundation-hosted project. It was created as a minimal alternative to using a general-purpose container engine as a Kubernetes node's runtime, implementing only what the kubelet's Container Runtime Interface requires, and is a Cloud Native Computing Foundation-hosted project most closely associated with Red Hat's OpenShift, which uses it as the default runtime.
Overview
CRI-O originated from a collaboration among Red Hat, Google, and other Kubernetes contributors who wanted a runtime purpose-built for Kubernetes rather than adapting a general container platform like Docker, which included many features Kubernetes did not need, such as its own CLI, build tooling, and networking stack. Instead, CRI-O implements exactly the CRI specification that the kubelet expects, pulling images and running containers using OCI-compliant tools like runc without any additional layers. Mechanically, when the kubelet needs to start a pod, it calls CRI-O over the CRI's gRPC interface, and CRI-O pulls the required OCI-compliant image, prepares the container's root filesystem, and hands off process creation to a configured low-level runtime such as runc, reporting status back to the kubelet through the same interface. Because it targets the CRI specification directly, CRI-O works with any OCI-compliant image and any OCI-compliant low-level runtime, giving cluster operators flexibility in choosing the actual process-isolation mechanism. Compared to containerd, which also implements the CRI but originated as a more general-purpose runtime extracted from Docker, CRI-O was designed from the outset purely for the Kubernetes use case, giving it a smaller footprint and fewer components to maintain. Its scope is deliberately narrow: it does not provide a command-line tool for building images or running standalone containers outside of Kubernetes, since that is not what the kubelet requires. In practice, cluster operators choose CRI-O when they want a minimal runtime with a smaller attack surface and fewer moving parts than a general-purpose engine, and it is particularly associated with Red Hat's OpenShift platform, which uses CRI-O as its default container runtime, though it is usable on any Kubernetes distribution. Its release versioning is tied to Kubernetes' own release cycle, with each CRI-O version aligned to a corresponding Kubernetes minor version, which simplifies compatibility decisions for cluster operators upgrading Kubernetes. Despite this tight alignment and minimal design, containerd's broader adoption across both Docker and Kubernetes has made it the more commonly deployed default in many environments, leaving CRI-O as a deliberate choice for operators who specifically want its narrower Kubernetes-only scope rather than a runtime shared with a general container engine. Cluster operators weighing the two runtimes generally consider organizational alignment as much as technical differences: an OpenShift-based deployment defaults naturally to CRI-O, while a cluster built on more general-purpose Kubernetes tooling more often inherits containerd as the path of least resistance. This organizational pattern mirrors how many infrastructure choices ultimately follow the platform vendor's own default recommendation rather than a purely technical evaluation.
Key Features
- Purpose-built implementation of Kubernetes' Container Runtime Interface
- Minimal scope limited to what the kubelet requires
- Compatibility with any OCI-compliant image and low-level runtime
- Release versioning aligned to corresponding Kubernetes minor versions
- Default container runtime for Red Hat OpenShift
- Cloud Native Computing Foundation-hosted open-source project
- No bundled CLI or build tooling beyond Kubernetes integration
- Smaller footprint compared to general-purpose container engines