В 2026 спор «containerd vs Docker» уже не про «что моднее», а про то, как вы будете жить с контейнерами в продакшене: обновлять хост, дебажить сеть, собирать логи, ограничивать ресурсы в cgroups v2 и (по возможности) снизить риски за счёт rootless. Containerd давно перестал быть «внутренней деталью Docker» — это самостоятельный рантайм, который часто встречается под капотом Kubernetes и минималистичных установок. Docker Engine при этом остаётся самым удобным «комбайном» для разработки и небольших/средних продакшенов.
Ниже — сравнение с упором на эксплуатацию на типовой VDS: systemd, journald, cgroups v2 и реальный сетевой стек (nftables/iptables).
Карта понятий: кто за что отвечает
Сравнение будет честным только если разделить уровни:
OCI runtime (обычно
runc) — запускает контейнерные процессы в namespaces и cgroups.containerd — менеджер контейнеров низкого уровня: образы, снапшоты, задачи (tasks), плагины, интеграция через CRI.
Docker Engine — платформа: демон, API, CLI, сборка, сети, тома, логирование, дефолты и UX-обвязка.
CLI: у Docker —
docker, у containerd чаще используютnerdctl(аctr— для низкоуровневых операций).
Практический вывод: containerd — «движок», Docker Engine — «движок + панель управления + батарейки». Поэтому выбирать стоит по тому, что вы хотите автоматизировать и где важнее простота, а где — контроль и минимализм.
Rootless containers в 2026: реалистичные ожидания
Rootless — это не «контейнеры вообще без привилегий», а перенос управления в пользовательское пространство через user namespaces. Для VDS это обычно означает меньший риск при компрометации приложения и меньший «blast radius» от ошибочного запуска контейнера.
Docker Engine rootless
У Docker rootless-режим зрелый и хорошо задокументированный. Сильная сторона — экосистема (включая Compose), привычные команды и единый UX. Но есть нюансы, которые всплывают именно в эксплуатации:
Сеть: rootless часто опирается на user-space networking. На высокой нагрузке это обычно даёт меньшую пропускную способность и больше задержку, чем rootful bridge.
Публикация портов: в большинстве случаев работает, но низкие порты и «строгие» политики безопасности требуют аккуратной настройки и проверок.
ФС и права: overlay/uid-mapping добавляет слой сложности в диагностике прав доступа и иногда проявляется в I/O-нагрузке.
Containerd rootless (обычно через nerdctl)
Rootless с containerd в 2026 тоже распространён, особенно там, где нужен минимальный и контролируемый стек. Но «из коробки» это чаще ощущается как набор компонентов, которые нужно согласовать: runtime, сеть, маппинг uid/gid, systemd user units. Взамен вы получаете меньше лишнего и более «прозрачную» архитектуру, если заранее договорились о стандартах конфигурации.
Rootless — отличный базовый уровень защиты, но не замена политик безопасности. Для продакшена всё равно нужны минимальные привилегии, контроль capabilities, по возможности read-only FS и понятная стратегия обновлений образов.
cgroups v2: лимиты, OOM и «почему контейнер съел всю память»
cgroups v2 — фактический стандарт современных дистрибутивов. И Docker, и containerd с ним работают, но в продакшене важны детали: где искать причину OOM и как воспроизводимо применяются лимиты.
Что проверить в первую очередь
В какой иерархии вы живёте: v2 unified или «гибрид».
Как systemd владеет cgroup-деревом и как ваш runtime в него встраивается.
Включены ли и настроены ли защитные механизмы:
systemd-oomd, PSI, лимиты на slices.
Практика лимитов CPU/RAM и диагностика OOM
В Docker лимиты обычно задаются флагами запуска или через Compose, поэтому команда быстрее приходит к единообразию. В containerd+nerdctl возможности тоже есть, но на одиночных хостах админы нередко стандартизируют сервисы через systemd units (включая лимиты и рестарты), чтобы всё было видно через systemctl/journalctl и не зависело от привычек конкретного инженера.
Для расследований OOM в cgroups v2 полезно не зацикливаться на «контейнер упал»: смотрите признаки memory pressure и кто именно инициировал убийство процесса (OOM-killer в пределах cgroup или глобально). Если у вас уже отлажен процесс разбора инцидентов вокруг systemd, то минималистичный стек с containerd часто ощущается «честнее». Если важнее скорость диагностики «здесь и сейчас» — Docker обычно экономит время.
Мини-чек по хосту (на чтение, без «магии»):
stat -fc %T /sys/fs/cgroup
cat /sys/fs/cgroup/cgroup.controllers
systemctl status systemd-oomdЕсли хотите углубиться именно в правила firewall и то, как Docker их добавляет, пригодится материал: как Docker взаимодействует с iptables/nftables и почему ломается publish портов.
Journald logging: удобство, стоимость и диагностика
systemd-journald остаётся самым удобным локальным «буфером» логов на VDS: быстрый поиск, привязка к unit, структурированные поля, предсказуемая ротация через journald.conf. Но важно помнить, что journald — не «бесплатный бесконечный диск»: при большом потоке логов он заметно грузит I/O, и вам нужна стратегия ограничения объёма или форвардинга.
Docker и journald
Docker умеет писать в journald через log driver. В эксплуатации это даёт два плюса:
Единая точка входа: логи контейнеров и сервисов хоста доступны через
journalctlс фильтрами по времени/юниту.Проще контролировать размер логов через системную политику journald и единые лимиты.
Пример включения journald для конкретного контейнера:
docker run --log-driver=journald --name app -d nginx:alpineПример для daemon-wide настройки (показано как текст):
{
"log-driver": "journald"
}Containerd и логи
В мире containerd (особенно рядом с Kubernetes) чаще встречается подход «пишем в stdout/stderr, собираем агентом». На одиночной VDS без Kubernetes journald-ориентированная схема тоже возможна, но «приятность» зависит от того, как вы управляете контейнерами: nerdctl, systemd units или отдельный менеджер. Чем ближе вы к systemd как к «верхнему уровню» управления сервисами, тем более естественно логи ложатся в journald.
Быстрые команды для поиска проблемного контейнера в journald:
journalctl -b -o short-iso -u docker
journalctl -b -o short-iso CONTAINER_NAME=app
iptables/nftables и контейнерная сеть: где чаще всего болит
Ключевая практическая боль «iptables nftables docker» — в том, что контейнерная сеть почти всегда «прописывается» в netfilter. В современных системах базовая подсистема — nftables, а совместимость часто реализуется через iptables-nft. Отсюда типовые инциденты:
Правила «вроде есть», но вы смотрите не туда:
iptablesпоказывает одно, аnft— другое.Конфликт приоритетов и цепочек: ваши правила firewall спорят с автогенерацией.
После обновления пакетов меняется поведение iptables-frontend и ломается публикация портов.
Docker Engine: удобство ценой «магии»
Docker чаще всего «сам всё настроит»: мост, NAT, пробросы портов. Это удобно, пока вам не нужно строго контролировать сетевую политику. В продакшене компромисс обычно такой: заранее определить правила игры (пулы подсетей, где разрешён publish, как вы документируете изменения) и держать firewall в порядке при обновлениях.
Containerd: меньше автоматизма, больше предсказуемости
С containerd на одиночном сервере вы либо берёте nerdctl (Docker-подобный опыт), либо строите сеть более «ручным» образом. Плюс — меньше скрытых движений и проще объяснить, почему пакет пошёл так, а не иначе. Минус — больше ответственности на вас: адресация, маршрутизация, DNS и правила.
Performance overhead: где разница бывает реальной
И containerd, и Docker Engine запускают контейнеры через OCI runtime, поэтому «чистый» оверхед для процесса контейнера обычно минимален. Разница всплывает вокруг инфраструктурных решений:
Сеть: rootless user-space networking почти всегда дороже rootful bridge под нагрузкой.
I/O и слой хранения: overlayfs/uid-mapping в rootless, размер образов, количество слоёв и режим записи логов.
Контрольный контур: сколько демонов, как часто они просыпаются, как вы собираете метрики и логи.
В реальном продакшене чаще упираются не в «Docker медленнее containerd», а в практику: раздутые образы, частые рестарты, шумные соседи по диску, неверные лимиты cgroups v2 и слабая наблюдаемость.
Production operations: что проще поддерживать годами
Эксплуатация — это не только команда запуска, а полный жизненный цикл: обновления, безопасность, бэкапы данных, ротация логов, мониторинг и реакция на инциденты.
Docker Engine выигрывает, если…
Команда уже «думает Docker» и вы не хотите плодить зоопарк инструментов.
У вас Compose-стек, и важна скорость изменений и откатов.
Нужен принцип «один пакет — всё работает», с понятными дефолтами.
Containerd выигрывает, если…
Нужен минимальный рантайм на хосте, где контейнеры — инфраструктурная функция, а не «центр вселенной».
Вы ближе к Kubernetes/CRI-миру и хотите единообразия между окружениями.
Вы готовы инвестировать в стандарты: systemd units, политики логов, сетевые профили.
Если вопрос упирается в безопасность изоляции (а не только в rootless), имеет смысл посмотреть обзор: gVisor и Firecracker для усиления изоляции контейнеров.
Практические сценарии выбора на VDS
Сценарий 1: один сервер, 5–30 сервисов, Compose, быстрые релизы
Чаще всего разумнее Docker Engine: ниже когнитивная нагрузка, проще унифицировать практики, быстрее онбординг. Rootless включайте там, где он не ломает требования по сети и производительности.
Сценарий 2: сервер как «нода» под k3s/k8s-подобный стек, нужен CRI
Containerd — естественный выбор: он ближе к тому, как контейнерный мир работает в оркестраторах. Для локальной отладки на хосте обычно добавляют nerdctl, чтобы сохранить привычный опыт CLI.
Сценарий 3: высокий трафик, чувствительность к latency, сложный firewall
Смотрите в сторону rootful-режима и строгого контроля netfilter. Здесь иногда выгоднее иметь меньше «магии» и больше предсказуемости — но важно, кто будет сопровождать. Если в команде сильный сетевой опыт, минималистичный containerd-стек может быть проще в долгой перспективе. Если нет — Docker с заранее описанными правилами firewall снижает риск ошибок.
Чеклист перед решением (containerd vs Docker Engine)
Нужно ли rootless? Если да — проверьте требования к сети и портам, оцените оверхед user-space networking под вашей нагрузкой.
Что у вас с
cgroups v2? Убедитесь, что лимиты воспроизводимы, а OOM диагностируется быстро.Куда пишем логи? Если ставка на journald — проверьте ротацию, лимиты и схему форвардинга.
Как устроен firewall? Определите, кто «владелец» правил: вы или рантайм, и как вы избегаете конфликтов iptables/nftables.
Операционная рутина: обновления, бэкапы, мониторинг и реакции на инциденты — что проще вашей команде поддерживать годами.
Итоги
В 2026 «containerd vs Docker» — это выбор между минималистичным, более «кирпичным» конструктором и удобной платформой с богатой экосистемой. Для большинства одиночных VDS с веб‑сервисами Docker Engine остаётся самым быстрым путём к стабильной эксплуатации, особенно если вы активно используете Compose и цените удобство диагностики.
Containerd имеет смысл, когда вы строите инфраструктуру ближе к Kubernetes-практикам, хотите меньше лишних компонентов и готовы формализовать окружение: сеть, логи, unit-файлы, политики ресурсов в cgroups v2. Rootless containers в обоих вариантах — сильное улучшение безопасности, но требующее предварительной проверки сети, логирования и производительности под нагрузкой.
