На AWS re:Invent 2018, что проходит в эти дни в Лас-Вегасе, состоялся анонс Firecracker — новой технологии виртуализации с открытым кодом, основанной на Linux KVM. Авторы обещают, что с ней «в доли секунды можно запускать легковесные микровиртуальные машины (microVMs) в невиртуализированной среде, получив преимущества и традиционных ВМ — в виде безопасности и изоляции рабочих нагрузок, и контейнеров — в виде эффективного использования ресурсов».
Предыстория
За разработкой Firecracker стоят сотрудники Amazon Web Services, задавшиеся целью улучшить потребление ресурсов и вообще жизнь пользователям таких сервисов, как AWS Lambda (стартовал в 2014 году и позволяет сегодня заявлять о том, что модель serverless продолжит своё существование) и AWS Fargate (появился год назад).
Основу проекту положила Open Source-разработка от Google — crosvm из Chromium OS, что написана на Rust и отвечает за запуск операционных систем с виртуализацией устройств (но без эмуляции реального аппаратного обеспечения). Посему код Firecracker тоже написан на языке Rust, и его авторы обещают возвращать свои исправления в кодовую базу родительского проекта, хотя сами проекты со временем сильно разошлись в своём предназначении.
Первый публичный релиз Firecracker — 0.1.0 — состоялся в марте этого года, а последний актуальный — 0.11.0 — всего несколько дней назад. Эту статью я начал писать вскоре после интернет-анонса Firecracker, когда у проекта было 76 звёзд на GitHub, а на момент публикации этот показатель превысил уже 500.
Особенности Firecracker
Главным компонентом Firecracker является virtual machine monitor (VMM), что использует Linux KVM для создания и запуска так называемых microVMs. Авторы именуют свой продукт «облачной альтернативой QEMU» [используется в Kata Containers], «предназначенной только для безопасного и эффективного запуска контейнеров».
А вот как иллюстрируется пример хостовой системы, в которой запущены упомянутые microVMs:
Разработчики стремятся к минимализму, включая в продукт только самое необходимое и обеспечивая тем самым минимальные расходы на память, а заодно и уменьшая возможности для потенциальных уязвимостей. В Firecracker эмулируются всего 4 устройства: virtio-net, virtio-block, serial console и клавиатура с 1 кнопкой, используемой для остановки работы microVM. В качестве хостовой и гостевой операционных систем на данный момент поддерживаются ОС на базе ядра Linux версии 4.14 (релиз от ноября прошлого года) и выше, а в текущих планах разработчиков — поддерживать две последние стабильные ветки ядра Linux. В разрезе аппаратного обеспечения пока что поддерживаются только процессоры Intel, но AMD и ARM значатся в планах.
Сам Firecracker состоит из единого процесса VMM, который при запуске делает доступным API endpoint (RESTful) на хостовой машине. Собственно API описан в формате OpenAPI и, в частности, позволяет запускать microVM с указанными параметрами (образ ядра, корневая файловая система, аргументы для загрузки) и останавливать её, настраивать виртуальные машины (количество vCPU, оперативной памяти, шаблон для CPU), добавлять на них сетевые интерфейсы, диски (представлены как блочные устройства, доступны режимы read-write и read-only), настраивать систему для логов и метрик.
Главные достоинства Firecracker — безопасность (ориентация на multi-tenant computing, несколько уровней изоляции), высокая производительность (запуск microVM может осуществляться за 125 мс, и авторы обещают улучшить этот показатель в следующем году), минимальные накладные расходы (каждый microVM потребляет около 5 мегабайт памяти). Что прибавляет веса проекту — он уже был протестирован «в бою» и обеспечивает работу ряда сервисов AWS (включая упомянутые Lambda и Fargate).
Подробнее о безопасности
Среди главных возможностей Firecracker, ориентированных на обеспечение высокого уровня безопасности, упоминаются следующие:
- Простая гостевая модель (для всех гостей обеспечен лишь самый минимум — см. выше про 4 устройства).
- Изолирование процесса Firecracker с помощью cgroups и seccomp BPF, а также ограниченного набора разрешённых системных вызовов.
- Статическая линковка процесса Firecracker для его запуска в условиях изоляции от хостового окружения.
Демонстрация работы с Firecracker
В блоге AWS показали, как можно попробовать microVMs в действии. Для этого достаточно создать экземпляр i3.metal и загрузить на него 3 файла (исполняемый файл firecracker
, образ корневой ФС, ядро Linux):
После чего — установить нужные права на /dev/kvm:
$ sudo setfacl -m u:${USER}:rw /dev/kvm
Задать конфигурацию для первой гостевой машины:
$ curl --unix-socket /tmp/firecracker.sock -i
-X PUT "http://localhost/machine-config"
-H "accept: application/json"
-H "Content-Type: application/json"
-d "{
"vcpu_count": 1,
"mem_size_mib": 512
}"
… затем ядро для неё:
$ curl --unix-socket /tmp/firecracker.sock -i
-X PUT "http://localhost/boot-source"
-H "accept: application/json"
-H "Content-Type: application/json"
-d "{
"kernel_image_path": "./hello-vmlinux.bin",
"boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
}"
… и корневую ФС:
$ curl --unix-socket /tmp/firecracker.sock -i
-X PUT "http://localhost/drives/rootfs"
-H "accept: application/json"
-H "Content-Type: application/json"
-d "{
"drive_id": "rootfs",
"path_on_host": "./hello-rootfs.ext4",
"is_root_device": true,
"is_read_only": false
}"
Осталось собственно запустить гостя:
# curl --unix-socket /tmp/firecracker.sock -i
-X PUT "http://localhost/actions"
-H "accept: application/json"
-H "Content-Type: application/json"
-d "{
"action_type": "InstanceStart"
}"
Результат:
Что насчёт других проектов для контейнеров?
Хотя авторы Firecracker обещают его «интеграцию с популярными исполняемыми средами для контейнеров», вот что они отвечают на вопрос, можно ли использовать проект с Kubernetes, Docker или Kata containers:
«Пока нет. Мы разрабатываем Firecracker как Open Source-проект, потому что он предлагает значимо другой подход к безопасности в запуске контейнеров. Надеемся, что и другие сообщества, создающие Open Source-технологии для контейнеров, сочтут его полезным. Мы работаем над тем, чтобы обеспечить естественную интеграцию Firecracker в экосистему контейнеров — с целью реализовать в будущем бесшовную интеграцию, предоставив больше возможностей по изоляции рабочих нагрузок в контейнерах».
P.S.
Читайте также в нашем блоге:
- «Прошлое, настоящее и будущее Docker и других исполняемых сред контейнеров в Kubernetes»;
- «Red Hat заменяет Docker на Podman»;
- «CRI-O — альтернатива Docker для запуска контейнеров в Kubernetes»;
- «Kubernetes в Amazon (EKS) стал общедоступным»;
- «Awless — мощная альтернативная CLI-утилита для работы с сервисами AWS».
Автор: shurup