Управление кластерами DP

Для реализации механизма управления кластерами Deckhouse Platform (DP) используются модули commander и commander-agent.

Кластер DP, в котором установлен модуль commander, является управляющим кластером. Кластер DP с установленным модулем commander-agent является управляемым.

Модуль commander

Модуль commander реализует веб-приложение, позволяющее создавать однотипные кластеры на базе DP, управлять их конфигурациями и жизненным циклом.

Для установки модуля commander требуется экземпляр PostgreSQL, который может быть развёрнут вне кластера или в нём с помощью модуля managed-postgresql.

Подробнее с описанием возможностей, настройки и примерами использования модуля можно ознакомиться в разделе документации модуля.

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

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

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

Модуль включает в себя базовые, служебные и опциональные компоненты.

Базовые компоненты

В базовые компоненты модуля commander входят:

1. Frontend (Deployment) — компонент предоставляет веб-интерфейс для управления кластерами.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • frontend — основной контейнер.

2. Backend (Deployment) — основной компонент, реализующий следующие API-интерфейсы:

   • UI API — управление настройками кластеров, шаблонов и рабочих пространств;
   • внешний API для интеграций и автоматизации — операции с кластерами, задачами, шаблонами, проектами, ролями и др.;
   • API для работы с cluster-manager — обмен состояниями задач кластера и обработка фаз развёртывания и настройки управляемых кластеров;
   • API для работы с commander-agent — авторизация и приём агентских метрик, а также получение целевой конфигурации управляемого кластера.

   Backend обеспечивает следующие возможности:

   • управление жизненным циклом кластеров — создание, изменение или удаление кластера (через cluster-manager), перезапуск задач с ошибками и связанные проверки;
   • управление кластерным RBAC и ограничение прав на API-операции;
   • управление шаблонами, хранение целевых и текущих настроек кластеров;
   • управление хранилищами образов;
   • управление проектами и шаблонами проекта;
   • управление настройками биллинга (если компонент включён).

   Компонент хранит целевое состояние системы в экземпляре PostgreSQL, а также использует экземпляр Redis для публикации задач в управляемых кластерах и для получения результатов их обработки.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • backend — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к основному контейнеру.

3. Cable (Deployment) — компонент обеспечивает работу WebSocket для обновления UI в реальном времени.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • cable — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к основному контейнеру.

4. Sidekiq (Deployment) — компонент, реализованный на базе библиотеки Sidekiq и обеспечивающий работу с очередями в Ruby on Rails.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • sidekiq — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к основному контейнеру.

5. Cluster-manager (Deployment) — компонент, реализующий выполнение задач по развёртыванию и управлению конфигурацией управляемых кластеров DP, запрошенных компонентом backend.

   При создании нового кластера cluster-manager создаёт следующие ресурсы в неймспейсе d8-commander в управляющем кластере:

   • Deployment и Secret с именем dhctl-<REGISTRY_HASH>-<VERSION> — запуск dhctl в режиме gRPC-сервера. Cluster-manager использует RPC-вызовы для установки и настройки кластера DP;
   • для обработки подключений от commander-agent и реализации обратного канала взаимодействия с control plane соответствующего кластера:
     • Deployment (ampg-connector-<UUID>);
     • Service:
       • ampg-connector-<UUID>;
       • ampg-console-backend-<UUID>;
       • ampg-api-server-<UUID>;
       • ampg-deckhouse-tools-<UUID>;
       • ampg-aggregating-proxy-<UUID>;
       • ampg-upmeter-<UUID>;
       • ampg-label-proxy-<UUID>;
     • Secret (ampg-console-backend-<UUID>);
     • Ingress (ampg-agent-api-connector-<UUID>, ampg-console-backend-<UUID>);
   • DexClient (cluster-<UUID>) — настройка сервиса аутентификации для управляемого кластера с использованием возможностей модуля user-authn.

   Во время бутстрапа кластера cluster-manager также выполняет следующие действия в управляемом кластере:

   • устанавливает модуль commander-agent;
   • отключает модуль terraform-manager;
   • выполняет настройку аутентификации на основе контроллера Dex модуля user-authn. В качестве Dex-провайдера cluster-manager устанавливает DexClient cluster-<UUID> управляющего кластера;
   • настраивает подключение управляемого кластера к хранилищу образов;
   • если биллинг включён, создаёт кастомный ресурс PrometheusRemoteWrite для отправки метрик в компонент billing-prometheus управляющего кластера.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • cluster-manager — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к основному контейнеру.

