Как работает планировщик Кубернеса?

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

Моя первоначальная мысль заключается в том, что этот планировщик - это просто система управления доступом, а не настоящий планировщик. Правильно ли это?

Я нашел краткое описание, но это не очень информативно:

Планировщик kubernetes - это богатый политиками, имеющий топологию, специфичная для рабочей нагрузки функция, которая значительно влияет на доступность, производительности и емкости. Планировщик должен учитывать индивидуальные и коллективные требования к ресурсам, качество обслуживания требования, аппаратные/программные/политические ограничения, сродство и характеристики анти-аффинности, местность данных, межремонтная нагрузка вмешательство, сроки и т.д. Требования к рабочей нагрузке будут отображаться через API по мере необходимости.

Ответ 1

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

Планировщик - это не только контроллер допуска; для каждого созданного контейнера он находит "лучшую" машину для этого контейнера, и, если машина не подходит, контейнер остается незапланированным до тех пор, пока машина не станет подходящей.

Планировщик настраивается. Он имеет два типа политик: FitPredicate (см. Master/pkg/scheduler/predicates.go) и PriorityFunction (см. Master/pkg/scheduler/priority.go). Я опишу их.

Для предикатов требуются правила, например метки на node должны быть совместимы с селектором меток на контейнере (это правило реализовано в PodSelectorMatches() в predicates.go), а сумма запрошенных ресурсов контейнера (ов), уже запущенного на машине, плюс запрошенные ресурсы нового контейнера (ов), который вы планируете планировать на машине, не должны быть больше, чем емкость машины (это правило реализовано в PodFitsResources() в предикатах .go; обратите внимание, что "запрашиваемые ресурсы" определяются как pod.Spec.Containers [n].Resources.Limits, и если вы запрашиваете нулевые ресурсы, то вы всегда подходите). Если какое-либо из требуемых правил не выполняется для конкретной пары (новый модуль, машина), то новый модуль не запланирован на этой машине. Если после проверки всех машин планировщик решает, что новый блок не может быть запланирован на какой-либо машине, тогда блок остается в состоянии ожидания, пока он не будет удовлетворен одной из машин.

После проверки всех машин относительно предикатов соответствия планировщик может обнаружить, что несколько машин "подгоняют" модуль. Но, конечно, стручок может быть назначен только на одну машину. То, что происходит с приоритетными функциями. В основном планировщик оценивает машины, которые соответствуют всем предикатам соответствия, а затем выбирает лучший. Например, он предпочитает машину, чьи уже запущенные контейнеры потребляют наименьшие ресурсы (это реализовано в LeastRequestedPriority() в priority.go). Эта политика распространяет контейнеры (и, следовательно, контейнеры) вместо упаковки партий на одну машину, оставив другие пустыми.

Когда я сказал, что планировщик настраивается, я имею в виду, что вы можете решить во время компиляции, которые соответствуют предикатам и приоритетным функциям, которые вы хотите использовать Kubernetes. В настоящее время он применяет все те, которые вы видите в predicates.go и priority.go.

Ответ 2

Мы выполнили настройки, которые, например, применяют многоуровневое сродство и сродство на основе пользовательских селекторов. Планировщик не идеален, но он довольно хорош для большинства рабочих нагрузок на уровне сервиса, а в будущем должен быть намного лучше. https://docs.openshift.org/latest/admin_guide/scheduler.html#use-cases описывает одну конфигурацию планировщика Kube, которая обеспечивает это.