Hoe werkt Docker onder de motorkap?

Question

Accepted Answer

Docker maakt gebruik van Linux kernel-functies — **namespaces** (isolatie), **cgroups** (resourcebeheer) en **union filesystems** (gelaagde images) — om lichtgewicht containers te creëren. Het begrijpen van de onderliggende mechanismen verklaart hoe containers isolatie en efficiëntie bereiken.

## Namespaces — isolatie

```text
Linux NAMESPACES isolate what a process can SEE — giving each container its own view:
  PID namespace     → its own process tree (container sees only its processes)
  NET namespace     → its own network interfaces, IPs, ports
  MNT namespace     → its own filesystem mounts
  UTS namespace     → its own hostname
  IPC, USER namespaces → isolated IPC, user/group ID mapping
→ Namespaces are WHY a container feels like a separate machine (isolated view),
  while actually sharing the host kernel.
```

## cgroups — resourcebeheer

```text
Control Groups (CGROUPS) LIMIT and account for resource usage per container:
  → CPU, memory, disk I/O, network bandwidth
→ cgroups are WHY you can set resource limits (-m, --cpus) — the kernel enforces them.
```

## Union filesystem — gelaagde images

```text
UNION/OVERLAY filesystems (overlayfs) stack image LAYERS:
  → read-only image layers + a thin writable container layer on top, merged into one view
  → layers are SHARED between images/containers (one copy on disk) → space-efficient
→ This is WHY images are layered, cached, and shareable, and containers are lightweight.
```

## De architectuur

```text
Docker CLI → Docker DAEMON (dockerd) → containerd → runc (creates containers using
  namespaces + cgroups). The daemon manages images, containers, networks, volumes.
→ Containers are just ISOLATED PROCESSES on the host (not VMs) — using kernel features,
  sharing the host kernel → lightweight and fast.
```

## Waarom het belangrijk is

Het begrijpen hoe Docker onder de motorkap werkt is waardevolle kennis op senior-niveau omdat het **containers demystificeerd** en hun belangrijkste eigenschappen verklaart (isolatie, efficiëntie, resourcebeheer), wat je vermogen verdiept om geredeneerd over gerelateerde systemen na te denken, deze in te stellen en problemen op te lossen.

Het cruciale inzicht is dat **containers geen VM's zijn — het zijn geïsoleerde processen op de host** met behulp van Linux kernel-functies, wat verklaart waarom ze lichtgewicht en snel zijn (de hostkernel delen in plaats van aparte OS'sen uit te voeren).

Het begrijpen van de **drie kernmechanismen** verklaart de eigenschappen: **namespaces** isoleren wat een proces kan zien (zijn eigen procestree, netwerk, bestandssysteem, hostnaam — wat *waarom* een container aanvoelt als een aparte machine ondanks het delen van de kernel), **cgroups** beperken en verantwoorden resourcegebruik (wat *waarom* je CPU- en geheugenlimieten kunt instellen — de kernel dwingt ze af), en **union/overlay filesystems** stapelen imagelayers (wat *waarom* images gelaagd, in cache geplaatst en deelbaar zijn, en containers lichtgewicht zijn — alleen-lezen layers gedeeld tussen containers met een dunne beschrijfbare laag erboven).

Het begrijpen van de **architectuur** (CLI → daemon → containerd → runc, waarbij de daemon alles beheert) geeft het volledige beeld van hoe Docker werkt.

Dit diepere begrip helpt je redeneren over isolatiegrenzen (en hun beveiligingsimplicaties, omdat containers de kernel delen), verklaart prestatie- en efficiëntiekenmerken en helpt bij het oplossen van problemen.

Omdat het begrijpen van de onderliggende mechanismen (namespaces, cgroups, union filesystems) verklaart *waarom* containers zich gedragen zoals ze doen — hun isolatie, efficiëntie, resourcebeheer en het belangrijke feit dat ze de hostkernel delen (met beveiligingsimplicaties) — en het vermogen verdiept om zelfverzekerd met gerelateerde systemen te werken, is het begrijpen hoe Docker onder de motorkap werkt waardevolle kennis op senior-niveau die je optilt van het gebruiken van Docker naar het werkelijk begrijpen ervan, een onderwerp dat de diepte weerspiegelt die voor senior-rollen wordt verwacht en nuttig is voor het redeneren over containergedrag, beveiligingsgrenzen en prestaties.