В Red Hat OpenShift 4.8 появилась общедоступная версия функции Bring Your Own Host для Windows, которая позволяет включать в кластер OpenShift кастомные ноды Windows (так называемые «ноды-питомцы», см. ниже). О чем вообще речь? У многих заказчиков в дата-центрах есть выделенные инстансы Windows-серверов, которые регулярно обновляются, патчатся и сопровождаются. Зачастую эти инстансы работают на платформах vSphere, OpenStack или на «голом железе». Было бы очень неплохо использовать эти сервера для запуска контейнерных нагрузок, сделав их вычислительные мощности частью гибридного облака. Именно эту задачу и решает Bring Your Own Host (BYOH) – берет и переносит on-premises нагрузки в облако.
Аналогия с домашними животными: питомцы и скот
BYOH – это когда вы заводите на OpenShift Windows-инстанс и обращаетесь с ним, как с домашним питомцем, индивидуально, а не через Machine API. А домашний скот – это обезличенные машины в кластере OpenShift, которые управляются строго через Machine API.
Питомцы
Когда домашних животных немного, их легко вырастить и держать дома: свозить к ветеринару на прививки, пока маленькие, а когда подрастут – регулярно кормить, водить на прогулки или менять наполнитель, и, в общем-то, всё – они просто живут в доме и исполняют свою роль. Примерно так же обстоят дела с традиционным виртуальным машинам: вы делает им «прививку» сразу после создания (с помощью Puppet, Chef, Ansible или путем ручного обновления) и затем просто пользуетесь ими. Конечно, если ВМ «заболеет», понадобится вмешательство «ветеринара»: надо будет войти на нее, найти и устранить неполадки, или запустить сценарий обновления. Неважно, делается это вручную или с помощью какой-то автоматизации, все управление всегда осуществляется индивидуально. Проблема в том, что это очень плохо масштабируется. В самом деле, представьте, что у вас дома 2 000 кошек или собак.
Скот
Что касается домашнего скота и птицы, то тут все обстоит совсем иначе. Коров, овец и кур не зря выращивают на фермах, это банально эффективнее. Фермы изначально заточены на большие масштабы. Много земли, особенно при чередовании пастбищ, тракторы, заборы, хранилища кормов, спецтранспорт для перевозки животных и оборудование для переработки того, ради чего они выращиваются. Держать животных на ферме гораздо эффективнее, но и обходится это гораздо дороже по сравнению с домом. Облачные платформы, вроде OpenShift, более похожи на ферму, чем на дом. Запуск облака похож на создание фермы с нуля, здесь нужен четкий план и тщательное выполнение. А после запуска облаку тоже требуется постоянный уход, то есть техническое обслуживание: добавление и удаление хранилищ, уборка подзависших инстансов, добавление и удаление VLAN, расчистка pod-ов, застрявших в состоянии ожидания, возврат на исходные после срабатывания сервисов высокой доступности (Cinder, API-ноды, OSE/Kube Master, Hawkular Metrics), обновление облачной платформы и т.д. и т.п. В общем, как и на ферме, в облаке очень много регулярной работы. Фермы очень эффективны при выращивании тысяч животных. И никто не думает сносить ферму под ноль, когда она перестает работать в оптимальном режиме – вместо этого ее перестраивают. С облаками дела обстоят примерно так же.
Облако – это много работы для тех, кто обеспечивает его работу, и мало работы для тех, кто пользуется его результатами, то есть, для разработчиков. Выращивание куриц в промышленных масштабах – это сложно для фермеров, зато просто для потребителя. А фермеры, в свою очередь, скрывают эту сложность от потребителя.
Windows Machine Config Operator (WMCO) – добавление и удаление Windows-нод
Windows Machine Config Operator (WMCO) – это то, с помощью чего администратор кластера в рамках задач второго дня может добавлять Windows-ноды с заданной конфигурацией в кластер OpenShift (OpenShift Container Platform/OKD) и задействовать при для распределении рабочих нагрузок Windows. Windows-инстансы можно добавлять либо путем создания MachineSet, либо указывая уже существующие инстансы через ConfigMap. И в том, и в другом случае на Windows-инстансе должна быть установлена среда выполнения контейнеров Docker. WMCO производит все настройки инстанса, нужные для того, чтобы он вошел в состав кластера как worker-нода.
Предварительные требования
Перед тем заводить Windows-ноду BYOH в кластер OpenShift, надо обеспечить выполнение ряда условий, причем часть из них можно выполнить только на этапе установки кластера, но – обратите внимание – не потом.
Предварительные требования:
OpenShift 4.8+
Использование OVNKubernetes в качестве SDN (задается на этапе установки)
Настроенная Hybrid-Overlay Networking (задается на этапе установки)
Windows Server 2019 version 2004
Инстанс должен быть в той же сети, что и Linux-овые worker-ноды кластера
Требования к BYOH-инстансу
Требования по Windows Server будут рассмотрены в следующем разделе. Дополнительную информацию о Windows Containers можно найти в официальной документации. Обратите особое внимание на требования к настройке сети, поскольку, как уже отмечалось, их можно выполнить только на этапе установки кластера.
Установка WMCO
После того, как кластер установлен и предварительные требования выполнены, можно приступать к установке Windows Machine Config Operator (WMCO). Для администратора этот оператор является отправной точкой для запуска контейнеризованных Windows-нагрузок на кластерах OpenShift и устанавливается из Operator Hub в рамках задач второго дня.
Для установки WMCO залогинимся на кластер OpenShift как администратор и в панели слева щелкнем Operators -> OperatorHub.
В поле Filter by keyword… введем Windows Machine Config Operator , и затем щелкнем плитку Windows Machine Config Operator.
На открывшейся странице щелкнем кнопку Install.
На открывшейся странице Install Operator в разделе Update channel установим переключатель stable. В секции Installation mode оставим A specific namespace on the cluster. В разделе Installed Namespace оставим Operator recommended Namespace и включим флажок Enable Cluster Monitoring. И наконец, в разделе Approval strategy оставим Automatic и щелкнем Install.
На экране появится страница состояния установки оператора Installing Operator.
Дождемся, пока в ней появится надпись ready for use, которая сигнализирует об успешной установке оператора WMCO.
Убедимся, что оператор успешно установился. Для этого проверим, что выполняется его pod:
$ oc get pods -n openshift-windows-machine-config-operator
NAME READY STATUS RESTARTS AGE
windows-machine-config-operator-749bb9db45-7vzfh 1/1 Running 0 148mПосле установки и запуска WMCO надо будет создать или предоставить ему SSH-ключ. Этот же ключ будет установлен на Windows-ноду, и именно с его помощью WMCO будет настраивать эту ноду для OpenShift. Можно использовать уже существующий SSH-ключ. Если его нет, или вы хотите использовать специальный ключ для Windows-нод, то это можно сделать следующим образом:
$ ssh-keygen -t rsa -f ${HOME}/.ssh/winkey -q -N ''Теперь, когда ключ готов, добавим закрытый ключ в качестве секрета для использования WMCO в пространстве имен openshift-windows-machine-config-operator.
$ oc create secret generic cloud-private-key \
--from-file=private-key.pem=${HOME}/.ssh/winkey \
-n openshift-windows-machine-config-operatorОбратите внимание, что в кластере может быть только одна пара SSH-ключей для всех серверов Windows. Использовать свою пару для каждого Windows-сервера в настоящий момент нельзя.
Дополнительные сведения по установке WMCO см. в документации.
Настройка Windows Server
В таблице ниже перечислены поддерживаемые версии Windows Server для различных облачных платформ. Примечание: любые другие версии Windows Server НЕ ПОДДЕРЖИВАЮТСЯ и попытки их использовать закончатся ошибкой. Поэтому применяйте версии в строгом соответствии с этой таблицей.
Облачная платформа | Поддерживаемая версия Windows Server |
AWS | Windows Server Long-Term Servicing Channel (LTSC): Windows Server 1809 |
Azure | Windows Server Long-Term Servicing Channel (LTSC): Windows Server 1809 |
VMware vSphere | Windows Server Semi-Annual Channel (SAC): Windows Server 2004 |
Использование на платформе Azure Example
Для настройки инстанса Windows-сервера на Azure, надо убедиться, что на нем используется поддерживаемая версия (1809) и этот инстанс находится в одной сети с Linux-овыми worker-нодами кластера.
Выполним вход в Azure и выберем поддерживаемую версию Windows Server
Для простоты можно выбрать ту же Resource Group, в которой создан наш кластер OpenShift. Также надо убедиться, что пространство имен задано символами нижнего регистра.
Теперь настроим учетную запись Администратора и щелкнем Next , чтобы перейти к вкладке Disks.
Выполнив нужные настройки на вкладке Disks, щелкнем Next, чтобы перейти на вкладку Networking. Убедимся, для инстанса Windows-сервера выбрано то же имя vnet, что и для нашего кластера OCP. Также укажем, что этот инстанс находится в подсети worker-subnet. Затем создадим виртуальную машину.
После того, как ВМ создана, идем в Network Security Group и добавляем следующие правила, чтобы разрешить доступ по сети.
Проверяем, что к этой ВМ можно подключиться по RDP и SSH. Обратите внимание, у нее частный IP-адрес.
Использование на платформе AWS
Выполняем вход в AWS EC2 и выбираем поддерживаемую версию Windows Server:
Выбираем ту же Network, что и для кластера OCP, а также подсеть для worker-нод:
После настройки пользовательского хранилища и тегов, настраиваем Security Group:
Проверяем, что для нашей Security Group было создано входящее правило RDP:
Настраиваем наш инстанс на использование пары ключей SSH и затем запускаем его:
Проверяем, что к этой ВМ можно подключиться по RDP и SSH. Обратите внимание, у нее частный IP-адрес.
Использование на платформе vSphere
На vSphere процедура несколько дольше и подробно расписывается здесь (EN).
Подключаем наш Windows Server как ноду OpenShift
Теперь, когда WMCO установлен и наша Windows-нода настроена, можно добавить ее в качестве ноды OpenShift. WMCO отслеживает создание configMap с именем windows-instances в пространстве имен openshift-windows-machine-config-operator, где описываются инстансы, которые надо присоединить к кластеру. Для настройки инстанса требуется предоставить следующие сведения:
DNS-имя для входа на инстанс по SSH.
Имя пользователя-администратора.
Запись по каждой Windows-ноде в ConfigMap должны иметь в data-секцию, сформированную следующим образом: IP-адрес Windows-ноды в качестве ключа (вместо IP можно использовать и DNS-имя, но с этим пока есть баг) и строка username=<username> в качестве значения. В нашем случае это выглядит так:
kind: ConfigMap
apiVersion: v1
metadata:
name: windows-instances
namespace: openshift-windows-machine-config-operator
data:
10.0.32.8: |-
username=anachandТеперь сохраняем этот configmap и ждем. Подготовка инстанса Windows Server и его подключение к кластеру OpenShift в качестве worker-ноды занимает минут 10-15.
Посмотрим логи оператора, чтобы проверить статус добавления нашей ноды BYOH:
После того, как наша BYOH-нода добавится, ее видно в консоли OpenShift в разделе Compute->Nodes.
Для удаления Windows-ноды достаточно убрать ее запись из ConfigMap. В результате, Windows-нода вернётся в то состояние, в котором она была до включения в состав кластера, за исключением следов в логах и среде выполнения контейнеров.
Чтобы Windows-нода удалилась из OpenShift без ошибок, она должна быть доступна с текущим закрытым ключом, предоставленным WMCO.
Пример развертывания рабочей нагрузки
Итак, у нас есть Windows-нода OpenShift, попробуем запустить на ней Windows-контейнер. Но прежде напомним ряд важных моментов. Windows-контейнер должен быть совместим с Windows-платформой, на которой он запускается. Например, контейнер, созданный на Windows Server 2019, никак нельзя запустить на Windows Server 2016, а на Windows 10 – можно, но с ограничениями, подробнее см. документацию Microsoft.
Также важно помнить, что образы контейнеров Windows могут быть ОЧЕНЬ большими. В некоторых случаях базовый образ может тянуть на 8 ГБ! Это может создавать проблемы для планировщика Kubernetes, тайм-аут которого по умолчанию составляет 2 минуты. Чтобы решить эту проблему, рекомендуется предварительно скачивать на хост все необходимые базовые образы командой docker pull.
Для примера развернем вот тестовое приложение на базе веб-сервера Windows. Обратите внимание, что toleration задан так, чтобы соответствовать taint, созданному WMCO на Windows-ноде.
tolerations:
- key: "os"
value: "Windows"
Effect: "NoSchedule"
Развернем это приложение:
$ oc create -f WinWebServer.yamlТеперь предоставим его как сервис:
$ oc expose service win-webserverВ консоли OpenShift перейдем в раздел Networking->Routes и щелкнем соответствующий URL, чтобы получить доступ к этому приложению.
Заключение
Итак, функция Bring Your Own Host теперь позволяет администраторам Red Hat OpenShift вводить в состав кластера OpenShift кастомные ноды Windows, а оператор Windows Machine Config Operator (WMCO) помогает добавлять и удалять такие ноды, чтобы по ним можно было распределять рабочие нагрузки Windows.
