Pull to refresh

Comments 44

Авторы обещают, что с ней «в доли секунды можно запускать легковесные микровиртуальные машины (microVMs) в невиртуализированной среде, получив преимущества и традиционных ВМ — в виде безопасности и изоляции рабочих нагрузок, и контейнеров — в виде эффективного использования ресурсов».


Я могу ошибаться, но мне это напомнило OpenVZ.
Для некоторых задач вполне применимая технология
А OpenVZ это разве не сильно перепиленое ядро линукса которое также сильно отстает? а тут вроде за пределами ядра.
Совсем ни разу не OpenVZ. Даже наоборот — антагонист.
Это, скорее, [серверный|облачный] Qubes OS.
Нет, это разные вещи. OpenVZ — контейнеры, Firecracker — полноценная виртуализация через CPU с отдельным ядром на каждого гостя.

Ну и OpenVZ мертв уже, да.
Firecracker это гипервизор. Скорее его можно воспринимать как минималистичный QEMU в комплекте с минималистичным же ядром, которое может грузиться очень быстро. А userspace там, в примере, как раз Alpine.

Я не совсем понимаю как firecracker может быть гипервизором, что он работает поверх kvm. Гипервизор на гипервизоре можно запустить, но производительность будет ужасная. Здесь же речь идёт об "оркестраторе" по типу докера, но с другим типом полезной нагрузки (т.е. здесь схожесть с openvz).
Вопрос ещё и в том имеет ли эта технология смысл для end-user'а. Т.е. если это всего лишь прослойка, которая позволяет эффективно запускать lambda/serverless, то с большой степенью уверенности могу сказать, что мне пофигу, что у них под капотом: docker, rocket, kata или "тонкие" ВМ… Работает и нормально.

Если Вы не чувствуете разницу между виртуализацией и контейнеризацией и для вас это всё на уровне «работает и нормально» — печально.
КМК пользователю это в первую очередь выгодно, выгоднее чем самим AWS — Ваше ПО наиболее изолированно, чем оно было бы изолированно, например, в Docker-контейнере, при этом Вы не платите за ВМ сполна, т.к. Вы кушаете меньше ресурсов хост-машины.
Вы вообще соображете, что говорите?
Если Вы не чувствуете разницу между виртуализацией и контейнеризацией и для вас это всё на уровне «работает и нормально» — печально.

с точки зрения Ops — несомненно чувствую. С точки зрения архитектора (и слабых мест того или иного решения) — тоже. С точки зрения Dev (побыстрее выкатить фичи и чтоб стабильно работало) — знаете, но внезапно (!) действительно разницы нет.
К тому же речь шла именно про отдельный, изолированный случай — lambda. В остальном я сам способен решить, что мне в текущий момент времени интереснее — полноценные ВМ или контейнеры.
Ваше ПО наиболее изолированно, чем оно было бы изолированно, например, в Docker-контейнере,

а технологически можете аргументировать? Уже были прецеденты, когда docker-изоляция «протекала». В первую очередь — по производительности. Например, habr.com/company/southbridge/blog/429788
В целом, ВМ тоже могут давать схожие эффекты в случае неравномерной нагрузки и тем более — оверселлинга по ресурсам (не знаю грешит ли этим AWS, но вот местечковые провайдеры таким страдают).
> С точки зрения Dev (побыстрее выкатить фичи и чтоб стабильно работало) — знаете, но внезапно (!) действительно разницы нет.

Ну если вы считаете, что после выливки кода ваш конвейер закончился — то да, вы правы. А так ваши ошибки в коде в случае KVM более изолированы от хостовой системы.

Насчёт конвейера — он закончится только в момент вывода программной компоненты из эксплуатации.
А так ваши ошибки в коде в случае KVM более изолированы от хостовой системы.
При условии выполнения каждой лямбды в отдельной "микроВМ" — скорее соглашусь. Но если там поверх ещё докер навернут (а почему нет?). Или если брать изоляцию между каждым инстансом firecracker

