Хватит называть контейнеризацию виртуализацией
Привет, Хабр! Меня зовут Матвей Мочалов, я — компьютерный инженер и один из авторов корпоративного блога 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 и подобные технологии сделали контейнеризацию доступной и удобной, предоставляя инструменты для управления контейнерами и их образами.
Однако важно понимать, что контейнеры не создают полноценной изоляции на уровне ядра. Они больше похожи на отдельные процессы, запущенные в изолированных пространствах имён с ограниченными ресурсами. Это значит, что если в ядре системы есть уязвимость, она потенциально может быть использована для выхода из контейнера и воздействия на хостовую систему или другие контейнеры.
Почему это важно?
Разница между виртуализацией и контейнеризацией имеет практические последствия для безопасности, производительности и совместимости.
Виртуализация создаёт полноценное виртуальное окружение. Каждая виртуальная машина получает виртуальный набор аппаратных ресурсов: свой процессор, память, диски, сетевые интерфейсы. И главное — своё ядро операционной системы. Это обеспечивает высокую степень изоляции. Если в одной виртуальной машине происходит сбой или компрометация, это не влияет напрямую на хостовую систему или другие виртуальные машины.
Контейнеры же все работают на одном общем ядре. Они могут иметь свои файловые системы, библиотеки, приложения, но ядро системы у них общее. Это как квартиры в многоэтажном доме: у каждого своя планировка и мебель, но фундамент и коммуникации общие. Если происходит проблема с фундаментом, страдают все жильцы.
И что теперь?
Для начала нужно перестать сравнивать эти технологии, как конкурирующие решения. Контейнеры и виртуализация решают разные задачи: контейнеры нужны для упаковки приложений со всеми зависимостями, чтобы не загрязнять основную систему и обеспечить переносимость приложения. А виртуализация — для создания полноценных изолированных окружений, когда из одного физического сервера нужно получить несколько независимых.
Виртуализация нужна там, где требуется полная изоляция, где нужны разные операционные системы или их версии, где безопасность и совместимость важнее производительности. Виртуальные машины позволяют запускать совершенно разные среды на одном физическом сервере, обеспечивая высокий уровень изоляции и гибкости.
Если говорить проще, весь мировой хостинг работает на виртуалках, потому что это позволяет из одного сервера сделать десятки независимых. А контейнеры используются разработчиками, чтобы их приложение со всеми библиотеками и зависимостями гарантированно запустилось у заказчика точно так же, как и на их машине.
Архитектура виртуализации на гипервизоре KVM и эмуляторе QEMU
Сравнивать виртуализацию и контейнеризацию как нечто равнозначное или утверждать будто они друг с другом конкурируют — это как путать упаковку продуктов в контейнеры с разделением супермаркета на отделы. Вроде и то, и другое про организацию, но задачи решают совершенно разные.
Заключение
В IT часто возникают ситуации, когда модные слова и маркетинговые термины затмевают реальную суть технологий. Контейнеры и виртуализация — яркий пример такого смешения понятий. Понимая фундаментальные различия между ними, мы можем более осознанно выбирать инструменты для решения конкретных задач, избегая ненужных сложностей и оптимизируя ресурсы.
Давайте называть вещи своими именами и использовать технологии там, где они действительно уместны. Это позволит создавать более эффективные, надёжные и производительные системы.
А вы сталкивались с подменой этих понятий? К каким последствиям это приводило в ваших проектах? Возможно, у вас есть интересные истории о том, как неправильное понимание технологий приводило к неожиданным результатам или проблемам. Буду ждать всех в комментариях!
