The story starts with a very tangled early relationship between Kubernetes and Docker.

Kubernetes’ original, Docker-specific design

In its earliest years, Kubernetes was built with direct, specific knowledge of how Docker worked baked straight into its core node agent, called the kubelet. This worked fine while Docker was effectively the only widely used container engine, but it created a real architectural problem: every time a new container engine wanted to work with Kubernetes, someone had to modify Kubernetes’ own core codebase to understand that engine’s specific quirks, directly increasing the complexity and fragility of Kubernetes itself.

The idea behind a standard interface

The fix was to define a standard interface — a fixed, agreed-upon set of operations any container engine must support, described independently of any single engine’s internal implementation — and have Kubernetes talk only to that interface, never to a specific engine’s internals directly. This is exactly what CRI, the Container Runtime Interface, provides: a formally specified API that any container runtime can implement, letting the kubelet manage containers without ever needing engine-specific code inside Kubernetes’ own codebase again.

What “runtime” means in this context

The word “runtime” here refers to the software actually responsible for creating, starting, stopping, and removing containers on a machine — pulling images, setting up isolation, and managing the container’s running process. Docker itself, containerd, and CRI-O are all examples of software that can fill this role, each with a different internal design, but any of them can serve Kubernetes equally well as long as they speak CRI.

A few distinct layers cooperate to turn a Kubernetes scheduling decision into a real running container.

