Linux Namespaces and Container History Part 2: Cgroups

Recap In the last article we looked at a(n incomplete) history of containers and dived a bit into Linux namespaces, which help you partition parts of your system and limit their capabilities. However, namespaces aren’t so useful for limiting hardware resources. This article will cover how container runtimes deal with this using cgroups. Core Isolation […]

8 September 2020
Aidan Hobson Sayers

Recap

In the last article we looked at a(n incomplete) history of containers and dived a bit into Linux namespaces, which help you partition parts of your system and limit their capabilities. However, namespaces aren’t so useful for limiting hardware resources.

This article will cover how container runtimes deal with this using cgroups.

Core Isolation Technologies (continued)

cgroups

Linux namespaces are great, but don’t really touch classic resource usage like memory and CPU. cgroups (short for control groups) take a step in filling this gap by providing a unified filesystem-based interface for grouping processes, with assorted ‘subsystems’ supporting the alteration of process behaviour.

Among many other things, leveraging cgroups allows

  • Assignment of processes one or more specific CPUs (e.g. the ––cpuset-cpus argument to docker run)
  • Limiting of process memory and swap usage (e.g. the ––memory argument to docker run)
  • Freezing and resuming processes (e.g. docker pause)

Note that cgroups are used for more than just containers! For example, systemd allows configuration of cgroups for services, slices and scopes.

cgroups: Hands On

You can dig into container cgroups by looking at the cgroup information for any process within that container (I use podman as my container runtime which requires using sudo when applying cgroups, but Docker should work equivalently):