Container Internals & Linux Primitives

What namespaces do

Without namespaces, ps aux inside a container would list every process on the host. With PID namespaces, the container sees only its own process tree. NET namespaces give each container its own eth0, routing table, and iptables rules. MNT namespaces control which filesystem paths are visible—this is how the container's root filesystem differs from the host's.

The eight namespace types (Linux 5.6+)

How Docker creates namespaces

runc calls the clone() syscall (or unshare() for namespace-only changes) with CLONE_NEWPID | CLONE_NEWNET | CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC flags. The new process enters fresh namespaces before executing your container entrypoint.

# Run a container and capture its PID on the host
CID=$(docker run -d nginx:alpine)
PID=$(docker inspect --format '{{.State.Pid}}' $CID)

# List namespace links for the container process
ls -la /proc/$PID/ns/

# Compare host init namespace vs container (different inode numbers = isolated)
readlink /proc/1/ns/pid
readlink /proc/$PID/ns/pid

cgroups v1 vs cgroups v2

Resource controllers

What happens when memory limit is exceeded

The kernel's OOM killer selects a process in the cgroup and sends SIGKILL. Docker reports this as OOMKilled in docker inspect. The container's PID 1 dies—often taking the whole container down. Java apps without -XX:+UseContainerSupport may not respect cgroup limits and get OOM-killed unexpectedly.

$ docker run --rm --memory 32m progrium/stress --vm 1 --vm-bytes 64M
stress: FAIL: cannot allocate 67108864 bytes
Killed

$ docker inspect --format '{{.State.OOMKilled}}' <container_id>
true

$ cat /sys/fs/cgroup/system.slice/docker-*.scope/memory.events
low 0
high 0
max 1
oom 1
oom_kill 1

OverlayFS (default storage driver)

Since Linux 3.18, Docker on Linux uses OverlayFS. Four directories matter:

• lowerdir — read-only image layers (ordered bottom to top)
• upperdir — container's read-write layer (all modifications land here)
• workdir — OverlayFS internal scratch space (not visible to container)
• merged — unified view mounted as container rootfs

Copy-on-write (CoW)

Reads traverse the stack—upperdir first, then lower layers until the file is found. Writes to a file that exists only in a lower layer trigger a copy into upperdir first (CoW), then the write proceeds. This first-write penalty is why databases should use volumes, not the container layer.

Layer sharing

Ten containers from the same image share identical lower layers on disk—only their upperdirs differ. This is why pulling nginx:alpine once benefits every subsequent container using that image.

# Find the merged mount point for a running container
docker inspect --format '{{.GraphDriver.Data.MergedDir}}' mycontainer

# See overlay mount on the host
mount | grep overlay

# Storage driver in use
docker info --format '{{.Driver}}'

Other storage drivers

Container lifecycle

1. runc create — set up namespaces, cgroups, rootfs; create container but don't start process
2. runc start — execute the configured process (your ENTRYPOINT/CMD)
3. Process runs — PID 1 inside container executes application logic
4. runc delete — tear down cgroups, unmount, cleanup after exit

The OCI bundle: config.json

An OCI bundle is a directory containing rootfs/ and config.json. The config specifies the process (args, env, cwd), mounts, Linux namespaces, cgroups path, capabilities, and seccomp profile.

{
  "ociVersion": "1.0.2",
  "process": {
    "terminal": false,
    "user": { "uid": 0, "gid": 0 },
    "args": ["/bin/sh", "-c", "nginx -g daemon off;"],
    "env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],
    "cwd": "/"
  },
  "root": { "path": "rootfs", "readonly": false },
  "linux": {
    "namespaces": [
      { "type": "pid" },
      { "type": "network" },
      { "type": "mount" },
      { "type": "ipc" },
      { "type": "uts" }
    ],
    "cgroupsPath": "/docker/abc123"
  }
}

Docker architecture layers

flowchart TB
  CLI["docker CLI"]
  D["dockerd\nREST API · images · networks"]
  C["containerd\npull · snapshot · shim"]
  S["containerd-shim\nstdio · exit status"]
  R["runc\nclone · cgroups · exec"]
  K["Linux kernel\nnamespaces · OverlayFS"]
  CLI --> D
  D --> C
  C --> S
  S --> R
  R --> K

containerd sits above runc—it manages image content, creates snapshots (OverlayFS mounts), and supervises shims. containerd-shim keeps the container alive after dockerd disconnects and reports exit codes. This separation is why Kubernetes can use containerd directly without dockerd.

Why rootless matters

• Docker daemon compromise ≠ immediate host root access
• Developers can run containers without sudo on shared machines
• Aligns with least-privilege and CIS hardening guidance

How it works

A user namespace maps container root (UID 0) to a high unprivileged UID on the host (e.g. 100000). Processes inside the container believe they are root; the host kernel sees them as a normal user. Subuid/subgid ranges in /etc/subuid define the mapping.

Limitations

Podman: rootless-first alternative

Podman runs daemonless—each podman run is a direct fork/exec via containerd/runc under your user session. Rootless is the default. podman-docker provides a docker CLI alias. On RHEL 8+ and OpenShift developer environments, Podman replaced Docker Engine entirely.