Namespaces and cgroups
What cgroups and Namespaces Do in the Linux Kernel
cgroups, short for control groups, are a Linux kernel feature that groups processes together and controls how much of the system's resources they can use. Namespaces are a second kernel feature that controls what a process can see. Containers are built from both: namespaces give each container its own view of the system, and cgroups limit what it can consume. For a general introduction, see what a container is.
A container is not a special kind of object inside the kernel. It is a group of ordinary Linux processes that the kernel has been asked to isolate and limit. The software that creates containers, such as the Docker engine or LXC, sets up the namespaces and cgroups and then starts the application inside them.
The Main Types of Namespaces and What They Isolate
Linux provides several types of namespace. Each one isolates a different kind of resource:
- PID: the process ID space. The application sees its own process list, and the first process inside is numbered 1, so it cannot see the host's processes.
- Network: its own network interfaces, routing table and ports.
- Mount: its own view of the file system and mount points.
- UTS: its own host name.
- User: its own mapping of user and group IDs, so a root user inside the container can map to an ordinary user on the host.
Namespaces control visibility, not usage. A process inside a PID namespace cannot see host processes, but nothing in a namespace stops it from using all of the host's CPU. That job belongs to cgroups.
How cgroups Limit CPU, Memory and Disk Input and Output
A cgroup groups processes and applies limits or accounting to them. Depending on the controller in use, the kernel can cap the CPU time a group uses, set a maximum amount of memory, and limit disk input and output (I/O).
Memory limits are the most noticeable. If processes in a container try to use more memory than their cgroup allows, the kernel first tries to reclaim memory from them. If it cannot, it stops one of the processes in that group, and the rest of the host is unaffected.
cgroups also make resource use measurable. An operator can see how much CPU and memory each container uses, which helps explain why one site on a shared server feels slow. Current Linux distributions use the unified version of cgroups, often called cgroup v2, which organizes all controllers in one consistent tree.
Example: A Leaking Application With a Memory Limit
A container runs a small API with a memory limit of 512 MB. A bug in the code slowly increases its memory use. When the process reaches the limit, the kernel stops it, and the container runtime can restart it. The other containers on the server keep their memory, so the leak does not take down the whole machine. Without the limit, the same leak could consume the RAM that every site on the host depends on.
Frequently asked questions
Are namespaces and cgroups enough to make containers secure?
They are necessary but not sufficient. Namespaces and cgroups separate and limit processes, but containers still share the host kernel. Additional controls, such as restricting which system calls a process may make and dropping unneeded privileges, reduce the risk further. For strongly separated tenants, many operators still choose virtual machines. For how this compares with hypervisor-based separation, see VM isolation.
Do cgroups and namespaces work on Windows?
Not in the same way. They are Linux kernel features, so Linux containers depend on them. Windows has its own container technology with separate isolation mechanisms, and Windows containers need a Windows kernel. Linux containers can run on Windows only through a Linux environment, such as a lightweight virtual machine.