What are the core concepts covered in Linux Container Internals: cgroups v2 & Namespaces?

Why containers are NOT virtual machines: containers are ordinary Linux processes isolated by kernel Namespaces; The 8 Linux Namespaces: PID (Process IDs), Mount (Filesystems), Net (Network routing), User (Rootless mapping), IPC, UTS, Cgroup, Time; Managing CPU and Memory resource ceilings using cgroups v2 (`/sys/fs/cgroup`); Constructing a secure, rootless container environment using `unshare` and custom chroot/pivot_root

How long does it take to learn Linux Container Internals: cgroups v2 & Namespaces?

It typically takes about 28 minutes to complete this lesson and its interactive exercises.

What are best practices for Linux Container Internals: cgroups v2 & Namespaces?

Use cgroups v2 on all modern Linux distributions (Ubuntu 22.04+ default). Deploy Rootless Podman / Docker to prevent container escape privilege escalation. Use `pivot_root` instead of `chroot` for secure filesystem root isolation.

Advanced 28 min readModule: Module 13: Container Internals: cgroups v2, Namespaces & Rootless

Linux Container Internals: cgroups v2 & Namespaces

Demystify Docker and Kubernetes from the ground up: the 8 Linux Namespaces (`CLONE_NEWPID`, `CLONE_NEWNET`, `CLONE_NEWNS`, `CLONE_NEWUSER`), cgroups v2 unified resource hierarchy (`cpu.max`, `memory.max`, `io.weight`), and creating isolated containers using `unshare` and `pivot_root`.

What You Will Learn in This Lesson

Why containers are NOT virtual machines: containers are ordinary Linux processes isolated by kernel Namespaces
The 8 Linux Namespaces: PID (Process IDs), Mount (Filesystems), Net (Network routing), User (Rootless mapping), IPC, UTS, Cgroup, Time
Managing CPU and Memory resource ceilings using cgroups v2 (`/sys/fs/cgroup`)
Constructing a secure, rootless container environment using `unshare` and custom chroot/pivot_root

Introduction & Core Concept

There is no such physical object as a 'container' inside the Linux kernel. A container is simply a standard Linux process isolated by two fundamental kernel subsystems: Namespaces (which restrict what the process can SEE, such as process lists and network interfaces) and Control Groups / cgroups (which restrict what the process can USE, such as CPU cores, RAM, and disk I/O).

WHY DOES THIS MATTER IN THE REAL WORLD?

Understanding cgroups v2 and namespaces allows you to debug container memory limit throttling, resolve Kubernetes OOMKilled errors, and secure multi-tenant cloud platforms.

Syntax & Structure

bash

unshare --mount --uts --ipc --net --pid --fork --user --map-root-user chroot /container-root /bin/sh
echo "50000 100000" > /sys/fs/cgroup/mygroup/cpu.max

Creating an Isolated Linux Container from Scratch with unshare and cgroups v2

bash

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
#!/usr/bin/env bash
# Building a Pure Linux Container from Scratch (No Docker required!)
 
set -euo pipefail
 
echo "=== Linux Container Architecture: Namespaces & cgroups v2 ==="
 
# 1. Create a dedicated cgroups v2 resource restriction folder
CGROUP_DIR="/sys/fs/cgroup/kwas_sandbox"
sudo mkdir -p "$CGROUP_DIR"
 
# Configure Memory Limit (100MB max before OOM Killer triggers)
echo "104857600" | sudo tee "$CGROUP_DIR/memory.max" > /dev/null
 
# Configure CPU Quota: 50,000us per 100,000us period (50% of 1 CPU core)
echo "50000 100000" | sudo tee "$CGROUP_DIR/cpu.max" > /dev/null
 
echo "[1] Configured cgroups v2 limits: Max Memory = 100MB | CPU = 50% core"
 
# 2. Launch an isolated process inside private PID, Mount, UTS, and Network Namespaces
echo "[2] Spawning process inside isolated Namespaces via unshare..."
sudo unshare --pid --mount --uts --net --fork bash -c '
    # Attach this container process PID to our cgroups v2 slice
    echo $$ > /sys/fs/cgroup/kwas_sandbox/cgroup.procs
    
    # Set private container hostname (UTS Namespace)
    hostname "kwas-isolated-node-01"
    
    echo "Inside Container -> Hostname: $(hostname)"
    echo "Inside Container -> My PID: $$ (Visible as PID 1 inside namespace!)"
    echo "Inside Container -> Running under cgroup constraints."