6. Dhctl-<REGISTRY_HASH>-<VERSION> (Deployment) — компонент, состоящий из одного контейнера dhctl, запускает утилиту dhctl в режиме gRPC-сервера. Cluster-manager выполняет RPC-вызовы к серверу dhctl для установки или настройки управляемого кластера DP.

7. Ampg-connector-<UUID> (Deployment) — компонент, состоящий из одного контейнера main. Создаёт туннель и позволяет проксировать запросы к control plane управляемого кластера DP через входящее подключение от commander-agent.

   Компонент создаётся cluster-manager для каждого управляемого кластера DP.

8. Cluster-checker (Deployment) — компонент периодически выполняет запуск задач по проверке кластеров.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • backend — основной контейнер.

9. Cluster-task-checker (Deployment) — компонент периодически выполняет поиск запущенных задач, которые давно не сообщали о своём статусе, и переводит их в статус lost или lost_in_critical.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • backend — основной контейнер.

10. Redis (Deployment) — компонент состоит из одного контейнера redis и реализует отдельный экземпляр базы данных Redis, отвечающий за хранение данных об очередях задач и состояниях сессий commander.

11. Console-frontend (Deployment) — предоставляет веб-интерфейс администрирования управляемого кластера DP.

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

    • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
    • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
    • nginx — основной контейнер.

12. Console-backend (Deployment) — API-бэкенд администрирования управляемого кластера DP, обслуживающий запросы от компонента cluster-manager.

    Console-backend использует ресурсы Secret и Service, создаваемые компонентом cluster-manager, для подключения к control plane управляемого кластера DP.

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

    • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
    • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
    • backend — основной контейнер.

Служебные компоненты

В служебные компоненты модуля commander входят:

1. Cluster-task-cleaner (CronJob) — компонент запускается один раз в сутки и выполняет удаление завершённых задач, созданных более 30 дней назад.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • cluster-task-cleaner — основной контейнер.

2. Agent-tokens-rotation (CronJob) — регулярно выполняет обновление токенов для commander-agent.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • agent-tokens-rotation — основной контейнер.

3. Encryption-migrator (CronJob) — компонент запускается один раз в сутки и выполняет миграцию зашифрованных данных с SHA-1 на SHA-256. За один проход могут быть обработаны не все данные. Кроме того, после восстановления из резервной копии или из-за отложенных миграций могут появиться записи SHA-1.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • encryption-migrator — основной контейнер.

4. Audits-cleaner (CronJob) — компонент запускается один раз в сутки и удаляет старые аудит-логи.

   Deckhouse-контроллер модуля deckhouse создаёт audits-cleaner, если параметр модуля settings.featureFlags.auditsRetentionDays задан и определяет срок хранения аудит-логов.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • audits-cleaner — основной контейнер.

Опциональные компоненты

В опциональные компоненты модуля commander входят:

1. Billing-prometheus (StatefulSet) — компонент запускает Deckhouse Prom++ в режиме приёма метрик по протоколу Prometheus Remote Write.

   Модуль prometheus, установленный в управляемом кластере DP, отправляет метрики. Компонент хранит историю потребления ресурсов всеми управляемыми кластерами, что является важным источником данных для формирования отчётов по биллингу.

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

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

