Контейнеры Windows и Hyper-V в Windows Server 2016

Опубликовано: 18 Апреля, 2023

Фон

Если вы какое-то время работали в сфере ИТ, то знаете, что в технологии контейнеров нет ничего нового. Однако в последнее время он, возможно, больше использовался в средах Linux. ИТ-специалисты, работающие с инфраструктурами Windows, заново открывают для себя эту технологию благодаря выпускам продуктов таких компаний, как Docker и Microsoft. С выпуском Windows Server 2016 Microsoft предоставляет реализацию контейнеров с именами Windows Server Containers и Hyper-V Containers, а также делает эту технологию доступной в Microsoft Azure.

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

Виртуализация операционной системы

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

Изображение 14799
Рис. 1.
Базовая архитектура виртуализации на уровне операционной системы

Этот метод приводит к очень низким затратам на виртуализацию и может обеспечить высокую плотность разделов. Однако у этого типа решения есть ограничения. Основным ограничением является невозможность запуска разнородного набора операционных систем на данном сервере, поскольку все разделы совместно используют одно ядро операционной системы. Кроме того, любое обновление ядра операционной системы влияет на все виртуальные среды. По этим причинам виртуализация на уровне операционной системы, как правило, лучше всего работает в средах с однородными рабочими нагрузками. Возможно, вы помните продукт под названием Virtuozzo Containers от Parallels, основанный на виртуализации на уровне операционной системы. Контейнеры Virtuozzo были широко приняты и развернуты индустрией веб-хостинга для создания инфраструктур высокой плотности, предлагающих изолированные веб-сервисы.

Контейнеры Windows

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

При создании контейнера Windows вы создаете экземпляр изолированной песочницы поверх операционной системы Windows Server 2016. Концептуально вы можете думать о хост-операционной системе Windows Server 2016 как о базовом образе, доступном только для чтения. Создаваемый вами новый контейнер Windows будет содержать внесенные вами изменения, такие как установка нового приложения и его зависимостей или изменение параметров. Базовый образ операционной системы хоста Windows Server 2016 не изменяется. Однако вы можете сохранить новую среду контейнера Windows как новый образ и сохранить его в репозитории образов. Большим преимуществом этих образов является то, что они, как правило, намного меньше по размеру, чем образ на основе VHD, потому что вместо всей виртуальной машины с гостевой операционной системой и приложениями хранятся только модификации на основе файлов. Образ контейнера Windows, созданный на определенном узле Windows Server 2016, можно развернуть в любом другом контейнере Windows Server 2016 и даже на виртуальной машине, если для конкретной рабочей нагрузки требуется более высокий уровень изоляции. Однако нет необходимости сохранять контейнер Windows как новый образ, что позволяет создавать временные контейнеры Windows, которые можно легко уничтожить без сохранения какого-либо содержимого.

Контейнеры Hyper-V

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

При этом образы контейнеров Windows можно развертывать как в контейнерах Windows, так и в контейнерах Hyper-V без каких-либо изменений, просто установив флаг определенного типа среды выполнения при создании нового контейнера. Это позволяет быстро развертывать приложение и его зависимости в любом типе контейнера, а также обеспечивает гибкость изменения степени изоляции по мере изменения требований для конкретного приложения.

Конфигурация сети контейнеров Windows

Контейнеры Windows обеспечивают гибкость доступа к вашим приложениям в сети двумя разными способами. Контейнеру можно настроить доступный извне IP-адрес с помощью DHCP или получить IP-адрес от хоста контейнера с помощью преобразования сетевых адресов (NAT). Если вы решите назначить внешний IP-адрес контейнеру Windows с помощью DHCP, контейнер будет обмениваться данными в сети, используя свой собственный MAC-адрес. Эта конфигурация требует подмены MAC-адреса. Вы должны выбрать этот вариант назначения IP-адреса, если вам требуется, чтобы каждый контейнер Windows имел маршрутизируемый адрес в вашей сети.

Используя NAT, узел контейнера назначает частный IP-адрес контейнеру Windows, а указанный порт контейнера Windows сопоставляется с портом на узле контейнера. Приложение, работающее в контейнере, доступно для внешних клиентов, если указать комбинацию IP-адреса и порта на узле контейнера. Узел контейнера перенаправляет сетевой трафик в конечный контейнер Windows, используя внутреннюю таблицу NAT, которая сопоставляет порт узла контейнера с парой адреса NAT и номера порта контейнера Windows. Вам следует выбрать этот вариант назначения IP-адреса, если вы собираетесь развернуть большое количество контейнеров и не требуете или не хотите управлять большим количеством маршрутизируемых IP-адресов.

Использование контейнеров Windows и Hyper-V на физическом хосте

Как видно на рис. 2, Microsoft предоставила вам возможность создавать и использовать контейнеры Windows и Hyper-V на одном физическом хосте, если это необходимо. В этом примере роль Hyper-V включена на физическом узле. В родительском разделе вы можете развертывать контейнеры Windows, каждый из которых имеет собственное абстрактное представление операционной системы хоста. Кроме того, вы также можете создать одну или несколько виртуальных машин или дочерних разделов, каждый со своей собственной гостевой операционной системой, в которой вы можете развернуть контейнеры Hyper-V. Каждая гостевая ОС виртуальной машины должна по-прежнему представлять собой разновидность Windows Server 2016, например конфигурацию Server Core или Nano Server. В то время как контейнеры Windows совместно используют операционную систему хоста в качестве своего базового образа, контейнеры Hyper-V, работающие на той же виртуальной машине, совместно используют гостевую операционную систему в качестве своего базового образа.

Изображение 14800
Рис. 2. Контейнеры Windows и Hyper-V на физическом хосте

Интеграция с докером

План Microsoft состоит в том, чтобы предоставить вам несколько вариантов управления контейнерной средой. Если вы работаете только с Microsoft, вы можете использовать PowerShell и WMI для управления инфраструктурой контейнеров в Windows Server 2016. Однако, чтобы способствовать быстрому внедрению технологии контейнеров, Microsoft также будет поддерживать Docker, широко используемую систему с открытым исходным кодом. в сообществе Linux для упаковки, развертывания и управления контейнерами. Docker позволит вам централизованно управлять контейнерами в инфраструктурах Windows Server 2016 и Linux. Docker по-прежнему не позволит вам развертывать контейнеры Windows в Linux или контейнеры Linux в Windows Server 2016, поскольку операционная система физического хоста используется совместно с контейнерами. Однако у вас будет доступ к Docker Hub, Docker Engine и Docker Client в Windows Server 2016.

Docker Hub — это репозиторий образов, который содержит большую коллекцию образов контейнеров, которые вы можете извлечь для развертывания в своих системах, а также передать образы контейнеров для совместного использования с сообществом Docker. Docker Engine позволит вам создавать, запускать и организовывать контейнеры в Windows Server 2016. Клиент Docker позволит вам использовать тот же интерфейс, что и в среде Linux, для управления контейнерами. С помощью этих двух вариантов управления контейнерами Microsoft надеется удовлетворить потребности ИТ-персонала, работающего в однородных и разнородных средах.

Вывод

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