Linux Namespace & cgroup
Linux namespaces and cgroups are the kernel features that make containers work. Namespaces decide what a process can see, and cgroups decide how much of the machine it can consume.
βΆArchitecture Diagram
π StructureDashed line animations indicate the flow direction of data or requests
If workloads on the same host can all see each other's processes, ports, and mount points, collisions and security issues are unavoidable. If one service can consume unlimited memory or CPU, the rest of the host suffers too. Containers need both visibility boundaries and resource limits.
Containers did not appear from nowhere. They are built on kernel features that existed long before Docker. Early tools exposed those features more directly, and Docker later popularized them by packaging images, builds, and deployment workflows into a friendlier experience.
PID namespaces give each container its own process numbering. Network namespaces provide separate network stacks and interfaces. Mount namespaces separate filesystem views. cgroups track and limit CPU, memory, and I/O so one container cannot easily starve the rest of the machine.
Namespaces and cgroups are not deployment units on their own. They are lower-level building blocks. A container adds images, runtime rules, networking, and storage behavior on top of those kernel primitives.
This concept matters whenever you debug why host PIDs differ from in-container PIDs, why memory limits trigger OOM kills, or what `--cpus` and `--memory` are really doing under the hood. Those flags are not magic. They map to concrete kernel controls.