Docker Engine Architecture & Kernel Mechanics (The Masterclass Manual)

An analogy-driven, professional-grade guide to Docker Engine architecture, covering dockerd, containerd, runC, OCI specs, Linux namespaces, cgroups v2, and OverlayFS storage drivers.

High-Level Concept Definition & Real-World Analogy

The Docker Engine is a client-server application built on top of modular OCI-compliant (Open Container Initiative) container runtimes and low-level Linux kernel isolation primitives.

Core Architectural Components

  • Docker Daemon (dockerd): High-level REST API service managing images, volumes, networks, and container lifecycles.
  • containerd: OCI-compliant core container execution daemon handling image transfer, storage, and container supervision.
  • runC: Low-level lightweight OCI CLI tool that directly interacts with the Linux kernel to create and run containers.
  • Kernel Isolation Primitives: Namespaces (visibility), cgroups v2 (resource quotas), and OverlayFS (storage driver).

Real-World Analogy: The Autonomous Prefab Apartment Complex

To visualize Docker Engine architecture, consider an Autonomous Prefab Apartment Complex:

  • Docker Client (docker): The Resident Intercom Keypad. Takes resident orders (docker run) and relays requests to management.
  • Docker Daemon (dockerd): The General Building Manager. Translates tenant requests into building operations, coordinates security, utilities, and room blueprints.
  • containerd: The Chief Modular Construction Supervisor. Supervises apartment assembly, fetches prefabricated room materials, and maintains room status.
  • runC: The Hydraulic Construction Crane Engine. Does the low-level physical heavy lifting to bolt down a room, attach utility pipes, and seal the door.
  • Linux Namespaces: One-Way Tinted Glass Windows. Ensures occupants in Apartment 101 cannot peek into or access Apartment 102.
  • Control Groups (cgroups v2): Smart Utility Circuit Breakers. Limits how many kilowatts of power (CPU) or gallons of water (RAM) an apartment can consume per hour.
  • OverlayFS: Stackable Prefab Floor Panels. Combines modular read-only floor layers into a unified living space.
Linux Kernel Isolation Layer gRPC / REST API gRPC Remote Protocol Executes OCI Bundle 1. clone with flags 2. write limits 3. mount layers Docker CLI (Client)(docker run / docker build) Docker Daemon (dockerd) containerd Daemon runC (Low-Level OCI Runtime) Linux Namespaces(PID, NET, MNT, IPC, UTS, USER) cgroups v2(CPU, RAM, Disk I/O Quotas) OverlayFS Driver(LowerDir + UpperDir = MergedDir)

Structured Module Roadmap

ModuleCore TopicsKey Focus & Engineering ConceptsRead Time
Daemon & Runtime Architecturedockerd, containerd, runC, OCI SpecModular Container Stack, gRPC Protocol, Shim Process Management5 min
Linux Kernel Namespacespid, net, mnt, ipc, uts, userProcess Isolation, Network Stack Isolation, User Mapping Security5 min
Control Groups (cgroups v2)CPU Quotas, Memory Limits, OOM KillerResource Throttling, Unified Hierarchy, Memory Exhaustion Handling4 min
OverlayFS Storage DriverLowerDir, UpperDir, WorkDir, MergedDirCopy-on-Write (CoW) Mechanics, Image Layer Merging, Write Overhead4 min

Quick Reference & Comparison Matrices

1. The 6 Core Linux Kernel Namespaces Isolation Matrix

Namespace FlagKernel SubsystemWhat it Isolates Inside ContainerSecurity & Operational Impact
CLONE_NEWPIDProcess IDs (pid)Container processes receive isolated PIDs (PID 1 inside container).Container processes cannot view or signal host processes.
CLONE_NEWNETNetwork Stack (net)Network interfaces, IP routing tables, iptables rules, socket ports.Container gets dedicated virtual loopback and eth0 interface.
CLONE_NEWNSMount Points (mnt)Filesystem mount point tree and directory structures.Container root / is decoupled from host filesystem root.
CLONE_NEWIPCInter-Process Comm (ipc)System V IPC objects and POSIX message queues.Prevents shared memory segment access between containers.
CLONE_NEWUTSHostname & Domain (uts)Hostname and NIS domain name settings.Container sets custom hostname without modifying host hostname.
CLONE_NEWUSERUser & Group IDs (user)Maps container root (UID 0) to unprivileged host UID.Prevents container root breakouts from gaining host root privileges.

2. OverlayFS Layer Directory Architecture Taxonomy

OverlayFS DirectoryMutability StateLayer Contents & Operational Role
LowerDirRead-Only (Immutable)The stacked read-only Docker image layers containing OS libraries and code.
UpperDirRead-Write (Mutable)The thin writable container layer holding runtime modifications, new files, and logs.
WorkDirInternal Engine UseUsed internally by Linux kernel to prepare atomic Copy-on-Write modifications.
MergedDirVirtual Unified ViewThe unified mount point exposed to container processes as the root / filesystem.

CLI Command Masterclass: Runtime Resource Limits & Introspection

1. Resource Limits in docker run

  • Mental Model: Configures low-level Linux cgroups v2 resource quotas directly upon container creation.
FlagOperational Purpose
--memory="512m"Hard upper limit on RAM memory. Triggering this causes kernel OOM Killer intervention.
--cpus="1.5"Restricts container execution to a maximum of 1.5 CPU cores per second.
--restart=unless-stoppedInstructs dockerd daemon to restart container automatically on crash or host reboot.
# Production Hardened Resource Allocation Run Command
$ docker run -d \
  --name production-api \
  --memory="512m" \
  --cpus="1.5" \
  --restart=unless-stopped \
  nginx:alpine

2. docker stats, docker inspect & docker top

  • Mental Model: Interrogates running container runtime processes and kernel cgroup metrics.
# 1. Live Real-Time Resource Usage Stream across all containers
$ docker stats

# 2. Query Container Host PID and IP address via JSON Format
$ docker inspect --format '{{ .State.Pid }} | {{ .NetworkSettings.IPAddress }}' production-api

# 3. List active host processes running inside container
$ docker top production-api

Architectural Deep-Dive & Engineering Concepts

OverlayFS Copy-on-Write (CoW) Engine Mechanics

OverlayFS eliminates file duplication across containers by sharing read-only LowerDir image layers:

[ Container Process Virtual View: MergedDir ]
  ├── /app/server.js  <-- Read from UpperDir (Modified)
  ├── /usr/bin/node   <-- Read from LowerDir (Shared Read-Only)
  └── /etc/alpine-release <-- Read from LowerDir (Shared Read-Only)

[ Physical Disk Layout ]
  ├── UpperDir  (Writable Container Layer) : [/app/server.js]
  └── LowerDir  (Read-Only Image Layers)   : [/usr/bin/node, /etc/alpine-release]

Interactive Self-Assessment Checkpoints

Knowledge Check

What is the architectural role of runC in the Docker Engine execution pipeline?

Knowledge Check

How does the Linux CLONE_NEWUSER namespace enhance container security?

Knowledge Check

What happens in OverlayFS when a process inside a container modifies a file residing in a read-only LowerDir layer?

Problem: Inspecting OverlayFS Layer Mount Points in Runtime

Write a Linux command sequence using docker inspect and mount to inspect the exact LowerDir, UpperDir, WorkDir, and MergedDir host filesystem paths for a running container.

On this page