kern, контейнерный рантайм и песочница в бинарнике 1,52 МБ, без демона

На Hacker News в рубрике Show HN показали kern, контейнерный и ресурсный рантайм, который умещается в один статический бинарник размером 1,52 МБ (сборка из исходников через cargo install даёт 1,91 МБ) и не требует фонового демона, сокета или чего-либо ещё, что нужно предварительно запускать: в состоянии покоя kern не потребляет RAM вовсе. Контейнер из готового OCI-образа поднимается примерно за 3,5 мс. Проект описывает себя не как ещё одну строку в сравнительной таблице контейнерных систем, а как единый инструмент, который объединяет контейнерный рантайм, песочницу, менеджер ресурсов и средство запуска Compose-стеков; из внешних Rust-зависимостей у него только libc, JSON и OCI-манифесты разбираются вручную, а загрузка образов идёт через уже установленные в системе curl и tar, без собственного стека TLS.

Песочница kern всегда работает без прав root (rootless) и изолирует пространства имён User, PID, mount, network, UTS и IPC поверх overlay- или read-only-корня; сверху добавлены запрещающий по умолчанию список разрешённых системных вызовов (seccomp) и лимиты cgroup v2. Один флаг, --security-profile untrusted, включает весь этот ужесточённый профиль разом, то же самое, что вручную выставить seccomp-политику, --cap-drop ALL и --read-only, а флаг --require-limits не даёт боксу стартовать, если лимиты памяти и числа процессов не применились по-настоящему. Ресурсы, CPU, память, дисковая квота (vdisk:) и устройства (vgpio:), описываются один раз в ~/.config/kern/kern.toml и подключаются по имени; те же профили можно навесить и на обычный процесс на хосте вообще без песочницы командой kern run. Диск vdisk:, это tmpfs на оперативной памяти, когда kern работает без прав root, и ext4-образ на loop-устройстве с настоящей квотой, когда он работает с правами root; какой именно вариант достался профилю, kern сообщает сам, а не оставляет угадывать. Доступ vgpio: выдаётся не на отдельную линию, а сразу на весь чип: запрос линии pins = [17] не ограничивает бокс этой линией, у ядра нет границы монтирования на уровне отдельной линии, так что список линий, это кооперативные метаданные, а не настоящая граница; изолирует доступ только выдача конкретного устройства целиком, как в примере с i2c.

kern понимает и собственный формат стека (kern-compose.toml), и уже существующий docker-compose.yml, без какого-либо шага конвертации: команда kern compose <файл> up поднимает многобоксовый стек, а сервисы находят друг друга по имени. На тестовом стеке из postgres и adminer, с уже закэшированными образами, web-сервис начинал отвечать примерно за 0,3 с, а весь стек потреблял около 66 МБ памяти при нулевом демоне поверх, для сравнения источник отмечает, что Docker Desktop поднимает фоновую виртуальную машину ещё до первого контейнера. При этом kern прямо называет себя не заменой Docker Engine: он говорит на языке форматов Docker, но не на языке его API, нет overlay-сетей, плагинов, Swarm. Это и не рантайм для Kubernetes, CRI не реализован, для k8s документация отправляет к containerd или CRI-O. Поддержки GPU-слайсов в этой версии тоже нет: она в планах, и кода под неё в этом релизе нет вообще.

Отдельная часть проекта, kern-sandbox, тонкая обёртка без сторонних зависимостей поверх бинарника kern для запуска кода агентов и LLM прямо из своей программы (pip install kern-sandbox или npm install kern-sandbox; сам бинарник kern должен быть на PATH). Каждый вызов идёт в свежем изолированном боксе: сеть выключена, память и число процессов ограничены, вывод обрезан по размеру, а таймаут проверяет сама библиотека-обёртка. Сбои, таймаут, OOM-kill, заблокированный системный вызов, возвращаются как поле результата, а не бросаются как исключение; по умолчанию под каждый вызов создаётся новый бокс, класс Sandbox умеет держать одно рабочее пространство между вызовами, а функция warm_kernel() держит один и тот же интерпретатор ради вычислений короче миллисекунды, ценой более слабой изоляции, и в проекте это называют осознанным выбором. Отдельно kern поставляет kern-mcp, сервер по протоколу MCP без сторонних зависимостей, который даёт Claude Desktop, Cursor или любому другому MCP-клиенту локальный интерпретатор кода: инструменты run_code (python/bash/node), write_file, read_file, list_files; каждый вызов run_code, это свежий бокс без сети, а файлы между вызовами сохраняются в рабочем пространстве на диске.

