The seven namespace types

• PID namespace — The container process sees itself as PID 1. It cannot see the host's processes. This is why ps aux inside a container shows only container processes.
• NET namespace — Private network stack: its own IP address, routing tables, and iptables rules. This is how each pod in Kubernetes gets its own IP.
• MNT namespace — The container sees its own filesystem root (/app, /bin, /etc). It cannot see the host's /etc/passwd or other sensitive files.
• UTS namespace — The container has its own hostname. Running hostname inside a container returns the container ID, not the host name.
• IPC namespace — Isolated inter-process communication (shared memory, semaphores). Containers cannot interfere with each other's IPC.
• User namespace — Map host user IDs to container user IDs. Allows running as "root" inside a container while being an unprivileged user on the host.
• Cgroup namespace — Container sees its own cgroup hierarchy, not the host's.

What cgroups control

• cpu — CPU shares and hard limits. --cpus=0.5 in Docker sets a cgroup cpu.cfs_quota_us limit — the container cannot use more than 50% of one core.
• memory — RAM limit. --memory=512m sets memory.limit_in_bytes. When the container exceeds this, the OOM killer terminates it — this is why you see OOMKilled in Kubernetes.
• blkio — Block I/O bandwidth limits. Prevents one container from monopolizing disk throughput.
• pids — Maximum number of processes. Prevents fork bombs from exhausting the host's PID space.
• net_cls / net_prio — Network traffic classification for QoS — prioritize or throttle container network traffic.

How Docker image layers work

• Base layer — The FROM image (e.g. ubuntu:22.04). Read-only. Shared by every container using that image.
• Intermediate layers — Each RUN, COPY, ADD instruction in a Dockerfile creates a new read-only layer. Cached by Docker and reused across builds.
• Container layer — A thin writable layer added when a container starts. All writes (new files, modified files) go here. Destroyed when the container is removed.
• Volumes — Mount points that bypass the container layer. Data written to volumes persists after the container is removed. Used for databases, logs, and config.

Problem → layer mapping

• OOMKilled — cgroup memory limit enforced by the kernel. Increase memory.limit or fix the memory leak.
• Container sees wrong hostname — UTS namespace. Expected behavior — container has its own hostname.
• Pod cannot reach another pod — NET namespace + CNI plugin (Calico/Flannel/Cilium). Check network policy and CNI logs.
• Slow image pull — OverlayFS layer download. Cache base layers in a registry mirror or use a smaller base image.
• CrashLoopBackOff — Application crash — the container layer is fine. Check application logs: kubectl logs <pod> --previous.
• Cannot run as root in container — User namespace or Pod Security Policy. Expected in hardened environments.