Кластер Kubernetes может показывать зелёные дашборды и при этом медленно деградировать: поды перезапускаются чуть чаще обычного, диск понемногу заполняется, реплики HPA подбираются к потолку - и ни один из этих сигналов по отдельности не выглядит критичным. Проблема большинства команд не в отсутствии мониторинга, а в его избыточности: собираются сотни метрик, дашборды разрастаются до десятков панелей, но инженер на дежурстве не может быстро отличить фоновый шум от предвестника инцидента. В результате алерты либо игнорируются из-за усталости от ложных срабатываний, либо реальная проблема тонет среди второстепенных графиков. Разбираем, какие показатели действительно определяют здоровье кластера, почему многие дашборды в продакшене показывают не то, что нужно, и как выстроить наблюдаемость так, чтобы она реально сокращала время реакции на инцидент, а не просто радовала глаз красивыми графиками.
Ресурсы подов: между запросом и лимитом
Самая частая ошибка - мониторить только факт превышения лимита, игнорируя динамику между request и limit. Именно в этом промежутке живёт большинство проблем с производительностью, которые не доходят до алертов, но постоянно снижают отказоустойчивость сервиса. Через оптимизацию использования CPU и RAM команды обычно проходят именно с анализа этого разрыва:
- CPU и Memory Requests vs фактическое потребление. Здоровым считается диапазон 60–80% от заявленного request в 90-м процентиле нагрузки. Меньшие значения означают переплату за неиспользуемые ресурсы, большие - риск конкуренции за ноду и вытеснения соседних подов.
- CPU и Memory Limit vs фактическое потребление. Ориентир - около 80% от лимита в 90-м процентиле. Превышение по CPU оборачивается тротлингом и ростом латентности, превышение по памяти - жёстким OOMKilled и потерей состояния приложения.
- Доля недоступных подов. Любое ненулевое значение этой метрики - уже отклонение от нормы, а не «допустимый шум». Порог алерта нужно подбирать под критичность конкретного сервиса, а не использовать одно значение для всего кластера, иначе фоновые перезапуски второстепенных компонентов будут маскировать деградацию действительно важных.
Отслеживание этих трёх показателей в связке даёт гораздо более точную картину, чем сумма отдельных алертов на CPU, память и рестарты подов по отдельности. Например, рост доли недоступных подов на фоне нормального потребления ресурсов почти всегда указывает не на нехватку мощностей, а на проблему с готовностью приложения, сетевой политикой или зависимостью от внешнего сервиса - и без сопоставления метрик друг с другом эта причина остаётся незаметной до тех пор, пока не перерастёт в полноценный простой.
Здоровье нод и предсказуемый автоскейлинг
Метрики уровня пода бесполезны, если сама нода деградирует. Инженеры часто узнают о проблемах на уровне инфраструктуры последними - уже после того, как её заметили пользователи. Чтобы этого избежать, стоит держать под наблюдением состояние узлов и параметры горизонтального масштабирования:
- Node condition checks. Ready, DiskPressure, MemoryPressure, PIDPressure и NetworkUnavailable нужно проверять с нулевой толерантностью - неисправная нода не должна оставаться в кластере дольше, чем требуется на автоматическое исключение из шедулинга.
- HPA desired replicas относительно максимума. Алерт стоит выставлять уже на 85% от установленного максимума реплик - это даёт запас времени на ручное вмешательство до момента, когда автоскейлер упрётся в потолок при растущей нагрузке.
- Утилизация Persistent Volume. Важна не текущая заполненность диска, а траектория роста: линейный прогноз позволяет спланировать расширение тома заранее, а не тушить инцидент по факту переполнения.
Комбинация health-checks нод и прогнозной метрики HPA закрывает большую часть инцидентов, которые иначе обнаруживаются только по жалобам пользователей. Важно понимать: нода редко выходит из строя мгновенно - обычно этому предшествует постепенное ухудшение показателей давления по диску или памяти, и именно это окно деградации даёт время на плановую замену узла без влияния на доступность сервиса, если наблюдаемость настроена на опережение, а не на констатацию уже случившегося отказа.
Как выбрать инструмент для мониторинга кластера
Выбор стека мониторинга зависит от масштаба инфраструктуры и от того, сколько времени команда готова тратить на поддержку самих инструментов наблюдаемости. Через платформенный мониторинг и метрики удобно сопоставлять несколько подходов сразу, не переключаясь между разрозненными системами:
- Prometheus и kube-state-metrics. Открытая pull-модель сбора метрик, гибкая и бесплатная, но требующая постоянной настройки правил алертинга и обновления дашбордов вручную при росте кластера - без выделенного времени на эту работу конфигурация быстро устаревает и перестаёт отражать реальную топологию сервисов.
- Полная видимость стека. Мониторинг должен охватывать не только Kubernetes, но и всю микросервисную цепочку целиком - иначе инженер видит здоровый под рядом с деградирующим внешним API и не понимает, откуда на самом деле пришла проблема.
- Автоматический анализ первопричины. AI-driven платформы вроде Dynatrace умеют самостоятельно связывать симптом с корневой причиной, что критично при большом количестве сервисов и коротком времени на реакцию дежурного инженера.
- Гибридная поддержка инфраструктуры. Если часть нагрузки остаётся вне облака, инструмент должен одинаково прозрачно показывать метрики локальных и облачных кластеров в одном интерфейсе, без переключения между разными системами и форматами дашбордов для каждой площадки.
Для небольшой команды разумной отправной точкой остаётся связка Prometheus и Grafana, но по мере роста числа сервисов расходы на поддержку самодельного стека мониторинга начинают конкурировать по стоимости с готовыми платформами. Каждое новое правило алертинга, каждый дашборд под новый сервис и каждое обновление экспортёров метрик требуют времени инженера - а это тоже часть реальной стоимости observability, которую редко считают на старте, но которая накапливается вместе с ростом кластера.
Мониторинг Kubernetes работает не тогда, когда собраны все возможные метрики, а когда из них отобраны те немногие, что действительно предсказывают инцидент. Ресурсы подов, здоровье нод, предел автоскейлинга и ёмкость хранилищ - тот минимальный набор, который стоит вывести на главный дашборд дежурного инженера, оставив остальные метрики для более глубокого разбора уже после срабатывания алерта. Такой подход не отменяет необходимость в глубокой диагностике, но избавляет команду от постоянного шума и позволяет реагировать на проблему до того, как её увидят пользователи, а не после жалоб в поддержку.