Привет, Хабр! Меня зовут Матвей Мочалов, я — компьютерный инженер и один из авторов корпоративного блога 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 часто возникают ситуации, когда модные слова и маркетинговые термины затмевают реальную суть технологий. Контейнеры и виртуализация — яркий пример такого смешения понятий. Понимая фундаментальные различия между ними, мы можем более осознанно выбирать инструменты для решения конкретных задач, избегая ненужных сложностей и оптимизируя ресурсы.
Давайте называть вещи своими именами и использовать технологии там, где они действительно уместны. Это позволит создавать более эффективные, надёжные и производительные системы.
А вы сталкивались с подменой этих понятий? К каким последствиям это приводило в ваших проектах? Возможно, у вас есть интересные истории о том, как неправильное понимание технологий приводило к неожиданным результатам или проблемам. Буду ждать всех в комментариях!
Комментарии (10)
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 исправили в новых моделях процессоров.
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 это вообще к чему? Он еще и бесплатный теперь будет для частных пользователей.Это же не доказывает ничего.
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.
А про контейнеры есть прекрасная статья в блоге ГПБ.
LuchS-lynx
ок, а как правильно тогда назвать virt-manager установленный в docker? Виртуализацией или контейнеризацией?
PetyaUmniy
Это программа реализующая UI для libvirt. Она не имеет отношения ни к первому, ни ко второму.
cdnnow_writer
Как уже отметили, это пользовательский интерфейс для взаимодействия с виртуальными машинами. Docker тут как и в ряде других случаев будет выступать просто инструментом для установки его.