Мониторинг Kubernetes: один кластер стоит как полсотни серверов — если ничего не делать
Кластер отдаёт метрики совсем не так, как обычный сервер. Главный расход здесь не узлы и не поды, а гистограммы control-plane: они растут от активности API, а не от размера кластера. Мы отсекаем их осознанно — и показываем, что именно теряется.
Напишите, что используете сейчас — Zabbix, Prometheus, PRTG или ничего. Отвечу сам и скажу, что можно упростить.
Откуда берутся десятки тысяч рядов
Цифры с нашего демо-кластера, и это кластер из одного узла. Всего в аккаунте было 49 000 рядов метрик. Из них 39 576 — гистограммы плоскости управления:
apiserver_request_duration_seconds_bucket— 10 370 рядов;etcd_request_duration_seconds_bucket— 8 375 рядов;- дальше по списку:
workqueue_*,rest_client_*,kubelet_runtime_operations_*,storage_operation_*.
Ключевое: эти ряды растут не от числа узлов, а от активности API. Добавьте деплойментов, операторов, CI, который постоянно что-то применяет, — и на живом кластере счёт идёт на сотни тысяч рядов с одного клиента. Именно поэтому «просто подключить Prometheus к кластеру» так часто заканчивается разговором про стоимость хранения.
Что мы с этим делаем и что теряется
Агент отбрасывает только суффикс _bucket у перечисленных
гистограмм. Ряды _sum и _count остаются, а значит остаются
средние задержки и скорость запросов — их считают именно по этим двум рядам. Теряются
только квантили: нельзя будет сказать «95-й перцентиль ответа apiserver». Это осознанный
размен, и мы называем его вслух, а не прячем в настройках.
Остаётся
Среднее время ответа apiserver и etcd, скорость запросов, ошибки, состояние узлов и подов, ресурсы, события кластера.
Уходит
Перцентили по времени ответа компонентов плоскости управления. Для клиентского кластера это диагностика уровня разработчика Kubernetes, а не эксплуатации.
Что видно в интерфейсе
Кластер в Voltir — отдельная сущность, а не строка в списке хостов. У него нет одного IP-адреса, он не занимает место в лимите хостов, и у него есть узлы:
- Кластер: статус, версия, число узлов и подов, метки.
- Узлы: имя, внутренний адрес, состояние Ready, версия kubelet. Список синхронизируется целиком — выведенный из кластера узел исчезает и из карточки.
- Дашборд: 29 панелей по узлам, подам, рабочим нагрузкам и ресурсам, разворачивается в вашей организации Grafana автоматически.
Алерты, которые приходят сразу
K8sClusterDown— кластер перестал выходить на связь;K8sNodeNotReady— узел вышел из состояния Ready;K8sNodeDiskPressureиK8sNodeMemoryPressure— давление по диску и памяти на узле;K8sPodCrashLooping— под перезапускается по кругу;K8sDeploymentDegraded— реплик меньше, чем требуется.
Пороги правятся в личном кабинете, доставка — Telegram, почта, вебхуки. Тишину на время работ можно поставить по имени конкретного алерта.
Подключение — один манифест
В портале генерируется ссылка на манифест, дальше одна команда:
Внутри — сбор метрик с узлов и kube-state-metrics и CronJob, который раз в минуту
сообщает платформе состав кластера. Права запрашиваются только на чтение. Повторный
kubectl apply идемпотентен: кластер определяется по паре «клиент + имя из
манифеста» и не задваивается.
Инструкция в документации →
Сколько кластеров и узлов входит в тариф
- Базовый — 1 кластер, до 10 узлов;
- Про — 5 кластеров, до 50 узлов;
- Enterprise — без ограничений.
Важная деталь: превышение лимита узлов не обрывает мониторинг. Кластер, доросший до предела тарифа, не должен исчезать с радаров целиком — лишние узлы просто не сохраняются, а факт превышения виден в карточке отдельной строкой. Тарифы →
Частые вопросы
Какие права получает агент в кластере?
Только чтение. Манифест создаёт сервисный аккаунт с правами на просмотр узлов, подов и рабочих нагрузок; ничего изменять или создавать в кластере агент не может.
Подойдёт ли для managed-кластера у облачного провайдера?
Да. Агенту нужен доступ к kube-state-metrics и к метрикам узлов изнутри кластера, а не к панели провайдера, поэтому способ создания кластера значения не имеет.
Что будет, если кластер вырастет за лимит тарифа?
Мониторинг продолжит работать: лишние узлы не сохраняются, а превышение видно в карточке кластера. Кластер не исчезает из наблюдения — это было бы худшим поведением из возможных.
Можно ли вернуть отброшенные гистограммы?
Да, на тарифах с индивидуальными условиями отсев настраивается. Но начинать стоит без них: за полгода эксплуатации перцентили control-plane не понадобились ни разу, а платить за них пришлось бы каждый день.
Мы запускаем 1С в Kubernetes — это поддерживается?
Да, и это редкий случай, который мы умеем: метрики кластера и метрики самой 1С видны рядом, на одной временной шкале.
Сколько узлов реально потянет один кластер в мониторинге?
Ограничение не техническое, а тарифное. После отсева гистограмм узлы дают предсказуемый и линейный прирост рядов, поэтому счёт идёт на десятки узлов без изменения архитектуры.