Комментарии 7
А как сильно может из-за троттлинга тормозить приложение? Просто если на 5% это одно, и может и не надо ничего делать, и это не проблема, а если на порядок - другое
Немного глаза режет мл.сек. Миллилитров секунд? Почему не мсек? По-русски должно быть или милли или м.
Не рассмотрен ещё один компромиссный (и, конечно же, спорный) вариант:
Допустим, ваше приложение в отсутствии лимитов потребляет 200m cpu, и работает на нодах с 4 или 8 ядрами. В некоторых случаях имеет смысл поставить лимит 2000m cpu (2 ядра). Скорее всего, при нормальном режиме работы приложения, троллинга никогда не случится. Но если что-то пойдет не так, например из-за ошибки в коде приложения, или из-за dos атаки на него, то приложение "не съест" всю ноду и всё-таки будет тротлиться.
Всю ноду не съест, потому что request гарантирует приложению его минимально доступное время CPU.
Ещё по теме рекомендую For the Love of God, Stop Using CPU Limits on Kubernetes и Why You Should Keep Using CPU Limits on Kubernetes
Upd: вот что действительно может съесть весь CPU, так это какой-нибудь iowait, но тут никакие лимиты не спасут.
прочитал как троллинг
С памятью все просто... Ну нет, с памятью все еще хуже. :)
Во-первых предложеное решение не сработает. Лимиты по памяти должны быть безальтернативно установлены. Иначе это грозит выселением всех подов с ноды или даже зависанием последней.
Во-вторых потребности в CPU гораздо проще определяются - смотришь график потребления CPU и выставляешь, и если нагрузка не меняется в 100 раз - у тебя все хорошо. С памятью так вообще не работает и сильно зависит от типа приложения. Одним ставишь лимит на 30% больше максимального RSS - и они работают как ни в чем ни бывало, например nginx. Другим ставить на 2000% больше максимального RSS в районе WSS - они стабильно и воспроизводимо падают, например postgres. Как формализовать установку лимитов по памяти, да так чтобы не тренироваться узнаванием "когда оно падает", до сих пор не знаю.
И еще кстати метрики CPU собираются как prometheus counter, а memory как gauge. А это значит что пропустить пик потребления CPU, который бы уперся в лимиты - невозможно, а по памяти - запросто (просто не попали и интервал "скребления", приходите "поскребсти" в следующих раз)
Троттлинг в Kubernetes. Или как настроить лимиты, чтобы приложения не “тормозили”