Container Runtimes (CRI)

Key Takeaways for AI & Readers

• CRI as the Interface: Kubernetes communicates with container runtimes via the Container Runtime Interface (CRI), allowing for interchangeable runtime implementations.
• Dedicated Runtimes: containerd (extracted from Docker) and CRI-O (Kubernetes-native) are the prominent runtimes, providing efficient container execution.
• DockerShim Deprecation: Direct Docker Engine support was deprecated in Kubernetes 1.24 due to the lack of native CRI compliance, simplifying the runtime landscape.
• OCI Standard: Runtimes adhere to the Open Container Initiative (OCI) specification for container images and runtime execution, ensuring interoperability and standardization.

Kubernetes doesn't actually "know" how to start a container. It delegates that task to a Container Runtime (like containerd or CRI-O). The language they speak is the CRI (Container Runtime Interface).

1. The CRI Handshake

💂

Kubelet

gRPC: RunPodSandbox()

📦

containerd

The Container Runtime Interface (CRI) is a standard that decouples Kubernetes from the actual container runtime. Kubelet doesn't "Run Docker"—it sends gRPC requests to containerd.

When the Scheduler assigns a Pod to a Node, the Kubelet on that node sends a gRPC request over the CRI socket to the runtime.

2. Common Runtimes

containerd

The industry standard. It was extracted from Docker to be a lightweight, high-performance runtime for orchestrators like Kubernetes.

CRI-O

A runtime specifically built only for Kubernetes. It follows the "KISS" (Keep It Simple, Stupid) principle and is the default for Red Hat OpenShift.

Docker Engine (Deprecated)

Kubernetes used to talk to Docker directly, but Docker doesn't support CRI. For a long time, K8s used a "Dockershim" to translate. As of K8s 1.24, this shim is gone.

3. OCI (Open Container Initiative)

The CRI tells the runtime what to do. The runtime then uses an OCI Executor (like runc) to actually talk to the Linux Kernel and create the namespaces/cgroups for the container.