Firecracker: микровиртуалки за миллисекунды

MAATRIX

Если вам нужно за секунду поднять и через несколько секунд убить тысячу изолированных окружений — обычная VM в Proxmox или голом KVM для этого попросту не годится: она грузит BIOS, эмулирует десяток устройств, ждёт инициализации гостевой ОС, и весь этот путь занимает секунды, иногда десятки секунд. Firecracker — виртуализатор, который решает именно эту узкую задачу: он умеет поднимать так называемые microVM с изоляцией на уровне полноценной виртуальной машины, но со стартом на два-три порядка быстрее классической VM, ценой отказа почти от всей гибкости обычного гипервизора.

Что такое Firecracker и откуда он взялся

Firecracker — открытый виртуальный machine monitor (VMM), написанный на Rust и опубликованный AWS в 2018 году. Его создали не как замену QEMU или Proxmox, а как внутренний инструмент для конкретной инфраструктурной задачи: AWS Lambda и позже AWS Fargate должны были запускать миллионы коротких изолированных сред для serverless-функций и контейнерных задач клиентов, и ни полноценные VM, ни голые контейнеры для этого не подходили одновременно по скорости и по безопасности.

До Firecracker чужой код клиентов на serverless-платформе изолировали либо тяжёлыми VM на базе QEMU (медленно, дорого по ресурсам на каждый вызов функции), либо контейнерами (быстро, но с общим ядром хоста — а значит, с риском, что уязвимость в ядре или в namespaces даст одному клиенту доступ к процессам другого). Firecracker закрывает именно этот зазор: даёт границу как у VM, но по цене и скорости, близким к контейнеру.

Технически Firecracker — не полноценный эмулятор вроде QEMU, а специализированный VMM, использующий тот же механизм аппаратной виртуализации ядра Linux — KVM. Он не воссоздаёт заново работу с CPU и памятью — за это по-прежнему отвечает KVM в ядре хоста, — а берёт на себя минимально необходимую обвязку вокруг гостевой VM: подготовку виртуального железа, загрузку ядра гостя, обработку виртуальных устройств. Разница с обычным QEMU/KVM не в границе изоляции (она та же, аппаратная), а в том, что именно виртуализируется вокруг этой границы.

Принцип: намеренно урезанный набор устройств

Ключевая идея Firecracker — если убрать из VM всё, что реально не нужно для запуска одной серверной нагрузки без графики, без USB, без звука, без десятка сетевых карт на выбор, — старт ускоряется на порядки, а память гостя перестаёт тратиться на эмуляцию ненужного железа.

Обычная VM в KVM/QEMU по умолчанию тянет за собой немалый набор эмулированных или virtio-устройств: BIOS/UEFI-прошивку, набор чипсета PIIX4 или Q35, видеокарту (пусть даже виртуальную VGA), USB-контроллер, последовательный порт, PS/2-клавиатуру и мышь, RTC-часы — даже если гостевая ОС ничего из этого не использует по факту, она проходит через инициализацию всего этого при загрузке. Про то, почему выбор между эмуляцией и виртио-устройствами вообще так сильно влияет на производительность, подробно разбирали в статье про virtio против эмуляции — Firecracker доводит ту же логику до предела.

Firecracker убирает из этого списка почти всё:

• Нет BIOS/UEFI — ядро гостя грузится напрямую по протоколу Linux boot (или PVH), минуя этап загрузчика и прошивки.
• Нет эмулированного чипсета и графики — доступа к консоли через VGA нет вообще, взаимодействие с VM идёт через serial-консоль или через vsock.
• Только virtio-устройства, и то в минимальном подмножестве: virtio-net (сеть), virtio-block (диск), virtio-vsock (связь с хостом), virtio-rng (энтропия при необходимости). Никакой эмуляции устаревших контроллеров вроде IDE или E1000 — их в Firecracker просто нет как класса.
• Нет USB, нет звука, нет пробрасываемых PCI-устройств, нет GPU — если задаче нужно что-то из этого списка, Firecracker для неё не инструмент.

Сама реализация VMM — это один статически слинкованный бинарник на Rust размером в единицы мегабайт, без зависимости от QEMU вообще. Каждый процесс Firecracker поднимает и обслуживает одну microVM, слушает управляющий API (обычно unix-сокет с REST-подобным протоколом) и живёт ровно столько, сколько живёт эта VM.

Почему это даёт такую скорость и такую экономию памяти

