Автоскейлеры Kubernetes решают разные задачи, но нередко меняют одни и те же параметры workload — число реплик, CPU и память контейнеров. В результате кластер может не экономить ресурсы, а устроить локальную борьбу контроллеров: один масштабирует приложение, другой пересматривает его запросы, третий пытается уплотнить поды на нодах. Для российских команд, которые держат production в Kubernetes, это не теоретическая тонкость, а источник лишних расходов и нестабильных SLO.
Проблему в материале от 24 октября поднимает Nikhil Kurup: как пишет The New Stack, вопрос «какой размер нужен checkout-api и сколько ему требуется реплик» только выглядит простым. В Kubernetes нет одного универсального ответа: он зависит от нагрузки, лимитов, доступной инфраструктуры, задержек, целей по стоимости и устойчивости сервиса. А несколько систем автоматического масштабирования смотрят на эту картину с разных сторон.
Когда автоматизация начинает спорить сама с собой
Горизонтальное масштабирование обычно отвечает на вопрос, сколько экземпляров приложения запустить. Вертикальное — сколько CPU и памяти выделить каждому экземпляру. Отдельно работает кластерный уровень: ему нужно добавить ноды либо, наоборот, убрать простаивающие машины. На бумаге обязанности разделены аккуратно. В живом кластере они пересекаются в одной точке — в ресурсных запросах и фактическом размещении подов.
Представим сервис с растущей CPU-нагрузкой. Контроллер, ориентированный на загрузку, может увеличить число реплик. Система подбора ресурсов способна увидеть другой сигнал и поднять CPU-запрос для каждой реплики. После этого планировщик обнаружит, что поды больше не помещаются на существующих нодах, а кластерный автоскейлер решит расширить пул машин. Нагрузка затем спадёт, но несколько контуров управления не обязаны синхронно прийти к прежнему состоянию. Команда получает больше инстансов, более крупные requests и инфраструктуру, которую уже не так просто быстро сократить.
Обратный сценарий неприятнее: вертикальная настройка увеличивает запросы настолько, что часть подов оказывается сложно разместить, а горизонтальный контроллер параллельно хочет добавить новые реплики. Для приложения это может выглядеть как дефицит мощности, хотя физические ресурсы в кластере есть — просто автоматика оценивает систему разными метриками и с разной задержкой. Особенно плохо это сочетается с сервисами, где p95 latency важнее средней загрузки CPU: метрика может выглядеть «здоровой», пока пользователи уже ждут ответ дольше допустимого.
Именно поэтому автоскейлинг нельзя сводить к включению пары стандартных контроллеров. Нужно заранее определить, какой контур имеет право менять конкретный параметр. Если число реплик регулируется по прикладной метрике — например, глубине очереди или числу запросов, — изменение CPU requests должно быть ограничено правилами и диапазонами. Если команда делает ставку на вертикальную оптимизацию, горизонтальное масштабирование нельзя оставлять без минимальных и максимальных границ. Иначе каждый компонент действует рационально в своей модели, а суммарный результат оказывается рациональным примерно как созвон трёх продакт-менеджеров без общего backlog.
Почему ручная настройка не масштабируется
У SRE и platform-команд есть привычный ответ: настроить пороги, cooldown-периоды, requests и limits вручную, а затем регулярно всё пересматривать. Для нескольких критичных сервисов это работает. Для платформы с десятками команд и сотнями deployment'ов — уже нет. Нагрузка меняется, версии приложений влияют на профиль потребления ресурсов, а команда, настроившая сервис полгода назад, может давно заниматься другим продуктом. Конфигурация остаётся, но её исходные предположения исчезают.
Kurup формулирует более жёсткий вывод: решение должно быть автономным. Речь не о том, чтобы отдать production безнадзорному алгоритму, а о едином контуре, который видит взаимосвязь реплик, размеров подов, доступной ёмкости и заданных ограничений. Такой контур должен не просто реагировать на единичную метрику, а выбирать действие с учётом последствий для всего кластера: поможет ли новая реплика, приведёт ли рост requests к масштабированию нод, не ухудшит ли изменение размещение соседних сервисов.
Для разработчиков практический вывод простой: качество autoscaling начинается ещё в манифесте приложения. Без адекватных requests, наблюдаемости по задержкам и ошибкам, понятной модели нагрузки и ограничений на масштабирование автоматика будет лишь быстрее воспроизводить неопределённость. Для бизнеса это вопрос не только облачного счёта: конфликтующие контроллеры способны одновременно создать перерасход инфраструктуры и ухудшить пользовательский опыт.
Следующий этап развития Kubernetes-платформ — не больше независимых автоскейлеров, а меньше несогласованных решений. Командам придётся выбирать: оставлять каждую петлю управления оптимизировать собственную метрику или строить общий механизм принятия решений. Чем плотнее кластер и чем выше цена простоя, тем менее убедительно выглядит надежда, что несколько «умных» контроллеров сами случайно договорятся.