В этой статье мы подробно расскажем о пути перехода платформы контейнеризации dBrain.cloud с MaaS на Metal³. Основная задача, которую решают оба этих проекта, состоит в установке операционной системы на серверы платформ. Озвучим причины, по которым мы искали альтернативные решения, и объясним, чем Metal³ превосходит MaaS.

Для начала напомним, что такое платформа контейнеризации dBrain.cloud. Это отечественное Enterprise-решение для разработки, развертывания и эксплуатации микросервисных приложений, способное объединить сотни серверов в единый отказоустойчивый кластер Kubernetes. Одной из важнейших задач команды разработки dBrain является создание единой точки управления кластером - консоли.

Начало развития платформы связано с использованием MaaS (Metal as a Service), который отлично справлялся с базовыми задачами конфигурации серверов и развертывания операционных систем. В 2016 году, когда мы приступили к разработке кластерной версии, мы ориентировались на Bare Metal инсталляции и нуждались в решении для быстрого развертывания операционной системы на множестве серверов. Поскольку в качестве базовой операционной системы была выбрана Ubuntu, решение MaaS от Canonical Ltd. стало идеальным выбором. Оно позволяло нам легко заводить аппаратные серверы, настраивать диски и сети через удобный UI и автоматизировать развертывание ОС, после чего мы уже запускали наш деплой и разворачивали платформу. На тот момент MaaS было фактически единственным Open Source решением, которое стабильно работало и полностью закрывало наши потребности.

Несмотря на то, что MaaS был рабочим вариантом, со временем мы столкнулись с его громоздкостью и избыточной функциональностью. Хотя задачи по его замене периодически поднимались, отсутствие адекватных альтернатив заставляло оставаться на MaaS.

Ключевым фактором, подтолкнувшим к изменениям, стал переход на операционную систему Debian. MaaS в основном ориентирован на Ubuntu, и даже для создания кастомных образов требовал наличия минимальной Ubuntu для базовых операций. Мы стремились полностью сосредоточиться на Debian и избежать привязки к Ubuntu, пусть даже минимальной.

В процессе поиска новых решений мы обратили внимание на Metal³. Этот выбор оказался особенно актуальным, когда мы начали прорабатывать решения для гибридных облаков и управления виртуальными машинами непосредственно из консоли dBrain. Ранее Metal³ уже рассматривался, но тогда он не закрывал всех наших потребностей. Теперь же, с развитием консоли, мы увидели в Metal³ идеальную замену MaaS.

Преимущества Metal³

Особенностью Metal³ является его глубокая интеграция с Kubernetes путем добавления кастомных ресурсов, что позволяет управлять Bare Metal серверами, как объектами Kubernetes. Это программное обеспечение состоит из следующих компонентов:

• Cluster API Provider Metal³ (CAPM3) добавляет поддержку Metal³ к Kubernetes Cluster API.

• Bare Metal Operator (BMO) решает задачи управления жизненным циклом серверов.

• Ironic на более низком уровне занимается непосредственно работой по тестированию и развертыванию новых серверов. И, кстати, он также является частью популярного инфраструктурного проекта OpenStack.

В Metal³, как и с другими ресурсами Kubernetes, используется декларативный подход. Мы создаем описание ноды, которое включает MAC-адрес хоста, данные IPMI, также поддерживается протокол Redfish. Загружаем нужный образ операционной системы для установки. Далее Ironic самостоятельно выполняет процедуру регистрации сервера в соответствии с YAML-манифестом. Он осуществляет загрузку указанного сервера по сети с использованием PXE или средствами virtual media, сбор информации о железе, установку операционной системы на сервер. При необходимости мы можем изменять ресурсы и добиться нужного состояния сервера. Таким образом обеспечивается управление питанием, установкой и настройкой операционной системы. Собранные во время тестирования оборудования данные тоже сохраняются.

Cluster API - это подпроект Kubernetes, направленный на предоставление декларативных API и инструментов для упрощения подготовки, обновления и эксплуатации кластеров Kubernetes. Дает возможность автоматизировать процесс развертывания K8s-кластера, а при использовании разных провайдеров создавать гибридные кластеры.

Наличие в проекте Metal³ провайдера позволяет интегрироваться с Cluster API и автоматически создавать кластеры Kubernetes на основе физического оборудования. Это означает, что мы можем не просто разворачивать операционную систему на ноде, а сразу же устанавливать Kubernetes и формировать полноценный кластер одной командой.

С Metal³ мы получаем возможность видеть всю структуру кластера, включая физические машины, непосредственно внутри Kubernetes. Например, команда kubectl get bmh позволяет получить список наших хостов прямо из Kubernetes. Что касается кастомизации образов, то и подготовка конечного образа для деплоя становится проще. Мы больше не привязаны к определенным требованиям MaaS, что особенно актуально для образов Debian.

Основное преимущество Metal³ заключается в его легковесности и возможности работы непосредственно во вспомогательном кластере Kubernetes, что исключает необходимость в отдельной физической машине, как было с MaaS. Это позволяет нам значительно упростить и унифицировать нашу инфраструктуру, интегрировав управление физическими и виртуальными машинами через единую консоль.

Большой плюс Metal³ в его глубокой интеграции с консолью dBrain. В то время как MaaS имеет собственный громоздкий графический интерфейс, Metal³ позволяет нам создавать любые необходимые интерфейсы, используя его API. Это избавляет нас от дублирования функционала и унифицирует управление всей инфраструктурой из единой точки.

Вместо заключения

Таким образом созданные и задеплоенные серверы мы можем использовать через единый стандартный механизм. Существует целый ряд инструментов с открытым исходным кодом для работы с Bare Metal, включая используемый нами MaaS. Но особенностью Metal³ является то, что его компоненты бесшовно интегрируются в экосистему Kubernetes для автоматизации управления инфраструктурой Bare Metal. Проект Metal³ также взаимодействует с Kubernetes Cluster API, что позволяет использовать его в качестве бэкэнда инфраструктуры.

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

Если у вас есть вопросы о работе платформы dBrain, пишите в комментариях или нам на platform@dbrain.cloud.

Читайте также:

• Как контролировать 140 петабайт данных и 80 тысяч подов в Kubernetes

• Мультитенантность: почему мы отказались от готовых решений и как приручали Keycloak

• Моя попытка №2. Как мы тестировали совместимость платформы контейнеризации с Astra Linux