Кластер отдаёт метрики совсем не так, как обычный сервер. Главный расход здесь не узлы и не поды, а гистограммы control-plane: они растут от активности API, а не от размера кластера. Мы отсекаем их осознанно — и показываем, что именно теряется.
Цифры с нашего демо-кластера, и это кластер из одного узла. Всего в аккаунте было 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-адреса, он не занимает место в лимите хостов, и у него есть узлы:
K8sClusterDown — кластер перестал выходить на связь;K8sNodeNotReady — узел вышел из состояния Ready;K8sNodeDiskPressure и K8sNodeMemoryPressure — давление по
диску и памяти на узле;K8sPodCrashLooping — под перезапускается по кругу;K8sDeploymentDegraded — реплик меньше, чем требуется.Пороги правятся в личном кабинете, доставка — Telegram, почта, вебхуки. Тишину на время работ можно поставить по имени конкретного алерта.
В портале генерируется ссылка на манифест, дальше одна команда:
Внутри — сбор метрик с узлов и kube-state-metrics и CronJob, который раз в минуту
сообщает платформе состав кластера. Права запрашиваются только на чтение. Повторный
kubectl apply идемпотентен: кластер определяется по паре «клиент + имя из
манифеста» и не задваивается.
Инструкция в документации →
Важная деталь: превышение лимита узлов не обрывает мониторинг. Кластер, доросший до предела тарифа, не должен исчезать с радаров целиком — лишние узлы просто не сохраняются, а факт превышения виден в карточке отдельной строкой. Тарифы →
Только чтение. Манифест создаёт сервисный аккаунт с правами на просмотр узлов, подов и рабочих нагрузок; ничего изменять или создавать в кластере агент не может.
Да. Агенту нужен доступ к kube-state-metrics и к метрикам узлов изнутри кластера, а не к панели провайдера, поэтому способ создания кластера значения не имеет.
Мониторинг продолжит работать: лишние узлы не сохраняются, а превышение видно в карточке кластера. Кластер не исчезает из наблюдения — это было бы худшим поведением из возможных.
Да, на тарифах с индивидуальными условиями отсев настраивается. Но начинать стоит без них: за полгода эксплуатации перцентили control-plane не понадобились ни разу, а платить за них пришлось бы каждый день.
Да, и это редкий случай, который мы умеем: метрики кластера и метрики самой 1С видны рядом, на одной временной шкале.
Ограничение не техническое, а тарифное. После отсева гистограмм узлы дают предсказуемый и линейный прирост рядов, поэтому счёт идёт на десятки узлов без изменения архитектуры.
Один kubectl apply — и посмотрим на узлы, поды и алерты вместе. Без обязательств.
Запросить демо