Deckhouse Monitoring Module: час до рабочего дашборда кластера без ручного YAML

В июле мы переводили кластер разработки на Deckhouse и вскользь упоминали встроенный мониторинг как приятный бонус. С тех пор провели ещё несколько установок - и встроенный стек стал одним из главных аргументов в разговоре с клиентами. Поэтому разбираем его отдельно и честно.

Проблема, которую мы решаем снова и снова

Ситуация типичная: есть кластер Kubernetes, нужен мониторинг. Берёшь kube-prometheus-stack, устанавливаешь через helm, начинается квест. Версия CRD не та. ServiceAccount конфликтует с существующим. additionalScrapeConfigs не применяется, потому что кто-то год назад вручную поправил ConfigMap. Grafana требует отдельного PVC, и непонятно, кто должен за ним следить. Алертинг - отдельная история с Alertmanager, его конфигом и попыткой разобраться, почему тестовый алерт не долетает до Telegram.

Это не жалоба на kube-prometheus-stack - он хорошо сделан. Это жалоба на то, что каждая установка с нуля требует дня-двух работы инженера, и каждый раз получается немного по-другому в зависимости от того, кто делал.

Что Deckhouse делает иначе

Мониторинг в Deckhouse - это не отдельный helm-чарт, который можно поставить или не поставить. Это модуль платформы, управляемый через CRD. Включается буквально так:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: prometheus
spec:
  enabled: true
  version: 2
  settings:
    retentionDays: 15
    storageClass: "fast"

Применяешь манифест - через несколько минут в кластере появляется Prometheus с уже настроенными ServiceMonitor-ами для всей внутренней инфраструктуры Deckhouse: etcd, kube-apiserver, controller-manager, scheduler, узлы через node-exporter, поды через cAdvisor. Grafana поднимается рядом, дашборды встроены и уже смотрят в этот же Prometheus.

Отдельного модуля для Grafana нет - она идёт в комплекте с prometheus. Alertmanager тоже. Каналы уведомлений настраиваются через отдельный CRD CustomAlertmanagerReceiver.

Как выглядит полная настройка

Ниже - всё, что нам понадобилось для одного клиента, чтобы получить рабочий мониторинг кластера с уведомлениями в Telegram:

Первое - включить модуль prometheus с параметрами retention и storageClass, как показано выше.

Второе - добавить receiver для алертов:

apiVersion: deckhouse.io/v1alpha1
kind: CustomAlertmanagerReceiver
metadata:
  name: telegram-ops
spec:
  type: telegram
  telegram:
    botToken: "<token>"
    chatID: "<chat_id>"
    parseMode: "HTML"

Третье - создать роутинг алертов через InternalTLSEnabled и AlertmanagerConfig - это чуть подробнее, но тоже CRD, не raw-конфиг Alertmanager.

Итого: три манифеста, один из которых - буквально пять строк. За час до нормального дашборда с алертами - это реально, если кластер уже работает на Deckhouse.

Что получаем из коробки

После включения модуля в Grafana появляются дашборды:

• Обзор кластера - узлы, CPU/RAM/диск, версия Kubernetes, состояние компонентов control plane.
• Поды и workloads - по неймспейсам, с разбивкой по контейнерам.
• etcd - latency, количество операций, размер базы, лидер.
• Ingress - запросы, статус-коды, latency по upstream, если используется nginx-ingress из Deckhouse.
• Узлы - через node-exporter, filesystem, network, system load.

Алерты по умолчанию тоже есть - Deckhouse поставляет набор PrometheusRule для основных ситуаций: OOMKill контейнера, недоступность узла, высокая утилизация диска, проблемы с etcd. Они включены сразу.

Где не обошлось без вопросов

Хранилище для метрик - первый вопрос, который надо решить до включения модуля. Если в кластере нет подходящего StorageClass с поддержкой ReadWriteOnce, Prometheus встанет в Pending. У Deckhouse нет магии для создания PVC из воздуха - нужно заранее позаботиться о storage. На bare metal мы обычно используем local-path или Ceph, в облачных окружениях - провайдерский CSI. Это не проблема Deckhouse, просто надо помнить.

Кастомные дашборды для приложений клиента требуют отдельной работы. Встроенные - только для самого кластера и компонентов Deckhouse. Если у клиента PostgreSQL или кастомный сервис с метриками, нужно добавлять ServiceMonitor вручную - стандартный ресурс Prometheus Operator, ничего специфичного для Deckhouse. Но это уже не «без YAML», а «с минимальным YAML».

Ещё нюанс: модуль monitoring-kubernetes-control-plane иногда требует отдельного включения, если control plane не управляется Deckhouse полностью (например, managed Kubernetes от облачного провайдера). Там метрики kube-apiserver и scheduler могут быть недоступны по сетевым причинам - зависит от конкретного провайдера.

Сравнение с ручной установкой kube-prometheus-stack

Мы не стали рисовать таблицу - она получилась бы маркетинговой. Честный вывод: если кластер строится на Deckhouse с нуля, встроенный мониторинг - очевидный выбор. Он версионирован вместе с платформой, обновляется вместе с ней, и не создаёт дрейфа конфигураций между кластерами.

Если же Deckhouse ставится поверх уже существующего Prometheus с годами кастомных дашбордов и правил - тут надо думать. Заменять рабочий мониторинг только ради интеграции с платформой - не очевидная задача, особенно если клиент завязан на конкретные алерты и их историю.

У нас сейчас несколько кластеров на управляемой инфраструктуре с мониторингом через Deckhouse. Опыт накапливается, следующий разговор - про кастомные PrometheusRule поверх встроенных и про то, как не потерять их при обновлении платформы.