В погоне за лучшей или, правильнее сказать, удобной жизнью я начал искать решение, которое помогало бы писать чарты для Kubernetes и лучше разбираться в зависимостях — что, куда и откуда подставляется в созданных чартах. Так я наткнулся на программу под названием Monokle. В ее описании сказано: «Вы сможете составлять чарты, быстро находить какие либо несовместимости или неправильный код, а также деплоить ваши чарты сразу в K8s». Глаза загорелись, я приступил к установке.
Важно: тестировалась версия 1.9; выводы основаны на личных впечатлениях.
Что такое Monokle
Monokle написан на Electron с добавлением React и TypeScript. Проект появился на GitHub’е 21 апреля 2021 года, активно развивается и за прошедшие полтора года набрал почти 600 звёзд. В нем поддерживаются плагины — JSON-файлы (они же темплейты), которые помогают создавать ресурсы. Для создания сейчас доступны: Basic Pod, Basic Job, Basic Service, Deployment, StatefullSet + RBAC. При этом в начальном состоянии плагинов от разработчиков представлено очень мало.
Monokle «из коробки» предлагает:
проверку правильности составления чартов, отслеживания зависимостей и поиск проблемных мест;
использование темплейтов для составления с нуля ресурсов кластера;
возможность деплоить чарты сразу же в кластер прямо из программы;
сравнивать чарты в кластере с локальными;
просматривать и редактировать онлайн то, что уже есть в кластере;
генерировать preview для Helm и Kustomize-ресурсов по заданным values.
Первые шаги и попытки освоиться
Сначала я скачал подходящий дистрибутив. После установки и запуска Monokle предложил мне выбор: открыть текущую папку с чартами, создать манифест с нуля или воспользоваться темплейтом для создания готового набора.
Недолго думая, я выбрал первый пункт, указав папку, которая была подготовлена для использования с werf (Open Source-утилитой для сборки приложений и их деплоя в Kubernetes), в которой уже лежали YAML-темплейты. Стоит отметить, что werf — это мой единственный инструмент, с которым я сейчас работаю.
Далее всё пошло наперекосяк. Папка открылась нормально, но из всего содержимого были доступны только файлы с расширениями *.yml
или *.yaml
, да и то как-то выборочно. Например, я не смог открыть файл .gitlab-ci.yml
, как бы ни старался. Очень огорчило, что нельзя открыть и редактировать *.tpl
-файлы, в которых задана дополнительная логика. В итоге я решил, что делаю всё неправильно и принялся осваивать всё с нуля.
Прежде чем продолжить, остановлюсь на интерфейсе.
Интерфейс пользователя
Окно программы разбито на колонки: первая служит для обзора структуры проекта, вторая — для просмотра созданных в чартах ресурсов, третья — редактор.
Для удобства навигации в первой колонке есть закладки:
Файлы проекта.
Просмотр структуры Kustomize ( с этим софтом я не знаком, поэтому закладку пропускаю).
Просмотр структуры Helm.
Images — образы, используемые в проекте (в нашем случае только один: ubuntu:latest).
Предварительно подготовленные темплейты, из которых можно создавать новые ресурсы для кластера.
Проверка на валидность созданных ресурсов в соответствии с различными версиями Kubernetes.
Поиск и замена.
Навигатор ресурсов. В этой закладке будут появляться и первично проверятся созданные ресурсы, а также ссылки на ресурсы, созданные в чартах.
Окно редактора.
Текущее состояние работы Monokle. Может быть: None, Cluster mode, Helm Preview и, возможно, Kustomize preview.
Настройки. Здесь можно выбрать версию Kubernetes, задать местоположение
.kube/config
и настроить, как все это будет работать.
Старт с нуля
В этот раз я выбрал пункт «Создание манифеста с нуля». Создал папку для нового проекта и попробовал накидать в нее файлов из темплейтов. На мой взгляд, наиболее востребованными из темплейтов могут быть: Advanced Pod, RoleBinding and Service Accounts, а также Basic Kubernetes StatefulSet. Я выбрал Advanced Pod, чтобы понять, как происходит этот процесс, и что будет дальше.
В результате получилось что-то визуально похожее на то, с чем можно начать работать.
Но, на мой взгляд, при создании проекта с нуля Monokle не предлагает достаточной функциональности. Да, можно накидывать что-то на скорую руку и даже деплоить это в кластер, но я ожидал другого. При таком подходе у вас будет просто набор разрозненных файлов и никакой структуры.
Макет проекта Helm
На этот раз я решил создать макет проекта на Helm.
Командой helm create mytestproject
я получил заготовку для будущего проекта. После этого сразу же заполнилась вкладка для работы с Helm-чартами и появилась кнопка Install в правом верхнем углу для установки Helm Chart в Kubernetes (Во второй итерации была только кнопка Deploy, которая делает почти то же самое. Но после нее в кластере очень тяжело будет найти, что и откуда выкатилось. Также K8s не будет следить за тем, живо оно или нет).
Вот теперь я уже приблизился к тому, что хотел увидеть: структура в левом столбце очень напоминала мне ту, с которой я постоянно работаю — здесь создался полноценный макет проекта.
При выборе файла values.yaml
справа от него появляется кнопка Preview, при нажатии на которую темплейты заполняются значениями из этого файла. Вот так выглядит созданный чарт:
Текущее состояние Monokle перешло в Helm Preview. В этом режиме в среднем блоке Navigator можно просматривать, какие ресурсы будут созданы в кластере. Этот режим, как следует из названия, не позволяет ничего редактировать, но зато дает возможность установить сгенерированное в Kubernetes и посмотреть, не появились ли какие-либо нестыковки в ресурсах.
Дальше я решил попробовать что-нибудь задеплоить в предварительно поднятый на машине Minikube. Теперь в дело пошла кнопка Install: нужно выбрать файл values.yaml
, а затем либо предварительно перейти в Helm Preview и посмотреть, что же будет деплоиться, либо, если это уже готовый чарт, который нужно просто установить.
Так как я ничего не кастомизировал, появилось еще одно окно с выбором:
После создания нового пространства имен test-helm
Helm-чарт успешно задеплоился:
Далее можно много рассказывать о том, что где находится, как создавать ресурсы, как их редактировать, как сверять то, что в чартах, с тем, что в кластере… Но я остановился на этом этапе, по одной простой причине: я понял, что Monokle лично мне не подходит.
Плюсы и минусы Monokle
Что мне понравилось в Monokle и, возможно, заставит читателя обратить свое внимание на продукт (а он несомненно этого заслуживает):
Можно создать почти любой ресурс Kubernetes через GUI (подробнее про создание ресурсов).
Встроенные ссылки по описанию текущего ресурса на kubernetes.io. Доступно в Preview Mode и в окне редактора.
-
Подсветка синтаксиса. Например, если ошибся в написании имени Secret’а, то Monokle подскажет, что такого Secret’а нет (неявное указание на ошибку в имени). Аналогично и с другими ресурсами, где есть перекрестные ссылки:
-
Проверка на ошибки всего чарта целиком. В блоке навигатора чарты с ошибками или предупреждениями будут подсвечены соответствующим символом:
желтый треугольник с восклицательным знаком — показывает ссылки на несуществующие ресурсы;
восклицательный знак в красном кружке — сообщает о синтаксических ошибках. Подробнее с этими функциями можно ознакомиться в официальной документации.
В Preview Mode можно перемещаться туда, где задана сущность, а не искать ее вручную по всем файлам. Сделать это можно с помощью кнопки.
-
При работе в режиме Helm доступно использование различных команд Helm’a. Так, например, можно задавать окружения через Preview Configuration:
-
Возможность подключения к кластеру через
.kube/config
и просмотра уже имеющихся сущностей: -
Режим сравнения, в котором можно сравнить свой чарт с тем, что уже есть в Kubernetes (выбирается в окне Navigator кнопкой с двойными синими стрелочками):
-
Декодирование base64 при наведении курсора мыши:
Я подозреваю, что это не полный список возможностей, которые могли бы мне понравится. Но в связи со спецификой работы мне было тяжело разбираться в Monokle и немного рвало шаблон разницей подходов к формированию чартов и структуры проекта.
Что не понравилось:
Не все файлы можно открыть на редактирование (многое уже исправлено в версии 1.10).
Нет поддержки Git’а. При необходимости придется пользоваться терминалом или сторонними утилитами.
Конфиги Preview Configuration сохраняются в самом Monokle и не привязаны к проектам.
Таким образом, вы получаете полный набор конфигов от разных проектов для всех проектов сразу.Отдельно стоит отметить, что Monokle несовместим со структурой папок и темплейтов утилиты werf. Поэтому лично для меня софт оказался не настолько полезным, как я себе представлял.
Ну что же, остаюсь на VsCode от Microsoft — старом добром редакторе с кучей плагинов, в том числе и для Kubernetes.
Заключение
В статье я рассмотрел свой личный опыт тестирования Monokle, программы для управления чартами в Kubernetes. Мои ожидания не оправдались. Но впечатления субъективны, поэтому другим эта программа может показаться, наоборот, удобной и полностью удовлетворяющей запросы.
У Monokle хороший набор инструментов для создания почти любого ресурса Kubernetes, он позволяет легко выбрать необходимую сущность. Утилита может пригодиться в освоении K8s. Ее можно использовать как справочный материал.
Если у вас уже есть Helm-чарты, однозначно советую присмотреться и попробовать Monokle. При этом назвать его самодостаточным софтом я не могу, лучше использовать его в связке с другими решениями как дополнение.
Несмотря на все вышесказанное, проект очень быстро набирает обороты и так же быстро обрастает новыми функциями. Если на текущий момент кажется, что чего-то не хватает, вполне возможно, что это появится в следующей версии.
P.S.
Читайте также в нашем блоге: