Как Microsoft стирает границы между виртуальными машинами и контейнерами

Hyper-V от Microsoft был представлен вместе с Windows Server 2008 в качестве платформы для размещения виртуальных машин. С момента своего скромного начала Hyper-V развивалась таким образом, что тогда никто не мог предсказать. Одно из крупнейших архитектурных изменений Hyper-V произошло, когда Microsoft предоставила Hyper-V возможность выступать в качестве узла контейнера.

Виртуальные машины против контейнеров

Хотя Hyper-V может размещать как контейнеры, так и виртуальные машины, они не могут быть более разными. Виртуальные машины — это всего лишь виртуальное представление физического компьютера. Как и физическая машина, виртуальная машина имеет собственную операционную систему.

Кроме того, виртуальная машина полностью изолирована от других виртуальных машин, которые могут работать на узле. Если проблема (например, ошибка «Синий экран смерти») возникает на виртуальной машине, эта проблема обычно не влияет на соседние виртуальные машины, поскольку каждая виртуальная машина действует независимо.

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

Контейнеры, работающие на хосте, обычно используют общий базовый образ. Базовый образ содержит операционную систему, от которой зависят контейнерные приложения. Сами контейнеры хранят двоичные файлы приложений и связанные с ними зависимости, такие как записи реестра или файлы DLL, которые необходимы для запуска приложения. Поскольку контейнеры не включают в себя операционную систему, они, как правило, намного меньше по размеру, чем виртуальные машины (часто размером всего в мегабайты), а также легко переносимы. Контейнерное приложение можно легко перенести из лабораторной среды в производственную среду или из локальной среды в облако.

Почему границы между виртуальными машинами и контейнерами стираются

В предыдущем разделе я хотел подчеркнуть, что контейнеры и виртуальные машины очень сильно отличаются друг от друга. Несмотря на то, что Hyper-V может размещать как виртуальные машины, так и контейнеры, между ними существуют серьезные архитектурные различия, и контейнеры служат совершенно другим целям, чем виртуальные машины.

Но что, если бы можно было использовать архитектуру контейнеров Hyper-V для преимуществ виртуальных машин? Это именно то, что Microsoft сделала по крайней мере с одной утилитой. Корпорации Майкрософт удалось использовать архитектуру контейнеров Hyper-V для добавления новых функций и возможностей в виртуальные машины Hyper-V. Если вы не видели эти новые функции, возможно, это потому, что они не доступны через диспетчер Hyper-V и не доступны через Windows PowerShell.

Одной из новых возможностей базовой инфраструктуры контейнеров является возможность организации виртуальных машин Hyper-V в группы ЦП. Группы ЦП — это, по сути, наборы виртуальных машин Hyper-V, которые имеют схожие требования к ЦП или которые необходимо коллективно регулировать, чтобы ограничить загрузку ЦП. Всестороннее обсуждение групп ЦП выходит за рамки этой статьи, но важный вывод заключается в том, что, хотя функция групп ЦП предназначена для использования с виртуальными машинами Hyper-V, она полностью зависит от архитектуры контейнера. Позволь мне объяснить.

Знакомство со службой Host Compute Service

Решение Microsoft о поддержке контейнеров в Windows Server столкнулось с некоторыми серьезными архитектурными проблемами. Одной из таких проблем был тот факт, что контейнеры Docker уже давно существуют и широко используются. Таким образом, Microsoft пришлось построить свою экосистему контейнеров, чтобы работать с тем, что уже было на месте. Это означало поддержку существующих команд и компонентов Docker.

Вторая проблема, с которой столкнулась Microsoft, заключалась в том, что контейнеры Docker были разработаны для использования в средах с открытым исходным кодом. Docker был создан для Linux и никогда не предназначался для работы на Windows Server. Таким образом, Microsoft пришлось придумать способ заставить контейнеры Docker изначально работать в операционной системе Windows Server, но без изменения архитектуры контейнера в процессе (в противном случае контейнеры могут перестать быть переносимыми).

Решение Microsoft для этих и других проблем заключалось в разработке API, который компания называет Host Compute Service или HCS. Host Compute Service — это то, что позволяет Docker Engine и компонентам Docker, таким как libvontainerd, libnetwork, graph и подключаемые модули, работать с операционной системой Windows.

Хотя можно совершать прямые вызовы к Host Compute Service, Microsoft создала несколько оболочек, упрощающих использование API. Одной из таких оболочек является оболочка виртуализации dotnet-compute, которую можно загрузить с GitHub. Вы можете использовать эту оболочку для создания контейнеров, а будущие версии также позволят создавать виртуальные машины.

Вторая оболочка под названием hcssim также доступна на GitHub. Эта оболочка написана на Go и включает интерфейс Golang, который используется при запуске контейнеров Docker.

Итак, как насчет тех новых функций и возможностей виртуальных машин, о которых я говорил ранее? Как упоминалось ранее, Microsoft сделала так, что вы можете создавать группы ЦП для виртуальных машин, но эта возможность не предоставляется через диспетчер Hyper-V или через PowerShell. Насколько мне известно, он также не отображается через System Center Virtual Machine Manager.

Вместо того, чтобы открывать группы ЦП через любой из обычных интерфейсов управления, Microsoft создала автономный инструмент командной строки под названием CpuGroups.exe. Поскольку группировка ЦП может быть выполнена только с помощью Host Compute Service, этот инструмент командной строки предположительно выполняет вызовы непосредственно к HCS API.

Новый системный центр?

На данный момент доступно не так много информации об утилитах виртуальных машин Hyper-V, основанных на HCS API. Вполне возможно, что CpuGroups.exe — первый такой инструмент. Однако со временем я ожидаю, что это изменится. Я ожидаю, что со временем Microsoft в конце концов создаст новый инструмент System Center, который будет действовать как единая стеклянная панель, объединяющая Virtual Machine Manager и Kubernetes. Такой инструмент позволит параллельно управлять как виртуальными машинами, так и контейнерами. Поскольку у этого типа инструментов не будет иного выбора, кроме как выполнять вызовы HCS API, Microsoft, вероятно, будет легко включить дополнительные возможности виртуальных машин с помощью аналогичных вызовов API.