Обзор Helm-Dashboard — графического интерфейса для управления релизами Kubernetes
Привет! На связи Павел Басалгин, DevOps-инженер компании «Флант». Сегодня я расскажу об инструменте, который упрощает управление релизами Kubernetes.
Часто разработчики предпочитают использовать именно визуальные средства, чтобы более эффективно управлять релизами Kubernetes. Один из таких инструментов — Helm-Dashboard. С его помощью можно самостоятельно создавать, развертывать, обновлять различные релизы Kubernetes-приложений и отслеживать их состояние.
В этой статье мы рассмотрим возможности и преимущества Helm-Dashboard и разберем, как он может упростить задачи по управлению релизами Kubernetes. Я расскажу про основные функции и интерфейс пользователя и покажу примеры использования этого инструмента.
Что такое Helm-Dashboard
Helm-Dashboard — это графический пользовательский интерфейс Helm с открытым исходным кодом от Komodor. Helm — это менеджер пакетов для Kubernetes, который помогает упростить установку приложений Kubernetes и управление ими. А Helm-Dashboard дает удобный интерфейс для изучения установленных релизов и работы с ними. Например, в нем можно изменять или удалять релизы.
Как устанавливается Helm-Dashboard
Согласно официальной документации в GitHub-репозитории проекта есть несколько способов установки Helm-Dashboard:
Скачать архив с собранным исполняемым файлом.
Установить в качестве Helm-плагина.
Установить из чарта в кластер K8s, при этом будет создан Ingress для использования сервиса.
Собрать исполняемый файл из исходников.
Для обзора мы взяли вариант с плагином, так как его часто рекомендуют разработчики, а еще с ним отлично работает наша CLI-утилита для сборки приложений и их деплоя в Kubernetes — werf. Чтобы установить плагин, нужно перейти по ссылке и установить плагин локально.
Чтобы теперь с помощью плагина можно было подключиться к кластеру, нужен kubeconfig — конфигурационный файл для доступа к кластеру Kubernetes. Подробнее об этом по ссылке.
Далее из терминала запустим установленный плагин командой werf helm dashboard. В итоге откроется страница в браузере с графическим представлением релизов.
Какие возможности есть у Helm-Dashboard
В браузере у нас откроется такая страница:
В верхней части интерфейса можно увидеть вкладки Installed и Repository. Это основные вкладки, в которых мы будем работать. Разберем их подробнее.
Installed
На вкладке Installed в левой части интерфейса можно выбрать кластер и необходимые namespace«ы. В результате система выдаст установленные релизы выбранного кластера:
После выбора необходимого релиза у нас появляется возможность изучить его детальнее.
Если у релиза есть проблемы, то вместо ресурсов можно увидеть сообщение об ошибке:
Здесь можно посмотреть причины, по которым релиз не установился до конца. Если с релизом всё в порядке, мы увидим список ресурсов.
Рассмотрим это на примере релиза zookeeper-operator-dev:
В левой части интерфейса можно увидеть состояния релизов, которые нашла система в кластере. В основной части интерфейса нам нужны для работы две вкладки: Resources и Manifests.
Во вкладке Resources можно увидеть список ресурсов, которые есть в релизе. У каждого из них есть кнопка Describe. Нажимаем на нее и получаем описание ресурса:
Описание ресурса представляет собой обычный вариант от kubectl describe.
Также на вкладке Resources у ресурса рядом с кнопкой Describe может быть кнопка Scan:
Кнопка будет активна в том случае, если установлен Trivy — инструмент для сканирования безопасности контейнеров, который позволяет обнаруживать уязвимости и потенциальные угрозы.
Если нажать на кнопку Scan, запустится процесс сканирования ресурса. В итоге получим такой отчет:
На вкладке Manifests можно посмотреть манифесты ресурсов в релизе. Выбрать можно любой из тех, что имеются в кластере:
В открывшемся окне сверху можно переключаться между вкладками:
Diff with previous — показывает разницу между текущим и предыдущим релизами.
Diff with specific revision — показывает разницу между текущим и конкретным релизом.
Например, diff с неудачной версией 3:
Любой релиз можно апгрейдить, откатить или удалить из кластера. Для этого на странице есть кнопки Reconfigure, Rollback и Uninstall соответственно:
Пример окна для апгрейда:
Repository
Repository — это окно для управления локально установленными репозиториями. Слева на этой панели можно посмотреть, какие репозитории подключены:
Здесь можно выбрать репозиторий, чтобы изучить доступные в нем Helm-чарты. А еще можно:
добавить репозиторий — кнопка Add Repository;
обновить репозиторий — кнопка Update;
удалить репозиторий — кнопка Remove.
Доступные в репозитории Helm-чарты можно установить в кластер после заполнения Values. Для этого нужно нажать кнопку Install, которая находится напротив названия чарта. В результате откроется следующее окно:
Какие особенности работы у Helm-Dashboard
Среди основных возможностей Helm-Dashboard можно выделить следующие:
Helm-Dashboard можно установить локально или через чарт в кластер.
Можно просматривать установленные в кластер чарты и историю их релизов.
Возможность посмотреть diff между различными версиями релизов.
Можно откатить релиз или обновить его.
При локальной установке возможно просматривать релизы нескольких кластеров.
Возможность интеграции со сканерами уязвимостей.
Интуитивно понятный и приятный UI.
Стоит отметить, что использование графического интерфейса влияет на API server. В момент запуска Helm-Dashboard сервис запрашивает секреты с релизами, из-за чего растет потребление CPU.
Например, так выглядит состояние кластера до запроса секретов релизов для Helm-Dashboard:
Здесь можно увидеть стандартное состояние кластера до начала работы с Helm-Dashboard: потребление CPU, какие ресурсы K8s запрашиваются и как часто.
А это состояние кластера после запроса секретов релизов для Helm-Dashboard:
На этих графиках видно, что выросло потребление CPU, так как активно идет запрос ресурсов секретов.
Вместо заключения
На мой взгляд, Helm-Dashboard — удобный web-UI для просмотра и управления релизами благодаря функции diff между релизами. Также у него минималистичный, приятный и понятный дизайн. Этот инструмент поможет команде разработки при работе в тестовых кластерах, так как они в моменте могут изучить, что пошло не так, и сразу внести исправления.
