Как вы выставляете memory and cpu requests для подов?

Question

[Вадим]

Относительно новый кластер с не очень большим, но растущем количеством пользователей. Поэтому решили перейти к системе с высокой доступностью и масштабируемостью.

Такой вопрос, как вы подходите к выставлению ресурсов для деплоймента приложений, которые будут служить основой для Horizontal Pod Autoscaler?

пример

resources:
  limits:
    memory: 190Mi
  requests:
    cpu: 80m
    memory: 190Mi

Используете ли вы результаты нагрузочных тестов или метрики с продакшена? Последние довольно сильно отличаются.

добра всем !

Comments

[mayton2019]

Ты хочешь, чтобы кто-то тебе дал готовую формулу нагрузки твоей системы?

Если ты - наблюдаешь нагрузку продуктовой системы то только ты знаешь ее.

По поводу нагрузочных тестов тебе надо спрашивать того, кто их разработал.

[Вадим]

я хочу услышать соображения опытных людей.. и да, думаю, что примерную формулу можно вывести, хотя она подойдет не для всех случаев, но предварительно можно

[shurshur]

Вадим, в реальной ситуации порой приходится действовать даже ситуативно: к поду посреди ночи приходит OOM killer и надо срочно починить. Тем более что реально никто не знает специфику конкретного приложения. Может, ему в новогоднюю ночь на пять минут потребуется 5x памяти...

[Mikhail Osher]

Вадим, какая еще формула? была бы формула, не нанимали бы столько девопсов, чтобы мониторить систему.

[Вадим]

Mikhail Osher, я рассчитывал на что-то вроде возьмите макс расход памяти за достаточный промежуток времени (месяц) с Prometheus, добавьте по XX% для запаса (в среднем для .net backends) или YY% (для node.js итд) и выставьте значение в requests... соответсвенно те же и в limits. Такого же рода и по cpu. Мониторьте поды на OOM kills. Рекомендация такого рода. От вас толку нет... старый прогер.

[shurshur]

Вадим, ну это самому можно догадаться, что берёшь максимум из мониторинга плюс немного запаса. Это не высшая математика.

[Mikhail Osher]

Вадим, ибо в Вашем вопросе невозможно дать однозначный ответ. Одно дело тюнить 5-долларовые впски под вордпресс, где всё плюс-минус одинаковое. А Ваш проект выглядит посложнее. И сразу не скажешь, насколько cpu или ram зависимая система, и какие спайки когда ожидаются.

[Вадим]

shurshur, понятно, но интересно было бы как раз про запасы, зависимости от фреймворков и языков итд

[shurshur]

Вадим, даже в системах с фиксированным максиальным размером кучи типа java сложно сказать, сколько будет накладных расходов на работу самой jvm. Вот выделили XMX=4G, а сколько реально будет использоваться? Может 5G хватить, а может не хватить. И это зависит в том числе от специфики приложения, структуры объектов в куче итд итп. Тут реально нельзя угадать.

А потом ещё разработчики выкатят новую версию, в которой потребуется чуть больше. Или вырастет доля очень маленьких объектов с более высокими накладными расходами на каждый. Или компилятор/флаги сборки поменяются. Или поменяется/обновится библиотека логгирования/шифрования/кофеварения. Никогда нельзя угадать, к чему это приведёт.

[Вадим]

shurshur,

будем методам проб и ошибок действовать. А в .net куча разве не фиксированная?

[shurshur]

Вадим, про дотнет ничего не могу сказать, эксплуатировать не приходилось.

[Вадим]

shurshur, нет, не фиксированная... растет по мере необходимости - для инфы

Answer 1

[akelsey]

В приведенном примере ресурсы и лимиты для подов kubernetes, эти настройки не имеют отношения к HPA.
Информация тут: https://kubernetes.io/docs/concepts/configuration/...

про HPA тут: https://kubernetes.io/docs/tasks/run-application/h...

Comments

[Вадим]

со всем уважением... можете удалить ваш ответ, это всем известные вещи. Я здесь больше о best practices спрашиваю

[akelsey]

Вадим, правильно заданный вопрос - половина ответа.

если по существу,

То как написали лучше вас продукт никто не знает, но за неимением лучшего я бы использовал исторические данные с прод., например с помощью подобного инструмента:
https://github.com/robusta-dev/krr

Возьмет метрики из прометея - проанализирует, составит вам таблицу - от которой можно будет отталкиваться.

[Вадим]

akelsey,

спасибо, не знал про такую тулзу !

[Вадим]

akelsey,

кстати, вы по средним значения расхода cpu и макс значениям памяти устанавливаете requests?

[Saboteur]

Вадим, реквест лучше ставить по минимуму, но с учетом "прогревания перформанса".

Answer 2

[Saboteur]

Приложения приложениям рознь.
Тут основной вопрос к разработчикам, чтобы они могли написать приложение, которое требует минимум ресурсов и в случае чего легко скейлится горизонтально.
Можно вообще выделить максимум 1 cpu/4gb памяти на под и сказать разработчикам - крутитесь как хотите, но чтобы все влезало в эти лимиты. Сюда влезет 90% микросервисов, но понятно что или придется пилить много микросервисов, и вдобавок какие-то тяжелые вещи типа базы данных сюда не влезут.
НО, все ведь зависит от нагрузки и количества клиентов.

Тут нужно не у опытных людей спрашивать, а сделать брейншторм архитектора и техлидов, чтобы определиться с архитектурой приложения и прикинуть что и как вы будете писать. Возможно нужно будет написать несколько концепций с перформанс тестами, чтобы посмотреть как оно идет в вашем случае.

А рандомные ответы из интернета дадут слишком общую картинку, которая может наоборот навредить.

Comments

[Вадим]

все бы хорошо, но приложения уже написаны и 50% разрабов ушли. Базы в куб не засовываем :-)
Да, концепции с перформанс тестами это правильная мысль.