Автомасштабирование кластера (Cluster Autoscaler)
Cluster Autoscaler — это компонент
MKaaS, который автоматически меняет количество воркер-нод в вашем кластере в зависимости от текущей нагрузки. Он добавляет новые ноды, когда приложениям не хватает ресурсов, и удаляет лишние, когда нагрузка снижается. Это позволяет не думать о ручном масштабировании инфраструктуры и не переплачивать за простаивающие ресурсы.
Как это работает
Автоскейлер анализирует состояние кластера примерно раз в минуту и после каждой проверки принимает одно из решений:
- добавить ноды (Scale Up);
- удалить ноды (Scale Down);
- ничего не менять.
Важно. Решения принимаются не по фактической загрузке CPU или памяти, а по ресурсам, запрошенным в манифестах подов (Resource Requests). Если под запросил 4 CPU, но реально использует 5%, для автоскейлера эти 4 CPU всё равно считаются занятыми — освободить их сможет только удаление или изменение самого пода.
Поэтому показатели в мониторинге (Grafana, Prometheus, `kubectl top`) и логика автоскейлера могут расходиться: нода может выглядеть почти пустой по факту использования, но при этом считаться полностью занятой, если ресурсы под неё были заранее зарезервированы.
Когда добавляются новые ноды (Scale Up)
Масштабирование вверх запускается, если в кластере появляются поды, которые невозможно разместить на существующих нодах. Автоскейлер сам определяет, в какой пул нод добавить ресурсы, и сколько нод потребуется.
Расширение кластера не произойдёт, если:
- под не помещается даже на новую ноду выбранного пула;
- пул уже достиг максимального размера, заданного в настройках;
- ограничения планирования (например, правила размещения подов) не позволяют разместить под даже после добавления ноды.
Когда ноды удаляются (Scale Down)
Нода удаляется автоматически, если одновременно выполняются условия:
- суммарные запросы ресурсов подов на ноде занимают менее 50% её ёмкости;
- нода находится в таком состоянии продолжительное время;
- все поды с этой ноды можно безопасно перенести на другие ноды.
Удаление ноды может не произойти, даже если она почти не используется. Частые причины:
- настроен PodDisruptionBudget, запрещающий выселение подов;
- на ноде запущен под, не управляемый контроллером;
- под использует локальное хранилище на этой ноде;
- правила размещения (affinity, taints, топология) не позволяют перенести под;
- на поде или ноде стоит аннотация, запрещающая удаление.
Границы масштабирования
У каждого пула нод есть минимальное и максимальное количество нод, заданное в настройках кластера. Автоскейлер никогда не выйдет за эти границы — ни вверх, ни вниз.
Что стоит учитывать при проектировании нагрузки
- Указывайте Resource Requests осознанно. Именно они определяют, как быстро и насколько сильно будет масштабироваться кластер, а не реальное потребление ресурсов.
- PodDisruptionBudget защищает доступность приложения при плановых операциях (например, при Scale Down), но не спасает от аварийного отказа ноды.
- Правила размещения подов (affinity, taints/tolerations, топологические ограничения) могут привести к тому, что под останется в состоянии Pending, даже если в кластере формально есть свободные ресурсы — просто не на той ноде.
Если у вас есть приложения с особыми требованиями к размещению (например, GPU-нагрузка или строгое распределение по зонам доступности), рекомендуем заранее продумать соответствующие настройки в манифестах, чтобы автоскейлер мог корректно на них реагировать.
