Привет, Хабр! Меня зовут Матвей Мочалов, я — компьютерный инженер и один из авторов корпоративного блога cdnnow! Как-то мы уже обсуждали особенности Docker на разных системах, а сегодня я хочу копнуть глубже — поговорить о том, как наша индустрия поймала саму себя в ловушку Джокера и умудрилась запутать всех, выдавая контейнеризацию за виртуализацию.
Продолжим об этом ниже в посте.
Виртуализация: что это на самом деле
Виртуализация — это технология, программно создающая копии физических устройств: серверов, рабочих станций, сетей и хранилищ данных. От процессора до видеокарты, от оперативной памяти до сетевых интерфейсов.
Виртуализация берет своё начало в 70-х годах прошлого века, когда Джеральд Попек и Роберт Голдберг в своей статье «Formal Requirements for Virtualizable Third Generation Architectures» формализовали принципы работы этой технологии. И главное там — не файловые системы или процессы, а то, как изолировать привилегированные инструкции процессора. Как сделать так, чтобы одно физическое железо могло притворяться несколькими независимыми компьютерами, обеспечивая каждому своё собственное окружение.
Если углубиться в историю, то в то время компьютеры были огромными и дорогими машинами, доступ к которым требовался множеству пользователей и задач. Возникла необходимость разделить ресурсы одного мощного компьютера между разными операционными системами и приложениями, обеспечивая при этом изоляцию и безопасность. Виртуализация стала решением этой проблемы, позволив запускать на одном физическом сервере несколько виртуальных машин, каждая из которых думала, что она работает на собственном оборудовании.
Современная виртуализация основывается на тех же принципах, но с использованием более продвинутых технологий и аппаратной поддержки. Процессоры получили специальные инструкции для поддержки виртуализации, такие как Intel VT-x и AMD-V, которые позволяют гипервизорам эффективно управлять виртуальными машинами без значительных потерь производительности.
Гипервизоры: теория, практика и суровая реальность
В мире виртуализации всё крутится вокруг гипервизоров — программ, которые управляют виртуальными машинами. Они бывают двух типов. И тут начинается самое интересное.
По классике жанра гипервизоры первого типа или «bare‑metal» гипервизоры якобы работают прямо на железе без участия операционной системы. Гипервизоры второго типа работают как обычные программы внутри операционной системы. Красивая теория, не правда ли? Но реальность, как всегда, сложнее.
Возьмём, к примеру, KVM в Linux и Hyper-V в Windows. Оба позиционируются как гипервизоры первого типа. Однако на самом деле они являются частью операционной системы. KVM интегрирован в ядро Linux и функционирует как модуль, предоставляя возможности виртуализации на уровне ядра. Hyper-V в Windows тоже встроен в систему, но при его активации Windows сама становится виртуальной машиной, работающей поверх Hyper-V. Получается своеобразная матрёшка, где хостовая ОС становится гостевой внутри собственного гипервизора.
А помните технологии Intel VT-x и AMD-V? Они были разработаны для того, чтобы предоставить аппаратную поддержку виртуализации на уровне процессора. Именно благодаря им современные гипервизоры могут эффективно управлять виртуальными машинами, не прибегая к сложной программной эмуляции каждой инструкции. Это значительно повышает производительность и снижает накладные расходы.
Но тут возникает вопрос: если гипервизоры первого типа должны работать напрямую с железом, а второго — внутри ОС, то куда отнести KVM и Hyper-V, которые являются модулями ядра? Да и VMware ESXi, который записывают в гипервизоры первого типа, также не самостоятелен, а нуждается в ОС с ядром, подозрительно напоминающим Linux.
Реальность же такова, что границы между этими типами гипервизоров размыты, и классификация становится условной. Главное — как они работают на практике и какие возможности предоставляют.
А что там с контейнерами?
И тут начинается самое забавное. Контейнеры выросли из совершенно другого корня — из утилиты chroot, появившейся в Unix V7 в 1979 году. Её задача была проста — изменить корневую директорию для процесса, создавая иллюзию, что это и есть вся файловая система. Никакой магии с процессором, никакой эмуляции железа — просто хитрый трюк с файловой системой.
Позже появились дополнительные механизмы — pivot_root, namespaces для изоляции процессов, cgroups для контроля использования ресурсов. Но суть не изменилась: всё это работает поверх одного ядра системы. Контейнеры предоставляют изолированную среду выполнения для приложений, но используют общее ядро операционной системы. В этом и заключается их прелесть — лёгкость и эффективность, и проблема — ограничения и риски, связанные с общей средой.
Контейнеры стали популярны благодаря своей способности обеспечивать быстрое развёртывание приложений, а также обеспечивать консистентность среды и эффективно использовать ресурсы в рамках одной хостовой системы, где контейнеров может быть сразу целое множество. Docker и подобные технологии сделали контейнеризацию доступной и удобной, предоставляя инструменты для управления контейнерами и их образами.
Однако важно понимать, что контейнеры не создают полноценной изоляции на уровне ядра. Они больше похожи на отдельные процессы, запущенные в изолированных пространствах имён с ограниченными ресурсами. Это значит, что если в ядре системы есть уязвимость, она потенциально может быть использована для выхода из контейнера и воздействия на хостовую систему или другие контейнеры.
Почему это важно?
Разница между виртуализацией и контейнеризацией имеет практические последствия для безопасности, производительности и совместимости.
Виртуализация создаёт полноценное виртуальное окружение. Каждая виртуальная машина получает виртуальный набор аппаратных ресурсов: свой процессор, память, диски, сетевые интерфейсы. И главное — своё ядро операционной системы. Это обеспечивает высокую степень изоляции. Если в одной виртуальной машине происходит сбой или компрометация, это не влияет напрямую на хостовую систему или другие виртуальные машины.
Контейнеры же все работают на одном общем ядре. Они могут иметь свои файловые системы, библиотеки, приложения, но ядро системы у них общее. Это как квартиры в многоэтажном доме: у каждого своя планировка и мебель, но фундамент и коммуникации общие. Если происходит проблема с фундаментом, страдают все жильцы.
И что теперь?
Для начала нужно перестать сравнивать эти технологии, как конкурирующие решения. Контейнеры и виртуализация решают разные задачи: контейнеры нужны для упаковки приложений со всеми зависимостями, чтобы не загрязнять основную систему и обеспечить переносимость приложения. А виртуализация — для создания полноценных изолированных окружений, когда из одного физического сервера нужно получить несколько независимых.
Виртуализация нужна там, где требуется полная изоляция, где нужны разные операционные системы или их версии, где безопасность и совместимость важнее производительности. Виртуальные машины позволяют запускать совершенно разные среды на одном физическом сервере, обеспечивая высокий уровень изоляции и гибкости.
Если говорить проще, весь мировой хостинг работает на виртуалках, потому что это позволяет из одного сервера сделать десятки независимых. А контейнеры используются разработчиками, чтобы их приложение со всеми библиотеками и зависимостями гарантированно запустилось у заказчика точно так же, как и на их машине.
Сравнивать виртуализацию и контейнеризацию как нечто равнозначное или утверждать будто они друг с другом конкурируют — это как путать упаковку продуктов в контейнеры с разделением супермаркета на отделы. Вроде и то, и другое про организацию, но задачи решают совершенно разные.
Заключение
В IT часто возникают ситуации, когда модные слова и маркетинговые термины затмевают реальную суть технологий. Контейнеры и виртуализация — яркий пример такого смешения понятий. Понимая фундаментальные различия между ними, мы можем более осознанно выбирать инструменты для решения конкретных задач, избегая ненужных сложностей и оптимизируя ресурсы.
Давайте называть вещи своими именами и использовать технологии там, где они действительно уместны. Это позволит создавать более эффективные, надёжные и производительные системы.
А вы сталкивались с подменой этих понятий? К каким последствиям это приводило в ваших проектах? Возможно, у вас есть интересные истории о том, как неправильное понимание технологий приводило к неожиданным результатам или проблемам. Буду ждать всех в комментариях!
Комментарии (40)
spirit1984
05.11.2024 12:53Это обеспечивает высокую степень изоляции. Если в одной виртуальной машине происходит сбой или компрометация, это не влияет напрямую на хостовую систему или другие виртуальные машины.
Ну это опрометчивое утверждение. Как показали уязвимости Spectre и Meltdown, протечки из виртуальной машины в другие машины или хостовую систему вполне возможны. Так что в первую очередь виртуальные машины нужны, когда нам нужно запустить приложение на принципиально ином ядре операционной системы.
xitriy87
05.11.2024 12:53Ну так очевидно, что виртуализация не сможет обеспечить полной изоляции. Процессор так пробрасывается в вм, его нельзя эмулировать. Но с ней явно изоляция больше чем с контейнерами. Kata containers не зря же появилось.
cdnnow_writer
05.11.2024 12:53Против лома нет приёма, против социальной инженерии или уязвимости на уровне перефирии, к примеру взлома удалённого доступа к KVM(который для доступа к серверам, а не который виртуальная машина), виртуалки тоже не защитят.
Да и Spectre с Meltdown исправили в новых моделях процессоров.
alex-khv
05.11.2024 12:53Не надо забывать что существует также виртуализация процессора. Полностью программная. Так что иногда нужно запустить приложение на принципиально другой архитектуре. Не всё в ограничивается запуском другой ОС.
cdnnow_writer
05.11.2024 12:53Виртуализация процессора это уже эмуляция, а не виртуализация.
Либо слой трансляции, но это тоже не синоним эмуляции, так как там нету цели имитации конкретной модели процессора.
Ava256
05.11.2024 12:53Картинки конечно красивые, но статья ни о чем. Чисто клиебейтный заголовок. И где вы в ESXi ядро Linux увидели? Там только совместимость для драйверов была.
cdnnow_writer
05.11.2024 12:53Картинки конечно красивые, но статья ни о чем. Чисто клиебейтный заголовок.
С учётом того что люди активно путают эти два понятия, вынужден не согласиться.
И где вы в ESXi ядро Linux увидели?
Увидели не мы, а разработчики ядра, которые с VMware судятся последние лет 10 кажется.
https://www.theregister.com/2015/03/05/vmware_sued_for_gpl_violation_by_linux_kernel_developer/https://sfconservancy.org/news/2019/apr/02/vmware-no-appeal/
И немного в сторону из совсем свежего, для VMware Workstation они теперь используют KVM в качестве гипервизора.
https://www.heise.de/en/news/VMware-makes-a-splash-KVM-instead-of-proprietary-hypervisor-10001742.htmlAva256
05.11.2024 12:53Ядро Linux и части кода из ядра Linux - это все же разные вещи.Что раздувать-то? ) А то что они переводят workstation на kvm это вообще к чему? Он еще и бесплатный теперь будет для частных пользователей.Это же не доказывает ничего.
cdnnow_writer
05.11.2024 12:53Это лишь вершина айсберга из 10 лет разбирательств, ядро ESXi всегда считалось Linux-подобным, а эти подозрения и разбирательства могут указывать на то, что это вовсе просто его форк.
Что раздувать-то? )
Потому что на рынке принято защищать свою интеллектуальную собственность, особенно если у тебя её использует практически монополист рынка виртуализации и не делает тебе многомиллионных отчислений за это.
kvm это вообще к чему?
К теме моего поста и обсуждения VMware в целом, я же написал в самом начале "И немного в сторону", указав, что это не относится напрямую к ветке обсуждения.
Al_Tar
05.11.2024 12:53Эти ссылки - точно не доказательство, что esx = linux. Судебная : обычная практика по вытаскиванию на свет Божий закрытой инфы о конкурирующей технологии в процессе суда. KVM для VMW Workstation: Broadcom не хочет тратить деньги на бесплатный продукт, пытается перейти на opensource хоть в чем-то малом( VMW Workstation для Win смогут на KVM перевести? Гарантируют полностью аналогичное функционирование после перехода на KVM одной и той же ВМ и в Win , и в Lin, и в ESX, и в Mac Workstation'ах? Сейчас то просто скопировал OVA и вперёд!).
Да(как намек), слой Linux совместимости в FreeBSD ее тоже Линуксом делает?
cdnnow_writer
05.11.2024 12:53Эти ссылки - точно не доказательство, что esx = linux.
Нет, но за 10 лет там накопились далеко не только эти ссылки.
KVM для VMW Workstation: Broadcom не хочет тратить деньги на бесплатный продукт, пытается перейти на opensource хоть в чем-то малом( VMW Workstation для Win смогут на KVM перевести?
Как я уже упомянул выше, это не аргумент в сторону того что VMware стащили ядро Linux для ESXi, это упоминание другого интересного мне инфоповода, в контексте обсуждения VMware вообще, а не конкретно этого судебно дела.
Да(как намек), слой Linux совместимости в FreeBSD ее тоже Линуксом делает?
И то, и то продукты с открытым исходным кодом, их лицензии позволяют копировать друг друга на все 100%. ESXi - закрытый, проприетарный продукт. Продукт от компании которая практически монополист на рынке виртуализации. И если когда-нибудь эти судебные дела продолжатся и будет подтверждено, что ядро ESXi это просто форк Linux, то тем самым они нарушили лицензию и хотели сэкономить на отчислениях за это.
navion
05.11.2024 12:53Насколько я понимаю, это вольная интерпретация Systems Performance, где используется термин OS Virtualization и объясняется почему:
In the Linux kernel there is no notion of a container. There are, however, namespaces and cgroups, which user-space software (for example, Docker) uses to create what it calls containers.
А про контейнеры есть прекрасная статья в блоге ГПБ.
lambda_tmn
05.11.2024 12:53Благодарность автору, для начинающих и мало понимающих полезная информация. Лично давненько освоил виртуализацию, но не как не могу начать пользовать контейнеризацию. Я понимаю так что wine в Linux это тоже своего рода контейнер.?
RolexStrider
05.11.2024 12:53Ни то, ни другое. Если сравнивать с Windows - то это ближе к Cygwin/MSYS - транслятор вызовов POSIX в WinAPI. В них правда формат бинарников родной для Windows.
cdnnow_writer
05.11.2024 12:53Wine это совсем другая история, это слой совместимости. Если говорить в общем, то он конвертирует системные вызовы на уровне процессора характерные для Windows в аналогичные для Linux.
d00m911
05.11.2024 12:53Ну, если Docker выполняет линукс под wsl, то там вполне себе виртуальзация, используется hyper-v, но это более или менее очевидно, конечно.
Acidter
05.11.2024 12:53Речь же не о матрёшках, а о самих технологиях. Можно в Linux запустить Windows, в котором запустить wsl с Docker и говорить о двойной виртуализации, но зачем.
slonopotamus
05.11.2024 12:53Точно можно? Или окажется что нет поддержки nested virtualization?
michsh
05.11.2024 12:53В Hyper-V точно можно включить nested virtualization для VM через PowerShell.
Вот так вот: Set-VMProcessor -VMName MyVM -ExposeVirtualizationExtensions $true
А вот для WSL - не знаю.
leon-mbs
05.11.2024 12:53ну для поколенияну для поколения тик тока вообще проблема связать три слова грамотным техническим языком. посему статья полезная
andmerk93
05.11.2024 12:53А виртуальные машины в языках программирования - это виртуализация или контейнеризация?
Vad344
05.11.2024 12:53Виртуализация ...Если в одной виртуальной машине происходит сбой или компрометация, это не влияет напрямую на хостовую систему или другие виртуальные машины.
...
Контейнеры же ...как квартиры в многоэтажном доме... Если происходит проблема с фундаментом, страдают все жильцы.
А если страдает хост - система ("фундамент", ага), то гостевым виртуалкам пофиг, что ли, "жильцы" не пострадают? :)
...а сбой в одном контейнере влечет крах операционки и/или других контейнеров?
Какая сложная система классификаци!
"...если они в самом деле едят яйца, значит, они тоже змеи, только другой породы – вот и все!" - (с).
Zara6502
05.11.2024 12:53Мне кажется любое количество статей по этой теме не изменит соотношения тех кто это понимает и тех кто не понимает. Я в ИТ среде вроде умным мужикам всё это объясняю уже лет 10 - не понимают.
Вообще мне кажется основная проблема в том, что термин "виртуализация ОС" и "виртуальный", уже применительно к чему-то в другой или смежной области, засовывают в тождественные, отсюда и глупое кудахтанье.
Я всегда объясняю так:
Виртуализация ОС - это симуляция работы ХОСТ системы на хост системе;
Контейнеризация - это симуляция программного окружения.
itGuevara
05.11.2024 12:53А виртуализация — для создания полноценных изолированных окружений, когда из одного физического сервера нужно получить несколько независимых.
Виртуализация высоконагруженных серверов, включая СУБД, где единственная гостевая ОС (миграция и т.п.), – не подходит под это определение.
Victor64
05.11.2024 12:53А, так когда я у себя в windows делаю контейнер с ubuntu, это всё подхватывает свою файловую систему и работает на ядре windows?
Или когда на маке с arm запускаю ту же обычную ubuntu - она так и работает с arm ядром?
А простейший кейс, запуск контейнеров под линуксом на x86-64 машине, у меня пока не возникал. Линуксы не приживаются.
alex-khv
05.11.2024 12:53Докер. Это только Линукс. И нативно он работает только в Линуксе. Для запуска в других ОС докер контейнеров, всегда нужна виртуальная машина с линуксом.
Так что в этом случае без виртуализации не возможно использовать контейнеризацию.
cdnnow_writer
05.11.2024 12:53Есть ещё нативные Docker-контейнеры для Windows-сервера, но меня терзают сомнения о том как много людей знает об их существование, и какой процент из знающих их использует.
alex-khv
05.11.2024 12:53Не существует нативных docker контейнеров для windows. существуют windows контейнеры.
Это разные виды контейнеров. Docker container только для linux, windows container только для windows.
Другими словами контейнеры - это упаковка приложений и их изоляция друг от друга и от хоста. Один для linux приложений и другой для windows.
Нельзя на чистом linux запустить windows приложение, и наоборот.
Чтобы это сделать надо прибегать к помощи wine или wsl 1.
cdnnow_writer
05.11.2024 12:53Эм, контейнеры для которых портировали под Windows Server runc и которые запускаются не через виртуалку WSL по определению нативные. То что они не совместимы с Docker для Linux, и наоборот, уже другая история.
kekslop
05.11.2024 12:53Схемы прямиком из клода
Надеюсь текст не от туда)))
cdnnow_writer
05.11.2024 12:53UML-схемы он на удивление хорошо генерирует по примеру из имеющихся изображений, которые как правило в низком разрешение. С учётом того что я не дизайнер, получилось не хуже, чем если бы я вручную это всё делал в draw.io, да и быстрее, чем если бы сам копировал с картинки в mermaid.js.
Pyth0nic
05.11.2024 12:53Статья полный бред. Контейнеры это изоляция окружения, аппаратная виртуализация- это изоляция ресурсов, и то и другое виртуализация. Все перепутано, просто каша. Архитектура x86 тоже виртуализирована, современные процессоры давно ушли от от архитектуры х86 и давно ее эммулируют.
Виртуализация - предоставление набора вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации, и обеспечивающее при этом логическую изоляцию друг от друга вычислительных процессов, выполняемых на одном физическом ресурсе.
LuchS-lynx
ок, а как правильно тогда назвать virt-manager установленный в docker? Виртуализацией или контейнеризацией?
PetyaUmniy
Это программа реализующая UI для libvirt. Она не имеет отношения ни к первому, ни ко второму.
cdnnow_writer
Как уже отметили, это пользовательский интерфейс для взаимодействия с виртуальными машинами. Docker тут как и в ряде других случаев будет выступать просто инструментом для установки его.
thesunlight17
А зачем virt-manager устанавливать и запускать в докер контейнере? В каких случаях это может потребоваться?