Даже если там поверх докер (не совсем понятно зачем), то все равно же выход на хост систему (та в которой работает гипервизор) менее вероятен.
чтобы лямбды гонять. Или они поверх FireCracker сразу будут выполняться (ну, через ОС, ес-но)?
то все равно же выход на хост систему (та в которой работает гипервизор) менее вероятен.

я с этим и не спорил )
Вы сами запутались — я прямым текстом сказал, что Docker и контейнеризация — кривая технология, на что вы потребовали обоснования того, что Docker и контейнеризация — кривая технология приведя в пример ссылку того, когда она кривая тем самым доказывая мне то, что я и сам утверждаю. :)
А что мне технологически аргументировать? На соседей разделяется nf_conntrack, разделяется энтропия, разделяется etc…

С точки зрения Dev (побыстрее выкатить фичи и чтоб стабильно работало) — знаете, но внезапно (!) действительно разницы нет.

На моей машине всё работает. (с) Но ладно, да, с точки зрения Dev разницы никакой. Если только не… команда состоит не из 1,5 землекопа, а там начинается игра в футбол, которая зря потратит время всем: «это виноват Dev!» — «не, это Ops'ы косячат!»
То есть говоря отдельно об Dev окружении — разницы никакой. Но говоря в целом о команде — всё равно есть просадка по времени.
Я и говорю, что kvm/qemu или любой другой гипервизоре даёт степень изоляции выше, чем докер, но не абсолютную изоляцию (например, проблема с общими iops, оверселлингом cpu и пр. — очень хочется понять, что под капотом Амазона).
При решении каждой конкретной задачи можно решить какой уровень изоляции нужен. Главное понимать trade-off и в какой момент абстракция «потечёт».
Касательно dev/prod-контуров — их полностью идентичными не сделать по разным причинам (экономические, технологические и пр.). Да и не всегда нужно, чтобы dev был точной копией.

Касательно firecracker — это очень интересный вопрос как его предлагает использовать Амазон. Условно, если они представляют его как легковесную замену ВМ, чтобы запускать лямбды (т.е. все инкапсулировано и скрыто от пользователя платформы), то это очень интересное решение. Но ещё и интересно технологически — будет ли firecracker хостинг только лишь одну лямбду, например, или их коллекцию? Или может даже лямбды разных пользователей. Короче — посмотрим.
В целом да. Но дилетантское IMHO — для CPU-bound виртуалки в принципе не подходят — многого не добиться, так что оверселлинг CPU вряд ли в точку.
KVM предоставляет только базовую инфраструктуру для виртуализации — по сути только процессор и менеджер памяти. Остальное — сеть, видео, USB и прочую периферию предоставляет QEMU, либо иной софт — как описанный тут Firecracker.

Здесь же речь идёт об «оркестраторе» по типу докера, но с другим типом полезной нагрузки (т.е. здесь схожесть с openvz).

Нет тут никакого оркестратора. Тут один процесс Firecracker — одна ВМ. Плюс API. Оркестратор нужно сверху прикручивать через API. Причем тут OpenVZ вообще не понятно.
Хм. Т.е. получается, что Firecracker — это аналог qemu, но с меньшими возможностями, а поэтому более «легкий»?
Ну, и меня немного сбило с толку (т.к. читал быстро и по диагонали)
Изолирование процесса Firecracker с помощью cgroups и seccomp BPF

ОК. Т.е. ничего нового на самом деле не сказано ) те же qemu/kvm можно было засунуть в cgroups.
Да, это легковесный гипервизор с легковесным ядром (собранным с минимумом функций). Что позволяет ему быстро стартовать.
но, вероятно, ядро можно будет при необходимости собирать побольше, в т.ч. подключать модули, что невозможно в случае lxc.
Да, с меньшими — он не эмулирует реальное железо или процессор, и гораздо шустрее. Скорее он ближе к Xen или к UML, чем к QEMU.

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

