Container Runtime Internals
The runtime layer beneath Docker and Kubernetes, explained. Learn how containerd, shims and runc actually run a container, the OCI specs, the CRI and the end of dockershim, snapshotters and overlayfs storage — remembered with spaced repetition.
- flashcards
- 75
- flashcards
- per day
- ~10 min
- per day
- level
- Intermediate
- level
- modules
- 5
- modules
What is containerd?
Every Docker command and every Kubernetes pod ultimately runs through a container runtime. containerd is the CNCF-graduated runtime that sits in that layer: it pulls and stores images, unpacks them into a filesystem, and hands the low-level work of creating the process to runc. Docker uses it under the hood, and Kubernetes talks to it directly over the CRI.
This track is about runtime internals, not another Docker course — there is no Dockerfile authoring or Compose here. It covers containerd's architecture (the daemon, the shim, plugins and the content store), the OCI image, runtime and distribution specs, the Container Runtime Interface and why dockershim was removed, snapshotters and copy-on-write overlayfs storage, and the ctr / nerdctl / crictl toolchain.
It uses spaced repetition so the moving parts stick — the layer that turns "I use containers" into "I understand how containers actually run".
5 modules, seed to bloom
Each module is a set of flashcards — 75 in total. Answer, review, and watch your knowledge grow from seed to full bloom.
Architecture & Components
How containerd is structured — daemon, runc, shims, plugins, content store, and the container/task model
15 cardsOCI Specifications
The Open Container Initiative standards containerd implements — image, runtime, and distribution specs, manifests, layers, and digests
15 cardsCRI & Kubernetes
How containerd serves Kubernetes — the CRI, kubelet integration, pod sandboxes, crictl, RuntimeClass, and the dockershim removal
15 cardsSnapshotters & Storage
How containerd assembles and stores container filesystems — snapshotters, overlayfs, the content store, copy-on-write, and garbage collection
15 cardsCLI & Operations
Operating containerd in practice — ctr, nerdctl, crictl, config.toml, namespaces, rootless mode, BuildKit, and day-to-day debugging
15 cardsSample questions
A taste of the real flashcards. Pick an answer, then reveal the explanation.
What is containerd?
- AA high-level container runtime that manages the full container lifecycle — image transfer, storage, execution, and supervision
- BA low-level runtime that directly creates the container process — setting up namespaces, cgroups, and the init process itself
- CAn image builder that assembles layers from build instructions — producing OCI images and pushing them to registries
- DA command-line client that talks to a background engine — sending container commands over a local API socket
What is the Open Container Initiative (OCI)?
- AAn open governance project that defines standard specifications for container images and runtimes
- BA proprietary container engine maintained by a single vendor for its own cloud platform only
- CA registry service that hosts and distributes public container images to the community
- DA certification body that tests whether container images are free of known vulnerabilities
What replaced dockershim after its removal in Kubernetes 1.24?
- ACRI-native runtimes like containerd and CRI-O — the kubelet talks to them over the CRI directly
- BA rewritten dockershim maintained by Kubernetes — kept in-tree under a new component name
- CDocker Engine speaking CRI natively — updated so the kubelet can call it without any adapter
- DA cloud-provider shim bundled with each distro — vendor code translating Docker calls to CRI
How does copy-on-write work in an overlayfs container filesystem?
- AReads come from read-only lower layers — a write copies the file up into the writable upper layer
- BReads and writes both go to the lower layers — the upper layer is used only for logging changes
- CEvery write rewrites all lower layers in place — keeping a single flattened copy of the filesystem
- DWrites are discarded immediately — the container filesystem is strictly read-only at runtime
Learn it once, keep it for good
Answer a question
Each card is one practical concept with multiple options. Pick what you think is right.
Get the full answer
See the correct option plus a clear explanation, and a link to deeper docs when one is available.
Review at the right time
A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.
Why container runtime internals are worth your time
The layer between Docker and Kubernetes
containerd is what both actually run on. Knowing it fills the gap most container courses skip.
Debug real node problems
When a Kubernetes node misbehaves, the answers live in containerd, crictl and the CRI — not in kubectl.
Make sense of the dockershim removal
Understand what changed in Kubernetes 1.24, why, and what "containerd is the runtime" really means.
Standards that outlast tools
The OCI image and runtime specs underpin every container engine — learn them once, apply them everywhere.
Common questions
Is this just another Docker course? +
No. This track is about the runtime layer beneath Docker — how containerd, runc and the OCI specs actually run a container. There is no Dockerfile authoring or Compose here; that lives in the Docker track.
Should I learn Docker or Kubernetes first? +
Ideally yes. This track sits between them — it makes the most sense once you have used containers and want to understand how they really work underneath.
How long does it take? +
About 10 minutes a day. Spaced repetition means short, frequent sessions beat long cramming, so the concepts stick.
Is it free? +
Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.
Ready to look under the hood?
Plant your first seed today. Ten minutes a day is all it takes to understand how containers actually run.