Веб-интерфейс

Веб-интерфейс — единая точка управления Deckhouse Kubernetes Platform: он упрощает администрирование и делает состояние системы наглядным. Интерфейс доступен во всех редакциях, включая Community Edition, без ограничений по функциональности.

Доступ к интерфейсу есть у всех пользователей согласно их правам в платформе.

Если шаблон публичных доменов — %s.example.com, веб-приложение доступно по адресу https://console.example.com.

Сильные стороны

• Единая консоль для всей платформы. Кластер и его обновления, модули, узлы, сеть, хранилища, доступы, мониторинг, логи и виртуализация — в одном интерфейсе, без переключения между инструментами.
• Графические формы с подсказками и валидацией для ресурсов, которые в CLI описываются YAML-манифестами. На каждом ресурсе доступна вкладка YAML для прямого редактирования.
• Встроенный терминал с сессией в подах оператора платформы — без отдельного SSH-доступа.
• История изменений с отменой и повтором выполненных действий.
• Ресурсы под управлением GitOps помечаются (werf, Argo CD, Helm) — видно, что объект изменяется автоматикой и его не стоит править вручную.
• Доступ ограничен правами пользователя в платформе (RBAC): в интерфейсе доступны только разрешённые объекты и действия.
• Состояние кластера на одном экране: версии Deckhouse и Kubernetes, статусы подсистем, активные алерты, узлы с проблемами и ожидающие обновления.
• Один интерфейс для всех редакций, включая Community Edition.

Особенности и принципы работы

Снижение требований к квалификации команды

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

Ускорение типовых операций

Рутинные задачи — развёртывание виртуальных машин, добавление узлов, проверка состояния — выполняются за минуты через веб-формы вместо ручного написания и отладки конфигураций.

Сокращение времени онбординга

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

Прозрачность состояния платформы

Единый интерфейс с дашбордами и статусами подсистем даёт инженерам и руководителям общую картину без необходимости собирать данные из разных источников.

Возможности

Интерфейс разделён на два контекста, между которыми переключаются селектором в левом верхнем углу:

• Управление системой — администрирование платформы целиком: обновления, модули, узлы, сеть, хранилища, доступы, наблюдаемость и безопасность кластера.
• Проект — применение платформы внутри выбранного проекта: работа с приложениями и ресурсами (нагрузки, виртуальные машины, сервисы, секреты).

Администрирование платформы

Обзор

Версии Deckhouse и Kubernetes, состояние подсистем, активные алерты и доступные инструменты: дашборд Kubernetes, документация, мониторинг, Prometheus, статус-страница, генератор kubeconfig и сканер уязвимостей (CVE).

Обновления и модули

Обновление платформы и версии Kubernetes с выбором канала и режима обновлений; управление модулями (настройки, источники и политики обновлений, changelog, переустановка) и глобальные настройки модулей. Маркетплейс приложений: репозитории пакетов, установка приложений, их ресурсы и отслеживание новых версий.

Конфигурация кластера

Домен кластера, сети сервисов и подов, тип container runtime, реестр образов, а также выбор и обновление версии Kubernetes.

Оператор платформы

Статус, мониторинг, логи, очередь задач и вебхуки оператора платформы, а также встроенный терминал с сессией в его подах.

Узлы

Группы узлов, отдельные узлы и их масштабирование, классы машин, конфигурации групп узлов (NodeGroupConfiguration), статические узлы и пользователи на узлах, метрики и мониторинг по узлам и группам.

Сеть

Ingress-контроллеры с настройкой через формы и валидацией параметров, управление TLS-сертификатами и кластерными издателями, сетевые политики, UI модуля SDN (если включён).

Хранилище

Persistent Volume, классы хранилищ, снимки томов (VolumeSnapshot) и их классы. Программно-определяемое хранилище (SDS): пулы, группы и логические тома, блочные устройства.

Доступ

Провайдеры аутентификации (Dex) и интеграция с внешними каталогами пользователей, права групп и пользователей (RBAC), кластерные и проектные роли и назначения, Cluster Authorization Rules с квотированием.

Безопасность

Политики запуска контейнеров и операционные политики, сканер уязвимостей (CVE). При включении соответствующих модулей — WAF & DLP, NeuVector, управление секретами Stronghold.

Наблюдаемость

Мониторинг: метрики, алерты и recording rule, дашборды и источники данных Grafana, настройки Prometheus, список горящих алертов, политики уведомлений. Журналирование: сбор логов с узлов и подов и отправка в различные хранилища.

Применение (проекты)

Проекты и неймспейсы

Проекты и шаблоны проектов (мультиарендность), обзор проекта и неймспейсов, проектные роли и назначения.

Рабочие нагрузки

