CRI-O: the kubelet's OCI interface, scoped to the CRI

Kubelet to runc, assembled from OCI parts

CRI-O exists to be the integration path between OCI-conformant runtimes and the kubelet: it implements the Kubernetes Container Runtime Interface, and it leans on established projects for everything underneath rather than reimplementing them. Runtime work goes to runc, or any OCI runtime-spec implementation, with the OCI runtime tools alongside. Image management uses the containers image libraries, storage and overlay filesystems the containers storage libraries, and networking arrives through CNI, the Container Network Interface. The consequence of that assembly is focus: the project's own code is the CRI surface, and its scope is explicitly tied to the scope of the CRI itself, which keeps the moving parts countable and each part replaceable by name.

In scope: images, layers, lifecycle. Out: building and CLIs

The scope statement is unusually candid about both edges. In: support for multiple image formats including the existing Docker image format, multiple ways to download images including trust and image verification, container image management with layers and overlay filesystems, container process lifecycle management, and the monitoring, logging and resource isolation the CRI requires. Out: building, signing and pushing images to registries, and a supported CLI, since any CLI built by the project is for testing it and carries no backward compatibility guarantees. That second exclusion is the sharp differentiator against containerd, the other widely adopted CRI implementation, which grew out of the Docker stack and ships as the default in many distributions, while CRI-O was built Kubernetes-first and refuses to accumulate a general-purpose tooling surface around the kubelet contract.

Minor versions follow Kubernetes, patches only when needed

Versioning is coupled to Kubernetes by policy. CRI-O follows Kubernetes release cycles for minor versions, while patch releases are issued only when necessary rather than monthly as Kubernetes does, and when a Kubernetes release goes end of life the corresponding CRI-O version is treated the same way. Feature graduation, deprecation and removal follow the Kubernetes n-2 version skew policy, including for features independent of Kubernetes, with backports to supported branches decided case by case. The parallel-branch reality is visible in the tags: v1.37.1, v1.36.6 and v1.35.9 were all released on 2026-09-21, one patch per active branch. Release notes are hand-crafted and published continuously on the project's GitHub Pages site.

Governance files for a Kubernetes-community project

This is not a lone repository, it is a governed Kubernetes community effort, originally proposed through a Kubernetes design pull request and discussed in the sig-node Slack channel. The tree carries the paperwork to match: GOVERNANCE.md, MAINTAINERS.md, OWNERS and OWNERS_ALIASES for review routing, SECURITY.md with SECURITY_CONTACTS, ADOPTERS.md naming users, a code of conduct, and a documented deprecating process for retiring features. Direction is tracked twice, in roadmap.md in the repository and a Feature Roadmap GitHub project, and there is a weekly meeting plus an awesome.md index of the surrounding ecosystem. For an operator, that paper trail is operational information: it tells you who decides, how features die, and where to raise the issue you actually have.

CI split between GitHub Actions and Prow

Continuous integration is a two-system arrangement: GitHub Actions shares the work with OpenShift CI, the Prow installation at prow.ci.openshift.org, and the Prow side periodically rebuilds the virtual machine images its jobs run on, with named periodic jobs for the main setup, a Fedora variant, and an evented PLEG configuration. Quality and security reporting is broad on paper: codecov for coverage, a scorecard.dev viewer, the CII best practices badge, and a FOSSA license scan badge, with a .snyk configuration and golangci-lint plus gosec pinned in the Makefile at v2.13.2 and 2.2 respectively. Tooling lint extends to the repository's own prose, via a markdownlint configuration, which is a reasonable discipline for a project whose hand-written release notes are a primary interface.

conmon, pinns and criu in the dependency graph

Reading go.mod sketches the runtime's helper processes. conmon appears in two forms, the original C tool and conmon-rs, its Rust rewrite, both container monitors. pinns, present as its own source directory, handles namespace pinning. The checkpoint-restore stack, go-criu and checkpointctl, brings container checkpointing, and kata-containers' runtime is a dependency for VM-isolated pods. Image encryption arrives through ocicrypt, Intel's goresctrl provides resource control, and the HTTP router chi plus an OpenTelemetry-aware ttrpc point at the status API, metrics and tracing sections of the documentation. A crictl.yaml ships defaults so the crictl debugging client talks to CRI-O without extra flags. None of this is exotic; it is the standard parts list of a production container runtime, assembled with intent.

Man pages from markdown, completions for three shells

The build system treats documentation as an artifact: every docs/*.md file becomes a man page through go-md2man, and shell completions are installed for bash, fish and zsh from a completions directory. Build tags expose the platform security and storage knobs, seccomp, SELinux, AppArmor, btrfs, OpenPGP and libsubid among them, so a distribution build enables what its base system supports. Development environments are first-class via a Nix flake and a Vagrantfile, the build's container runtime defaults to podman rather than Docker, and AGENTS.md and CLAUDE.md sit in the tree behind the README's AI Assistants section, meaning agent-driven contribution is an acknowledged workflow. The last push was on 2026-09-27, and the project's homepage at cri-o.io collects the user-facing entry points.

Editorial conclusion

Run CRI-O where you want the kubelet talking to OCI containers through a runtime whose scope stops at the Container Runtime Interface, with runc underneath and CNI for networking. Prefer containerd when your stack grew out of the Docker world or you want the runtime many distributions ship as default. Verify first that your Kubernetes version has a matching CRI-O release branch under the n-2 skew policy, and follow install.md plus the cri-o/packaging project rather than building ad hoc.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes