Demystifying Kubernetes CRI: Design, Implementations, and Handy Tools

What is CRI?

Before CRI (pre‑Kubernetes v1.5), Docker was the sole container runtime accessed via an embedded dockershim, and later runtimes such as rkt and hyper.sh increased code complexity. To decouple Kubelet from specific runtimes, the Container Runtime Interface (CRI) was introduced as an abstraction layer.

Design of the CRI Interface

CRI uses gRPC for communication, offering two main services:

CRI Server – handles standard operations like creating and deleting containers.

Streaming Server – provides streaming APIs such as exec and port‑forward.

The CNI (Container Network Interface) also operates through CRI, allowing network resources to be created alongside Pods. The following diagram shows the Kubelet architecture after CRI integration:

Managing Container Lifecycle via CRI

When a user runs kubectl run, Kubelet invokes the following CRI calls in order: RunPodSandbox – creates a sandbox that holds network, PID, and other resources for the Pod. CreateContainer – creates the actual workload container inside the sandbox. StartContainer – starts the container; the corresponding termination calls are StopContainer and RemoveContainer.

CRI Streaming Exec Interface

The exec streaming flow works as follows: the request goes to the API server, which authenticates and forwards it to the Kubelet server; Kubelet calls the CRI exec method, which hands the request to a streaming server that asynchronously returns execution results. This design keeps the CRI server lightweight and reliable.

Implementations of CRI

Common CRI implementations include:

CRI‑containerd

CRI‑O

PouchContainer (Alibaba)

…

CRI‑containerd

Originally a separate process communicating with containerd, CRI‑containerd later became a plugin integrated directly into containerd, eliminating extra inter‑process overhead. It wraps containerd’s services (metadata, runtime, storage) with a gRPC layer, exposing both CRI and richer containerd‑specific APIs via the ctr tool.

CRI‑O

CRI‑O implements the CRI by directly wrapping OCI container interfaces, exposing only the standard CRI APIs without the additional containerd features. It manages both container runtimes and images.

CRI Tools

Several utilities help developers work with CRI directly:

crictl – a Docker‑like CLI for debugging containers via CRI, bypassing the longer API‑server → Kubelet path.

critest – validates that a CRI implementation behaves as expected.

Performance testing tools – measure CRI call latency and throughput.

Discussion Points

CRI is currently at v1 alpha2; how can the specification be further refined?

Customizing runtime behavior via annotations – each CRI interface can accept annotation fields that the runtime interprets to modify its behavior.

Summary

CRI decouples container runtimes from Kubernetes, providing a stable gRPC‑based interface.

Major implementations include CRI‑containerd and CRI‑O, each with distinct integration models.

Tools such as crictl and critest simplify debugging and testing of CRI implementations.