Container Runtime Interface (CRI)

What is CRI?

A gRPC plugin API letting kubelet talk to any container runtime without being hardcoded to one. Kubelet = gRPC client, runtime = server, communicating over a Unix socket.

Before CRI, Docker and rkt were embedded in kubelet source code — hard to maintain, high barrier for new runtimes.

Two gRPC services

• ImageService — pull, inspect, remove images
• RuntimeService — manage pod/container lifecycles, exec/attach/port-forward

PodSandbox

CRI exposes a PodSandbox (not a Pod) — the isolated environment a Pod runs in. What that means is runtime-defined:

• Docker → Linux namespaces
• Hypervisor-based → a VM

Lifecycle: RunPodSandbox → CreateContainer → StartContainer. Teardown reverses it.

Why imperative, not declarative?

Kubernetes is declarative, but the CRI interface kubelet exposes to runtimes is imperative (“start this container”).

1. Code reuse — kubelet owns Pod-level logic (crash-loop backoff, liveness checks, restart policy). Runtimes don’t have to reimplement it.
2. Spec was evolving fast — new features like init containers only required kubelet changes, not runtime updates.

See also

• container-runtimes — OCI standard, runtime types (runc, containerd, CRI-O)
• docker-deprecation — why dockershim was removed in K8s 1.24