Namespaces: вид ядра, который контейнеру дозволено видеть

Восемь видов, один процесс

Зачем инженеру знать все восемь? Потому что когда что-то ломается — копятся зомби, пропадает сетевой интерфейс, root-процесс не может смонтировать — тип namespace сразу говорит, какая граница дала сбой и где искать. Это полная карта поверхности контейнера.

Namespace оборачивает один глобальный ресурс ядра так, что процессы внутри видят свой экземпляр этого ресурса. На современном ядре 8 типов namespace, и контейнер — это просто процесс, помещённый в свежий набор из них:

• PID — идентификаторы процессов; первый процесс становится PID 1.
• mount (mnt) — дерево файловой системы; именно это делает / контейнера его собственным корнем.
• network (net) — интерфейсы, таблицы маршрутизации, loopback, iptables.
• UTS — hostname и domainname (так hostname внутри отличается от хостового).
• IPC — System V IPC и POSIX-очереди сообщений.
• user — карты UID/GID; позволяет root-в-контейнере (UID 0) отобразиться в непривилегированный хостовый UID.
• cgroup — какой вид дерева cgroup видит процесс.
• time — смещения boot/monotonic-часов (добавлен в ядре 5.6).

Вместе эти восемь типов покрывают полный вид ядра, который процесс может запросить: кто я, какие файлы существуют, что в сети, как меня зовут, с кем я общаюсь через IPC, что я вижу в дереве cgroup и который час. Упусти любой из них — и контейнер протечёт в глобальный хостовый вид по этому ресурсу, а это ровно тот класс ошибок, что выглядит как «локально работало, в поде нет».

Ключевой сдвиг в голове: процесс-контейнер — объект того же рода, что любой хостовый процесс. ps на хосте показывает его напрямую, его планирует тот же планировщик, в том же ядре. Нет гостевого ядра, нет ловушки гипервизора. Изоляция — это лишь: когда процесс спрашивает «какие PID существуют?», ядро отвечает из его PID namespace, а не из глобального.

// Примерно то, что рантайм делает, создавая первый процесс контейнера.
// CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET | CLONE_NEWUTS |
// CLONE_NEWIPC | CLONE_NEWUSER | CLONE_NEWCGROUP  — по флагу на namespace.
int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET |
            CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWUSER | CLONE_NEWCGROUP;
pid_t pid = clone(child_fn, stack_top, flags | SIGCHLD, arg);
// child_fn теперь работает как PID 1 в новеньком наборе namespace.

runc — OCI-рантайм, который вызывают Docker и containerd, — читает массив linux.namespaces из config.json контейнера и делает unshare(2) / clone(2) именно для них. Namespaces ортогональны: можно взять сетевой namespace, но разделить хостовый PID namespace — именно это делает docker run --pid=host, и именно это позволяет отладочному sidecar выполнить ps целевого контейнера.

Mount и network: видимая изоляция

Два namespace делают бо́льшую часть того, что вы видите. Mount namespace даёт контейнеру своё дерево файловой системы: рантайм делает pivot_root в распакованный образ, так что / контейнера — корень образа, а хостовые пути просто не существуют в его виде, если только не примонтированы через bind. Network namespace даёт ему свой loopback, свои интерфейсы, свои таблицы маршрутизации и фаервола — поэтому у свежего контейнера есть только lo, пока рантайм не переместит один конец пары veth (виртуальный Ethernet-кабель: два конца, каждый в своём namespace) внутрь, а другой не подключит к мосту на хосте. Namespace живёт, пока в нём есть процесс или пока его пинит файловый дескриптор либо bind-mount; так ip netns и docker exec повторно входят в namespaces существующего контейнера через setns(2), а не создают новые.

User namespace — краеугольный камень безопасности и тот, что чаще всего забывают: с userns-remap UID 0 внутри контейнера отображается в непривилегированный хостовый UID (скажем, 100000), так что «root» контейнера, сбежавший из mount, имеет на хосте привилегии nobody. Без него root-в-контейнере становится root-на-хосте в тот миг, как любой другой барьер (плохой bind-mount, забытая невыброшенная capability) поддастся.