Incus против Docker: системные контейнеры выигрывают по цифрам, но проигрывают в экосистеме
Бенчмарк 2026 года показывает: LXC запускается за 0,8 секунды, Docker — за 1,2, а Kubernetes Pod — от 2,5. При этом Docker остаётся стандартом. Разбираемся, почему Incus и LXC, изолирующие окружение, а не приложение, оказываются легче и быстрее, но уступают в удобстве доставки.
Incus, LXD и Docker: почему «инструмент энтузиастов» обгоняет индустриальный стандарт по цифрам
В апреле 2026 года на сервере с AMD EPYC 9754, 512 ГБ DDR5 и сетью 100 GbE прогнали бенчмарк, результаты которого неудобны для мейнстрима. LXC запускает контейнер за 0,8 секунды. Docker — за 1,2. Kubernetes Pod — от 2,5. В простое LXC съедает 15–25 МБ памяти против 35–50 МБ у Docker и 80–120 МБ у пода Kubernetes. Накладные расходы на CPU при интенсивной нагрузке: 1–2% против 5–8%.
При этом Docker — индустриальный стандарт, а LXC и его наследник Incus принято называть «инструментом энтузиастов». Сравнивать их напрямую — методологическая ошибка, потому что это разные классы инструментов. Но именно так их сравнивают все. И по цифрам картина складывается неловкая.
Разные классы: Docker изолирует приложение, Incus — окружение
Docker изолирует приложение. Один основной процесс, immutable-образы, обновление через замену контейнера, логи в stdout, конфигурация через переменные окружения. Контейнер эфемерен по дизайну: остановил — данные исчезли, если не смонтировал volume.
Incus и LXD изолируют окружение. Внутри — свой systemd, apt, пользователи, cron, сокеты. Контейнер «чувствуется как виртуалка»: установленные пакеты сохраняются после остановки, SSH работает привычно, администрирование почти не отличается от работы с обычным сервером. Это не «ещё один Docker», а другой способ думать об изоляции: не «доставка приложения», а «управление окружением».
У Incus есть и уникальное позиционирование, которое редко всплывает в сравнениях: он умеет и системные контейнеры, и application-контейнеры в стиле Docker, и виртуальные машины через KVM/QEMU. Одна платформа для всех трёх моделей. Ни Docker, ни чистый LXD такого не дают.
Incus против LXD: свобода как институциональное решение
Incus — форк LXD, который остался в Linux Containers project после того, как LXD перешёл под крыло Canonical. Ведётся теми же людьми, что создали LXD. Лицензия Apache 2, никакого CLA, коммерческая поддержка от Zabbly, LTS-релиз 6.0 с поддержкой до июня 2029 года, feature-релизы выходят ежемесячно.
Технически разница между LXD и Incus пока небольшая. Но институциональная — существенная. На форумах всё чаще звучит, что в новых проектах LXD выбирают реже именно из-за вопросов прозрачности развития и долгосрочного сопровождения. Для self-hosted-инфраструктуры предсказуемость важнее фич: вопрос не «что умеет», а «кто контролирует и кто отвечает».
Показательно, что на Arch Linux Incus — дефолтный инструмент для Linux-контейнеров. Установка сводится к pacman -S incus, systemctl start incus, incus admin init. Для дистрибутива, который сообщество считает эталонным, это сигнал о том, куда движется экосистема.
Четыре VPS на сервере с 4 ГБ RAM
Практический кейс с habr.com: преподаватель IT-курса организовал изолированные пространства для четырёх студентов на одном сервере Ubuntu с 4 ГБ RAM. Через LXD. Студенты получили полноценные окружения с SSH, apt и root-доступом — почти VPS, только дешевле.
Гладко не пошло. Официальный образ Ubuntu 22.04 по умолчанию разрешает SSH только по ключу — пароль не принимает. Чинится массовой командой через lxc exec. Затем завис apt: контейнеры получили IPv6-адреса из внутренней сети, а внешнего IPv6-маршрута на хосте не было. Решение — lxc network set lxdbr0 ipv6.address none. Дальше выяснилось, что установленный на хосте Docker переписал iptables и отбрасывает транзитный трафик в цепочке FORWARD — контейнеры вообще потеряли интернет. Лечится двумя правилами iptables -I FORWARD -i lxdbr0 -j ACCEPT и iptables -I FORWARD -o lxdbr0 -j ACCEPT, после чего контейнер перезапускается.
Сцена показательная: LXC/Incus дают то, что Docker не даёт в принципе — изолированные Linux-окружения с привычным администрированием на слабом железе. Но это не волшебная кнопка. Инструмент для тех, кто готов разбираться в сети и файрволе.
Где Incus проигрывает
KVM остаётся там, где нужна максимальная изоляция и совместимость. Windows, другие архитектуры, live migration — у LXC миграция только с перезапуском, у VM теряется максимум один пинг. В LXC не всё работает: podman в Alpine внутри LXC на Proxmox не запустился, freeIPA ломался из-за трансляции ID пользователей.
В чистом LXC/LXD лимиты CPU и RAM могут быть не настроены по умолчанию — контейнер способен съесть все ресурсы хоста, и это риск OOM. Формально «advanced resource control» заявлен как фича, но контроль надо включить. По умолчанию его нет.
Безопасность — отдельная тема. Для внешнего доступа к веб-серверу в контейнере часто требуется security.privileged=true, а привилегированный режим, по сути, рушит изоляцию. Удобство против безопасности, и выбор приходится делать вручную. Cloud-init тоже подводит: cloud-init.user-data не мерджится между профилями — работает только из последнего. Проблема не решена годами, обсуждение тянется на discuss.linuxcontainers.org.
Incus закрывает большинство Linux-only сценариев с меньшими накладными расходами, чем KVM. Но не заменяет KVM полностью. И не должен.
Цена Docker — контроль над хостом
Docker доминирует не из-за технического превосходства. Экосистема: тысячи готовых образов, отлаженные CI/CD-практики, низкий порог входа. По цифрам он проигрывает, но по удобству доставки приложений конкурентов у него нет.
Реальная цена — контроль над хостом. Docker работает под рутом, переписывает iptables и nftables, конфликтует с другими инструментами. Два независимых источника описывают один и тот же failure mode с разных сторон: на habr.com Docker режет FORWARD-цепочку и ломает сеть LXD-контейнерам, на Arch Linux Docker добавляет свои правила в nft, и из контейнера Incus пропадает интернет — лечится nft flush ruleset и рестартом incus.
Если вы используете Docker на сервере, где живёт что-то ещё, — вы уже отдали этому серверу часть контроля. Вопрос не в том, заметите ли вы это, а в том, когда.
Что выбирать
Incus и LXC — для self-hosted-инфраструктуры на одном или нескольких Linux-серверах, где нужны изолированные окружения с привычным администрированием: systemd, apt, SSH, персистентные данные. Docker — для доставки конкретных приложений с готовыми образами. KVM — для гетерогенных сред и максимальной изоляции.
Исторический контекст полезен: оверсейлинг времён OpenVZ, когда 10 ГБ RAM делили на 20 «VDSок» без гарантий и с постоянными OOM, объясняет, почему индустрия ушла к KVM. Но LXC/Incus 2026 года — это не OpenVZ. Это другой уровень зрелости, и единственный способ убедиться — попробовать на тестовом сервере. Благо, разворачивается всё за пару минут.
