Как сделать так, чтобы модули распределялись равномерно по узлам при добавлении нового хоста?

avatar
TheQueenIsDead
9 августа 2021 в 04:03
109
1
0

Обзор

Ошибка планирования Kubernetes заключается в том, что «не перетасовывает вещи после запланированного и счастливого», что может привести к довольно высокому уровню дисбаланса с точки зрения распределения ЦП, памяти и количества контейнеров. Это также может означать, что иногда правила Affinity и Topology могут не применяться / по мере изменения положения дел:

Относительно ограничений распространения топологии, введенных в версии 1.19 (стабильная)

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

Контекст

В настоящее время мы используем ограничения распространения топологии pod, и они довольно превосходны, за исключением того факта, что они, кажется, обрабатывают перекосы только во время планирования, а не выполнения (в отличие от способности различать с Загрязнения и допуски).

Для таких функций, как Привязка узлов, в настоящее время мы ожидаем возможности добавления требований RequiredDuringExecution вместо ScheduledDuringExecution требований

Вопрос

Мой вопрос:, есть ли собственный способ заставить Kubernetes переоценить и попытаться применить перекос распространения топологии при добавлении нового домена сбоя (топологии) без записи мой собственный планировщик?

Или мне нужно подождать, пока Kubernetes выпустит еще несколько выпусков? ;-) (Я надеюсь, что у кого-то может быть умный ответ относительно объединения ограничений сходства/топологии)

Источник

Ответы (1)

avatar
TheQueenIsDead
9 августа 2021 в 04:03
0

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

Похоже, не существует комбинации ограничений Taints, Affinity rules или Topology, которые могли бы работать вместе для достижения повторной оценки правил топологии во время выполнения.

Descheduler позволяет убивать определенные рабочие нагрузки в зависимости от требований пользователя и позволяет kube-scheduler по умолчанию перепланировать удаленные модули. Его можно легко установить с помощью манифестов или Helm и запускать по расписанию. Его можно даже запускать вручную при изменении топологии, что, я думаю, мы реализуем в соответствии с нашими потребностями.

Это будет лучшим средством для достижения нашей цели, пока мы ждем, пока правила RequiredDuringExecution станут зрелыми для всех предложений функций.

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

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "LowNodeUtilization":
    enabled: true
    params:
      nodeResourceUtilizationThresholds:
        thresholds:
          "memory": 20
        targetThresholds:
          "memory": 70