Планирование Kuberenetes: как добиться поведения при планировании глубины? - PullRequest
0 голосов
/ 26 мая 2020

// Я почти уверен, что это дублирование или, по крайней мере, решенная проблема, но я не смог найти то, что искал, через поиск во многих сообществах k8.

У нас есть задания, которые выполняются для от минуты до многих часов. Учитывая, что мы назначаем им значения ресурсов, которые обеспечивают им статус Гарантированный QOS, как мы можем минимизировать трату ресурсов на узлах? . Они не распространены, но позволяют поддерживать все узлы в рабочем состоянии, даже если они нам не нужны. есть емкость, будет назначен самый заполненный. Другими словами, если у нас есть два общих узла, работающих при 90% использования ЦП / памяти и 10% назначенных ЦП / памяти, 90% всегда будут назначаться первыми при условии, что он имеет достаточную емкость.

Открыто для любого ввода здесь и / или идеи. Большое спасибо.

1 Ответ

0 голосов
/ 27 мая 2020
• 1000

Но он находится в альфа-стадии, начиная с k8s v1.18 +, поэтому, вероятно, использовать его для производства небезопасно.


Также есть этот параметр, который вы можете установить для kube-scheduler, который я нашел здесь :

MostRequestedPriority : отдает предпочтение узлам с наиболее запрашиваемыми ресурсами. Эта политика поместит запланированные модули на наименьшее количество узлов, необходимое для запуска общего набора рабочих нагрузок.

и вот пример того, как его настроить.


И последнее, что приходит мне в голову, это использование привязки узлов . Используя nodeAffinity на долго работающих модулях (точнее с preferredDuringSchedulingIgnoredDuringExecution), предпочтительнее планировать эти модули на узлах, которые работают все время, и предпочитать не планировать их на узлах, которые автоматически масштабируются. Этот подход требует исключения некоторых узлов из автомасштабирования и соответствующей маркировки, чтобы планировщик мог использовать привязку узлов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...