Готова ли технология к использованию в прайм-тайм?
Пока еще находится предварительная версия, Служба Azure Kubernetes (AKS) недавно объявила о поддержке контейнеров Windows Server.
Вы можете развертывать приложения ASP.NET, запускать сценарии подсистемы PowerShell или Linux и включать автомасштабирование в соответствии с требованиями клиентов. Пользуюсь сервисом уже около месяца, это мои ключевые выводы.
Контейнеры Windows медленнее и неуклюже
Контейнерная разработка имеет ряд преимуществ, таких как согласованные среды, изоляция и подход к запуску где угодно².
При использовании контейнеров на основе Linux в Kubernetes он обычно имеет преимущество в том, что он достаточно легкий для масштабирования и быстрого удовлетворения потребностей в трафике. Даже на странице О контейнерах Windows говорится об этих преимуществах:
«Контейнеры обеспечивают легкую изолированную среду, которая упрощает разработку, развертывание и управление приложениями. Контейнеры быстро запускаются и останавливаются, что делает их идеальными для приложений, которым необходимо быстро адаптироваться к меняющемуся спросу ». ³
Приходя из мира контейнеров на базе Linux, я был удивлен как большим размером образов, так и количеством времени, которое требуется для масштабирования новых узлов Kubernetes и развертывания дополнительных модулей.
Размер изображения по умолчанию ltsc2019 превышает 850 мегабайт, поэтому я пока не знаю, готовы ли мы использовать упрощенную фразу, но все остальное по-прежнему звучит правдоподобно.
Контейнеры Windows также требуют больше ресурсов, чем их аналог, что увеличивает стоимость, по крайней мере, в два раза, если сравнивать Standard_DS2_v2 с Standard_DS3_v2 в Azure⁴ (требуемый минимальный размер для пулов узлов Windows).
Я использовал только Standard_DS3_v2 узлы при использовании контейнеров Windows, так что отнеситесь к этому с недоверием, но я заметил большую задержку и замедление при взаимодействии с запущенными модулями.
Например, при отладке систем я часто запускаю такую команду:
$ kubectl exec -it [pod-name] /bin/bash
В Windows это становится:
$ kubectl exec -it [pod-name] powershell.exe
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
PS C:\>
Выполнение команд отсюда, таких как загрузка файлов или установка исполняемых файлов, может занять некоторое время, хотя на моем Mac довольно здорово прыгнуть в контейнер Windows. Это определенно огромный шаг вперед для разработчиков вроде меня, которые обычно запускают любую работу по разработке Windows.
Объедините эту функциональность с последней подсистемой Windows для Linux (WSL), и вы получите общую цепочку инструментов для операционных систем.
Теперь я использую ранее протестированный сценарий bash в Windows через Kubernetes с минимальными усилиями. Эта поддержка еще больше снижает входной барьер для большего числа разработчиков, заинтересованных в кроссплатформенной поддержке.
Делать все правильно - это искусство
Хотя для контейнеров Windows доступны базовые образы Windows Server Core и Nanoserver, насколько я могу судить, AKS поддерживает только образы Windows Server Core. Это потому что:
«Контейнеры Windows Server и базовый хост совместно используют одно ядро, версия ОС базового образа контейнера должна совпадать с версией хоста». ⁵
Если вы не поняли это правильно, ожидайте увидеть The operating system of the container does not match the operating system of the host.
Я видел это много раз. Я использовал Azure Pipelines⁶ для создания образа контейнера из настраиваемого файла Dockerfile. Затем мне нужно было сделать мой базовый образ Windows версией, соответствующей версии виртуальной машины Azure Pipeline.
Затем я сопоставил образ контейнера с узлом Kubernetes. Мне не удалось найти точную версию Windows в документации по Azure, и, запустив kubectl get nodes -o wide, вы получите что-то вроде:
NAME OS-IMAGE KERNEL-VERSION linux-node Ubuntu 16.04.6 LTS 4.15.0-1061-azure windows-node Windows Server 2019 Datacenter 10.0.17763.737
Это преобразовано в базовый образ Docker mcr.microsoft.com/windows/servercore:ltsc2019 и образ виртуальной машины Azure vmImage: ‘windows-2019’.
Надеюсь, со временем будет проще сопоставить и настроить эти параметры и, в конечном итоге, запускать базовые образы наносервера на AKS.
AKS не готов к производственному трафику
В настоящее время я использую AKS для выполнения производственных вычислительных заданий, которые являются асинхронными и не влияют напрямую на клиентов. Я думаю, что сейчас это хороший и безопасный вариант использования.
Причина, по которой я не думаю, что он готов для производственного веб-трафика или чего-либо синхронного, заключается в том, что я столкнулся с более чем несколькими проблемами с фактическим кластером. Вот несколько:
- Узлы неожиданно стали недоступны из-за зависания контейнеров в состоянии
ContainerCreating. - Удаленные задания не очищали связанные поды (поломка Kubernetes API).
- Отключение опции автомасштабирования узла невозможно через пользовательский интерфейс, что приводит к некоторым сложностям ручного масштабирования.
Я ожидал, что такие проблемы, как поломка Kubernetes API, можно будет быстро решить с помощью службы поддержки Azure, но, не доплачивая, я не мог напрямую обострить проблему.
Я считаю, что через GitHub можно отправлять такие проблемы, но кажется безумием, что во время предварительного просмотра они не допускают отзывов и ошибок.
