A container is not a tiny VM. It is a regular Linux process with three kernel features applied: namespaces, cgroups, and a union filesystem. This lesson shows you exactly what that means, provably.

1. A Container Is Just a Process

Run docker run -d nginx, then immediately run docker top <id> on the host. You will see a plain nginx process with a regular PID. There is no hypervisor, no separate kernel, no hardware virtualisation — just a Linux process the kernel launched with some extra flags.

# On the host:
$ docker run -d --name web nginx
$ docker top web
UID    PID    PPID   CMD
root   18432  18410  nginx: master process nginx -g daemon off;
www    18487  18432  nginx: worker process

# Same PID visible in the host process table:
$ ps aux | grep 18432

2. Namespaces — The Isolation

The kernel feature that makes a process feel isolated is the namespace. Each namespace wraps one aspect of the global system and gives the process its own private view of it. Docker applies six namespaces at container start.

3. Cgroups — Resource Limits

Control groups (cgroups) answer a different question: not what can the process see, but how much of the machine can it consume. The kernel enforces hard limits on CPU time, RAM, disk I/O, and number of processes.

# Cap memory at 512 MB and CPU at 1.5 cores:
$ docker run --memory=512m --cpus=1.5 nginx

# Inspect actual cgroup settings:
$ docker inspect web --format '{{.HostConfig.Memory}}'
536870912          # 512 × 1024 × 1024 bytes

$ docker inspect web --format '{{.HostConfig.NanoCpus}}'
1500000000         # 1.5 × 10^9 nanocpus

4. Union Filesystem — Layers

Container filesystems are built from stacked read-only image layers with a single writable layer on top. The kernel stitches them into one apparent filesystem using a union mount (OverlayFS on modern Linux). Reads fall through to whichever layer owns the file; writes go to the top layer only — copy-on-write.

Practical consequences: image layers are shared between containers that use the same base — ten nginx containers each get their own writable layer but share one copy of the nginx image layers on disk. And writes are ephemeral — the container layer vanishes with docker rm.

5. Putting It All Together: docker run nginx

When you run docker run nginx, runc executes these steps in order — all within a fraction of a second:

6. Proving It: Inspect the Kernel Structures

Every claim above is verifiable from the host without any special tooling — the Linux /proc filesystem exposes it all.

# Start a container
$ docker run -d --name probe nginx

# Ask Docker for the host PID
$ docker inspect probe --format '{{.State.Pid}}'
18432

# Confirm it in the host process table
$ ps -p 18432 -o pid,ppid,cmd

# Using the PID from Task 1:
$ PID=$(docker inspect probe --format '{{.State.Pid}}')

# List the namespace symlinks
$ sudo ls -la /proc/$PID/ns/
lrwxrwxrwx  ipc  -> ipc:[4026532305]
lrwxrwxrwx  mnt  -> mnt:[4026532303]
lrwxrwxrwx  net  -> net:[4026532308]
lrwxrwxrwx  pid  -> pid:[4026532306]
lrwxrwxrwx  uts  -> uts:[4026532304]
lrwxrwxrwx  user -> user:[4026531837]

# Compare with a host process — different inode numbers = different namespace
$ sudo ls -la /proc/1/ns/

# Start a container limited to 64 MB
$ docker run -d --name memtest --memory=64m nginx

# Check the cgroup limit (cgroups v2 path):
$ PID=$(docker inspect memtest --format '{{.State.Pid}}')
$ sudo cat /proc/$PID/cgroup
0::/system.slice/docker-<id>.scope

$ sudo cat /sys/fs/cgroup/system.slice/docker-<id>.scope/memory.max
67108864    # 64 × 1024 × 1024

# Or use docker stats:
$ docker stats memtest --no-stream