How Docker actually works: cgroups and namespaces

A common myth is that Docker containers are “mini virtual machines”. They are not.

A container has no guest operating system, no virtualized BIOS, and no hypervisor. A container is simply an ordinary Linux process running directly on the host kernel, isolated by two native Linux kernel features: Namespaces and Control Groups (cgroups).

Virtual Machine:  [ App ] ──> [ Guest OS Kernel ] ──> [ Hypervisor ] ──> [ Host Hardware ]
Docker Container: [ App ] ──> [ Namespaces + cgroups ] ───────────────> [ Shared Linux Kernel ]

1. Namespaces: What the process can see

Namespaces provide illusion of private system resources by partitioning what a process can view:

Namespace	What it isolates	The illusion inside the container
PID (Process ID)	Process tree	The app sees itself as PID 1 (init), unaware of host processes
NET (Network)	Network interfaces & routing	Its own `eth0`, `localhost`, and private IP routing tables
MNT (Mount)	Filesystem mounts	Root filesystem (`/`) rooted to the container image layers
UTS (Hostnames)	Hostname & domain	Custom hostname independent of the host machine
IPC (Inter-Process)	Shared memory & semaphores	Isolated POSIX message queues
USER (User IDs)	UID/GID mappings	Root (UID 0) inside container maps to an unprivileged UID outside

Because of namespaces, running ps aux inside a container shows only 2 processes, while running ps aux on the host machine reveals the exact same container process running natively alongside everything else.

2. Control Groups (cgroups): What the process can use

Namespaces isolate visibility, but they don’t stop a rogue process from consuming 100% of the host machine’s CPU or RAM.

cgroups enforce hard resource boundaries:

CPU limits: Restrict CPU shares or assign specific CPU cores (e.g. --cpus="1.5").
Memory limits: Sets a hard RAM cap (e.g. -m 512m). If the process exceeds it, the kernel triggers an OOM (Out Of Memory) killer.
Block I/O & Network bandwidth: Throttles read/write speeds to storage devices.

3. OverlayFS: How container images layer

Docker images don’t copy an entire OS disk for every container. They use OverlayFS (a union filesystem):

┌──────────────────────────────────────────────┐
│  Container Layer (Read/Write)                │ ──> Deleted when container dies
├──────────────────────────────────────────────┤
│  Layer 3: Application code & dependencies    │ ──> Immutable, cached
├──────────────────────────────────────────────┤
│  Layer 2: Node.js / Python runtime           │ ──> Immutable, cached
├──────────────────────────────────────────────┤
│  Layer 1: Base image (Alpine / Debian)       │ ──> Shared by 50 containers
└──────────────────────────────────────────────┘

When 10 containers run on the same machine, they all share the exact same read-only base image layers in memory, making container startup take milliseconds rather than minutes.

Virtual Machines vs Containers

Feature	Virtual Machines (KVM, VMware)	Docker Containers
Isolation Level	Hardware-level (Hypervisor)	OS-level (Kernel namespaces/cgroups)
Startup Time	30 to 120 seconds (boots full kernel)	< 1 second (spawns process)
Resource Overhead	High (each VM takes 1–4GB RAM for OS)	Near zero (just the application memory)
Kernel	Each VM runs its own independent kernel	All containers share the host Linux kernel