Проблема автоматического масштабирования GPU-нагрузок может заключаться не в том, что Kubernetes не способен принять решение, а в том, что решение принимается слишком поздно. Ramkumar Nagaraj и Bingi Narasimha Karthik из Adobe описывают инцидент, во время которого критически важный производственный сервис столкнулся с волной запросов, повысившей пользовательские показатели ошибок до 15–20%, несмотря на то, что Horizontal Pod Autoscaler начал масштабирование. Причина заключалась в том, что сотни контейнеров оставались в очереди, а новым GPU-узлам требовалось много времени, чтобы стать готовыми.
Согласно зафиксированной авторами последовательности событий, волна запросов началась в 06:00, показатели HPA превысили порог в 06:05, а планирование контейнеров началось в 06:15. Однако подготовка первых GPU-узлов завершилась только в 06:45 — уже после окончания всплеска. Подготовка GPU-узлов обычно занимает в три-пять раз больше времени, чем подготовка сервисов, использующих CPU, из-за загрузки встроенного ПО, настройки драйверов и подготовки CUDA.
От реакции на спрос к готовности к нему
Команда предложила запускать внутри Kubernetes контроллер каждые 60 секунд. Он считывает данные за предыдущий час и прогнозирует спрос через десять минут. Цель заключается не в идеальном прогнозировании, а в том, чтобы начать подготовку мощностей достаточно заранее, чтобы узлы и контейнеры были готовы к моменту возникновения волны.
В проекте использовались данные, собираемые Prometheus, включая загрузку CPU и памяти, время отклика, частоту запросов и загрузку GPU. Команда протестировала ARIMA, экспоненциальное сглаживание, библиотеку Prophet и LSTM, прежде чем выбрать двухслойную модель Bi-LSTM с 64 и 32 блоками соответственно. Согласно статье, выбор был обусловлен особенностями данных, включавшими короткие всплески, периоды восстановления и аномальные постоянные значения, а не тем, что эта модель теоретически лучше всего подходит для любого случая.
Модель переобучается еженедельно, а опубликованная модель работает только в режиме вывода внутри бинарного файла контроллера, написанного на Go, с использованием TensorFlow Lite. Поэтому проекту не нужны внешняя платформа машинного обучения или отдельный слой обслуживания моделей.
Три уровня управления масштабированием
Проект основан на трёх взаимосвязанных функциях: прогнозировании, подготовке и поглощении. Модель прогнозирует спрос, после чего контроллер постепенно увеличивает количество реплик, а заранее подготовленная мощность обеспечивает запас для фактической волны.
Поскольку прогнозирование не способно справиться с каждой неожиданностью, команда параллельно добавила детектор внезапных всплесков. Этот компонент сравнивает фактический спрос с прогнозами, используя адаптивный порог, рассчитанный на основе скользящего стандартного отклонения. Если спрос превышает прогноз на величину, соответствующую заданному уровню доверия, детектор ускоряет масштабирование. Авторы описывают этот компонент как эвристическую защитную сеть, а не как вторую прогнозную модель.
Поэтапный масштабировщик ограничивает увеличение 20 контейнерами в минуту. Это должно предотвращать массовую волну планирования, создающую нагрузку на планировщик и etcd и приводящую к конкуренции между операциями загрузки образов, запуска контейнеров, инициализации начальных контейнеров и внедрения побочных модулей. Целевой уровень использования также установлен на 70%, а не на 100%, чтобы сохранить запас для поглощения всплесков и позволить модели иногда ошибаться без превращения ошибки в цепочку сбоев.
Что показали испытания?
Сначала команда запустила систему в теневом режиме: прогнозы записывались, но фактическое масштабирование не выполнялось; было собрано более 500 часов данных. Результаты показали точность 85%, когда прогноз спроса через десять минут укладывался в диапазон ±10% от фактического спроса. Детектор всплесков также обнаружил девять из десяти волн, допустив два ложных срабатывания, тогда как испытания поэтапного масштабировщика не выявили случаев каскадных отказов или колебаний масштабирования.
Система также работала совместно с HPA v2 без конфликтов. В течение недели проверки в контролируемой среде разработки она успешно прошла 23 из 23 тестов. При моделировании сценариев всплеска, вызвавших исходный инцидент, система смогла обнаружить волну примерно за 11 минут до её возникновения.
Когда этот подход подходит?
Ценность прогнозируемого масштабирования проявляется, когда подготовка узлов занимает более двух-трёх минут, а спрос частично предсказуем — например, при наличии суточных, недельных или известных событийных закономерностей. Кроме того, необходимы качественные данные мониторинга: как минимум неделя метрик Prometheus. Напротив, идея менее оправданна, если узлы подготавливаются за 30 секунд, спрос полностью случаен или главным приоритетом команды является снижение стоимости: поддержание горячих узлов означает оплату резервной мощности.
Редакционный комментарий: Практическое изменение здесь заключается не в замене HPA, а в добавлении прогнозного времени к системе, которая обычно реагирует на спрос уже после его появления. Это особенно важно для GPU-нагрузок, поскольку скорости принятия решения о масштабировании недостаточно, если инфраструктуре требуются десятки минут до запуска контейнеров. Однако представленные доказательства по-прежнему получены в результате контролируемой проверки, а не независимого широкомасштабного измерения в нескольких производственных средах.
Опыт самой команды также указывает на важные ограничения: корректно настроенная модель ARIMA может дать близкий результат при более простой архитектуре, а модель может устареть за несколько дней при изменении структуры спроса. Кроме того, по-прежнему сложно объяснить, почему прогнозируется именно такое количество реплик; не решены окончательно вопросы об оптимальном объёме данных, периодичности переобучения и способности эвристического детектора всплесков обнаруживать беспрецедентные события.
Поэтому статья предлагает начать со сбора метрик за неделю, обучить простую модель, запустить её в теневом режиме и измерить точность до активации масштабирования. При переходе в производство следует установить максимальное количество реплик, предусмотреть понятную процедуру отключения и, желательно, пройти этап ограниченного масштабирования перед полным включением. Практический вывод, который повторяют авторы, таков: сложность модели сама по себе не является преимуществом; если более простое решение работает, лучше использовать его.