В чем разница между Ignite и gVisor с точки зрения их варианта использования?
Я хотел бы знать, есть ли разница между gVisor и Weave Ignite с точки зрения их вариантов использования (если они есть). Мне кажется, что они оба пытаются сделать одно и то же: сделать выполнение кода в виртуализированных средах более безопасным.
gVisor делает это, представляя runscсреда выполнения, которая включает контейнеры с песочницей, и Ignite делает это с помощью Firecracker, который в их контексте, похоже, также используется как песочница.
1 ответ
И Firecracker, и gVisor - это технологии, которые обеспечивают песочницу / изоляцию, но по-разному.
- Firecracker (оранжевая коробка) - менеджер виртуальных машин.
- gVisor (зеленое поле) имеет архитектуру, которая контролирует / фильтрует системные вызовы, которые достигают реального хоста.
Weave Ignite - это инструмент, который помогает вам использовать Firecracker для запуска контейнеров внутри легких виртуальных машин, а также делать это с красивым UX, аналогично использованию Docker.
Это также упоминается в разделе " Область применения " на https://github.com/weaveworks/ignite.
Объем
Ignite отличается от Kata Containers или gVisor. Они не позволяют вам запускать настоящие виртуальные машины, а только обертывают контейнер в новый слой, обеспечивая некоторую границу безопасности (или "песочницу").
С другой стороны, Ignite позволяет вам запускать полноценную виртуальную машину, просто и супер-быстро, но с привычным контейнером UX. Это означает, что вы можете "перейти на один уровень вниз" и начать управлять своим парком виртуальных машин, например, кластером Kubernetes, но при этом упаковывать свои виртуальные машины как контейнеры.
Что касается варианта использования вашего вопроса, то я чувствую, что благодаря более сильной изоляции виртуальных машин Ignite может быть более готовой к работе. Кроме того, подход gVisor, по-видимому, требует значительных затрат на производительность, как это упоминается в разделе "Истинная стоимость содержания: пример использования gVisor":
Заключение
- gVisor, возможно, более безопасен, чем
runc- К сожалению, наш анализ показывает, что реальные затраты на эффективное хранение высоки: системные вызовы в 2,2 раза медленнее, выделение памяти в 2,5 раза медленнее, большие загрузки в 2,8 раза медленнее, а открытия файлов в 216 раз медленнее.
Текущие методы песочницы
Песочница с gVisor
Нужен ли мне gVisor?
Нет. Если вы работаете с рабочими нагрузками, даже не думайте об этом! Прямо сейчас это метафорический научный эксперимент. Это не значит, что вы можете не использовать его по мере его развития. У меня нет проблем с тем, как он пытается решить проблему изоляции процессов, и я думаю, что это хорошая идея. Есть также альтернативы, которые вы должны потратить время на изучение, прежде чем применять эту технологию в будущем.
Где я мог бы использовать это?
Как оператор, вы захотите использовать gVisor для изоляции контейнеров приложений, которые не являются полностью доверенными. Это может быть новая версия проекта с открытым исходным кодом, которому ваша организация доверяла в прошлом. Это может быть новый проект, который ваша команда еще не провела, или что-то еще, в чем вы не совсем уверены, можно ли доверять вашему кластеру. В конце концов, если вы запускаете проект с открытым исходным кодом, который вы не написали (все мы), ваша команда, конечно, не написала его, так что было бы хорошей безопасностью и хорошей разработкой для надлежащей изоляции и защиты вашей среды в случае может быть пока неизвестная уязвимость.
дальнейшее чтение
Мой ответ содержит информацию из следующих источников, которые находятся в разделах цитат, когда они приняты "как есть", и я рекомендую их для дальнейшего чтения: