Kubernetes v1.36: метрики PSI стали стабильными — как это поможет бороться с задержками

Вы когда-нибудь видели, что CPU загружен на 70%, а приложения тормозят? Классические метрики использования ресурсов часто обманчивы. В Kubernetes v1.36 появилось решение: метрики PSI (Pressure Stall Information), которые показывают не просто процент занятости, а время, которое задачи провели в ожида

Kubernetes v1.36: метрики PSI стали стабильными — как это поможет бороться с задержками

Вы когда-нибудь видели, что CPU загружен на 70%, а приложения тормозят? Классические метрики использования ресурсов часто обманчивы. В Kubernetes v1.36 появилось решение: метрики PSI (Pressure Stall Information), которые показывают не просто процент занятости, а время, которое задачи провели в ожидании ресурсов. Теперь этот механизм официально стабилен (GA), а значит, готов к боевым нагрузкам.

PSI — это не просто ещё один датчик. Он был впервые реализован в ядре Linux в 2018 году и с тех пор помогал администраторам выявлять насыщение ресурсов до того, как оно перерастёт в аварию. В отличие от стандартных метрик утилизации, PSI показывает, сколько времени задачи были заблокированы из-за нехватки CPU, памяти или I/O — и всё в удобных процентах за последние 10, 60 или 300 секунд. С выходом Kubernetes v1.36 эти данные стали доступны через стабильный интерфейс на уровне узлов, подов и контейнеров.

Как PSI изменил мониторинг в Kubernetes

Главная проблема традиционного мониторинга — он может показывать 80% загрузки CPU, в то время как часть задач уже страдает от серьёзных задержек из-за планирования. PSI решает эту проблему, предоставляя два типа данных: кумулятивные суммы времени в состоянии ожидания и скользящие средние за окна 10, 60 и 300 секунд. Это позволяет отличить кратковременные всплески от устойчивой нехватки ресурсов.

В Kubernetes v1.36 метрики PSI собираются на трёх уровнях. На уровне узла — через kubelet, который агрегирует данные из /proc/pressure/. На уровне подов и контейнеров — через cgroups v2, где PSI отслеживается для каждой контрольной группы. Включить сбор можно через фичу-гейт KubeletPSI, который теперь стабилен и включён по умолчанию. Для просмотра метрик используйте стандартные эндпоинты /metrics/resource/v1alpha1 и /metrics/resource/ в kubelet.

Почему это безопасно для продакшена?

Когда речь заходит о новых метриках, первый вопрос — не повлияет ли сбор на производительность. SIG Node провела масштабное тестирование на высокоплотных нагрузках (более 80 подов) на разных типах машин. Сценарии были такими: сравнение работы kubelet с включённым и выключенным сбором PSI (при активном ядре) и сравнение работы ядра с PSI и без него (при активном kubelet).

Результаты оказались обнадёживающими. На 4-ядерных машинах накладные расходы kubelet составили менее 0,5% CPU и менее 1% памяти. На 8-ядерных — ещё меньше. Ядро Linux при включённом PSI (psi=1) добавляло не более 0,2% CPU. Таким образом, даже на плотных кластерах сбор PSI практически не влияет на производительность. Это подтверждает, что метрики можно смело включать в продакшене.

Кому это пригодится

Разработчики и SRE-инженеры получат возможность точно определять, какой именно ресурс вызывает задержки. Например, если приложение жалуется на медленные ответы, можно посмотреть PSI для его пода и увидеть, что 5% времени оно ждёт I/O, а не CPU. Это ускоряет диагностику и помогает оптимизировать запросы ресурсов. Бизнес-команды, в свою очередь, смогут точнее планировать ёмкость кластеров, избегая как недогруза, так и перегрузок.

Для российских компаний, использующих Kubernetes на собственных серверах или в облаках, PSI — это способ снизить затраты на инфраструктуру за счёт более точного выделения ресурсов. Вместо того чтобы гадать, почему сервис тормозит, можно сразу увидеть корень проблемы.

Как настроить мониторинг PSI в Kubernetes?

Настройка мониторинга PSI не требует сложных манипуляций. Поскольку KubeletPSI включён по умолчанию, достаточно убедиться, что ваши узлы используют ядро Linux с поддержкой PSI (версия 4.20+ с параметром psi=1). Для сбора метрик используйте Prometheus, настроив таргеты на эндпоинты kubelet. В Grafana можно создать дашборды, отображающие скользящие средние PSI для CPU, памяти и I/O по каждому поду. Это позволит оперативно выявлять проблемные компоненты.

Что дальше

С выходом Kubernetes v1.36 PSI становится стандартным инструментом мониторинга. В будущих версиях ожидается интеграция с HPA (Horizontal Pod Autoscaler) для автоматического масштабирования на основе PSI, а также улучшенная визуализация в дашбордах Grafana. Команда SIG Node продолжает работу над снижением накладных расходов и расширением метрик для новых типов ресурсов.

Итог

Метрики PSI в Kubernetes v1.36 — это не просто очередная фича, а важный шаг к более умному и отзывчивому мониторингу. Они позволяют увидеть реальные задержки, скрытые за средними значениями, и принять меры до того, как проблема станет критической. Если вы управляете кластерами Kubernetes, самое время включить PSI и начать получать честные данные о состоянии ресурсов.