Отдельный бенчмарк на настольном компьютере с Intel i7-14700KF (Linux 7.0.0, релизный бинарник, скрипт examples/benchmark.py) показал: три тысячи боксов одновременно поднимаются примерно за 2,2 с, и каждый работающий бокс стоит около 0,3 МБ памяти. Сборка из исходников имеет единственную зависимость-крейт (libc), поэтому она короткая: клонирование, сборка и установка заняли 36 с на том же настольном компьютере с Intel i7-14700KF (на маленьких ARM-платах, дольше). Работает kern на Linux, WSL2 (готового билда под Windows нет, но в релиз входит подготовленный rootfs для WSL2) и на ARM-платах, Raspberry Pi, Jetson, Arduino UNO Q; команда kern doctor заранее проверяет совместимость окружения. В релиз, помимо основного бинарника, входят сборка под aarch64 и обёртка-shim под Windows (.exe), у каждого файла, свой SHA256, а сам тег релиза подписан GPG и независимо проштампован по времени. В репозитории, 90 готовых к запуску примеров, каждый на одну конкретную задачу.

Ключевые факты

Единственный бинарник размером 1,52 МБ (при сборке из исходников, 1,91 МБ), без демона и фонового процесса: в состоянии покоя kern не потребляет RAM, а контейнер из OCI-образа поднимается примерно за 3,5 мс.
Песочница всегда работает без прав root: изолирует пространства имён User, PID, mount, network, UTS и IPC, добавляет запрещающий по умолчанию список системных вызовов (seccomp) и лимиты cgroup v2; один флаг --security-profile untrusted включает весь этот профиль сразу.
Ресурсные профили CPU, памяти, дисковой квоты (vdisk:) и устройств (vgpio:) задаются один раз в kern.toml и применяются по имени, как к изолированному боксу, так и к обычному процессу на хосте вообще без песочницы (kern run).
Понимает docker-compose.yml без конвертации, но прямо не заменяет Docker Engine (нет overlay-сетей, плагинов, Swarm) и не является рантаймом для Kubernetes (CRI не реализован).
Для агентного кода: пакеты kern-sandbox для Python и Node (одноразовый изолированный бокс на каждый вызов, сеть выключена, сбои возвращаются как данные результата, а не как исключения) и MCP-сервер kern-mcp, который даёт Claude Desktop, Cursor и другим MCP-клиентам локальный интерпретатор кода.

Почему это важно

kern, это не ещё одна строка в списке контейнерных рантаймов, а попытка убрать сам класс инфраструктуры «фоновый демон плюс отдельный клиент», на котором держится Docker и его аналоги: проект прямо сравнивает своё состояние покоя (0 RAM, вообще ничего не запущено) с Docker Desktop, где ещё до первого контейнера поднимается фоновая виртуальная машина. Один статический бинарник на 1,52 МБ с единственной внешней Rust-зависимостью (libc), из которого контейнер по OCI-образу поднимается примерно за 3,5 мс, заявка на то, что полноценную изоляцию можно не жалеть поднимать на каждый отдельный вызов. Отдельно значим акцент на ИИ-агентов: готовые SDK для Python и Node и MCP-сервер kern-mcp превращают kern в готовый примитив «выполнить код, который сгенерировала модель, и не отвечать за его побочные эффекты», то, что агентным системам сейчас чаще приходится собирать вручную из Docker, gVisor или облачных песочниц.

Кому это важно

В первую очередь, разработчикам, которые строят ИИ-агентов и должны выполнять сгенерированный моделью код, не доверяя ему полностью: под это заточены и kern-sandbox для Python/Node, и MCP-сервер kern-mcp для Claude Desktop, Cursor и других MCP-клиентов. Дальше, инженерам CI и локальной разработки, которым не нужен постоянно висящий демон ради разового бокса или тестового docker-compose-стека. Отдельная аудитория, те, кто работает с ARM-платами (Raspberry Pi, Jetson, Arduino UNO Q) и хочет управлять ресурсами устройства, включая GPIO, через один и тот же инструмент. kern прямо не подходит тем, кому нужен полноценный Kubernetes-рантайм (CRI не реализован) или изоляция GPU-нагрузок (в этой версии кода под GPU нет вообще).

Как это применить

