Namespaces и cgroups — примитивы контейнера

Семь типов namespace. Namespace оборачивает глобальный ресурс ядра так, что процессы внутри видят собственную изолированную копию. Linux предоставляет семь типов namespace.

# Список namespace для текущего процесса оболочки:
ls -la /proc/$$/ns/
# lrwxrwxrwx 1 user user 0 Jun 22 09:00 cgroup -> cgroup:[4026531835]
# lrwxrwxrwx 1 user user 0 Jun 22 09:00 ipc    -> ipc:[4026531839]
# lrwxrwxrwx 1 user user 0 Jun 22 09:00 mnt    -> mnt:[4026531840]
# lrwxrwxrwx 1 user user 0 Jun 22 09:00 net    -> net:[4026531992]
# lrwxrwxrwx 1 user user 0 Jun 22 09:00 pid    -> pid:[4026531836]
# lrwxrwxrwx 1 user user 0 Jun 22 09:00 user   -> user:[4026531837]
# lrwxrwxrwx 1 user user 0 Jun 22 09:00 uts    -> uts:[4026531838]

# Два процесса с одинаковым inode-номером для типа namespace
# находятся в ОДНОМ namespace. Разные inode = разные namespace.

Создание namespace через unshare. unshare запускает новый процесс в новом namespace без какого-либо контейнерного рантайма. Это и есть голая возможность ядра.

# Создать новый UTS namespace и изменить hostname внутри:
sudo unshare --uts /bin/bash
# Внутри нового namespace:
hostname container-test
hostname
# container-test

# Открыть другой терминал на хосте и проверить:
hostname
# myserver    ← hostname хоста не изменился

# Создать новый PID namespace — оболочка становится PID 1 внутри:
sudo unshare --pid --fork --mount-proc /bin/bash
# Внутри:
echo $$
# 1    ← эта оболочка — PID 1 в новом namespace
ps aux
# USER  PID %CPU %MEM VSZ   RSS TTY   STAT TIME COMMAND
# root    1  0.0  0.0 4236 3492 pts/1 S    0:00 /bin/bash
# root    2  0.0  0.0 7484 2992 pts/1 R+   0:00 ps aux
# Видны только два процесса — 200+ процессов хоста скрыты

# Создать новый network namespace (изолированный сетевой стек):
sudo unshare --net /bin/bash
# Внутри:
ip link
# 1: lo: <LOOPBACK> mtu 65536 ...   ← только loopback, нет eth0, нет docker0

unshare с несколькими флагами комбинирует namespace: --pid --net --uts --ipc --mount — это примерно то, что делает контейнерный рантайм при старте контейнера, минус смена корня.

Вход в существующие namespace через nsenter. nsenter подключает процесс к namespace уже запущенного процесса. Именно так отлаживают контейнеры с хоста без docker exec.

# Найти PID контейнера на хосте:
# (В Docker: docker inspect <container> --format '{{.State.Pid}}')
CPID=12345

# Войти в сетевой namespace контейнера для инспекции снаружи:
sudo nsenter --net --target $CPID ip addr
# 1: lo: <LOOPBACK,UP>
# 15: eth0@if16: <BROADCAST,MULTICAST,UP> ...
#   inet 172.17.0.3/16

# Войти в PID namespace контейнера для просмотра его дерева процессов:
sudo nsenter --pid --target $CPID ps aux

# Войти во ВСЕ namespace контейнера (эквивалент raw exec):
sudo nsenter --target $CPID --mount --uts --ipc --net --pid -- /bin/bash
# Ты теперь внутри полного окружения контейнера без Docker

# Именно так работает 'docker exec' под капотом —
# он вызывает nsenter для входа в namespace контейнера.

nsenter незаменим, когда контейнер не имеет оболочки (образы FROM scratch, distroless) — входишь в его сетевой namespace с хоста, но запускаешь инструменты из файловой системы хоста.

