тем что в cluster-autoscaler у них дефолтные настройки стоят? А именно --skip-nodes-with-local-storage=true. То есть ноды, на которых есть поды с emptyDir игнорируются и никогда не даунскейлятся когда реквесты подов ниже scale-down-utilization-threshold? В поддержке ответили, что настройки менять в cluster-autoscaler не предусмотрено
Казалось бы, descheduler может решить проблему c помощью стратегии HighNodeUtilization. Но она бесполезна, если не настроить scheduler куба на стратегию уплотнения нод, поды будут просто создаваться на тех же нодах после удаления. А в яндекс кубе естественно нельзя задавать кастомные настройки scheduler, так как это тоже не предусмотрено.
Неужели все пишут свои костыли?
Если честно чем дольше использую managed куб от яндекса, тем больше проблем. Начинаю жалеть что свой куб просто поверх виртуалок не развернул
Я просто отказался от автоскейлинга.
а как же экономия =). Ночью хотелось бы ноды прибивать
джобы запускаются на специфичных нодах, всегда резервируется одна резервная нода для ворклоадов
у меня вон, по ночам почти нет нагрузки на одной приложеньке
По ночам почти нагрузки нет на одной приложеньке, жалко что ноды проставивают
по ночам почти нагрузки нет на приложеньки, жалко что ноды проставают =(
а ты можешь подсчитать, вот с утра пойдет трафик, соклько у тебя будут создаваться ноды? и какие косты для бизнеса будут, если триггер не сработает? я поговорил с бизнесом - мне дали ок, что затраты на. то, что поды ночью будут рабоатть в холостую, нежели вв нужный момент просто не поднимится нода или будет создаваться группа нод полчаса и болеее (по моим замера на поднятие одной ноды уходит примерно 7-10 минут в ЯО, в хороших условиях, а не как что-то у них было в пятницу)
#yandex #cluster_autoscaler #clusterautoscaler #scheduler #descheduler По тикету ответ: нет, флажок с true на false в cluster-autoscaler не поменяют. Адекватных workaround'ов нет, предложили странный с pvc вместо emptyDir и daemonset'ом вместо деплоймента. Но это дичь для моего кейса
Обсуждают сегодня