What are cgroups and namespaces, and how do they power containers?
Learn the kernel mechanics behind containers — how namespaces isolate and cgroups constrain resources, with real Docker examples.
Expected Interview Answer
Linux namespaces give a process its own isolated view of system resources (PIDs, network, mounts, hostname, users, IPC), while cgroups (control groups) limit and account for how much CPU, memory, and I/O a process or group of processes can actually consume — together they are the two kernel primitives that make a container a container.
Namespaces create isolation: the PID namespace makes a containerized process see itself as PID 1 with its own process tree, the network namespace gives it a private network stack and interfaces, the mount namespace gives it its own filesystem view, and UTS/IPC/user namespaces isolate hostname, inter-process communication, and user/group ID mappings respectively. Cgroups create constraint: they group processes and cap or throttle their CPU shares, memory ceilings, and block I/O bandwidth, and cgroups v2 also enforces these limits hierarchically across the whole tree. Docker (via runc) simply combines both when it starts a container: it puts the new process into a fresh set of namespaces so it cannot see or touch anything outside its slice, then attaches it to a cgroup so it cannot starve the host of resources. Neither mechanism alone is "containers" — namespaces without cgroups gives isolation with no resource ceiling, and cgroups without namespaces gives resource limits with no privacy.
- Explains the real kernel mechanism behind container isolation, not just the marketing term
- Clarifies why containers are lightweight compared to VMs — no hypervisor, just kernel bookkeeping
- Helps debug “noisy neighbor” and OOM-killed container incidents correctly
- Distinguishes what security boundary containers actually provide versus what they do not
AI Mentor Explanation
Namespaces are like giving each net-practice bay its own numbered set of stumps, its own scoreboard, and its own entry gate, so a bowler inside bay 3 genuinely cannot see or interfere with bay 5's session even though both share the same indoor facility. Cgroups are the facility manager’s separate rule that bay 3 gets only 20 minutes of bowling-machine time and bay 5 gets 40, regardless of how badly either team wants more. A team practicing in bay 3 experiences total privacy from bay 5 thanks to namespaces, but is still capped on machine time thanks to cgroups. Both rules are enforced by the same facility, just for different reasons — one for privacy, one for fairness.
Step-by-Step Explanation
Step 1
Kernel creates namespaces
runc asks the kernel for fresh PID, net, mount, UTS, IPC, and user namespaces for the new process.
Step 2
Process gets isolated view
Inside the namespaces, the process sees itself as PID 1, has its own network interfaces, and its own mount table.
Step 3
Process is attached to a cgroup
The container runtime places the process into a cgroup with configured CPU shares, memory limits, and I/O weights.
Step 4
Kernel enforces limits at runtime
If the process exceeds its memory cgroup limit it is OOM-killed; CPU cgroup throttling limits its scheduled CPU time.
What Interviewer Expects
- Clear separation of concerns: namespaces isolate, cgroups constrain
- Naming at least three specific namespace types (PID, net, mount, UTS, IPC, user)
- Understanding that both are kernel features, not Docker inventions
- Awareness that containers share the host kernel, unlike VMs
Common Mistakes
- Treating “namespaces” and “cgroups” as synonyms for “containers” without explaining the split
- Forgetting that a shared kernel means a kernel-level exploit can escape both mechanisms
- Believing cgroups provide process isolation rather than resource accounting
- Not knowing that cgroups v2 changed the hierarchy model from v1
Best Answer (HR Friendly)
“In simple terms, namespaces are what give a container the illusion of having its own machine — its own processes, its own network, its own files — while cgroups are the rulebook that stops one container from hogging all the CPU or memory on a shared server. Docker just wires both kernel features together, which is why containers start almost instantly and use far less overhead than a full virtual machine.”
Code Example
# Find the PID of a running container process on the host
docker inspect -f "{{.State.Pid}}" myapp-container
# List the namespaces that process belongs to
ls -la /proc/<PID>/ns
# View the memory cgroup limit Docker applied
cat /sys/fs/cgroup/memory/docker/<container-id>/memory.limit_in_bytes
# Run a container with explicit resource caps
docker run -d --memory="512m" --cpus="1.5" --name myapp-container myapp:1.0Follow-up Questions
- What is the difference between cgroups v1 and cgroups v2?
- Which namespace would you disable to run a container in the host network stack, and why?
- How does the kernel handle a process that exceeds its memory cgroup limit?
- Why do containers provide weaker isolation than virtual machines?
MCQ Practice
1. What is the primary role of Linux namespaces in a container?
Namespaces isolate what a process can see — its process tree, network stack, mounts, and more — not resource limits.
2. What happens when a process exceeds its cgroup memory limit?
The kernel enforces memory cgroup limits by invoking the OOM killer against processes that exceed their allotted memory.
3. Which statement correctly distinguishes the two mechanisms?
Namespaces provide isolated views of resources; cgroups provide resource accounting and limits — the two are complementary.
Flash Cards
What do namespaces do? — Give a process an isolated view of PIDs, network, mounts, hostname, IPC, or users.
What do cgroups do? — Limit and account for CPU, memory, and I/O a process or group can consume.
Who enforces both? — The Linux kernel — Docker/runc simply configures them at container start.
Why does exceeding a memory cgroup limit matter? — The kernel OOM-kills the offending process to protect the rest of the host.