Планирование на основе фактического потребления: VPA в Kubernetes

info@vsetut.pro

Стать автором

Вернуться

29.09.2025 07:21:06 | Хабр

Хабы: Блог компании OTUS, Kubernetes, Программирование

Привет, Хабр!

Помните тот момент, когда вы в очередной раз выставляли requests и limits для вашего пода, основываясь на... чем, собственно? На глазок? На данных «ну там вроде 128 мегабайт хватает»? На результатах пятиминутного стресс‑теста, который показал, что под нагрузкой нужно 2 ядра? Мы все через это проходили. Получается классическая ситуация: либо мы недодаем ресурсов, и наш падает от OOMKilled в самый неподходящий момент, либо мы перестраховываемся и заливаем в него гигабайты памяти и ядра, которые он использует раз в год под Новый Год, а кластер тем временем плачет от нехватки нод.

Горизонтальное масштабирование (HPA) — наш спаситель, он известен всем и каждому. Увеличилась нагрузка — запустил еще пару копий приложения. Красиво. Но что, если само приложение не очень‑то умеет работать в несколько копий? Или если нагрузка не «всплесковая», а просто приложение со временем начало есть больше памяти из‑за роста данных? Тут подходит менее раскрученный, но полезный коллега — Vertical Pod Autoscaler (VPA).

Идея VPA до проста: он смотрит на фактическое потребление ресурсов вашими подами и говорит: «твоему приложению на самом деле нужно не 100 милликор, а стабильно 150, давай исправим эту несправедливость». А в продвинутом режиме он не просто говорит, а берет и делает. Главная загвоздка, из‑за которой многие плюются — для применения новых лимитов под нужно перезапустить, это downtime, но эту проблему можно и нужно грамотно обойти.

Подробнее