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

Wait 5 sec.

Привет, Хабр!Помните тот момент, когда вы в очередной раз выставляли requests и limits для вашего пода, основываясь на... чем, собственно? На глазок? На данных "ну там вроде 128 мегабайт хватает"? На результатах пятиминутного стресс-теста, который показал, что под нагрузкой нужно 2 ядра? Мы все через это проходили. Получается классическая ситуация: либо мы недодаем ресурсов, и наш падает от OOMKilled в самый неподходящий момент, либо мы перестраховываемся и заливаем в него гигабайты памяти и ядра, которые он использует раз в год под Новый Год, а кластер тем временем плачет от нехватки нод.Горизонтальное масштабирование (HPA) — наш спаситель, он известен всем и каждому. Увеличилась нагрузка — запустил еще пару копий приложения. Красиво. Но что, если само приложение не очень-то умеет работать в несколько копий? Или если нагрузка не "всплесковая", а просто приложение со временем начало есть больше памяти из-за роста данных? Тут подходит менее раскрученный, но полезный коллега — Vertical Pod Autoscaler (VPA).Идея VPA до проста: он смотрит на фактическое потребление ресурсов вашими подами и говорит: "твоему приложению на самом деле нужно не 100 милликор, а стабильно 150, давай исправим эту несправедливость". А в продвинутом режиме он не просто говорит, а берет и делает. Главная загвоздка, из-за которой многие плюются — для применения новых лимитов под нужно перезапустить, это downtime, но эту проблему можно и нужно грамотно обойти. Читать далее