[Open source, Виртуализация, Разработка под Windows, Openshift] Windows-контейнеры на Red Hat OpenShift

Автор Сообщение
news_bot ®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
04-Мар-2021 17:30

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Сценарий использованияПреимуществаНедостаткиRehostOpenShift VirtualizationПеренос ВМ Windows в OpenShiftСамый простой путь, вызывает наименьшее сопротивлениеДает минимум преимуществ контейнеризацииRefactorWindows 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Да (со 2го марта) 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 пока не поддерживается.
===========
Источник:
habr.com
===========

Похожие новости: Теги для поиска: #_open_source, #_virtualizatsija (Виртуализация), #_razrabotka_pod_windows (Разработка под Windows), #_openshift, #_red_hat, #_open_source, #_openshift, #_windows, #_containers, #_visual_studio, #_azure, #_aws, #_.net, #_rhel, #_blog_kompanii_red_hat (
Блог компании Red Hat
)
, #_open_source, #_virtualizatsija (
Виртуализация
)
, #_razrabotka_pod_windows (
Разработка под Windows
)
, #_openshift
Профиль  ЛС 
Показать сообщения:     

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 03:20
Часовой пояс: UTC + 5