Ставится готовым релизным бинарником: скрипт curl ... install.sh | sh сам определяет архитектуру (x86_64/aarch64), кладёт бинарник в ~/.local/bin (или /usr/local/bin от root) и отказывается устанавливать файл, если не сошлась контрольная сумма SHA256; тот же результат, двумя командами вручную с проверкой .sha256. Сборка из исходников (cargo install --git ... --locked) заняла 36 с на настольном компьютере с Intel i7-14700KF, благодаря единственной зависимости (libc) это одна из самых лёгких пересборок такого рода. Команда kern doctor заранее говорит, чего не хватает окружению, например, uidmap и /etc/subuid для образов, переходящих на непривилегированного пользователя, или pasta для исходящих pull-запросов. Базовые команды: kern box dev --image alpine -it -- sh, разовый бокс; kern run --memory 256M --cpus 0.5 -- ./crunch, лимиты без всякой песочницы; kern box svc ... --restart --health-cmd ..., сервис с автоматической проверкой работоспособности и перезапуском; kern compose stack.toml up/down, многобоксовый стек в своём формате или в формате Docker. Ресурсные профили описываются в ~/.config/kern/kern.toml (секции vcpu, vdisk, vgpio) и проверяются командой kern validate до первого запуска. Для ненадёжного кода, один флаг: --security-profile untrusted включает seccomp-политику, --cap-drop ALL и --read-only разом, а --require-limits не даёт боксу стартовать, если лимиты по памяти и числу процессов не применились по-настоящему. Для интеграции в агентный код, pip install kern-sandbox или npm install kern-sandbox (нужен бинарник kern на PATH) и вызов вроде run_code("import platform; print(platform.python_version())"); для MCP-клиентов, точка входа {"mcpServers": {"kern": {"command": "kern-mcp"}}}. Данных о цене или лицензии проекта источник не приводит.

Можно ли доверять

Проект формулирует границу доверия сам, без прикрас. Периметр безопасности, это само ядро Linux, а не отдельный гипервизор: уязвимость повышения привилегий в ядре, это побег из песочницы, и это условие kern делит с Docker и Podman (документация прямо называет это причиной, по которой вообще существуют gVisor и Firecracker). Изоляция без прав root построена на непривилегированных пространствах имён пользователя (user namespace), и SECURITY.md проекта, раньше любых других заявлений, прямо называет их «плодородным источником уязвимостей повышения привилегий в ядре». Заявленный сценарий использования, код, который пользователь сам решил запустить и сам отвечает за последствия (вызовы инструментов агента, задачи CI, шаги сборки, ячейки кода), а не враждебный код от посторонних и не общий кластер с чужими арендаторами. Монтирование вроде -v $HOME:/host, решение о доверии самого пользователя, а не граница, которую обеспечивает kern; --net host и --privileged, это опции отказа от изоляции, названные прямо по имени, а единственный путь, монтировать который kern отказывается в принципе, собственный реестр рантайма. Чего при этом нет в самом источнике: имени автора или компании за проектом, номера версии, лицензии и любых цифр об использовании, звёзд на GitHub, числа установок, отзывов; конкретное число CVE или историю аудита для этого подхода к изоляции источник тоже не называет, только общее признание категории риска. По этим пунктам судить не на чем.

Риски и подводные камни

Главный риск, оборотная сторона той же честной оговорки: раз граница, это ядро, а не гипервизор, любая уязвимость повышения привилегий в самом ядре превращается в полный побег из песочницы, а rootless-механизм на непривилегированных пространствах имён пользователя, источник именно таких уязвимостей по признанию самого проекта. Использовать kern для враждебного кода от посторонних или на ядре, которое обслуживает ещё и чужих арендаторов, прямо не тот сценарий, для которого он задуман. Отдельная ловушка, у профиля vgpio: доступ выдаётся не на отдельную линию, а сразу на весь чип, и pins = [17] в конфиге не ограничивает бокс этой линией, у ядра нет границы монтирования на уровне отдельной линии, список линий работает как кооперативные метаданные, а не как настоящий барьер. Похожая тонкость, у профиля vdisk: без прав root это tmpfs на оперативной памяти, а с правами root, ext4-образ на loop-устройстве с настоящей квотой; лимит формально один и тот же, но физически это разные вещи, и в режиме без прав root дисковая квота фактически съедает оперативную память. kern прямо не заменяет ни Docker Engine (нет overlay-сетей, плагинов, Swarm, только форматы, не API), ни рантайм для Kubernetes (CRI не реализован, для k8s, containerd или CRI-O), а поддержки GPU-слайсов в этой версии нет вообще, это пункт дорожной карты, и кода под него в релизе не появилось. Нативной сборки под Windows тоже нет, только WSL2. Конкурентов, Docker, Podman, gVisor, Firecracker, bubblewrap, youki, E2B, источник только называет для сравнения, без единой цифры бенчмарка против них. И последнее: сам исходный текст обрывается на середине предложения в разделе про задержку («Two honest notes»), число, с которым там сравнивают kern, из этого источника недоступно.

«Граница, это ядро Linux, поэтому уязвимость повышения привилегий в ядре, это побег.»

— документация проекта kern (README, раздел о безопасности)