What is the Container Runtime Interface (CRI), and what changed when Docker was deprecated as a Kubernetes runtime?
Quick Answer
The CRI is a standard plugin interface that lets the kubelet talk to any compliant container runtime without being hardcoded to a specific one — this is what allows containerd, CRI-O, and others to be used interchangeably. Docker itself was never CRI-compliant, so Kubernetes used a shim (`dockershim`) to translate between the two; that shim was removed starting with Kubernetes 1.24, meaning Docker specifically can no longer be used as the underlying runtime — but containers built with the Docker CLI/Dockerfile format are completely unaffected and run identically under containerd or CRI-O, since the OCI image format is a separate, shared standard.
Detailed Answer
What the CRI standardizes
The kubelet needs to pull images, start/stop containers, and get container status — the Container Runtime Interface defines a standard gRPC API for exactly these operations, so the kubelet can work with any runtime that implements it, without runtime-specific code baked into the kubelet itself.
kubelet ──(CRI gRPC calls)──▶ containerd / CRI-O / any CRI-compliant runtime
│
└──▶ actually creates/manages containers
containerd and CRI-O are the two most widely used CRI-compliant runtimes today — both are lightweight, purpose-built specifically to be driven by Kubernetes (or standalone), unlike Docker, which is a much larger toolset (CLI, build tooling, networking, volumes) built primarily for a human developer's local workflow rather than for being one component in an orchestrated cluster.
Why Docker itself was never CRI-native
Docker predates the CRI standard and was never restructured to implement it directly — Docker Engine has its own internal API, not the CRI gRPC interface the kubelet expects. To let Kubernetes use Docker anyway, an adapter component called dockershim was built directly into the kubelet, translating CRI calls into Docker Engine API calls.
The deprecation, precisely
Starting with Kubernetes 1.24 (2022), dockershim was removed from the kubelet itself. This means: Docker Engine can no longer be used directly as the runtime the kubelet talks to on a 1.24+ cluster — clusters still using Docker needed to migrate their nodes to containerd (or another CRI-compliant runtime) before upgrading past 1.23.
What this deprecation did NOT change
This is the detail that trips people up: Docker (the CLI, docker build, Dockerfiles) is completely unaffected as a developer tool. Container images are built to the OCI (Open Container Initiative) image format, a standard shared by Docker, containerd, and every other modern runtime — an image built with docker build runs identically under containerd with zero changes needed. The deprecation was specifically about which component the kubelet talks to at runtime on a cluster node, not about how developers build or push images. In fact, containerd is itself one of the components inside Docker Engine — Docker uses containerd internally already, so removing dockershim mostly just cut out a redundant middle layer for the Kubernetes-specific path, rather than removing some fundamentally different technology.
Why this is a good interview question
It tests whether a candidate can precisely distinguish "the tool I use to build images on my laptop" from "the component the kubelet uses to run containers on a cluster node" — conflating the two is an extremely common (and revealing) misunderstanding, since the deprecation announcement caused a lot of confusion at the time about whether "Docker" as a whole was somehow being removed from Kubernetes.