Ажіотаж навколо контейнерної візуалізації

Гипервизор працює по досить простим принципом (дивіться малюнок 1): відбувається емуляція операційного забезпечення, поверх якого запущені гостьові ОС, і за все це відповідає операційна система. Це означає, що взаємозв`язок між гостьовий і хостовой операційними системами слід «залізної» парадигмі: все, що «вміє» робити обладнання, повинно бути доступно гостьовий ОС з боку хостовой. Навпаки, контейнери (див. Рисунок 2) - це віртуалізація на рівні операційної системи, а не обладнання, тобто кожна гостьова ОС використовує те ж саме ядро (а в деяких випадках - і інші частини ОС), що і хостової. Це дає контейнерів велика перевага: вони менше і компактніше гіпервізорних гостьових середовищ, оскільки у них з хостом набагато більше спільного.


Інший великий плюс - значно більша ефективність контейнерної віртуалізації щодо спільного використання ресурсів, так як для неї контейнери - це всього лише керовані ресурси. Наприклад, коли Контейнер 1 і Контейнер 2 працюють з одним і тим же файлом, ядро хоста відкриває цей файл і розміщує сторінки з нього в сторінковий кеш ядра, які потім передаються контейнери i і контейнерів 2: якщо обидва «хочуть» прочитати одні й ті ж дані, вони отримують одну і ту ж сторінку. Якщо ж гіпервізорним віртуальним машинам VMi і VM2 треба виконати таку ж операцію, то спочатку сам хост відкриває запитуваний файл (створюючи сторінки в своєму сторінковому кеші), а потім ще і кожне з ядер VMi і VM2 виконує аналогічну дію. Таким чином, в процесі читання машинами VMi і VM2 одного і того ж файлу в пам`яті існує цілих три однакових сторінки (по одній в сторінковому кеші хоста і в ядрах VMi і VM2), тому що вони не «вміють» одночасно використовувати одну і ту ж сторінку, як це роблять контейнери.





Справа навіть не стільки в «читанні» файлів, скільки в можливості використовувати одну копію виконуваних файлів і бібліотек, що (shared libs) в різних контейнерах. У звичайній системі, якщо два або більше процесів звертаються до однієї і тієї ж розділяється бібліотеці (наприклад, libc), її код присутній в пам`яті тільки в одному екземплярі. Це відноситься і до виконуваних файлів, і до сегментів немодіфіціруемих даних, що дозволяє істотно знизити вимоги до розміру оперативної пам`яті. Так як контейнери використовують єдине ядро, вищеописаний механізм при деяких умовах поширюється і на них, що призводить, зокрема, до підвищення щільності їх розміщення, яка і без цього механізму спочатку вище, ніж у віртуальних машин, оскільки відсутні множинні копії ядра.

В результаті у контейнерів щільність (кількість віртуальних середовищ, які можна запустити на сервері) може бути до трьох разів вище, ніж у віртуальних машин, а на одному сервері цілком може розміщуватися кілька сотень контейнерів. Настільки висока щільність - одна з головних причин популярності контейнерів на ринку хостингу віртуальних виділених серверів (VPS). Якщо на одному і тому ж сервері можна створити в три рази більше VPS, то в розрахунку на один VPS витрати знижуються на 66%, що для такого низькомаржинального бізнесу, як хостинг, іноді дорівнює різниці між збитковістю і прибутковістю.

Звичайно, не все ідеально в світі контейнерів. Наприклад, через спільного використання ядра на одному сервері можна запускати різні гостьові ОС (наприклад, на системі з Linux-контейнерами неможливо запустити FreeBSD або Windows, але різні дистрибутиви Linux - хоч греблю гати). Тому Windows і Linux на одному і тому ж сервері (що для гіпервізора не проблема) не працюють. Однак принаймні в разі Linux цей недолік можна пом`якшити за рахунок використання інтерфейсів ABI і бібліотек: завдяки цьому з`являється можливість запускати на одному сервері контейнери з різними збірками Linux, але одночасно скорочується загальна для цих контейнерів частина ресурсів. У максимальній же мірі переваги контейнерів проявляються в однорідному середовищі.