The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Google открыл gVisor, гибрид системы виртуализации и контейнеров

03.05.2018 09:20

Компания Google представила проект gVisor, в рамках которого подготовлен новый открытый runtime для обеспечения изолированного запуска контейнеров, соответствующих требованиям спецификации Open Container Initiative (OCI). gVisor может применяться в качестве слоя в Docker и Kubernetes, заменяя предлагаемый в них штатный runtime. Код gVisor написан на языке Go и поставляется под лицензией Apache 2.0.

При разработке gVisor была поставлена задача создания решения для выполнения контейнеров более легковесного чем системы виртуализации, но обеспечивающего сходный с ними уровень изоляции. Ключевым компонентом gVisor является собственное ядро, которое написано на языке Go и реализует большинство системных вызовов ядра Linux. Язык Go выбран для обеспечения дополнительной защиты, благодаря встроенным средствам контроля типов и границ блоков памяти, исключению проблем use-after-free, защите от переполнений стека и наличию детектора состояний гонки.

Ядро gVisor выполняется как обычный непривилегированный процесс и обеспечивает работу изолированного окружения контейнера. По аналогии с системами виртуализации в каждом подобном окружении используется своё ядро и набор виртуализированных устройств, отделённых от хост-системы и других контейнеров. Ядро gVisor обрабатывает все системные вызовы от приложений, изолируя их от остальной системы. При этом, gVisor не просто транслирует системные вызовы приложений в запросы к ядру Linux, а самостоятельно реализует основные примитивы ядра (сигналы, ФС, блокировки, маппинг памяти, неименованные каналы и т.п.) и выстраивает предоставляемые приложениям обработчики системных вызовов на основе данных примитивов. Так как ядро gVisor реализовано в форме обычного процесса, то для реализации функциональности примитивов выполняется обращение к ограниченному набору штатных системных вызовов основного ядра Linux (по аналогии с UML - User Mode Linux).

Подобный подход предоставляет высокую гибкость в управлении ресурсами и более низкие накладные расходы по сравнению с VM, но ценой этому становится повышение накладных расходов при обработке системных вызовов и ограниченная совместимость с приложениями. В настоящее время реализовано около 200 наиболее часто применяемых системных вызов. Некоторые системные вызовы и параметры пока не реализованы, также отсутствует поддержка части иерархии /proc и /sys, что требует особого отношения при подборе программ для запуска в контейнерах gVisor. Из работающих с gVisor приложений отмечены Node.js, Java 8, MySQL, Jenkins, Apache httpd, Redis, PHP, Tomcat, WordPress и MongoDB. Из пока не работающих приложений можно отметить nginx, Elasticsearch и PostgreSQL.

Для организации доступа к частям основной файловой системы хост-окружения применяется специальный процесс-прокси Gofer, взаимодействующий с ядром gVisor при помощи протокола 9P. Для доступа к сети в ядре gVisor реализован собственный сетевой стек (netstack), поддерживающий отслеживание состояний соединения и пересборку пакетов. Netstack полностью изолирован от сетевого стека ядра Linux и взаимодействует с внешним миром через виртуальное устройство, работающее в отдельном пространстве имён. Для особых ситуаций предусмотрен режим прямого проброса сетевых соединений, ценой снижения уровня изоляции. Для переключения контекста и реализации маппинга памяти предлагается использовать Ptrace или KVM.

