How Docker Actually Works: A Deep Dive into Namespaces and Cgroups

TL;DR: Docker containers are just standard Linux processes restricted by Namespaces and Cgroups. Namespaces provide visibility isolation by partitioning kernel resources like PIDs and networking, while Cgroups (Control Groups) provide resource isolation by enforcing hard limits on CPU, memory, and I/O usage to prevent host exhaustion.

Docker feels like magic until your container gets OOMKilled or you can’t reach a port you swore was open. Then you realize you aren’t running a mini-virtual machine; you’re just running a process in a very fancy cage. That cage is built out of two fundamental Linux kernel features: Namespaces and Cgroups. If you want to move beyond the basics of docker run, you need to understand how the kernel handles these two mechanisms.

How do Linux Namespaces isolate container processes?

Namespaces partition kernel resources so that one set of processes sees one set of resources while another set sees a completely different set. They provide an isolated view of global kernel resources—such as the process tree, network interfaces, and mount points—without actually virtualizing the hardware.

Think of a private office inside a communal WeWork. When you’re inside those walls, you feel like the CEO of your own domain. You see your own desk and your own files. In Linux terms, your process thinks it is PID 1, the first process on the system. However, from the perspective of the WeWork manager—the host kernel—you’re just Tenant 3458. Namespaces make this possible by using the unshare system call to detach a process from the host's default view.

This isolation extends to the network stack. In a NET namespace, your process gets its own routing table and its own virtual network interfaces. Docker typically hooks this up by creating a veth (virtual ethernet) pair: one end stays on the host’s docker0 bridge, and the other is shoved into the container's namespace. The container thinks it has a physical NIC, but it’s just a tunnel to the host’s bridge.

What is the role of Cgroups in Docker resource management?

Cgroups (Control Groups) are the resource governors of the Linux kernel. They define the hard limits on how much CPU, memory, and I/O a process can consume to prevent a "noisy neighbor" from crashing your host or starving other containers.

If Namespaces are the walls of the office, Cgroups are the circuit breakers. Imagine a startup in the office next to you tries to run fifty crypto-mining rigs. In a raw Linux environment, they’d suck all the power out of the building and trip your lights. Cgroups prevent this by metering consumption. You can see this in action on any Linux machine by looking at /sys/fs/cgroup/. This filesystem is where the kernel exposes the control knobs for every running process.

Modern systems have largely transitioned to Cgroup v2, which replaced the fragmented, multiple-hierarchy mess of v1 with a unified hierarchy. This makes it easier for the kernel to manage resources like memory and I/O together. When you set a memory limit in your Docker Compose file, the kernel monitors that process's usage against the threshold defined in the cgroup. If the process tries to overreach, the kernel’s Out-Of-Memory (OOM) killer calculates an oom_score_adj and terminates the offender to keep the rest of the system stable.

How do Namespaces and Cgroups compare?

Namespaces determine what a process is allowed to see, while Cgroups determine what it is allowed to use. One is about scoping identity and visibility, while the other is about measuring and limiting physical hardware consumption.

Feature	Linux Primitive	Primary Responsibility	The Analogy
Namespaces	ns	Visibility / Isolation	The office walls and door
Cgroups	cgroup	Resource Allocation	The utility meter/circuit breaker
Focus	Security & Context	Performance & Stability	Privacy vs. Power Usage

Why does the distinction between Namespaces and Cgroups matter?

Understanding this distinction is the difference between debugging a permissions error and a performance bottleneck. It allows you to pinpoint whether a failure stems from a restricted view of the system or a resource ceiling imposed by the kernel.

Let's say your microservice is failing to connect to a database. If the network interface is missing or the routing table is empty, you're looking at a Namespace configuration issue—the process literally can't see the path to the outside world. On the other hand, if your service is mysteriously disappearing during high-traffic spikes without throwing a stack trace, you’re likely hitting a Cgroup limit. The kernel doesn't ask for permission; it sees the memory limit has been breached and kills the process instantly (Exit Code 137).

FAQ

Can I manually inspect the namespaces of a running container?
Yes. You can use the nsenter tool or the lsns command to see which namespaces are active. Every process on Linux has a directory in /proc/[pid]/ns/ that contains symlinks to the namespaces it currently occupies.

Does Cgroup v2 change how Docker performs?
Cgroup v2 provides more consistent resource accounting, especially for buffered I/O, which was notoriously difficult to track in v1. Most modern Linux distributions use v2 by default, and Docker leverages this for better performance isolation.

Is it possible for a process to escape a namespace?
Namespace escapes usually require a kernel vulnerability or a misconfiguration, such as running a container with the --privileged flag or mounting the host's /proc filesystem inside the container. In a standard setup, the isolation is enforced by the kernel's internal security checks.