Содержание
Коротко
AWS Lambda не крутит ваш код в классическом Docker-контейнере — там Firecracker microVM. Многопользовательский GKE — gVisor, Cloudflare Workers — WASM. На Dev.to автор прогнал один и тот же Go HTTP-сервер (образ 3 МБ) через пять изоляторов и сравнил холодный старт, память и сценарии, где каждый имеет смысл.
Что произошло
Базовый вариант — distroless + runc: минимальный образ без оболочки и пакетного менеджера. Это не меняет модель изоляции (общее ядро хоста), но усложняет жизнь злоумышленнику после взлома — нечем достраивать атаку.
gVisor (runsc) перехватывает системные вызовы в ядре Sentry в пользовательском пространстве; хост не видит системные вызовы контейнера напрямую. Включение — флаг --runtime=runsc. Режим Systrap (с 2023) заметно быстрее ранних версий. Типичные сценарии: CI-раннеры с чужим кодом, плагины SaaS, облачные IDE.
Kata Containers с QEMU поднимает лёгкую VM на контейнер — настоящая граница ядра. Холодный старт порядка ~500 ms, память ~52 МБ поверх приложения. Нужен там, где аудит требует изоляции на уровне VM (PCI-DSS, HIPAA, многопользовательские БД).
Kata + Firecracker — тот же образ, другой VMM: ~125 ms холодного старта, ~28 МБ накладных расходов. Так устроены Lambda, Fly.io Machines, пакетный вывод LLM и окружения предпросмотра для PR.
WASM/WASI — отдельная цель компиляции: модель полномочий без системных вызовов по умолчанию. HTTP в WASI preview1 ещё ограничен, но WASI 0.2 и wasi-http уже в продакшене на периферийных платформах. Docker Desktop 4.27+ умеет --platform=wasi/wasm.
На прогретом сервисе медианная задержка p50 у всех OCI-рантаймов остаётся <1 ms — платите холодным стартом и оперативной памятью, а не пропускной способностью.
| Рантайм | Холодный старт | Память (ориентир) |
|---|---|---|
| runc / distroless | ~20 ms | ~7 МБ |
| gVisor | ~50 ms | ~18 МБ |
| Kata / QEMU | ~500 ms | ~52 МБ |
| Kata / Firecracker | ~125 ms | ~28 МБ |
Почему это важно
«Какой рантайм безопаснее?» — неверный вопрос. Важна модель угроз: свои образы в доверенном кластере, произвольный код пользователей, регуляторика или периферия с чужими скриптами — у каждого свой ответ.
Размер образа почти не меняется (~3 МБ) — меняется только --runtime. Это снимает страх, что усиление изоляции сломает пайплайн сборки.
На практике
- Внутренние микросервисы в однопользовательском кластере → runc + distroless как базовая гигиена.
- CI/CD и SaaS с пользовательским кодом → gVisor без KVM и с изоляцией системных вызовов.
- Требования соответствия с формулировкой «граница VM» → Kata/QEMU или конфиденциальные контейнеры.
- Бессерверная платформа, окружения предпросмотра, пакетные задачи → Firecracker.
- Периферия, плагины, один бинарник везде → WASM/WASI и фреймворки вроде Spin.
Репозиторий copyleftdev/micro-containers содержит бенчмарки и install.sh для каждого рантайма.
Итог
Экосистема контейнеров шире Docker + runc. Выбор — не «максимум безопасности», а соответствие угрозам, холодному старту и операционным затратам. Для интерактивных платформ Firecracker часто оказывается практичным компромиссом между gVisor и полноценной VM на QEMU.