What are cgroups and how does Docker use them?
cgroups (control groups) is a Linux kernel feature that limits, accounts for, and isolates the resource usage of a collection of processes. Docker uses cgroups to enforce hardware resource constraints on containers, ensuring each container gets its fair share of CPU, memory, and disk I/O without affecting others.
cgroups, short for control groups, is a fundamental Linux kernel capability that provides fine-grained control over system resources such as CPU, memory, network bandwidth, and block I/O. It organizes processes into hierarchical groups and allows administrators to set limits, prioritize access, and monitor usage for each group. Docker leverages cgroups as one of its core building blocks alongside namespaces—where namespaces provide isolation (what you can see), cgroups provide resource control (what you can use) .
When you start a Docker container, the Docker daemon automatically creates a cgroup for that container under the appropriate subsystems. Through cgroups, Docker can enforce quotas, set limits, and guarantee that a container cannot consume more than its allocated resources. This prevents any single container from starving others or overwhelming the host system, which is essential for multi-tenant environments and production deployments .
- 1
CPU control: Using --cpus to limit CPU cores (e.g., 1.5 cores) or --cpu-shares to set relative weight for CPU contention . The underlying cgroup parameters are cpu.cfs_period_us and cpu.cfs_quota_us which work together to define how much CPU time a container gets per period .
- 2
Memory control: Using --memory to set hard RAM limits. If a container exceeds this limit, the kernel may invoke the Out-of-Memory (OOM) killer to terminate processes . Memory limits are enforced via the memory cgroup subsystem.
- 3
Block I/O control: Using --blkio-weight (range 10-1000) to set disk I/O priority, or --device-read-bps/--device-write-bps to set absolute speed limits per device .
- 4
Network bandwidth: While cgroups provide a net_cls classifier, Docker typically implements network limits through other mechanisms, though cgroups can be used to classify traffic for external shaping tools like tc .
Internally, when you run a container with resource constraints, Docker writes the corresponding values to cgroup files in the /sys/fs/cgroup/ directory. For example, CPU limits are written to cpu.cfs_period_us and cpu.cfs_quota_us, while memory limits are written to memory.limit_in_bytes. You can verify these settings by inspecting the cgroup files directly or using docker inspect to see the host configuration . The cgroups hierarchy allows Docker to manage resources at the container level, and any child processes spawned by the container automatically inherit the same cgroup restrictions .
Understanding the distinction between namespaces and cgroups is crucial: namespaces provide isolation by giving each container its own view of the system (process IDs, network interfaces, mount points), while cgroups provide resource control by limiting how much of the system's resources each container can actually consume. Together, they form the foundation of Docker's container runtime environment, enabling lightweight virtualization with strong guarantees about resource usage and isolation .
Scenario Questions
0-2 years experience
- 1If you run `docker run -m 500m nginx`, what part of the Linux kernel ensures the container doesn't exceed 500 MB of memory, and how does Docker set that up?
- 2Suppose you need to limit a container's CPU to two cores. Which cgroup subsystem would you configure, and what Docker flag would you use?
- 3What would happen if you start a container without any cgroup limits on a heavily loaded host?
2-5 years experience
- 1We noticed a container occasionally gets killed with OOM despite setting `--memory=1g`. Walk me through how Docker uses cgroups for memory and what could cause this behavior.
- 2During a rollout, one of our services started throttling CPU heavily after we added a new sidecar container. How would you investigate the cgroup settings to identify the issue?
- 3Explain why Docker's default cgroup driver might affect performance on a system using systemd, and how you'd switch it.
5-8 years experience
- 1Design a multi‑tenant SaaS platform that runs untrusted user workloads in Docker. How would you leverage cgroups to enforce strict resource isolation, and what trade‑offs would you consider for CPU vs. memory accounting?
- 2Our cluster is experiencing noisy‑neighbor problems where one tenant's containers starve others of I/O. How can cgroups be used to mitigate this, and what limitations should we be aware of?
- 3If you need to implement per‑container network bandwidth throttling, can cgroups handle it directly? If not, how would you combine cgroups with other Linux primitives?
8+ years experience
- 1We are migrating a legacy monolith that currently runs on VMs to a microservices architecture using Docker. At the architecture level, how would you plan the cgroup hierarchy and driver strategy to support rolling upgrades, observability, and compliance across multiple data centers?
- 2Describe how you would evolve the container runtime stack in a large organization to move from Docker's default cgroup driver to a unified systemd‑managed approach, considering existing workloads, CI pipelines, and cross‑team coordination.
- 3In a multi‑cloud environment, you need consistent resource guarantees across Kubernetes clusters that use different container runtimes. How would you abstract cgroup configurations to ensure uniform behavior, and what challenges might arise?
Follow-up Questions
- What differences have you seen between the cgroupfs and systemd drivers in practice?
- How would you monitor cgroup metrics to detect a runaway container?
- Can you describe a situation where cgroup limits might interfere with application behavior?