cgroups/seccomp нужны исключительно для того чтобы никто не выбрался дальше, ведь фактически Firecracker нужно только read/write и ещё несколько простых и сравнительно безопасных системных вызовов, в то время как QEMU нужно гораздо больше для нормальной работы, и его гораздо сложнее изолировать.

Таким образом, роль самого Firecracker заключается только в инициализации и реализации обмена данными с хостом (на уровне файлов/сокетов для virtio устройств), больше ни к чему гость не имеет доступа и соответственно навредить вряд ли сможет (разве что поедая ресурсы — но от этого как раз спасут cgroups).

В общем, я бы назвал это UML на стероидах.
Интересно, почему решили реализовать virtio-block, в дополнение к virtio-net? Не получается эффективно (с незначительным оверхедом) реализовать блочный доступ поверх virtio-net?
Блочный доступ через virtio-net — это как?
Я думаю, имелся в виду NBD и аналоги.

Но смысла в этом оверхеде всё равно нет (он не такой уж и незначительный), если можно отдать block device.
Как-то это неочевидно… Если есть virtio-net для связи с окружающим миром и в ядро впихнули модуль nbd — никто не мешает его юзать, дополнительных телодвижений не нужно. Вопрос — зачем?
С NBD нужны телодвижения со стороны хоста — как минимум, серверная часть, которая будет отдавать файлы или устройства. Плюс оверхед никуда таки не денется — всё пойдёт через сетевой стек (+ память на буфера, дополнительно к кэшу), пожирая ресурсы дважды, как у гостя, так и у хоста, при этом разбивая доступ на сравнительно мелкие пакеты (никто не даст гостю Jumbo Frames, хотя и они не сильно помогут).

В то же время «прямой» доступ через virtblk — это просто проброс на уровне read()/write(), вероятно даже с прямым доступом к памяти гостя со стороны хоста. Оверхед конечно останется, но ощутимо меньший.

Теперь умножим это на много VM на одном физическом хосте — и получим ужасную картину с оверхедом в случае NBD + гость может воспользоваться уязвимостью со стороны NBD сервера на хосте (если таковая обнаружится).
Что бы сделать гипервизор ещё меньше, если в этом была цель.
Разработчики стремятся к минимализму, включая в продукт только самое необходимое и обеспечивая тем самым минимальные расходы на память, а заодно и уменьшая возможности для потенциальных уязвимостей.
Я думаю что virtio-block сильно проще nbd в плане кода. Лезть сравнивать лень, но почти уверен. Так что плоскость атаки будет еще меньше.
Ну вот хайп Докера и подходит к концу. Страшно представить что для поддержки контейнерного-бума даже целую специальность создали из недо-сисадминов DevOps.

Итог всего этого простой — дико переусложненная экосистема и оверинжиниринг всего и вся.
Страшно представить что для поддержки контейнерного-бума даже целую специальность создали из недо-сисадминов DevOps.
у вас абсолютно неправильное представление о devops. И да, не все devops связаны с docker. Хотя последний очень сильно упрощает некоторые моменты в процессе жизненного цикла ПО.
Очень рад видеть рост числа энтерпрайз проектов написанных на Rust. Да еще и таких интерестных!

Ох, сколько уже их было, этих супер-быстрых, в следствии своей супер-минималистичности же, гипервизоров, которые в бенчмарках, то есть в тестах, писанных самими же разработчиками, в надцать раз быстрее qemu-kvm и в эти же надцать раз безопаснее и проще.
К примеру тот же freeBSD-шный bhyve…
Хотя это совсем другая песня, тем более что не на растения писанная.
Так вот: сколько уже их было видимо-невидимо (на опеннете что не месяц — новость о новом гипервизоров), да только ни один не выстрелил, потому что всем, по какой-то невиданной причине, почему-то оказывается очень нужна эмуляция всевозможного оборудования, всякие миграции и т.д. и т.п., а тут нам что же предлагают..? — аппаратную клавиатуру с одной кнопкой!
Зачем вообще нужна эта кнопка в таком кейсе? Уже бы тушили питание посредством bios-uefi, если они там, конечно, есть.