Экономия складывается из нескольких источников, и каждый из них по отдельности звучит как мелочь — но вместе они убирают почти весь путь от «команды на старт» до «гостевая ОС готова отвечать».

Во-первых, пропадает время на инициализацию прошивки и обнаружение железа. Обычная VM тратит заметную часть времени старта на BIOS/UEFI, который перебирает шины, ищет устройства, настраивает их перед тем, как вообще передать управление загрузчику ОС. Firecracker передаёт управление ядру гостя напрямую, с заранее известной, статически заданной конфигурацией устройств — угадывать и опрашивать нечего.

Во-вторых, ядру гостя (обычно специально собранному минимальному Linux-ядру) не нужно инициализировать драйверы для устройств, которых физически нет — не тратится время на поиск несуществующего USB-контроллера или видеокарты. В-третьих, экономится память на сам процесс VMM: минималистичный Rust-бинарник Firecracker потребляет заметно меньше оперативной памяти на управляющий процесс, чем полноценный QEMU с его подсистемами эмуляции устройств, которые в этом сценарии всё равно не используются.

Важная оговорка: точных цифр «столько-то миллисекунд» намеренно не привожу как гарантию. AWS в публичных материалах о Firecracker заявляла о старте microVM в диапазоне низких десятков миллисекунд и о накладных расходах памяти в единицы мегабайт на VM — но это ориентир из чужих измерений на конкретном железе, а не обещание для любого стенда. Если цифры важны для проекта, их стоит измерить самостоятельно: время — через time вокруг вызова Firecracker API на старт VM, память — через поле VmRSS в /proc/<pid>/status процесса.

Сочетание этих факторов и позволяет держать на одном физическом хосте на порядок больше параллельных изолированных окружений, чем при использовании обычных VM с полным набором устройств — при том же объёме памяти и CPU.

Принципиальное отличие от контейнеров: изоляция уровня полной VM

Здесь стоит остановиться отдельно, потому что именно тут чаще всего путают Firecracker с чем-то вроде «облегчённого Docker». Это не облегчённый Docker — это по-прежнему полноценная виртуальная машина с точки зрения границы безопасности, просто очень маленькая и очень быстро стартующая.

Разница принципиальна и касается того, что именно разделяет рабочие нагрузки друг от друга:

Ключевая мысль здесь — то, что мы разбирали в статье про миф «контейнер — это песочница»: контейнеры делят одно ядро хоста через namespaces и cgroups, и это реальная, но не абсолютная граница — баг эскалации привилегий в самом ядре Linux потенциально доступен из любого контейнера на этом хосте, потому что все они обращаются к одному и тому же ядру через одни и те же системные вызовы.

У Firecracker microVM — своё собственное ядро, запущенное поверх аппаратной виртуализации KVM, ровно как у обычной Proxmox-виртуалки. Чтобы один арендатор добрался из своей microVM до хоста или до чужой microVM, нужна уязвимость не в общем ядре, а в самом гипервизоре — том же классе редких и дорогих уязвимостей, что и для «взрослой» VM. Именно поэтому Firecracker и называют попыткой дать «лучшее из двух миров»: сильную аппаратную границу VM при скорости и плотности размещения, близких к контейнерам.

Важно не переоценивать и это: сильная граница означает более высокую *планку* для атаки, а не её принципиальную невозможность — уязвимости в гипервизорах тоже случаются, просто заметно реже и тяжелее эксплуатируются, чем баги в namespaces или в подсистемах ядра, видные из контейнера напрямую.

Для чего Firecracker подходит и для чего — категорически нет

Вот здесь честность важнее маркетинга: Firecracker — это не «более быстрый Proxmox» и не универсальная замена обычной виртуализации. Это инструмент под один конкретный сценарий, и вне этого сценария он попросту хуже обычной VM почти по всем параметрам, кроме той самой скорости старта.

Сценарий, для которого Firecracker создавался и в котором он оправдан:

• Массовый параллельный запуск множества короткоживущих изолированных сред. Классический пример — serverless-платформа: пришёл вызов функции, за миллисекунды поднялась microVM, функция отработала, microVM уничтожена. Тысячи таких циклов в секунду на одном парке серверов.
• Изолированное выполнение недоверенного кода клиентов. CI/CD-платформы, которые запускают произвольный код пользователей (тесты, сборки, скрипты в pull request'ах), сталкиваются с той же проблемой, что и AWS Lambda: нужно изолировать чужой код так, чтобы взлом одной сборки не дал доступа к другим сборкам или к хосту. Несколько публичных CI/CD-сервисов на рынке используют Firecracker или похожие microVM-подходы именно для этой задачи — запуска джобов недоверенных пользователей с границей на уровне VM, а не на уровне namespaces контейнера.
• Мультитенантные serverless- и FaaS-платформы в целом, где на одном физическом парке серверов уживаются рабочие нагрузки многих независимых клиентов и утечка между ними недопустима по контракту.

Для чего Firecracker не подходит и где обычная виртуализация или контейнеры остаются практичнее:

• Один долгоживущий сервер или приложение. Для VM под сайт, базу данных, почтовый сервер Firecracker не даёт преимущества: скорость холодного старта не важна для процесса, который и так работает месяцами, а урезанный набор устройств только создаёт лишние ограничения без выгоды.
• Нужен полный набор виртуального железа. Проброс GPU, специфичный USB-контроллер, сложная виртуальная сеть с несколькими интерфейсами и VLAN — это территория Proxmox/QEMU-KVM, где гибкость важнее миллисекунд на старте. Про выбор для типичного сервера разбирали в статье про Proxmox или голый KVM — Firecracker в этом сравнении не участвует, это инструмент другого класса задач.
• Нужна графическая консоль, снапшоты через веб-интерфейс, живая миграция, GUI-администрирование. Ничего из этого у Firecracker нет из коробки — это низкоуровневый VMM, управляемый через API, а не панель с кнопками.
• Простое разделение своих же сервисов на одном сервере без задачи «недоверенный код». Docker с грамотно настроенными namespaces и cgroups (см. статью про изоляцию сервисов через Docker) обойдётся быстрее в разработке и достаточен по границе риска в большинстве случаев.

Прямым текстом: если ваша задача — «поднять сервер и на нём что-то работает годами» — Firecracker не даст выигрыша, но добавит операционной сложности на пустом месте. Это инструмент для инфраструктуры serverless-платформ и специализированных изолированных раннеров, а не для обычного хостинга приложений.

Как это выглядит на практике: базовый запуск

Firecracker управляется через unix-сокет с JSON-based REST API — это не «виртуалка в один клик», а инструмент, вокруг которого строится оркестрация (в AWS — отдельный контрольный слой, в опенсорсных проектах — обвязка вроде Weave Ignite или собственные скрипты). Минимальный пример запуска:

# Поднимаем процесс VMM — он слушает сокет и ждёт конфигурацию через API
firecracker --api-sock /tmp/firecracker.socket &

# Ядро гостя и параметры загрузки
curl --unix-socket /tmp/firecracker.socket -X PUT 'http://localhost/boot-source' \
  -H 'Content-Type: application/json' \
  -d '{
        "kernel_image_path": "/opt/firecracker/vmlinux",
        "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
      }'

# Корневая ФС как virtio-block устройство
curl --unix-socket /tmp/firecracker.socket -X PUT 'http://localhost/drives/rootfs' \
  -H 'Content-Type: application/json' \
  -d '{
        "drive_id": "rootfs",
        "path_on_host": "/opt/firecracker/rootfs.ext4",
        "is_root_device": true,
        "is_read_only": false
      }'

# Минимум vCPU и памяти
curl --unix-socket /tmp/firecracker.socket -X PUT 'http://localhost/machine-config' \
  -H 'Content-Type: application/json' \
  -d '{"vcpu_count": 1, "mem_size_mib": 128}'

# Старт инстанса
curl --unix-socket /tmp/firecracker.socket -X PUT 'http://localhost/actions' \
  -H 'Content-Type: application/json' \
  -d '{"action_type": "InstanceStart"}'

Параметр pci=off и минимальный набор устройств здесь — буквальная иллюстрация принципа «ничего лишнего»: ядро даже не ищет шину PCI, потому что Firecracker её не эмулирует, а устройства подключаются через MMIO-транспорт. Для сети добавляется отдельный вызов PUT /network-interfaces с tap-устройством на хосте — тоже virtio-net и ничего сверх него.

Требования к образу гостя тоже специфичны: нужно собственное минимальное ядро Linux и минимальный rootfs — обычные ISO-образы дистрибутивов не подходят без адаптации, потому что рассчитаны на BIOS/UEFI-загрузку и полный набор драйверов, которого у Firecracker просто нет.

Частые вопросы