cgroups v2: лимиты ресурсов на группу процессов. Namespaces контролируют что процесс видит. cgroups контролируют сколько ресурсов хоста он может использовать. Урок 08 покрыл cgroups в глубину; здесь мы связываем их с картиной контейнера.

# Иерархия cgroup v2 находится в /sys/fs/cgroup (единая иерархия):
ls /sys/fs/cgroup/
# cgroup.controllers  memory.current  memory.max  system.slice  user.slice

# Найти, к какому cgroup принадлежит PID контейнера:
cat /proc/$CPID/cgroup
# 0::/system.slice/docker-abc123.scope

# Инспектировать лимит памяти для этого cgroup:
cat /sys/fs/cgroup/system.slice/docker-abc123.scope/memory.max
# 536870912   ← лимит 512 МБ, установленный Docker

# Инспектировать лимит CPU:
cat /sys/fs/cgroup/system.slice/docker-abc123.scope/cpu.max
# 100000 1000000   ← квота 100мс на период 1000мс = 10% одного CPU

# Создать cgroup вручную и ограничить его (показывает сырой механизм, который использует Docker):
sudo mkdir /sys/fs/cgroup/demo
echo 268435456 | sudo tee /sys/fs/cgroup/demo/memory.max   # 256 МБ
echo $$ | sudo tee /sys/fs/cgroup/demo/cgroup.procs        # добавить эту оболочку

# Эта оболочка теперь не может выделить более 256 МБ суммарно.
# OOM killer (из урока 08) сработает при попытке.

Флаги Docker --memory, --cpus и --cpu-shares записывают именно эти файлы cgroup. Другого механизма нет.

Уравнение контейнера: namespaces + cgroups + rootfs. Контейнерный рантайм выполняет три действия последовательно при запуске контейнера:

# 1. NAMESPACES — создать изолированные представления ядра:
#    --pid:   новое пространство PID (процесс контейнера — PID 1)
#    --net:   новый сетевой стек (veth-пара к bridge хоста)
#    --mnt:   новая таблица монтирования
#    --uts:   новое имя хоста
#    --ipc:   новое IPC-пространство
#    --user:  (опционально) переназначение UID для rootless-контейнеров

# 2. CGROUPS — применить лимиты ресурсов:
#    memory.max   → --memory в Docker
#    cpu.max      → --cpus в Docker
#    pids.max     → ограничение fork bomb

# 3. ROOTFS — предоставить другую файловую систему как корень:
#    pivot_root() или chroot() в стек слоёв образа контейнера
#    Образ контейнера — просто дерево директорий (tar-слои)
#    overlayfs объединяет read-only слои образа с записываемым верхним слоем

# Собрать минимальный контейнер вручную (образовательно — не для продакшна):
sudo unshare --pid --fork --mount-proc --net --uts \
  chroot /path/to/rootfs /bin/sh
# Это контейнер. Без демона Docker, без containerd, без магии.
# Единственное отличие от настоящего контейнерного рантайма:
# - нет назначения cgroup (нет лимитов ресурсов)
# - нет veth-пары (нет сетевой связности)
# - нет управления образами / слоями
# Настоящий рантайм автоматизирует эти три шага, добавляет управление
# жизненным циклом, дистрибуцию образов и API управления.

# Проверить с хоста, что у "контейнера" свой PID namespace:
ls -la /proc/<pid-контейнера>/ns/pid
# pid:[4026532345]   ← другой inode = другой namespace
ls -la /proc/$$/ns/pid
# pid:[4026531836]   ← PID namespace хоста

Это мост: трек Docker начинается с docker run, но теперь ты знаешь, что под капотом он вызывает clone() с флагами namespace, записывает лимиты cgroup и вызывает pivot_root() в стек слоёв образа. Каждая сессия отладки контейнера — docker exec, nsenter, лимиты памяти cgroup, инспекция сетевого namespace — обретает смысл, когда видишь три примитива.