flowchart TB
    A["Kubernetes Control Plane
(schedules a Pod)"] --> B["Kubelet
(on the target node)"]
    B -->|"CRI gRPC calls"| C["CRI Shim / Plugin"]
    C --> D["Container Runtime
(containerd, CRI-O, etc.)"]
    D --> E["OCI Runtime
(low-level container creation)"]
    E --> F["Running Container Process"]
        

Underneath the concept, CRI is a defined set of remote procedure calls, grouped into two clear services.

CRI is formally defined using a technology called gRPC, a framework for defining and calling remote procedures using structured, strongly typed messages. The specification splits its operations into two logically separate services, each focused on a distinct responsibility.

Why the split matters

Separating image management from container lifecycle reflects a real architectural insight: a runtime’s image-handling logic and its container-execution logic are genuinely different concerns, sometimes even implemented by different underlying components. Keeping the interface split this way gives implementers more flexibility in how they build their own runtime internally, as long as both services are exposed correctly to the kubelet.

The pod sandbox concept

CRI introduces the idea of a pod sandbox — a shared execution environment, including shared networking, that all containers within a single Kubernetes pod run inside together. Creating a pod sandbox happens as its own distinct CRI operation, separate from creating the individual containers that will run within it, reflecting how Kubernetes pods work as a genuinely shared unit rather than just a loose grouping label.

From a scheduling decision to a fully running set of containers, in a fixed, predictable order.

sequenceDiagram
    participant Kubelet
    participant Runtime as Container Runtime (via CRI)

    Kubelet->>Runtime: RunPodSandbox
    Runtime-->>Kubelet: Sandbox ready
    Kubelet->>Runtime: PullImage
    Runtime-->>Kubelet: Image ready
    Kubelet->>Runtime: CreateContainer
    Runtime-->>Kubelet: Container created
    Kubelet->>Runtime: StartContainer
    Runtime-->>Kubelet: Container running
    Kubelet->>Runtime: PodSandboxStatus (ongoing polling)
        

This is the chapter most people are actually looking for when they ask about CRI and Docker together.

Docker predates CRI, and never spoke it natively

Docker’s own engine was never built to implement the CRI specification directly — it existed before CRI did, and CRI was designed with Docker’s existing behavior as one of its early reference points, not the other way around. To let Kubernetes keep using Docker after CRI was introduced, the Kubernetes project maintained a built-in translation layer, commonly called dockershim, that sat between the kubelet and Docker, translating CRI requests into calls Docker itself understood.

Why dockershim was eventually removed

Maintaining dockershim meant the Kubernetes project itself was responsible for keeping a Docker-specific compatibility layer working correctly, essentially recreating the exact kind of tightly coupled, engine-specific maintenance burden that CRI was originally introduced to eliminate. As other runtimes with native CRI support matured, the Kubernetes project made the decision to remove dockershim from the kubelet, simplifying Kubernetes’ own codebase and fully committing to the standard-interface model CRI was designed to enable.

Once CRI existed as a standard, several runtimes were built or adapted specifically to speak it natively.

An important, often surprising detail: containerd being Docker’s former internal engine means that most modern Kubernetes clusters, running containerd directly as their node runtime, are actually running the very same underlying technology Docker itself is built on top of — just accessed through the standard CRI interface, without Docker’s own additional layers sitting on top of it.

Standardizing the interface between Kubernetes and container engines paid off broadly, with a few real costs along the way.

The choice of CRI implementation is itself a meaningful security decision, not just a plumbing detail.

Isolation strength varies by implementation

Because CRI defines an interface rather than a specific isolation technology, different compliant runtimes can offer meaningfully different levels of isolation between containers and the host — from standard Linux namespace and control-group isolation to stronger, VM-based sandboxing for workloads that need to run genuinely untrusted or multi-tenant code.

The runtime as a high-privilege component

Whichever runtime implements CRI on a node runs with substantial privilege, since it’s directly responsible for creating and managing every container on that machine. Its own security posture — how quickly it receives and applies patches, how carefully its configuration is managed — directly affects the security of every workload scheduled onto that node.

Diagnosing a container problem in Kubernetes often means knowing which layer to actually look at.

Kubelet-level visibility

The kubelet exposes events and status information reflecting its view of pod and container state as reported back through CRI, which is usually the first and most convenient place to check when a pod isn’t behaving as expected.

Most of the friction teams hit with CRI comes from treating it as an implementation detail instead of a real architectural layer.

Pattern: choosing runtime class deliberately by workload

A mature pattern explicitly assigns different runtime classes to different categories of workload — standard isolation for typical internal services, stronger VM-based isolation for anything running less-trusted or externally supplied code — rather than treating every workload as needing identical isolation guarantees.

Pattern: treating the runtime as a managed, versioned dependency

Tracking the node-level CRI runtime’s version deliberately, upgrading it on a planned schedule alongside the rest of cluster infrastructure, avoids the surprise of a workload behaving differently simply because different nodes in the same cluster are silently running different runtime versions.

Small habits that keep the CRI layer from becoming an invisible source of confusion.

CRI’s adoption reshaped what “running Kubernetes” actually means at the infrastructure level industry-wide.

Yes. Building images with Docker and running a Kubernetes cluster on a different CRI implementation are entirely separate concerns. Docker produces standard, OCI-compliant images that run perfectly well on any CRI-compliant runtime.

No. CRI defines how Kubernetes’ kubelet talks to a container runtime. The OCI Runtime Specification, discussed as its own lower layer in this tutorial’s architecture chapter, defines how that runtime actually creates a container’s low-level isolation on the machine. They’re related, complementary standards operating at different layers.

It means Docker is no longer used directly as the node-level container runtime by default. Docker remains an extremely common tool for building images in development and CI pipelines that ultimately get deployed to Kubernetes clusters running a different, native CRI runtime.

Because containerd includes a CRI plugin built directly into it, letting it speak CRI natively without any separate translation layer — unlike Docker’s full engine, which was never built with native CRI support and required the external dockershim adapter instead.

No. CRI standardizes the interface, not the isolation technology underneath. Different implementations can offer meaningfully different isolation strength, from standard Linux container isolation to stronger, VM-based sandboxing.

Kubernetes exposes each node’s runtime name and version as part of its standard node status information, making it straightforward to confirm exactly which CRI implementation a given cluster’s nodes are running.

The Container Runtime Interface exists to answer a question Kubernetes’ early, Docker-specific design couldn’t answer well: how does an orchestrator manage containers without being permanently tied to one specific engine’s internals? By defining a fixed, independent API contract — split cleanly into runtime and image services, and built around the shared pod sandbox concept — CRI let Kubernetes stop caring which specific engine actually runs containers on a node, as long as that engine speaks the standard interface. This is the direct reason Docker’s own role changed: never having been built to speak CRI natively, Docker required a translation layer that the Kubernetes project eventually removed once better-suited, natively compliant runtimes like containerd and CRI-O matured — a change that affected how clusters run containers, not how Docker builds them.