Windows-контейнеры на Red Hat OpenShift
В конце прошлого года Red Hat OpenShift получила общедоступную версию функционала Windows Container Support, позволяющего включать в состав кластера OpenShift Container Platform узлы Windows Compute Node, чтобы запускать на них рабочие нагрузки в виде Windows-контейнеров и управлять этими контейнерами точно так же, как и Linux-контейнерами. Сегодня расскажем об этом чуть подробнее.
(Очень) краткая история Windows-контейнеров
В 2016 году Microsoft решила разработать свой контейнерный движок, реализующий спецификацию Docker, чтобы Windows-контейнеры можно было запускать с помощью привычных инструментов, например, так:
docker run -it microsoft/windowsservercore cmdВ итоге, Microsoft создала две реализации Windows-контейнеров:
Процесс-контейнеры (они же Windows Server Containers, WSC);
Контейнеры Hyper-V.
Разница между ними хорошо описывается, например, в здесь (EN) или в документации Microsoft.
Обратите внимание, что в этом посте мы говорим только о контейнерах WSC. Высокоуровневая архитектура Windows Containers выглядит следующим образом:
Ограничения Windows-контейнеров
Размер Windows-образа – по сравнению с Linux, он гораздо больше. Впрочем, размер можно уменьшить за счет использования урезанного серверного ядра Nano вместо Windows Server Core, но тогда вы лишаетесь и ряда возможностей, например, вместо PowerShell придется довольствоваться PowerShell Core на основе .NET Core.
GUI-приложения – многие Windows-приложения пишутся в расчете на UI, но в рамках контейнеризации эта парадигма не поддерживается.
Ограничения по выбору версий Windows Server. Windows-контейнеры без проблем могут совместно использовать ядро Windows, но вам не удастся полностью изолировать приложение от системных служб и DLL. Поэтому при запуске контейнерных нагрузок вы ограничены той версией, что стоит на нижележащем Windows-узле. Для Linux-контейнеров такого ограничения нет.
Зачем нужна контейнеризация традиционных Windows-приложений
Возможность ускорить переход на публичные и гибридные облака. Windows Server занимает существенную долю на рынке серверных ОС, а C# является одним из шести ведущих языков программирования. Контейнеры позволяют значительно ускорить перевод приложений Windows Server в публичное облако.
Сокращение расходов на инфраструктуру и управление Windows-приложениями. Зачем развертывать полноценную виртуальную машину (ВМ) для Microsoft SQL или сервера IIS, если можно обойтись небольшими и легковесными контейнерами? Контейнеры не только позволяют разместить больше нагрузок на одном сервере, но и могут легко перемещаться в средах bare metal, а также в публичных, частных и гибридных облаках, включая мультиоблачные среды.
Больше переносимости, agility и управляемости для Windows-приложений. Благодаря лучшей ресурсоемкости и переносимости контейнеры – это очень привлекательный способ упаковки и доставки приложений. Вместо того, чтобы создавать для каждого приложения отдельную ВМ и создавать в ней весь стек ПО, включая ОС, Windows-контейнеры нескольких приложений можно «повесить» на один и тот же экземпляр Windows. При таком подходе приложения можно создавать в Visual Studio или Visual Studio Code, контейнеризировать и затем запускать везде: в средах OpenShift on premises, а также на платформе OpenShift в облаке Azure или AWS.
Сценарии использования Windows-нагрузок на платформе OpenShift
Следуя 5R-подходу к миграции приложений в облако (Rehost, Refactor, Revise, Rebuild и Replace), сформулированному компанией Gartner, можно выделить следующие сценарии использования Windows-нагрузок на платформе OpenShift:
Этап 5R | Задействуемые функции OpenShift | Сценарий использования | Преимущества | Недостатки |
Rehost | OpenShift Virtualization | Перенос ВМ Windows в OpenShift | Самый простой путь, вызывает наименьшее сопротивление | Дает минимум преимуществ контейнеризации |
Refactor | Windows Machine Config Operator | Контейнеризация традиционных приложений .Net framework на Windows Server Containers с последующим развертыванием на узлах Windows Worker Node в OpenShift | Многие, но не все выгоды контейнеризации и OpenShift | Экосистема Windows-контейнеров поддерживается только на Windows Server 2019 и выше |
Rearchitect | Контейнеры RHEL/Red Hat CoreOS | Миграция традиционных приложений.Net framework на to .Net Core с последующим развертыванием на RHEL-контейнерах в OpenShift | Все выгоды контейнеризации и OpenShift, а также плюсы быстро развивающегося сообщества | Длительный и трудоемкий способ миграции |
Rebuild | Контейнеры RHEL/Red Hat CoreOS | Создание изначально облачных приложений на базе Linux-контейнеров с последующим развертыванием на RHEL-контейнерах в OpenShift | Все выгоды контейнеризации и OpenShift, а также плюсы быстро развивающегося сообщества | Разработка приложений с нуля подходит далеко не всем, поскольку многие лишь эксплуатируют готовое ПО |
Что такое Windows Machine Config Operator (WMCO)
Оператор WMCO – это отправная точка для запуска рабочих нагрузок Windows в кластере OpenShift. Именно он позволяет администратору кластера добавлять в кластер узлы Windows worker node и активировать диспетчеризацию (scheduling) Windows-нагрузок. Для WMCO требуется OpenShift 4.6 и выше с настроенной гибридной сетью OVN Kubernetes.
Платформы, поддерживаемые WMCO
Платформа | Уже поддерживается | Скоро будет |
Red Hat OpenShift Container Platform (OCP) on Azure | Да |
|
OCP on AWS | Да |
|
OCP on vSphere |
| |
OCP on Bare metal | Нет | Да |
OCP on Red Hat Virtualization | Нет | Да |
OCP on Red Hat OpenStack Platform | Нет | Да |
Управляемые сервисы OpenShift (Azure Red Hat OpenShift, OpenShift Dedicated итд) | Нет | Да |
Операционные системы, которые могут использоваться в качестве Windows Worker Node
Первоначальный релиз WMCO поддерживает Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019 (версия 10.0.17763.1457 и выше).
Как устроена работа с Windows-нагрузками
Для запуска Windows-нагрузок в кластере OpenShift сначала надо проинсталлировать WMCO, который представляет собой Linux-оператор, работающий на Linux-узлах Control Plane и Compute, и оркестрирующий процессы развертывания и управления Windows-нагрузками в кластере.
Затем надо присоединить к кластеру узел Windows Compute Node, на котором и будут хоститься Windows-нагрузки. Windows Compute Node создается путем создания набора MachineSet для машин Windows Server. К этому набору надо применить специальную метку (label) с указанием образа ОС Windows с установленной средой выполнения Docker-контейнеров (Kubernetes отказался от Docker как среды выполнения и в будущих версиях Kubernetes для Windows-узлов будет использоваться Containerd).
WMCO следит за машинами с Windows-меткой и как только будет создан набор Windows MachineSet и появятся указанные в нем машины, WMCO сконфигурирует нижележащую ВМ Windows, чтобы ее можно было присоединить к кластеру в качестве Compute Node.
WMCO рассчитывает, что в его пространстве имен есть некий заранее заданный секрет с закрытым ключом для взаимодействия с экземпляром Windows. WMCO проверяет этот секрет при загрузке и создает объект user data secret, на который должен ссылаться созданный вами Windows MachineSet. Затем WMCO заполняет user data secret открытым ключом, который соответствует закрытому ключу. Имея эти данные, кластер может подключаться к ВМ Windows по SSH.
После того, как кластер установит соединение с ВМ, Windows-узлом можно управлять точно так же, как и узлами Linux, а диспетчеризация Windows-нагрузок ведется аналогично, через taints, tolerations и node selectors. Для разграничения контейнерных нагрузок Windows и Linux, а также Windows-нагрузок на различных версиях Windows надо использовать объекты RuntimeClass.
Подробнее про установку и настройку WMCO, работу с Windows-контейнерами на различных платформах, а также про обновление WMCO можно прочитать в документации.
Логи Windows-контейнеров
Возможность просмотра логов важна как для отладки, так и в целях безопасности, например, для того, чтобы отследить вредоносные события или утечки секретов. Для Windows-контейнеров Windows в OpenShift доступные следующие логи:
● C:\var\log\kube-proxy\kube-proxy.exe.INFO
● C:\var\log\kube-proxy\kube-proxy.exe.ERROR
● C:\var\log\kube-proxy\kube-proxy.exe.WARNING
● C:\var\log\hybrid-overlay\hybrid-overlay.log
● C:\var\log\kubelet\kubelet.log
● %APPDATA%\Local\Docker\log.txt
Просматривать логи кластера OpenShift Container Platform для Windows-pod’ов можно из командной строки:
$ oc logs -f windows-pod-name -n openshift-windowsС помощью инструмента must-gather можно собирать следующие логи:
Просмотр логов для Windows-pod’ов из веб-консоли OpenShift Container Platform пока не поддерживается.