PS: простите мне мой сарказм, просто я больше 10 лет наблюдаю как qemu все закапывают...

Да почему же сарказм — ведь вполне адекватный (пусть и критичный) взгляд на происходящее :-) Однако у Firecracker сразу есть сильное преимущество в лице собственно AWS и его применения на этой огромной площадке. Т.е.: даже если он не уйдёт куда-то дальше AWS, это уже большая часть рынка. Но уйти дальше он точно [по меньшей мере] попытается: 3000 GitHub-звёзд за сутки — это не шутки: в сообществе им явно заинтересовались. А дальше… чего тут гадать — время покажет, мы всё сами увидим.
потому что всем, по какой-то невиданной причине, почему-то оказывается очень нужна эмуляция всевозможного оборудования

Основная причина по которой используют qemu/kvm для хостинга (VPS & co) — это изоляция, а не эмуляция. В случае с qemu это большой оверхед (там много лишнего), поэтому минималистический гипервизор который дает только изоляцию, сеть и block-device, при этом способный выполнять любое ядро — это реальная тема, потому что это всё что нужно большинству контейнеров.

Уже бы тушили питание посредством bios-uefi

Тушить питание не проблема, проблема надёжно и безопасно дать OS знать что пора делать graceful shutdown, ACPI/UEFI etc тут явно будет перебором — клавиатуру эмулировать проще на порядок.
Основная причина по которой используют qemu/kvm для хостинга (VPS & co) — это изоляция, а не эмуляция.

Соглашусь.
Требования для хостинга простые:
— поддержка популярных операционных систем (linux, windows, freebsd различных дистрибутивов и версий)
— поддержка блочных устройств, сети, GPU акселлерации (опционально).
И по идее все… Получатеся, что действительно конфигурация ВМ на хостинга она, в целом, стандартизирована. Плюс еще на хостингах обычно используется закрытый перечень типов железа.
В отличии от запуска гипервизора с ПОЛНЫМ пробросом аппаратного обеспечения на рабочей машине разработчика или пользователя, где действительно нужно тянуть возможность поддержки всех фич и разного типа железа (те же USB пробросы )))
так я же совсем об ином говорил…
к тому же полноценная изоляция сейчас возможна только как часть виртуализации. и там qemu. или vmware. или даже hyper-v. но никак не гипервизор с поддержкой одной кнопки…
это я перефразировал себя же.

HRы и recruiters, теперь ваш ход…
С 1 декабря Firecracker во всех DevOps вакансиях, опыт от 5 лет.

Да. Я взял ядро 4.19, добавил ему virtnet/virtblk статикой (чтобы обойтись без initrd), и запустил Ubuntu 18.04. Ядро можно урезать до минимума, всякая поддержка железа не нужна.

Всё почти как обещано — CPU на уровне 95% от хоста (прикидывается ксеоном), а вот с сетью и диском — на полной загрузке жрёт CPU хоста просто безбожно. Сеткой даёт около 30 Gbits/s с хостом (на i7-6700). Впрочем, с qemu ситуация несколько хуже, оверхед там поболе будет, но это зависит.

В остальном — гипервизор как гипервизор, нужно просто юзать. Привлекает то что это один статический экзешник, никакого инсталла, простой API. Расстраивает что нет годного UI (пока), хотя они вроде уже запилили поддержку в containerd.

Если Proxmox это подхватит (рядом с QEMU) — может неплохая альтернатива lxc получится (в плане изоляции как минимум).

Сильно I/O loaded штуки в нём гонять будет накладно (как, впрочем, и в qemu/docker), но «стандартный пакет» для в основном ожидающих задач (веб-сервера & co) вполне сойдёт.
Всё это хорошо, если бы не бесконечные Spectre. Виртуализация почти мертва, и не важно насколько хорош софт, если железо протекает.
Sign up to leave a comment.