Если вы читали что-нибудь о безопасном запуске сгенерированного ИИ кода, вы видели слово microVM, обычно рядом с Firecracker. Его объясняют либо как «лёгкую VM» (правда, но бесполезно), либо схемой внутренностей ядра. Вот версия посередине.
Два старых варианта и почему ни один не подходит
Начнём с того, между чем стоит microVM.
Контейнер — это группа обычных процессов на вашей машине, которым ядро согласилось врать. Namespaces показывают им собственные файловую систему, список процессов и сеть; cgroups ограничивают, сколько CPU и памяти им можно брать. Он стартует за миллисекунды, потому что ничего нового не загружается. Но все контейнеры на хосте говорят с одним и тем же ядром. Баг ядра, достижимый из одного контейнера, — это выход из всех.
Виртуальная машина приносит собственное ядро. Процессор хоста через аппаратную виртуализацию (KVM в Linux) исполняет гостя так, будто у того свой компьютер. Граница — гипервизор, который открывает куда меньше, чем сотни системных вызовов ядра. Расплата — вес. Классическая VM эмулирует целый ПК: прошивку, шину PCI, контроллеры USB, видеокарту, иногда звуковую карту. Она грузится через всё это, стартует от секунд до минут, и каждый экземпляр несёт десятки или сотни мегабайт накладных расходов.
Аналогия, которая неплохо держится: контейнеры — квартиры в одном доме, с общим фундаментом, трубами и проводкой. VM — отдельные дома. Дома — более безопасные соседи, но ради визита на 20 секунд дом не строят.
Что выбрасывает Firecracker
Firecracker — это монитор виртуальных машин (программа, которая настраивает и запускает VM поверх KVM), написанный на Rust и открытый в 2018 году. Он сделан для одной задачи: запускать огромное число короткоживущих, не доверяющих друг другу нагрузок на общем железе. Достигается это в основном удалением:
- Нет прошивки и поиска оборудования. Ядро загружается прямо в память и запускается. Никто не ищет устройства, которых нет.
- Крошечная модель устройств. Сетевая карта, блочное устройство, последовательная консоль и ещё несколько, все virtio (устройства, задуманные для виртуальных машин, а не имитация физических). Ни USB, ни графики, ни PCI.
- Маленькая кодовая база с безопасной работой с памятью. Меньше кода, эмулирующего устройства, — меньше мест для бага, через который гость дотянется до хоста.
- Клетка вокруг самого VMM. Каждый процесс Firecracker работает в chroot, с фильтрами seccomp на его собственные системные вызовы и cgroups на ресурсы. Если что-то и вырвется из гостя, оно окажется в клетке, а не на хосте.
Опубликованные самим проектом цифры: user space за 125 мс и меньше 5 MiB накладных расходов памяти на microVM. Это лучшие лабораторные значения; настоящей песочнице ещё нужно подготовить диск и сеть и дождаться агента внутри, готового принимать команды, поэтому наша готова примерно за секунду. Это всё равно достаточно близко к скорости контейнера, чтобы создавать по одной на задачу и выбрасывать после.
Контейнер и microVM на практике
| Контейнер | Firecracker microVM | |
|---|---|---|
| Ядро | общее с хостом | своё |
| Граница с хостом | системные вызовы в общее ядро | гипервизор + маленький VMM |
| Время старта | миллисекунды | ~0.1–1 с |
| Накладные расходы на экземпляр | очень малые | несколько MiB |
| Устройства | что откроет хост | сеть, диск, консоль |
| GPU | возможен | нет |
| Подходит для | своего кода, упаковки приложений | недоверенного кода, мультиарендных нагрузок |
Важная строка — вторая. С контейнером вопрос «может ли этот код вырваться?» превращается в «есть ли где-то в ядре хоста достижимый баг?». С microVM — в «есть ли баг в гипервизоре или в горстке виртуальных устройств?». Вторая поверхность гораздо меньше, и именно её облачные платформы и так защищают для собственного мультиарендного хостинга.
Чем платите
MicroVM — не бесплатный апгрейд.
- Нет GPU и дисплеев. Это для запуска кода, а не для рабочих столов и графики.
- Меньше устройств — меньше гибкости. Всё, что ждёт реального железа или длинного списка модулей ядра, будет чувствовать себя неуютно.
- Границам всё равно нужна политика. MicroVM с открытым исходящим трафиком всё ещё может слать трафик, который вам не нужен; с вашими API-ключами внутри — всё ещё может их слить. Изоляция защищает хост от гостя, а не ваши секреты от кода, которому вы их отдали.
Как это используют наши песочницы
Каждая песочница EQVPS — это одна Firecracker microVM со своим ядром, от 0.25 vCPU и 512 MB до 8 vCPU и 16 GB. В ней Python 3.12, Node.js 22, bash, git и curl, исходящий интернет есть, входящих портов нет. Эфемерные песочницы удаляются, когда вы закончили; persistent сохраняют диск, а постановка на паузу записывает снапшот microVM на диск, так что она ничего не стоит до возобновления. Снапшоты на паузе хранятся 14 дней. Потом песочница удаляется, и её id отвечает 410 sandbox_deleted.
Мы выбрали microVM вместо контейнеров по одной причине: код в песочнице по определению никто не проверял. Вывод ИИ-агента, pull request незнакомца, бенчмарк из тысячи программ, написанных моделью. Для такого собственное ядро — граница, за которую стоит платить. Подробности того, что мы построили вокруг, — тарифы, квоты, лимит синхронной команды в 55 секунд — в документации песочниц.
Если хотите глубже сравнить эту границу с другими вариантами, в уровнях изоляции для недоверенного кода процессы, контейнеры, microVM и полноценные VM стоят рядом. А если внимание привлекла посекундная цена, как на самом деле работает посекундная оплата показывает арифметику.
Комментарии
Пока нет комментариев. Будьте первым.