Напомним, что в обычных контейнерах применяется общее для всех изолированных окружений ядро Linux с разграничением доступа к ресурсам на уровне cgroups и namespaces, что является слабым звеном безопасности, так как не все ресурсы ограничиваются, а уязвимость в ядре Linux компрометирует всю систему изоляции. В условиях, требующих надёжной изоляции приложений применяется метод запуска каждого контейнера в отдельной виртуальной машине со своим ядром и системным окружением, но по сравнению с контейнерами на базе cgroups и namespaces указанный способ требует существенно больше ресурсов и тратит много времени на запуск. В рамках проекта Kata развивается runtime на базе гипервизора и специальных урезанных окружений с оптимизированным ядром Linux, который частично решает указанные проблемы.

  1. Главная ссылка к новости (https://cloudplatform.googlebl...)
  2. OpenNews: Google представил Cilium, сетевую систему для Linux-контейнеров, основанную на BPF
  3. OpenNews: Компания Google открыла код системы изолированных контейнеров Lmctfy
  4. OpenNews: Linux Foundation представил containerd 1.0, runtime для изолированных контейнеров
  5. OpenNews: Intel представил инструментарий Clear Containers 3.0, переписанный на языке Go
  6. OpenNews: Компании Intel и Hyper представили проект Kata Containers
Лицензия: CC-BY
Тип: Интересно / Программы
Короткая ссылка: https://opennet.ru/48538-gvisor
Ключевые слова: gvisor, container, docker, virtual
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (28) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, анонимтут (?), 09:45, 03/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > протокол 9P

    O_o Не пропала концепция - Plan 9 вспомнили.

     
     
  • 2.18, Аноним (-), 15:02, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    И тебя с разморозкой. Протокол p9 давным давно используется, например обычным попсовым qemu (и kvm) для обмена файлами с хостом через виртуальные интерфейсы.
     

  • 1.3, Аноним (-), 09:50, 03/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Судя по всему, будет тормозить.
     
     
  • 2.11, пох (?), 10:56, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Судя по всему, будет тормозить.

    и неработать.
    Брысь, дедушка, ты не в тренде - сейчас это не важно, важно oci, go, протокол 9p.


     

  • 1.4, Аноним (4), 09:51, 03/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >В обычных контейнерах применяется общее для всех изолированных окружений ядро Linux с разграничением доступа к ресурсам на уровне cgroups и namespaces, что является слабым звеном безопасности, так как не все ресурсы ограничиваются

    Интересно каких именно ограничений им не хватает в докере?
    >а уязвимость в ядре Linux компрометирует всю систему изоляции

    Как и уязвимость в gVisor.

     
     
  • 2.7, F (?), 10:10, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    https://habr.com/post/332450/
     
     
  • 3.9, пох (?), 10:43, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    о, спасибо, прекрасное (там есть линк и на более свежие впечатления, в принципе, можно не читать, они предсказуемы).  А то аналогичная статья 14го года уже плохо помогала в спорах с генитальными разработчиками - "там же все вранье, это все уже переписали, уже три раза!".

    только обратите внимание - оно не про секьюрити ни разу, то есть гуглевая прослойка в этом компоте ничего не испортит, взболтать, не размешивать, вылить в корыто свиньям.

     
  • 2.10, пох (?), 10:53, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Интересно каких именно ограничений им не хватает в докере?

    очевидных. реальной а не виртуальной изоляции приложений, fine-grained изоляции ресурсов (докер, в силу родовой травмы, не может точно отмерять кусочек cpu/кусочек дискового throughput - то что умеет какой-нибудь openvz с незапамятных времен)
    >>а уязвимость в ядре Linux компрометирует всю систему изоляции
    > Как и уязвимость в gVisor.

    "выполняется от непривиллегированного пользователя", какое слово вам перевести?

    доцкер только _запускается_ от непривиллегированного пользователя, внутри полагаясь на ифраструктуру ядра, обеспечивающую этим пользователям, внезапно, root equivalence, периодически проламываемую до рута на хост-системе.

    другое дело, что эта гуглохрень наследует все инфраструктурные проблем доскера, поскольку без него неработоспособна, в ней работает аж три полезные и пять бесполезных программ, а вместо cgroups полагается на kvm, которая обеспечивает не root, а сразу kernel level equivalence, и которую точно так же ломали, ломают и ломать будут.
    зато на го.

     
     
  • 3.19, Аноним (-), 15:13, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > (докер, в силу родовой травмы, не может точно отмерять кусочек cpu/кусочек
    > дискового throughput - то что умеет какой-нибудь openvz с незапамятных времен)

    Сейчас это умеет уже более-менее и сам линух. А у опенвзы родовая травма в виде левого ядра которое поддерживается через пень колоду так и осталась. За что он и вылетает отовсюду - я уж не знаю что там случилось но у половины хостеров KVM стоит даже уже дешевле чем VZ у тормозных барыг которые им еще пользуются. А проблем радикально меньше. Ну то-есть для хостера openvz это куча грабель, а остальным "точно отмерять кусочек" не так уж сильно надо, чтобы с левыми ядрами мучаться.

    Да и "точно отмерять" например производительность HDD - дохлый номер, из-за того что софт не может прогнозировать время полета голов от сих до сих. Для SSD и тому подобного - еще куда ни шло.

    А что до kvm - его может и ломали, но - весьма умеренно. Я прямо удивлен что при такой попсовости и сложности там не наблюдается того что можно ожидать при таких исходных данных.

     
     
  • 4.20, пох (?), 16:27, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > За что он и вылетает отовсюду - я уж не знаю что там случилось

    банальное там "слуцилась" - те части их кода, которые удалось "каждое заверните в салфеточку и отнесите в машину" - успешно пользует...правильно, kvm, xen и libvirt (и немедленно обросли несовместимыми с прародителем правками, так что вреда им от этого было куда больше чем пользы).
    А те что в ядре пришлись не ко двору, потому что денег на взятки линусовой братии у них не хватило - в конце-концов стало невозможно без конца переделывать в погоне за вечно движущейся целью, силами полутора уцелевших разработчиков. Тем более что те имели дурную привычку делать хорошо и разбираться в том, что делают окружающие, а не "ну nginx не запускается, но нам нафиг не нужен".

    так что на этом проекте можно ставить крестик, но речь-то не об этом, а о том что современные и того не могут толком. Вот и изобретают обратно все тот же квадратноколесатый велосипед. Зато он модной расцветочки.

     
  • 3.32, Аноним (-), 12:40, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > кусочек дискового throughput - то что умеет какой-нибудь openvz с незапамятных времен)

    Да да. OpenVZ умеет вставлять циклы ожидания в JBD2, после чего начинают тормозить все :-)
    А еще умеет сломать дисковый кэш потому-что кому-то из разработчиков влом править GFP маску при kmalloc :-)

     

  • 1.8, Аноним (-), 10:39, 03/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    да-а-а, красота - "мы переписали uml (который, вообще-то, на минуточку, просто работал, медленно, зато на pentiumI, без малейших намеков на аппаратную помощь виртуализации) на игогошеньке - зачем - не знаем, патамушта магем. Правда, у нас даже nginx в нем не запускается, зато игогогогого!"

    Правда, uml не требовал для своей работы kvm (то есть, неожиданно, виртуализации не получилось, "к счастью, в ядре вообще-то было уже все готовое". Что это как бы не совсем "непривиллегированный процесс", аккуратно забыто).

    остается понять одно - гугль ЭТО выкинул на помойку, и именно по этой причине открыл (спаннер вон что-то не торопятся, предлагают китаезам переписывать с нуля) или это просто тоже в рамках модного тренда - во втором случае, может мы еще и попируем на развалинах гугля лет через десять-пятнадцать, главное чтоб все остальные подразделения не отставали.

     
     
  • 2.13, IB (?), 12:11, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да, странное изделие.
    Непредсказуемые несовместимости во все поля.
    Получается строго заточено под набор приложений с которыми тестировалось самим Гуглем.

    Запуская своё никто не гарантирует, что вдруг поведение не станет непредсказуемым.

     
     
  • 3.15, пох (?), 13:09, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    не переживай - запуская докер в коммерческом окружении, ты и так гарантирован что поведение станет непредсказуемым.

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

    Интересно, кстати, почему они вместо этой хрени не использовали работающие (в тех пределах, в которых вообще докер можно считать работающим) clear containers? NIH? Древнее железо (гугль любит очень странные процессоры и другие детали в своих картонных серверах)?

    Впрочем, я сомневаюсь что мы увидим техническое обоснование - скорее всего и внутри гугля они давно немодны, моден хайп (из которого целиком и состоит новость, в смысле, ее первоисточник)

     

  • 1.12, anonymous (??), 11:03, 03/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Так это же UML-2.0.
     
     
  • 2.14, пох (?), 12:34, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    uml, в отличие от этого гуглонедоразумения - работал. Но был не от гугля, не на модном go, не поддерживал модный oci-трэш, и не нравился Линусу. Поэтому быстро помер от недостатка внимания.

     
     
  • 3.22, Аноним (-), 19:02, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В смысле помер? до сих пор спокойно можно собрать ядро с ARCH=um. Когда в последний раз запускать такое ядро версии 4.0 (или чуть новее), то все более-менее работало.
     
     
  • 4.24, пох (?), 19:23, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В смысле помер? до сих пор спокойно можно собрать ядро с ARCH=um.

    собрать-то, наверное, можно, но зачем?

     

  • 1.21, Аноним (21), 17:26, 03/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что использовать вместо докера? Эта вся гомогребля с сетями и багами докера не кажется привлекательной.
     
     
  • 2.23, пох (?), 19:22, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Что использовать вместо докера?

    плетку. Которой отучать разработчиков создавать трэш, работающий только на побитовых копиях их собственных систем.

    То есть, это, собственно, если докер использовать по прямому назначению, единственному, где он как-то работает - для воссоздания кривых окружений кривых программ (непременно stateless, потому что не портить записываемые из под себя диски он так и не научился).

    Если тебе надо что-то другое, то уточняй задачу.

    В том числе с учетом новых знаний о неисправимых багах процессоров, из-за которых изоляция "контейнеров" невозможна в принципе, изоляция hardware virtualized систем - частично и без гарантий.

     

  • 1.25, _ (??), 19:39, 03/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >собственное ядро, которое написано на языке Go и реализует большинство системных вызовов ядра Linux

    Оло-ло-шечка ... 8-о
    А нкоторые до сих пор спорят взлетел ли Go? %-)

     
     
  • 2.26, пох (?), 19:43, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    только ничего не работает, кроме трех программ.

     
     
  • 3.27, пох (?), 19:45, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > только ничего не работает, кроме трех программ.

    (и да, если присмотреться - "реализует"-то - кривой враппер в основном, к реально работающим функциям стандартного линуксного ядра)

    своего осилено, походу, сетевой эмулятор (очередной, и неведомо с какой эффективностью) и что там - сокеты? Мухахаха.


     
  • 3.28, Аноним (-), 20:41, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    1) запускаем на нормальном Linux под strace
    2) находим вызовы, которые пока не поддерживаются
    3) пишем багрепорт
    ...
    PROFIT!!!
     
     
  • 4.29, пох (?), 00:30, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 3) пишем багрепорт

    получаем wontfix или просто он висит вечно.
    Как ты понимаешь, запустить nginx со strace разработчики могли и сами - только недостающий и не факт что тривиальный (ибо треды и взаимоблокировки) код сам не напишется.


     

  • 1.30, Аноним (-), 01:14, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Язык Go выбран для обеспечения дополнительной защиты, благодаря встроенным средствам контроля типов и границ блоков памяти, исключению проблем use-after-free, защите от переполнений стека и наличию детектора состояний гонки.

    Очень интересно оправдает оно себя или нет

     
  • 1.31, Аноним (-), 11:32, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А почему не на Rust?
     
     
  • 2.33, _ (??), 17:10, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    We leave the Rust for the competitors ... (C)

    ;-)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру