Состоялся (https://katacontainers.io/posts/kata-containers-first-release/) первый выпуск проекта Kata Containers (https://katacontainers.io/), в рамках которого развивается стек для организации выполнения контейнеров с использованием изоляции на базе полноценных механизмов виртуализации, созданный компаниями Intel и Hyper путём объединения технологий Clear Containers (https://github.com/clearcontainers/runtime) и runV (https://github.com/hyperhq/runv). Код проекта написан на языке Go и распространяется (https://github.com/kata-containers/) под лицензией Apache 2.0. Развитие проекта курирует рабочая группа, созданная под эгидой независимой организации OpenStack Foundation, в которой участвуют такие компании, как Canonical, China Mobile, Dell/EMC, EasyStack, Google, Huawei, NetApp, Red Hat, SUSE и ZTE.
Основу Kata составляет runtime (https://github.com/kata-containers/runtime), предоставляющий возможность создавать компактные виртуальные машины, выполняемые с использованием полноценного гипервизора, вместо применения традиционных контейнеров, использующих общее ядро Linux и изолированных при помощи пространств имён и cgroups. Применение виртуальных машин позволяет добиться более высокого уровня безопасности, защищающего от совершения атак, вызванных эксплуатацией уязвимостей в ядре Linux.
Kata Containers ориентирован на интеграцию в существующие инфраструктуры контейнерной изоляции c возможностью применения подобных виртуальных машин для усиления защиты традиционных контейнеров. Проектом предоставляются механизмы для обеспечения совместимости легковесных виртуальных машины с различными инфраструктурами контейнерной изоляции, платформами оркестровки контейнеров и спецификациями, такими как OCI (https://www.opennet.me/opennews/art.shtml?num=46889) (Open Container Initiative), CRI (Container Runtime Interface) и CNI (Container Networking Interface). Доступны средства для интеграции с Docker, Kubernetes, QEMU и OpenStack.Интеграция с системами управления контенерами достигается при помощи прослойки, симулирующей управление контейнером, которая через gRPC-интерфейс и специальный прокси обращается к управляющему агенту в виртуальной машине. Внутри виртуального окружения, которое запускается гипервизором, используется специально оптимизированное ядро Linux, содержащее только минимальный набор необходимых возможностей.
Системное окружение включает в себя только демон инициализации и агент (Аgent). Агент обеспечивает выполнение определённых пользователем образов контейнера в формате OCI для Docker и CRI для Kubernetes. При использовании совместно с Docker для каждого контейнера создаётся отдельная виртуальная машина, т.е. запускаемое поверх гипервизора окружение применяется для вложенного запуска контейнеров.
В условиях выполнения большого числа типовых окружений, накладные расходы на каждое последующее окружение составляет 18-20 Мб, что даёт возможность уместить 3500 виртуальных машин на сервере с 128 Гб ОЗУ. Окружение запускается менее, чем за 100ms, что позволяет использовать Kata Containers для запуска контейнера с приложениями на лету, в моменты, когда в них возникает необходимость. В качестве гипервизора по умолчанию предлагается использовать KVM в сочетании с инструментарием QEMU, но проект изначально позиционируется как не привязанный к конкретным архитектурам и способный работать с различными гипервизорами (например, Xen).Для уменьшения потребления памяти применяется механизм DAX (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) (прямой доступ к ФС в обход страничного кэша без применения уровня блочных устройств), а для дедупликации одинаковых областей памяти применяется технология KSM (https://github.com/kata-containers/ksm-throttler) (Kernel Samepage Merging), что позволяет организовать совместное использование ресурсов хост-системы и подключить к разным гостевым системам общий шаблон системного окружения.
URL: https://katacontainers.io/posts/kata-containers-first-release/
Новость: https://www.opennet.me/opennews/art.shtml?num=48642
>такие компании как (...) ZTE"Запомни меня молодой и красивой!"
А по сути: выглядит довольно интересно. Но, опять же, без "написано на Go" теперь вообще новых продуктов не появляется?
Какая разница, на каком языке написано? Вам шашечки или ехать?
Очень просто. GO часто equals lots of buggy features.
писать плохо можно на чем угодно, как бы
lots of buggy features - это смотря с чем сравнивать.
Вы предпочли бы реализацию аналогичной вещи на node.js?
Как бэ гоша вполне себе в рамках спеки действует, при этом спека а) простая, б) понятная, в) короткая.
Чем конкретно не устраивает GO и почему?
Какой язык был бы для вас идеальным для данного продукта и почему?
только C#1111
C# не тру никс вей.
> Какой язык был бы для вас идеальным для данного продукта и почему?Няшный JavaScript. В крайнем случае, питон в трех разных версиях.
Всем усраивает. Это скорее про статистику и "в целом интересно". К Go я отношусь ровно так же как к паскалю, плюсам и джаве: человек с пониманием алгоритмизации и на дельфях напишет безопасный код. Человек с Visual Hindu головного мозга напишет... Ну вот то, что напишет.
<Применение виртуальных машин позволяет добиться более высокого уровня безопасности, защищающего от совершения атак, вызванных эксплуатацией уязвимостей в ядре Linux. >
И открывает для совершения атак, вызванных эксплуатацией уязвимостей в виртуальных машинах. Маркетологи...
Основная уязвимость обычно в голове к "виртуализатора": ну оно ж в виртуалке, почему бы не исполнить этот скрипт (лень смотреть чего и как оно делает) от рута?
Интерфейс между виртуалкой и хостом намного компактнее и, соответственно, поверхность атаки тоже. Если виртуалки худо-бедно научились хостить на своем железе для незнамо кого, то контейнерам это и близко не светит: в большинстве публичных сервисах хостинга контейнеров ты покупаешь виртуалки, подключенные к системе управления хостера и уже в них запускаешь свои контейнеры.
>Интерфейс между виртуалкой и хостом намного компактнее и, соответственно, поверхность атаки тоже.Интерфейсы и количество кода лишь очень косвенная оценка безопасности, намного важнее качество.
Какой-нить браузер мб вполне безопаснее ПО васяна на 500 строк. А ОС безопаснее браузера.
Так что такой себе аргумент.
Я бы лучше посмотрел распределение реально работающих критических уязвимостей и время за которое их исправляли.
Классная штука, такими темпами скоро и OpenStack можно будет отправлять на помойку.> механизм DAX
Не совсем понятно что он из себя представляет и как это вообще выглядит со стороны гипервизора.
Кстати, почему не 9p?
> Не совсем понятно что он из себя представляетЭто, грубо говоря, виртуальный nvdimm. Основной плюс - это XIP (execution in place), когда секции бинарей с исполняемым кодом и статическими данными не копируются в память, а исполняются прям с nvdimm.
когда AMD прикрутят, тогда и посмотрим. штеуд даром не надо
Не, ну даром-то почему бы и нет)
Нехай доплачивают, а то у нас финансовые показатели.
И чаво смесью удобрения и алюминия в синагоге делать? Мусорить, чтобы иудеи в страданиях подметали за тобой? Ещё по морде дадут.
господа, у вас сообщение от удалённого сообщения отклеилось и к другому приклеилось
и ноги переломают
>для дедупликации одинаковых областей памяти применяется технология KSM (Kernel Samepage Merging)dedup est machina?
>>для дедупликации одинаковых областей памяти применяется технология KSM (Kernel Samepage Merging)
> dedup est machina?Нет, это активный зонд, на который внимание обратили только раз в рассказе о rowhammer, но потом срочно решили забыть, а то палево.
Оч полезная технология, когда пытаешься продать 200 вмок на серваке в который по ресурсам влезает только 100, так что не надо тут! Есть десятки более изящных предустановленных "зондов" нежели rowhammer.
> Оч полезная технология, когда пытаешься продать 200 вмок на серваке в который
> по ресурсам влезает только 100, так что не надо тут! Есть
> десятки более изящных предустановленных "зондов" нежели rowhammer.ага, изящнее чем подмена приватных ключей в состедней виртуалке путём теребления своей памяти