2.2.1.4 Containerd Runtime Abstraction
A focused guide to Containerd Runtime Abstraction, connecting core concepts with practical Docker and container operations.
Containerd runtime abstraction is the design that lets containerd delegate the actual creation of an isolated process to a pluggable, OCI-compliant runtime — typically runc — without containerd itself needing to know the low-level details of how namespaces and cgroups are configured.
Separating "What to Run" From "How to Isolate It"
containerd is responsible for deciding that a container should run, what image it uses, and what configuration it has; it then hands off a generated OCI runtime specification to a runtime implementation, which performs the actual low-level work of creating the isolated process.
runc spec
cat config.json
This generated specification file describes exactly what namespaces, mounts, and resource limits the container should have — containerd produces this specification, and the runtime consumes it.
Why This Abstraction Exists
By defining a standard specification format (the OCI runtime spec) and treating the actual runtime as a pluggable component, containerd is not tied to one specific implementation of process isolation — different runtimes implementing the same specification can be substituted without changing anything above this layer.
ctr run --runtime io.containerd.runc.v2 docker.io/library/alpine:latest mytask sh
Alternative Runtimes
Beyond runc, other OCI-compliant runtimes exist for different isolation needs — for example, runtimes that run each container inside its own lightweight virtual machine for stronger isolation, while still being driven by containerd the same way runc is.
ctr run --runtime io.containerd.kata.v2 docker.io/library/alpine:latest mytask sh
Substituting a different runtime here changes how strongly the container is isolated, without requiring any change to how containerd itself manages the container's lifecycle.
Why Runtime Abstraction Matters
This separation means stronger isolation technologies can be adopted for workloads that need them, without rearchitecting the entire system above the runtime layer — containerd, the Docker daemon, and any orchestrator built on top continue to operate the same way regardless of which OCI-compliant runtime is actually creating the isolated process underneath.
ctr plugins list | grep runtime
This lists the runtime plugins currently available to a given containerd installation.