CRI-O

CRI-O is a container runtime built for Kubernetes nodes. It implements the Container Runtime Interface, or CRI, that the kubelet uses to manage Pod sandboxes, containers, and images.

That narrow purpose is the key to understanding CRI-O. Kubernetes decides what should run. The kubelet turns that desired state into node-level requests. CRI-O fulfills those requests through the CRI and delegates container execution to an Open Container Initiative runtime.

Why CRI-O exists

Kubernetes needs a stable contract between the kubelet and a node's container runtime. The CRI provides that contract as a gRPC API. A runtime can implement the API without being compiled into Kubernetes.

CRI-O connects that Kubernetes contract to OCI standards and focused container libraries. It manages image retrieval, container filesystems, process lifecycle, monitoring, logging, and resource isolation required by the CRI.

CRI-O does not schedule Pods across nodes. It does not build, sign, or push images. It also does not provide a supported general-purpose container CLI. Those boundaries keep the project centered on Kubernetes node execution.

The request path

Use this mental model:

1. The Kubernetes control plane assigns a Pod to a node.
2. The kubelet on that node requests sandbox, image, and container operations through the CRI.
3. CRI-O pulls and stores image content, prepares the container root filesystem, and builds an OCI runtime specification.
4. An OCI runtime starts the container process.
5. conmon monitors each container process and supports logging and exit-status handling.
6. A Container Network Interface plugin configures Pod networking.

This path separates orchestration from execution. The kubelet remains the CRI client. CRI-O is the CRI server. The OCI runtime performs the final process launch.

Where CRI-O fits

CRI-O is one choice for the container runtime installed on every Kubernetes node. It is a natural fit when you want a runtime with a Kubernetes-specific scope and OCI-compatible execution.

CRI-O supports multiple OCI runtimes. Runtime handlers can connect Kubernetes RuntimeClass choices to different runtime configurations. This lets a cluster select an execution path for a Pod without changing the kubelet-to-CRI contract.

CRI-O also relies on neighboring components. Container storage libraries manage image layers and root filesystems. Container image libraries pull from registries. CNI plugins handle Pod networking. Linux controls provide namespaces, cgroups, capabilities, and other isolation mechanisms.

Operational judgment

Treat CRI-O as node infrastructure. A broken runtime socket, incompatible CRI version, image failure, storage failure, or cgroup mismatch can stop a node from running Pods correctly.

Keep the kubelet and runtime cgroup drivers aligned. Kubernetes documentation recommends the systemd driver when systemd is the init system. CRI-O uses the systemd cgroup driver by default.

Match CRI-O and Kubernetes minor release streams. CRI-O follows Kubernetes minor release cycles, while patch numbers do not need to match. Check the compatibility policy and release notes before an upgrade.

Use crictl when you need to inspect the CRI view that the kubelet uses. Use Kubernetes events, kubelet logs, CRI-O logs, and node state together. A symptom at the Pod level may originate in image retrieval, storage, networking, the OCI runtime, or resource configuration.

Limits and choice

CRI-O is useful when Kubernetes is the orchestrator and you want a focused CRI implementation. It is not a complete developer container platform. Choose separate tools for image building, registry operations, and general-purpose local container workflows.

Containerd is another common CRI-capable runtime. The important choice is not a slogan about size or speed. Compare operating-system support, distribution packaging, upgrade policy, security requirements, observability, runtime-handler needs, and your team's operational experience.

Your route forward

Start with the CRI request path and the boundary between kubelet, CRI-O, and the OCI runtime. Then learn installation and version compatibility. Continue with configuration, cgroups, image policy, storage, networking, and runtime handlers. Finish by practicing node diagnosis with crictl, logs, metrics, and controlled failure scenarios.