Describe the relationship between containerd and runc in starting a container.

What's really being asked

This question probes your understanding of the OCI runtime architecture and the clear separation of concerns between high-level and low-level runtimes. Interviewers want to see that you know containerd is a daemon managing the full container lifecycle, while runC is a stateless, low-level executor that only knows how to create and run an isolated process from an OCI bundle. It also checks whether you understand that Kubernetes and Docker rely on this split.

The full answer

First, define containerd as the CNCF-graduated, daemon-based container runtime that exposes a gRPC API and manages image pull and push, content storage, snapshot management, network namespace attachment, and container supervision. Second, explain that when a container is requested, containerd prepares an OCI bundle, which includes a root filesystem and a config.json file describing the process, environment, namespaces, and cgroups. Third, state that containerd delegates the actual creation of the container process to runC by invoking it as a binary; runC implements the OCI Runtime Spec and is responsible for setting up Linux namespaces, cgroups, capabilities, and seccomp profiles, then execing the user process inside that isolation boundary. Fourth, note that after runC starts the process, containerd retains ownership of the container for lifecycle operations like stop, delete, and event monitoring, while runC exits and remains stateless.

The mistakes people make

A major red flag is saying containerd directly creates namespaces and cgroups itself; that conflates the two layers. Another is claiming runC pulls images or manages networking, which it does not do. Some candidates say runC is a long-running daemon; it is actually a short-lived CLI tool that exits after starting the container. Also avoid stating that containerd replaces runC; they are complementary, not competitors.

What usually comes next

An interviewer might ask how containerd compares to the CRI-O runtime, or what happens if the containerd daemon restarts while containers are running. They could also ask about the shim process: containerd uses a per-container shim to allow runC to exit while keeping stdio and exit status forwarding alive. Another follow-up is how this architecture improves security by reducing the attack surface of the low-level runtime.

A concrete example

When Kubernetes kubelet asks containerd via the CRI to start a pod, containerd pulls the image into its content store, creates a snapshot of the rootfs, generates the OCI runtime spec, and then forks runC create followed by runC start. RunC reads the spec, configures the pid namespace, mount namespace, and cgroup v2 limits, and finally execs the container entrypoint. Containerd then monitors the container through its shim and reports status back to kubelet.