Архитектура containerd & shim
Тема дорожной карты · Docker & Containers
containerd — это демон, который реально качает образы, управляет снапшотами и супервизит контейнеры; dockerd и Kubernetes (через CRI) дёргают его. На каждый контейнер containerd запускает процесс containerd-shim, который держит runtime (runc) и остаётся живым после рестарта containerd, поэтому контейнеры продолжают работать. Инспектируйте через ctr (низкий уровень) или nerdctl (CLI, совместимый с Docker). Зачем знать: «Docker завис» часто решается прямой работой с containerd, а на нодах Kubernetes dockerd вообще нет — там runtime именно containerd.
Как это работает
Архитектура containerd & shim — это namespaces (mount, network, PID, IPC, UTS, user, cgroup) + cgroups (cpu, memory, io, pids, devices) + container-aware ФС (overlay2, btrfs, zfs). Daemon Docker (dockerd) общается с low-level runtime (containerd → runc), который и делает clone() с правильными флагами. Образы хранятся как content-addressed tar-слои; docker save/load экспортит/импортит; daemon собирает rootfs стекуя слои через overlayfs.
Когда применять
Внутренности важны когда (а) дебажите "почему контейнер видит X", (б) выбираете storage driver (overlay2 — дефолт и почти всегда правильный), (в) оцениваете альтернативные runtime (Podman, containerd, CRI-O для Kubernetes), (г) строите что-то поверх Docker (CI-builder, sandboxing-тул). Прочтите docker info, runc spec, OCI image format spec хотя бы раз.
Типичные ошибки
Ловушки Архитектура containerd & shim: выбор storage driver по старому блог-посту (overlay2 — ответ в 99% случаев); путаница Docker как компании с OCI-стандартом, который все теперь реализуют (docker pull работает с любым OCI registry); предположение, что Docker Desktop на macOS ведёт себя как Engine на Linux (нет — между ними VM с другими I/O perf и сетью). strace -f и lsns — для дебага runtime-мистики.