Модуль console

Модуль console реализует веб-интерфейс Deckhouse Kubernetes Platform (DKP), который упрощает управление платформой и позволяет отслеживать состояние системы.

Архитектура модуля

Для упрощения схемы приняты следующие допущения:

  • На схеме показано, что контейнеры разных подов взаимодействуют друг с другом напрямую. Фактически они взаимодействуют через соответствующие сервисы Kubernetes (внутренние балансировщики). Названия сервисов не указываются, если они очевидны из контекста. В остальных случаях название сервиса указано над стрелкой.
  • Поды могут быть запущены в нескольких репликах, однако на схеме все поды изображены в одной реплике.

Архитектура модуля console на уровне 2 модели C4 и его взаимодействие с другими компонентами DKP изображены на следующей диаграмме:

Архитектура модуля console

Номерами на схеме отмечен порядок прохождения запроса пользователя к компонентам frontend, backend и nginx.

На шагах 1, 2 и 3 запрос проходит через Ingress NGINX Controller, где выполняется обязательная аутентификация пользователя с использованием модуля user-authn. Подробнее об архитектуре модуля user-authn можно узнать в соответствующем разделе документации.

Компоненты модуля

Модуль состоит из следующих компонентов:

  1. Frontend — состоит из одного контейнера frontend и предоставляет веб-интерфейс для пользователей и администраторов DKP.

  2. Backend — состоит из одного контейнера backend и реализует API-интерфейс, обеспечивающий следующие возможности:

    • получение, создание, удаление и изменение ресурсов DKP в соответствии с правами пользователя;
    • генерация kubeconfig с профилем пользователя;
    • определение окружения, в котором развернут кластер DKP;
    • обнаружение версий DKP и Kubernetes;
    • загрузка метрик и логов;
    • загрузка информации о доступности платформы;
    • скачивание дисков ВМ (при включенных модулях virtualization и storage-volume-data-manager).
  3. Observability-gw — состоит из одного контейнера nginx и выполняет проксирование запросов к Grafana для встраивания дашбордов в основной веб-интерфейс платформы, а также для работы с метриками и логами выбранного проекта.

Взаимодействия модуля

Модуль взаимодействует со следующими компонентами:

  1. Kube-apiserver:
    • организация подключения к ВМ через console и VNC;
    • создание, удаление, изменение и отслеживание ресурсов DKP.
  2. Upmeter — получение информации о доступности DKP.

  3. Deckhouse-tools — пересылка запросов для загрузки утилиты Deckhouse CLI.

  4. Prometheus — получение системных метрик (CPU, RAM и др.) платформы.

  5. Observability — получение метрик и логов для выбранного проекта.

  6. Storage-volume-data-manager — экспорт образов дисков ВМ.

С модулем взаимодействуют следующие внешние компоненты:

  • Controller nginx — пересылка внешних запросов пользователя к веб-интерфейсу модуля.

Модуль documentation

Модуль documentation — это реализация веб-интерфейса с документацией, соответствующей запущенной версии DKP.

Архитектура модуля

Для упрощения схемы приняты следующие допущения:

  • На схеме показано, что контейнеры разных подов взаимодействуют друг с другом напрямую. Фактически они взаимодействуют через соответствующие сервисы Kubernetes (внутренние балансировщики). Названия сервисов не указываются, если они очевидны из контекста. В остальных случаях название сервиса указано над стрелкой.
  • Поды могут быть запущены в нескольких репликах, однако на схеме все поды изображены в одной реплике.

Архитектура модуля documentation на уровне 2 модели C4 и его взаимодействие с другими компонентами DKP изображены на следующей диаграмме:

Архитектура модуля documentation

Номерами на схеме отмечен порядок прохождения запроса пользователя к компоненту web:

  • на шагах 1, 2 и 3 запрос проходит через Ingress NGINX Controller, где выполняется обязательная аутентификация пользователя с использованием модуля user-authn;
  • на шагах 4 и 5 выполняется авторизация пользователя на основе Kubernetes RBAC для организации защищенного доступа.

Компоненты модуля

Модуль состоит из одного компонента:

  • Documentation — компонент, реализующий веб-интерфейс документации.

    Состоит из следующих контейнеров:

    • web — основной контейнер;

    • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к основному контейнеру. Является Open Source-проектом;

    • builder — сайдкар-контейнер, который динамически расширяет документацию при установке новых модулей DKP. Для рендеринга и генерации актуального содержимого сайта используется генератор статических сайтов Hugo.

      Контейнер builder автоматически создаёт и обновляет Kubernetes-ресурс Lease, размещая в нём эндпоинт для обновления документации. Этот эндпоинт используется контроллером модуля deckhouse для запуска обновления документации при обновлении или установке модулей. Благодаря этому изменения своевременно отображаются в веб-интерфейсе.

Взаимодействия модуля

Модуль взаимодействует со следующими компонентами:

  • Kube-apiserver:
    • создание и обновление ресурса Lease;
    • авторизация запросов к веб-интерфейсу документации.

С модулем взаимодействуют следующие внешние компоненты:

  1. Deckhouse — отправка запросов на обновление документации при изменении состава модулей.

  2. Prometheus — сбор метрик модуля.

  3. Controller nginx — пересылка внешних запросов пользователя к веб-интерфейсу модуля.

Модуль deckhouse-tools

Модуль deckhouse-tools — это реализация веб-интерфейса со ссылками на скачивание утилиты Deckhouse CLI под различные операционные системы.

Архитектура модуля

Для упрощения схемы приняты следующие допущения:

  • На схеме показано, что контейнеры разных подов взаимодействуют друг с другом напрямую. Фактически они взаимодействуют через соответствующие сервисы Kubernetes (внутренние балансировщики). Названия сервисов не указываются, если они очевидны из контекста. В остальных случаях название сервиса указано над стрелкой.
  • Поды могут быть запущены в нескольких репликах, однако на схеме все поды изображены в одной реплике.

Архитектура модуля deckhouse-tools на уровне 2 модели C4 и его взаимодействие с другими компонентами DKP изображены на следующей диаграмме:

Архитектура модуля deckhouse-tools

Номерами на схеме отмечен порядок прохождения запроса пользователя к компоненту web.

На шагах 1, 2 и 3 запрос проходит через Ingress NGINX Controller, где выполняется обязательная аутентификация пользователя с использованием модуля user-authn.

Компоненты модуля

Модуль состоит из одного компонента:

  • Deckhouse-tools — состоит из одного контейнера web и реализует веб-интерфейс со ссылками на скачивание утилиты Deckhouse CLI.

Взаимодействия модуля

С модулем взаимодействуют следующие внешние компоненты:

  • Controller nginx — пересылка внешних запросов пользователя к веб-интерфейсу модуля.

Дополнительные ресурсы