Автоскейлинг: HPA и Cluster Autoscaler
Увеличил число реплик (реплика - один из одинаковых экземпляров приложения) с двух до четырёх. Все четыре стали рабочими за 2884 миллисекунды. Потом обновил образ и смотрел на доступность каждые две секунды: готовых 3 из 4, актуальной версии 2, доступно 3; через восемь секунд актуальных уже 4; через десять - все четыре готовы. Доступность не опускалась ниже трёх из четырёх ни разу.
Стержень: масштабирование по числу экземпляров решает не всё - у него есть предел в виде общих зависимостей и время появления новой ёмкости.
// Формулировки: «как работает автоматическое масштабирование?», «почему добавление подов не помогло?», «как обновлять без простоя?»
Вширь, вверх и когда что
Вширь - больше экземпляров. Работает для приложений без состояния, где любой экземпляр обслужит любой запрос. Это основной способ, и он же самый быстрый: у меня две новые реплики поднялись меньше чем за три секунды.
Вверх - больше ресурсов одному экземпляру. Нужно там, где вширь не работает: одна база на запись, один процесс с большой памятью, приложение, которое не умеет работать в нескольких копиях. Цена - перезапуск: изменить ресурсы работающему поду обычно нельзя.
// И главный ограничитель, о котором забывают: добавление экземпляров упирается в ОБЩИЕ зависимости. Двадцать подов вместо пяти дадут вчетверо больше соединений к той же базе, и упрётесь вы не в кластер, а в предел соединений. Поэтому перед масштабированием стоит спросить, что у этих экземпляров общего: база, очередь, внешний сервис, общий диск. Именно там и находится настоящий потолок.
- масштабирование вширь
- больше одинаковых экземпляров; быстро, но упирается в общие зависимости
- масштабирование вверх
- больше ресурсов одному экземпляру; требует перезапуска
Автоматическое масштабирование
Автомат смотрит на метрику (обычно загрузку процессора или число запросов) и меняет число реплик, держа метрику около цели. Настроек у него три: минимум, максимум и целевое значение метрики. Минимум важен не меньше максимума - он держит запас на внезапный всплеск.
Главная тонкость - время. От роста нагрузки до готового обслуживать пода проходит: интервал опроса метрик, решение автомата, скачивание образа, старт приложения, прохождение пробы готовности. Это легко складывается в минуты, а всплеск от рассылки приходит за секунды. Поэтому автомат хорош для плавных предсказуемых изменений, а под известные пики мощность поднимают заранее, по расписанию.
// Второй механизм - масштабирование самого кластера: когда подам не хватает узлов, добавляются узлы. Тут время ещё больше, потому что машина должна загрузиться и войти в кластер. И третья тонкость: чтобы автомат работал по загрузке процессора, у подов ОБЯЗАНЫ быть заданы запросы - процент считается от них. Без запросов автомат просто не знает, от чего считать.
- целевое значение
- уровень метрики, около которого автомат держит число реплик
- время появления ёмкости
- от роста нагрузки до готового обслуживать пода; складывается из нескольких шагов
Обновление без простоя
Обновление идёт постепенно, а темп задают две настройки: сколько подов можно поднять сверх нормы и сколько можно держать недоступными. По умолчанию у меня стояло по 25% на обе, и на четырёх репликах это дало ровно то, что обещано: доступных всё время оставалось не меньше трёх.
Чтобы это работало, нужны три вещи. Проба готовности - без неё кластер считает под готовым сразу после старта процесса и переводит трафик на приложение, которое ещё не проснулось. Корректное завершение: под получает сигнал и должен дочитать текущие запросы, а не оборвать их. И бюджет недоступности - правило, запрещающее одновременно выводить больше N подов, оно защищает при работах на узлах.
// Отдельная деталь про завершение: между сигналом поду и его удалением из списка адресов сервиса проходит некоторое время, и они идут ПАРАЛЛЕЛЬНО. Поэтому в момент остановки на под ещё какое-то время приходят запросы. Лечится небольшой паузой перед завершением: под получает сигнал, продолжает отвечать несколько секунд и только потом закрывается.
- бюджет недоступности
- правило, сколько подов сервиса можно вывести одновременно
- корректное завершение
- дочитать текущие запросы после сигнала, а не обрывать их
Как отвечать: «Добавили подов, а быстрее не стало. Почему?»
Скорее всего, упёрлись не в кластер, а в общую зависимость. Экземпляры приложения делят между собой базу, очередь, внешний сервис - и двадцать подов вместо пяти дадут вчетверо больше соединений к той же базе, где предел соединений и находится настоящий потолок. Поэтому первым делом смотрю, что у реплик общего и где растёт очередь. Вторая частая причина: у подов не заданы запросы ресурсов, поэтому автоматическое масштабирование считает загрузку не от чего и работает неправильно. Третья: время. Я мерил, что сама раскатка быстрая - четыре реплики поднялись меньше чем за три секунды, - но полный путь от роста нагрузки до готового пода включает опрос метрик, скачивание образа, старт и пробу готовности, и это уже минуты. Если всплеск приходит быстрее, автомат не спасёт, надо поднимать мощность заранее.
Ответ сразу переводит разговор с числа подов на узкое место и называет три разные причины. Замер про быстрое масштабирование при медленном общем пути показывает понимание всей цепочки.
На чём валятся
- −Масштабируют вширь то, что упирается в общую базу или очередь.
- −Включают автомасштабирование по процессору, не задав подам запросы ресурсов.
- −Ставят минимум реплик в единицу и остаются без запаса на всплеск.
- −Рассчитывают на автомат там, где всплеск приходит быстрее, чем поднимается под.
- −Обновляют без пробы готовности и без корректного завершения и теряют запросы.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 7, остальные разбираются в тренажёре.
- HPA создан, нагрузка высокая, реплики не растут. В статусе — unknown по метрике. Что проверять?A)Максимум реплик: он мог быть достигнут молчаB)Наличие PodDisruptionBudget: он блокирует масштабированиеC)Права ServiceAccount у контроллера деплояD)Источник метрик и заданные requests у контейнеров
показать ответ и разбор
+D)Источник метрик и заданные requests у контейнеров// разбор: Unknown означает, что метрику не удалось получить или посчитать. Два частых случая: в кластере не установлен и не работает metrics-server (kubectl top тоже молчит) или у контейнеров нет requests по CPU — тогда процент утилизации не от чего считать. Реже — HPA смотрит на нестандартную метрику, а адаптер к ней не настроен.
- HPA добавил реплики, но новые поды висят в Pending, пока автоскейлер кластера поднимает ноду. Как сгладить провал?A)Держать запас ёмкости через поды-заглушки с низким приоритетомB)Уменьшить период синхронизации HPA до секундыC)Поднять maxReplicas, чтобы реплик заказывалось большеD)Отключить окно стабилизации, чтобы решения принимались мгновенно
показать ответ и разбор
+A)Держать запас ёмкости через поды-заглушки с низким приоритетом// разбор: Между решением HPA и готовой нодой лежат минуты: заказ машины, загрузка образов, старт. Классический приём — заранее занять место подами-заглушками с низким приоритетом: при всплеске их вытесняют, и настоящие поды стартуют сразу, а автоскейлер тем временем поднимает ноду под заглушки. Ускорять сам HPA бессмысленно — узкое место в поставке ёмкости, а не в частоте решений.
- HPA, VPA и cluster-autoscaler — что из них что масштабирует?A)Все три меняют число реплик, отличается лишь метрикаB)HPA меняет ноды, cluster-autoscaler — репликиC)VPA масштабирует ноды под нагрузку, HPA — памятьD)HPA — поды, VPA — размер пода, CA — ноды
показать ответ и разбор
+D)HPA — поды, VPA — размер пода, CA — ноды// разбор: Три разных уровня автоскейла: HPA (Horizontal Pod Autoscaler) меняет число реплик по метрике (CPU/кастомной); VPA (Vertical) подбирает requests/limits пода под реальное потребление; cluster-autoscaler добавляет/убирает ноды, когда подам не хватает места или ноды простаивают. HPA и VPA по CPU обычно не совмещают (конфликтуют). Часто связка HPA + CA: HPA плодит поды, CA подгоняет ноды.
- HPA дёргает реплики туда-сюда: то плодит, то сокращает по каждому всплеску. Как унять эти качели?A)Снизить целевой процент CPU до минимумаB)Настроить stabilizationWindow/behavior, чтобы сглаживать скачкиC)Убрать requests у контейнеров, чтобы метрика не скакалаD)Зафиксировать реплики вручную и отключить HPA насовсем
показать ответ и разбор
+B)Настроить stabilizationWindow/behavior, чтобы сглаживать скачки// разбор: Флаппинг HPA лечат политиками поведения: stabilizationWindowSeconds (особенно на scale-down) заставляет ждать устойчивого снижения перед сокращением; scaleUp/scaleDown behavior ограничивают шаг и темп изменения. Так HPA перестаёт реагировать на каждый короткий всплеск. Снижать целевой процент или убирать requests — только хуже. Цель — плавная реакция на тренд, а не на шум.
- Сервис тормозит, HPA по CPU плодит его реплики, но легче не становится — упор в общую базу. В чём ошибка автоскейла?A)Масштабируют не то звено: узкое место — БД, а не поды приложенияB)HPA настроен на CPU вместо памяти, отсюда бесполезностьC)Реплик всё ещё мало, нужно поднять максимум HPAD)Cluster-autoscaler не успевает поднимать ноды под реплики
показать ответ и разбор
+A)Масштабируют не то звено: узкое место — БД, а не поды приложения// разбор: Автоскейл помогает, только если узкое место — в масштабируемом звене. Здесь бутылочное горлышко — общая база (пул соединений, блокировки, диск), и добавление реплик приложения лишь усиливает на неё нагрузку, ухудшая ситуацию. Сначала находят реальный боттлнек (профилирование, метрики БД), потом масштабируют его (реплики чтения, пул, кэш) или ограничивают конкурентность к нему. HPA по CPU приложения тут бьёт мимо.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.