Упреждающее масштабирование GPU-нагрузок в Kubernetes: прогноз до пика¶
6.0/10
Контекст¶
Авторы описывают инцидент, когда реактивный HPA сработал слишком поздно: GPU-ноды поднимались около 40 минут, а пик трафика уже прошёл, вызвав ошибки у пользователей. Проблема была не в баге, а в несоответствии между скоростью провижининга GPU и реактивной логикой масштабирования.
Суть¶
Они построили контроллер, который каждые 60 секунд анализирует час метрик Prometheus и прогнозирует спрос на 10 минут вперёд. Архитектура состоит из трёх частей: Bi-LSTM предсказывает нагрузку, эвристический детектор всплесков ловит аномалии, а градуированный скейлер ограничивает масштабирование 20 подами в минуту, чтобы не перегрузить планировщик и etcd. Модель работает внутри бинарника контроллера через TensorFlow Lite, переобучается еженедельно и сосуществует с HPA v2. В теневом режиме авторы собрали более 500 часов данных и заявляют точность 85% в пределах ±10%, детектор поймал 9 из 10 всплесков, а 23 из 23 проверок в контролируемом окружении прошли без каскадных отказов. Они честно отмечают ограничения: Bi-LSTM, возможно, избыточен, а хорошо настроенный ARIMA дал бы 80% результата с меньшей инфраструктурой; ретраин стоит делать после инцидентов, а не раз в неделю; объяснимость модели остаётся слабым местом. Жёсткий потолок реплик и runbook для отключения — обязательные предохранители.
Вывод¶
Авторы делают вывод, что для медленного провижининга и предсказуемого трафика достаточно «хорошего, но не идеального» прогноза, сделанного заранее. Главный урок: модель важна меньше, чем последовательная валидация в теневом режиме и постепенное, ограниченное по скорости масштабирование.