Как мы боролись с овербукингом Kubernetes-кластеров

[lazy_val]

64 * 3 = 192

Надо бы поправить

[alekslebedev]

Спасибо, внесли правки!

[softError]

спасибо за интересную к прочтению статью, особенно за описание некоторых особенностей/багов JVM в контейнерной среде.
Правильно ли я понимаю, что одна из целей выставления "правильного" cpu request - ускорение старта JVM(ведь после старта сpu утилизировалась в меньшей мере)? Если это так, то почему в системе время старта JVM based пода настолько критично, ведь скорее всего он реплицирован и обновляется gradually (или же нет)? Или же имеет место ситуация, когда все поды сервисы перезагружаются одновременно?

[alekslebedev]

Мы не ставили во главу угла цель ускорить старт приложений, скорее пытались привести в порядок запросы на ресурсы от разработчиков, чтобы был единый подход к их выставлению. Но после отказа от CPU limits мы получили прирост и на старте, так как приложение больше не упиралось в них.

[cnmaste]

Какая полезная статья и знакомая проблема, спасибо!
При борьбе с похожей историей мы начали активно юзать validation/mutation хуки. Валидация не даст накосячить, а мутациями вмешиваемся в дев-окружения и другие не интересные развертывания, чтоб ресурсы в принципе не бронировали даже если хотят.

[AliveSubstance]

С памятью что-нибудь делали в итоге? VPA, случаем, не настраивали?