2. Billing-reports (StatefulSet) — компонент, запускающий веб-сервер nginx в качестве хранилища отчётов биллинга. Отчёты загружаются в nginx по протоколу Web-based Distributed Authoring and Versioning (WebDAV).

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

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

3. Billing-schedules-reporter (Deployment) — компонент реализует планировщик запуска и контроля задач для генерации требуемых отчётов биллинга.

   Компонент billing-schedules-reporter сохраняет сформированный отчёт в компоненте billing-reports по протоколу WebDAV.

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

   • wait-postgres — init-контейнер, проверяющий доступность экземпляра PostgreSQL;
   • wait-migrations — init-контейнер, ожидающий выполнения всех миграций в базе данных;
   • backend — основной контейнер.

4. Billing-aggregating-proxy (Deployment) — компонент выполняет агрегацию PromQL-запросов, проксирует их в billing-prometheus и возвращает результаты запросов.

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

   • billing-aggregating-proxy — сайдкар-контейнер, реализованный на базе Grafana Mimir, который обеспечивает оптимизацию запросов и кеширование данных. При отсутствии данных в кеше Grafana Mimir пересылает запрос на компонент billing-prometheus через сайдкар-контейнер promxy;
   • promxy — сайдкар-контейнер, реализованный на базе Promxy, который проксирует запросы к компоненту billing-prometheus и предоставляет единый эндпоинт для доступа к данным нескольких экземпляров Deckhouse Prom++;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к основному контейнеру.

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

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

1. Kube-apiserver:

   • работа с ресурсами Deployment, Service, Secret и Ingress в неймспейсе d8-commander;

   • авторизация запросов.

2. Хранилище образов — получение доступных релизов DP по каналам обновлений.

3. Экземпляр PostgreSQL — долговременное хранение состояния и метаданных кластеров, задач, токенов, проектов, параметров биллинга и отчётов.

4. Управляемый кластер — создание, изменение или удаление кластера DP.

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

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

• Prometheus-main — сбор метрик с компонентов модуля.

Модуль commander-agent

Модуль commander-agent реализует служебное подключение к управляющему кластеру DP.

Подробнее с описанием настроек модуля можно ознакомиться в разделе документации модуля.

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

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

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

Модуль состоит из одного компонента agent и одного контейнера commander-agent.

Agent выполняет следующие действия:

• приводит конфигурацию управляемого кластера в соответствие с целевой конфигурацией, полученной от backend модуля commander;
• собирает метрики управляемого кластера:
  • CPU cores — количество ядер узлов;
  • Memory — общий объём памяти узлов, ГиБ;
  • Filesystem — общий объём корневых дисков на узлах, ГиБ;
  • PVC — общий объём подключаемых дисков, ГиБ;
  • Nodes — общее количество узлов;
• собирает информацию о доступности кластера;
• устанавливает защищённое подключение к управляющему кластеру DP;
• отправляет метрики и информацию о доступности кластера в управляющий кластер DP;
• настраивает аутентификацию пользователей через Dex-провайдер управляющего кластера;
• если в управляющем кластере включён биллинг, agent создаёт кастомный ресурс PrometheusRemoteWrite для отправки метрик в сервис биллинга управляющего кластера DP.

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

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

1. Kube-apiserver — управление ресурсами управляемого кластера.

2. Prometheus — получение метрик управляемого кластера.

3. Upmeter — получение информации о доступности управляемого кластера.

4. Dex — синхронизация токенов доступа для запросов в API Kubernetes API из управляющего кластера в управляемый.

5. Управляющий кластер:

   • организация проксирующего подключения к управляющему кластеру;
   • получение целевой конфигурации кластера;
   • отправка метрик в сервис биллинга.

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

• Документация модуля commander
• Документация модуля commander-agent
• Документация модуля managed-postgresql
• Документация модуля prometheus
• Документация модуля terraform-manager
• Документация модуля user-authn