надо минимум 500 CPU, чтобы стартовать хотя бы за 15 минут, но потом за неделю дай бог 100 используется.
В итоге суммарно набегает например 100 CPU по лимиту, а фактически используется 10
burstable
Чем это поможет?
Пусть при старте троттляся
А что тогда? Я вот не пойму как быть. Купить 200 ядер, чтобы потом получить по ебалу за утилизацию 20 ядер дай бог в пик нагрузки? Или как...
писать софт так, чтобы он не жрал на старте как не в себя. Либо мириться с тем, что он стартует не 5 секунд, а 500
Я тестил вчера старт с 100/100 цпу и это Spring и за 20 минут мы успели подняться + миграции, а ещё даже до кафки не дошли )
у вас цель то в чем? задачу упаковки решить или что? дайте ему 100/12000
Есть сервисы, если по их лимиту в 500цпу брать, то 190 ядер выходит. На старте приложение чтобы запустилось за 10-20 минут надо 500цпу Но потом при использовании по статистике за неделю все сервисы эти жрут суммарно 10-15 ядер, задача в утилизации
ну так пусть они у вас шаренные ядра используют, которые между собой пересекаются, когда надо кому надо будет жрать чуть больше
ты не решишь проблему фундаментально
Я хотя бы хочу понять, как такое решают вцелом
Может быть vertical pod autoscaler поможет. Можете ещё отключить cfs quota. Я столько времени страдал с тротлингом, и отключил его в итоге. Все приложения в кубе стали стабильней работать. В целом весов по CPU share хватает (они же CPU requests), для справедливого деления ресурсов CPU на ноде.
И не страдал с шумными соседями?
так он в динамике не работает вроде
Почему спросил, есть у меня один легаси кластер, где я хочу отключить его, но боюсь, что тяжелая джоба может хорошо отъесть у остальных время
так даже если шумные, у тебя все равно ядро более или менее справедливо им веса назначает Ну то есть условно два процесса по 1000m, но один хочет больше. Ядро ему даст больше, но при этом не заберет у первого
они вообще все равны помоему
нет, от реквестов зависит
VPA поды пересоздает, он не поможет
я просто слышал что это хотели улучшить и думал что улучшили ошибочка
пусти пару pod'ов на ноду, и запусти свою тяжелеую джобу на ней же. Проверь просядут ли те поды
не, я про кейс, когда у всех или отсутвуют реквесты или они равны, так то да.
а я про отключение cfs quota, что отключает по сути лимиты, то есть отключает cpu.cfs_quota_us
Ога , после отпуска сделаю. А то как-то все не решался
ну у меня вот был кейс. nodejs приложение: Даю 1000m cpu request = limit - более или менее сносно работает. Но все равно довольно много вижу медленно выполняемых запросов Смотрю мноиге поды упираются и сильно тротлятся. Ну окей повысил - дал 1500m cpu - request = limit Количество 499 еще больше увеличилось =) тротлинг вроде как уменшился, но hpa уменшил количество подов и походу меншее количество подов не держат просто нагрузку, и плевать что у каждого cpu теперь больше. Ну и надо помнить что nodejs однопоточная Вернул на 1000m - количество 499 уменшилось Вобщем потом попробовал отрубить cfs quota нафиг совсем. количество 499 в разы уменшилось. Встало на нормальный уровень (0.01 - 0.05%) P.S. 499 - когда клиент на своей стороне отменяет запрос Понятное дело что этот кейс про конкретное приложение. Но ваще по ощущением в этом кластере все приложения стали себя лучше чувствовать
Ну, у меня на том кластере крутятся и нода, и дот нет, и джава (8 есть тоже, а она не умеет а cgroup), и пхп, и гошка. Сложно однозначно все сказать
Обсуждают сегодня