'
 
# 3. Clean up cgroup slice
sudo rmdir "$CGROUP_DIR"
echo -e "\n✅ Container execution completed and cgroups cleaned up."

Line-by-Line Technical Breakdown

1Rootless Containers & User Namespaces: The User Namespace (`CLONE_NEWUSER`) maps an unprivileged UID on the host (e.g. UID 1000) to UID 0 (root) inside the container. Even if an attacker escapes the container, they possess zero root privileges on the host kernel, preventing container breakout attacks.

Try It Yourself (Interactive Editor)

Modify the code in real-time and click Run to test live browser output and console logs.

Intelligent Code Runner & Live Sandbox[BASH]

BASH SOURCE EDITOR

Interactive Live Code

#!/usr/bin/env bash
# Building a Pure Linux Container from Scratch (No Docker required!)

set -euo pipefail

echo "=== Linux Container Architecture: Namespaces & cgroups v2 ==="

# 1. Create a dedicated cgroups v2 resource restriction folder
CGROUP_DIR="/sys/fs/cgroup/kwas_sandbox"
sudo mkdir -p "$CGROUP_DIR"

# Configure Memory Limit (100MB max before OOM Killer triggers)
echo "104857600" | sudo tee "$CGROUP_DIR/memory.max" > /dev/null

# Configure CPU Quota: 50,000us per 100,000us period (50% of 1 CPU core)
echo "50000 100000" | sudo tee "$CGROUP_DIR/cpu.max" > /dev/null

echo "[1] Configured cgroups v2 limits: Max Memory = 100MB | CPU = 50% core"

# 2. Launch an isolated process inside private PID, Mount, UTS, and Network Namespaces
echo "[2] Spawning process inside isolated Namespaces via unshare..."
sudo unshare --pid --mount --uts --net --fork bash -c '
    # Attach this container process PID to our cgroups v2 slice
    echo $$ > /sys/fs/cgroup/kwas_sandbox/cgroup.procs
    
    # Set private container hostname (UTS Namespace)
    hostname "kwas-isolated-node-01"
    
    echo "Inside Container -> Hostname: $(hostname)"
    echo "Inside Container -> My PID: $$ (Visible as PID 1 inside namespace!)"
    echo "Inside Container -> Running under cgroup constraints."
'

# 3. Clean up cgroup slice
sudo rmdir "$CGROUP_DIR"
echo -e "\n✅ Container execution completed and cgroups cleaned up."

>=== KWAS Production Deployment Pipeline ===

>Running set -euo pipefail checks: OK

>Containers healthy, 0 errors logged.

>Deployment completed successfully.

Common Mistakes & How to Avoid Them

#1: Setting Kubernetes CPU limits without understanding cgroup CFS throttling, resulting in severe latency spikes.

cgroup CPU limits enforce hard CFS quota slice throttling. If a multi-threaded process exhausts its quota within 10ms, it is frozen for the remaining 90ms of the period.

Incorrect / Antipattern

resources:
  limits:
    cpu: "500m" # Restricts process to 50ms per 100ms CFS period, causing periodic stalls

Correct / Professional Solution

resources:
  requests:
    cpu: "1000m" # Rely on requests or test CPU burstability

Industry Best Practices & Professional Standards

Use cgroups v2 on all modern Linux distributions (Ubuntu 22.04+ default).
Deploy Rootless Podman / Docker to prevent container escape privilege escalation.
Use `pivot_root` instead of `chroot` for secure filesystem root isolation.

Lesson Summary & Core Takeaways

Linux containers are normal processes governed by Namespaces and cgroups.
Namespaces isolate system visibility (PID, Mount, Network, Hostname, User).
cgroups v2 enforces strict CPU, Memory, and Disk I/O bandwidth boundaries.

Claim Free Developer Cloud Credits & VPS Perks

Claim Rewards