Поды, развёртывания и сервисы (включая распределение входящего трафика для типов LoadBalancer и HostPort), секреты, PersistentVolumeClaim, автомасштабирование (VPA, HPA) и сетевые политики.

Виртуальные машины

Создание ВМ и настройка через cloud-init, миграция с отображением этапов и метрик памяти, доступ к VNC и терминалу ВМ, групповые операции, диски и образы. Общие настройки виртуализации — в разделе администрирования.

Управляемые сервисы

Работа с управляемыми сервисами платформы (Managed Services).

Интерфейс

• AI-ассистент (✨) — встроенный чат по состоянию кластера, ресурсам и документации; по умолчанию работает только на чтение и в рамках прав пользователя. Подробнее — на странице «AI-ассистент».
• Работа с ресурсами в виде YAML-манифеста: создание любого ресурса (кнопка «+») и редактирование существующего ресурса прямо в YAML (вкладка YAML на каждом ресурсе); просмотр и правка произвольных ресурсов Kubernetes.
• Трёхколоночная раскладка: навигация, список ресурсов и детали (или форма) выбранного ресурса видны одновременно.
• Групповые операции над несколькими выбранными ресурсами.
• Тёмная и светлая темы.

Как включить

Чтобы включить модуль, создайте ModuleConfig:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: console
spec:
  enabled: true

Требования к ресурсам

Потребление ресурсов подами серверной части в зависимости от количества одновременных пользователей отображено в таблице ниже

Ограничение на вертикальное масштабирование подов: минимальные значения CPU/памяти в 100m/100MiB и максимальные значения в 1/512MiB. Две реплики серверной части включаются автоматически для DKP в режиме высокой доступности.

Технические особенности работы

Ресурсы публикации веб-интерфейса (Ingress, Certificate, DexAuthenticator) создаются только после первичной установки кластера (bootstrap).

Адрес веб-интерфейса (publicDomainTemplate)

Адрес формируется подстановкой имени console в глобальный шаблон публичных доменов global.modules.publicDomainTemplate: при шаблоне %s.example.com веб-интерфейс доступен по адресу console.example.com. Если шаблон не задан, модуль работает, но веб-интерфейс не публикуется: Ingress, Certificate и DexAuthenticator не создаются.

Публикация через Ingress (ingress-nginx)

Веб-интерфейс публикуется ресурсами Ingress: отдельные Ingress создаются для фронтенда, для API серверной части (путь /api), а также для ассистента и шлюза observability, если соответствующие функции включены. Класс Ingress определяется параметром модуля ingressClass, а если он не задан — глобальным global.modules.ingressClass.

Ingress-ресурсы используют аннотации nginx.ingress.kubernetes.io/*: переписывание путей для API, внешняя аутентификация, ограничение доступа по IP-адресам, размер буферов прокси. Поэтому обрабатывать их должен Ingress-контроллер на базе NGINX, например модуль ingress-nginx. Включённость самого модуля ingress-nginx при этом не проверяется: Ingress создаются в любом случае, а маршрутизацию обеспечивает контроллер, обслуживающий указанный класс.

Если режим HTTPS — Disabled, Ingress не создаются и веб-интерфейс недоступен.

HTTPS и cert-manager

Режим HTTPS задаётся параметром модуля https.mode, а при его отсутствии — глобальным global.modules.https.mode:

• CertManager — модуль создаёт ресурс Certificate, по которому указанный ClusterIssuer выпускает сертификат в Secret ingress-tls. Certificate создаётся, только если в кластере доступен CRD cert-manager.io/v1/Certificate. Намеренно проверяется наличие CRD, а не включённость модуля cert-manager: для выпуска сертификата достаточно и стороннего cert-manager, установленного вне Deckhouse.
• CustomCertificate — пользовательский сертификат копируется хуком модуля в namespace d8-console (Secret ingress-tls-customcertificate) и подключается к Ingress.
• OnlyInURI — Ingress создаются без TLS-секции; предполагается, что HTTPS терминируется вне кластера.
• Disabled — веб-интерфейс не публикуется.

Vertical Pod Autoscaler

Для каждого Deployment модуля создаётся ресурс VerticalPodAutoscaler с режимом обновления InPlaceOrRecreate. VPA создаётся, только если одновременно включён модуль vertical-pod-autoscaler и в кластере есть CRD verticalpodautoscalers.autoscaling.k8s.io (API autoscaling.k8s.io/v1). Двойная проверка намеренная: CRD может быть установлен сторонним VPA, поэтому его наличие само по себе не означает, что включён модуль платформы. Кроме того, режим InPlaceOrRecreate корректно обрабатывается именно VPA-контроллером платформы — сторонняя установка VPA может его не поддерживать. Если VPA не создаётся, подам задаются статические запросы ресурсов, совпадающие с минимальными значениями VPA.