Компании Intel и Hyper объединили свои разработки и представили (https://01.org/blogs/2017/kata-containers-next-evolution-of-...) проект Kata Containers (https://katacontainers.io/), в рамках которого сделан следующий шаг в развитии технологий Clear Containers (https://github.com/clearcontainers/runtime) и runV (https://github.com/hyperhq/runv), нацеленных на организацию выполнения изолированных контейнеров при помощи полноценных механизмов виртуализации. Развитие проекта будет курировать независимая организация OpenStack Foundation. О поддержке нового проекта уже заявили компании 99cloud, AWcloud, Canonical, China Mobile, City Network, CoreOS, Dell/EMC, EasyStack, Fiberhome, Google, Huawei, JD.com, Mirantis, NetApp, Red Hat, SUSE, Tencent, Ucloud, UnitedStack и ZTE. Код опубликован (https://github.com/kata-containers/) под лицензией Apache 2.0.Как и Clear Containers новый проект позволяет создавать компактные виртуальные машины, выполняемые с использованием полноценного гипервизора, а не в форме запускаемого в одной ОС набора процессов, изолированного при помощи пространств имён и cgroups. Ключевым отличием нового проекта является ориентация на интеграцию в существующие инфраструктуры контейнерной изоляции c возможностью применения подобных виртуальных машин вместо традиционных контейнеров. Применение виртуальных машин позволяет добиться более высокого уровня безопасности, защищающего от совершения атак, вызванных эксплуатацией уязвимостей в ядре Linux. При этом внутри виртуальная машина выступает в качестве дополнительного слоя изоляции, в котором выполняются типовые образы контейнеров.
В Kata Containers будут предоставлены механизмы для обеспечения совместимости легковесных виртуальных машины с различными инфраструктурами контейнерной изоляции, платформами оркестровки контейнеров и спецификациями, такими как OCI (https://www.opennet.dev/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/clearcontainers/proxy/blob/master/docs/ks...) (Kernel Shared Memory), что позволяет организовать совместное использование ресурсов хост-системы и подключить к разным гостевым системам общий шаблон системного окружения.
URL: https://www.businesswire.com/news/home/20171205005634/en/Kat...
Новость: http://www.opennet.dev/opennews/art.shtml?num=47718
Нужно больше контейнеров!
Minix (IntelME) всё равно дырявый.
Зато можно встроить пару свежих, оптимизированных бэкдоров в неведому фигню от интела. Все-равно код этой лабуды никто кроме интеоловских вассалов не будет.
не кати баллоны на миникс.
> Нужно больше контейнеров!Мусорных. Всё упаковать и вывезти на Apache.
> JD.comСерьёзно? А почему других каких-нибудь мошенников не спросили?
Как же не спросили? Там длинный список.
Ещё Huawei, JD.com, Tencent, China Mobile, как минимум.
> защищающего от совершения атак, вызванных эксплуатацией уязвимостей в ядре LinuxЯдро Linux можно легко аудитить, в отличие от процессоров Intel, и какие там "особенности реализации" внедрены в аппаратную виртуализацию - только узкому кругу интеловских инженеров ведомо.
Ядро линукс можно аудитить 100 лет подряд, и все равно багов останется больше чем в микропрошивке интел.
чорт, жалко сlear containers - идея была хорошая, и реализация понятная.
В этой модной меганавороченной хрени никто, наверное, не разберется, включая и ее авторов.
Ну, прототип от продакшн-решения примерно тем и отличается, что он ясно-понятный. А дальше наворачиваем то, что надо в реальной жизни... и этого "навёрнутого" оказывается процентов 80-90 кода.
и ты уверен что вот этот весь п-ц кому-то нада в реальной жизни?запустить единичный стремный контейнер с дополнительным уровнем изоляции - без всяких кубернетесов и прочих чудес, потому что такое ты точно не хочешь на автоматическом проде - это вполне понятная задача из реальной жизни.
Для "единственного контейнера" мне вообще пофигу накладные расходы, обычного KVM хватит.Я точно уверен, что дело идёт к тому, что в абсолютном большинстве случаев "ручные запуски" контейнеров уйдут, а останутся именно кубернетесы и прочее. Примерно как от явно выделенных процессов ушли к пулам (а потом к пулам потоков) потоков, которые создаются и убиваются какой-то автоматикой. И точно уверен, что с ростом сложности новые уровни безопасности будут нормой, и подход будет "отдетектиили подозрительную активность? Убиваем контейнер и перезапускаем где-то ещё с нуля, а потом (может быть) разбираемся", потому что диагностировать всё это в реальном времени никаких ресурсов не хватит.
так идея-то была не в этом совсем. Идея была - (чужой) стандартный докеровский или еще чей образ запустить, не разбираясь с его потрохами.
А не сетапить kvm с нуля, потом выковыривать из образа что они там наслесарили и вручную это воспроизводить.
Ну, это у кого какая идея. У меня - что сделать надёжно изолированные друг от друга контейнеры - всё меньше шансов, а быстро поднимать/убивать их хочется. В этом плане затея как раз правильная. Если что-то подобное не предполагать то совершенно непонятно, зачем выбирать то, где "20 мб на контейнер". Для вашего случая наверняка есть какой-то другой вариант уже сейчас. Скорее всего с оверхедом по сложности и тратам ресурсов - но для "один раз что-то запустить" - не критично.
>Для вашего случая наверняка есть какой-то другой вариант уже сейчас. Скорее всего с оверхедом по сложности и тратам ресурсов - но для "один раз что-то запустить" - не критично.Может Vagrant тогда?
Быстро запускать контейнеры это к kvm, из соспенда стартует как раз за <100мс
Увидел в новости логотип Магенто и испугался https://duckduckgo.com/?q=magento+logo
Комментаторы действительно поняли о чем речь, просто прочитав текст новости?
Нужно как-то всё систематизировать, и в одной статье разжевать. Я уже вообще не ориентируюсь в этой куче контейнеров, и не понимаю, на надо их столько?
Хайп.
Для упрощения, почти не совру: контейнеры в Линуксе сейчас одни. Сабж к контейнерам не относится, опять почти не соврал.
Начать можно отсюда https://lwn.net/Articles/531114/
Вот это годнота.
> Вот это годнота.| tr д в
sed ниасилил, да? ))
Чего только не придумают чтобы не юзать rkt, там ведь, все доступно из коробки через stages, плюс кроме этого в комплекте с SELinux получается вполне продакшен решение. Другое дело что есть некоторые огрничения при работе в связке с k8s, но это уже отдельная тема, надо активней пинать по ишам разрабо k8s и ребят из coreos.
> Чего только не придумают чтобы не юзать rkt,не нужно ничего придумывать, чтобы "не юзать" еще одну ненужно-ненужно обертку вокруг lxc, сделанную в режиме "зато не докер!"
> там ведь, все доступно из коробки через stages,
кроме самого rkt, который из коробки только в неведомой зверушке. При этом https://github.com/rkt/rkt/blob/master/Documentation/running...
How does it work?
It leverages the work done by Intel with their Clear Containers system.это я и без rkt могу (и да, перед этим там длинный список того, что у них в таком режиме не работает) - а вот сможет ли теперь что-нибудь rkt, когда интел забьет на старый проект?
> плюс кроме этого в комплекте с SELinux получается вполне продакшен решение.
на продакшн обычно некогда ковыряться с audit2allow "угадай что этой твари опять надо" и негде хранить терабайты мусора недоделанного линуксного audit.log.
К тому же контейнеры у нас такие контейнеры: https://nvd.nist.gov/vuln/detail/CVE-2015-1334
Эту дырку закрыли - новых понаделают.
>k8sнакой хрен этот вендорлочный монстр нужен?
ну хоть не docker swarm
так сварм, как часть докера, это наоборот красотуля, хотя с ростом проекта глюков всё больше
"Во-первых, это красиво"