Модуль upmeter

Модуль upmeter проверяет доступность Deckhouse Kubernetes Platform (DKP) и состояние компонентов кластера в реальном времени. Результаты проверок отображаются на дашбордах.

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

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

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

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

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

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

1. Upmeter (StatefulSet) — контроллер, выполняющий следующие операции:

   • отслеживает кастомный ресурс Downtime и рассчитывает доступность компонентов DKP на основе интервалов простоя в этом ресурсе;
   • хранит метрики доступности компонентов DKP в локальной базе SQLite;
   • принимает и обрабатывает данные проверок компонентов DKP;
   • обрабатывает API-запросы на получение информации о доступности платформы;
   • отслеживает кастомный ресурс UpmeterRemoteWrite и отправляет результаты проб на эндпоинт, указанный в этом ресурсе, по протоколу Prometheus Remote Write.

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

   • migrator — init-контейнер, применяющий миграцию базы данных SQLite компонента;
   • upmeter — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к API upmeter.

2. Upmeter-agent (DaemonSet) — компонент, работающий на master-узлах кластера и выполняющий на регулярной основе следующие группы проверок:

   • control-plane — проверка доступности Kubernetes API, а также проверки работы контроллеров control plane кластера;
   • deckhouse — проверка состояния кластера DKP, а также проверка работоспособности deckhouse-контроллера модуля deckhouse;
   • extensions — проверки, что у всех расширений есть хотя бы один под в состоянии Ready;
   • load-balancing — проверки доступности сервисов, обеспечивающих сетевую балансировку;
   • monitoring-and-autoscaling — проверки того, что подсистема Observability исправно работает и собирает метрики с системных компонентов;
   • nginx — проверки того, что у всех Ingress-контроллеров есть хотя бы один под в состоянии Ready;
   • nodegroups — проверка количества desired узлов в каждой NodeGroup;
   • synthetic — проверка сетевого взаимодействия между узлами кластера через HTTP-запросы к компоненту smoke-mini-[a-e].

   В группу проверок control-plane входят следующие пробы:

   • apiserver — upmeter-agent проверяет доступность Kubernetes API;
   • basic-functionality — upmeter-agent проверяет базовую работу Kubernetes API через жизненный цикл ConfigMap;
   • namespace — upmeter-agent создаёт неймспейс upmeter-probe-namespace и после проверки удаляет его;
   • scheduler — upmeter-agent создаёт под с именем upmeter-probe-scheduler, проверяет, что он назначен на какой-либо узел кластера, и удаляет его;
   • controller-manager — upmeter-agent создаёт StatefulSet с именем upmeter-probe-controller-manager и с заведомо несуществующим контейнером в спецификации создаваемого пода, проверяет, что нужный под создался и находится в ожидаемом состоянии, после чего удаляет StatefulSet;
   • cert-manager — upmeter-agent создаёт ресурс Certificate (самоподписанный) с именем upmeter-probe-cert-manager, проверяет, что cert-manager сформировал соответствующий ресурс Secret, после чего выполняет удаление созданных ресурсов Certificate и Secret.

   Для проверки работоспособности deckhouse-контроллера выполняется следующая последовательность действий:

   • upmeter-agent создаёт или обновляет кастомный ресурс UpmeterHookProbe;
   • deckhouse-контроллер следит за этим ресурсом и выполняет хук для обновления ресурса;
   • upmeter-agent также следит за ресурсом UpmeterHookProbe и при изменении проверяет их корректность.

   Проверки или группы проверок могут быть отключены в параметре .spec.settings.disabledProbes модуля.

   Собранные результаты проб upmeter-agent отправляет через HTTP-запрос POST /downtime в upmeter.

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

   • chown-volume-data — init-контейнер, устанавливающий необходимые права доступа на каталог /var/lib/upmeter/agent на узле кластера;
   • migrator — init-контейнер, применяющий миграцию базы данных SQLite компонента;
   • agent — основной контейнер.

3. Smoke-mini-[a-e] (StatefulSet) — компонент для синтетических проверок связности. Он состоит из одного контейнера smoke-mini. При получении запроса от upmeter-agent экземпляры smoke-mini-[a-e] выполняют запросы друг к другу и к DNS-сервису кластера, после чего возвращают результаты проверок.

   При установке модуля upmeter, deckhouse-контроллер модуля deckhouse регистрирует хук, который распределяет экземпляры StatefulSet по разным узлам кластера (при такой возможности) и после этого каждую минуту перераспределяет по одной реплике StatefulSet на другой узел.

4. Status (Deployment) — компонент, состоящий из одного контейнера status и реализующий веб-страницу с текущим статусом доступности всех компонентов DKP.

5. Webui (Deployment) — компонент, состоящий из одного контейнера webui и реализующий дашборд для просмотра истории доступности каждого компонента DKP.

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

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

1. Kube-apiserver:

   • управление кастомными ресурсами UpmeterRemoteWrite и UpmeterHookProbe;
   • обработка кастомных ресурсов Downtime;
   • авторизация запросов к upmeter;
   • создание, проверка и удаление стандартных ресурсов Pod, StatefulSet, Namespace, Secret и кастомных ресурсов Certificate.

2. Внешние системы хранения метрик — отправка результатов проверок по протоколу Prometheus Remote Write.

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

1. Prometheus-main — использование правила мониторинга и метрик, связанных с модулем upmeter.

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

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

• Документация модуля upmeter