Планирование Kubernetes от мелкого к глубокому: структура

облачный носитель

Сегодня zouyee расскажет вам о некоторых интересных фактах о CNCF за последнюю неделю:

  1. Завершились выборы представителя сообщества Kubernetes в Великобритании Пэрис Питтман избрана

  2. Проекты инкубатора CNCF в выпускной процесс OPA

  3. прошлая неделяhelmПроект выпускает функциональную версию v3.5.0

  4. Проект CoreDNS выпускает приложение для снятия ограничений через репозиторий образов Docker.

Книга связана с вышеупомянутой серией «Система планирования Kubernetes от мелкой к глубокой: предварительное исследование», сегодня zouyee представляет вам «Планирование Kuberneter от мелкой к глубокой: структура», соответствующая версия этой серии1.20.+.

1. Обзор предыдущей статьи

В разделе «Система планирования Kubernetes от мелкой к глубокой серии: предварительное исследование» приведена общая диаграмма взаимодействия для создания интуитивного опыта планирования подов. Мы расширяем диаграмму взаимодействия, как показано ниже.

Примечание. Эта диаграмма взаимодействия не является профессиональным UML, пожалуйста, поймите.

图1 交互流程图

Вышеприведенное использует создание Pod в качестве примера, чтобы кратко представить процесс планирования:

  1. Пользователи создают поды через командную строку (выберите создание подов напрямую вместо других рабочих нагрузок, чтобы пропустить kube-controller-manager)

  2. kube-apiserver записывается в etcd после проверки объектов, допусков, квот и других операций доступа

  3. kube-apiserver возвращает результат пользователю

  4. В то же время kube-scheduler прослушивает события node, Pod и т. д. (процесс 1).

  5. kube-scheduler добавляет модуль spec.nodeName в очередь планирования, система планирования выбирает модуль и входит в цикл планирования (представленный в этой статье) (процесс 2–3).

  6. kube-scheduler привязывает pod к узлу с наивысшим баллом (процесс 4)

  7. Kube-Apisiserver записывает привязку информацию для EtCD

  8. Кублет отслеживает назначенный ему под и вызывает интерфейс CRI для создания пода (эта часть контента будет представлена ​​позже в этой серии).

  9. После того, как kubelet создает под, он обновляет статус пода и другую информацию и сообщает об этом kube-apiserver.

  10. kube-apiserver записывает данные

2. Фон рамки

С увеличением функций в Kubernetes код и логика также становятся все более сложными. Увеличение размера и сложности кода неизбежно приведет к увеличению затрат на обслуживание, что неявно усложняет поиск и исправление ошибок. Старые версии планировщика Kubernetes (До 1.16) предоставляет веб-перехватчики для расширения. Но у него есть следующие недостатки:

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

  • Вызов интерфейса расширения использует HTTP-запросы, на которые влияет сеть и которые имеют гораздо более низкую производительность, чем локальные вызовы функций. В то же время каждый вызов должен сериализовать и десериализовать информацию Pod и Node, что еще больше снизит производительность.

  • Текущая связанная информация Pod не может быть доставлена ​​вовремя (с использованием кеша планирования).

Чтобы решить вышеупомянутые проблемы и сделать код системы планирования оптимизированным и более масштабируемым, сообщество Kubernetes 1.16Начиная с версии, была введена новая структура планирования - структура планирования.

Основываясь на исходном процессе планирования, рамочная структура планирования определяет множество интерфейсов точки расширения. Разработчики могут реализовывать плагины, реализуя интерфейсы, определенные точками расширения, и регистрируйте плагины с точки зрения удлинения. Когда структура планирования выполняет процесс планирования и запускается к соответствующей точке расширения, он выполняет плагин, зарегистрированный пользователем и генерирует результат текущего этапа. Таким образом, логика планирования пользователя встроена в рамки планирования. Рамка планирования корректирует следующие цели:

  • Масштабируемость: планирование более масштабируемо
  • Ремонтопригодность: перенос некоторых функций планировщика в плагины
  • Особенность
    • Фреймворк предоставляет расширения
    • Предоставляет механизм для получения результатов плагина и продолжения или прекращения работы на основе полученных результатов.
    • Предоставляет механизм для обработки ошибок и связи с плагинами.
В-третьих, рамочные принципы

Процесс планирования Framework делится на два этапа:

  • Фаза планирования выполняется синхронно, в одном цикле есть только один цикл планирования, потокобезопасный
  • Фаза связывания (гурутина) выполняется асинхронно. В одном цикле может выполняться несколько циклов связывания, и поток небезопасен.

Прежде чем представить процесс планирования Framework, сначала представим процесс планирования на рисунке выше, то есть логику обработки schedulerOne:

А. Фаза планирования

1. **过滤**操作即findNodesThatFitPod函数
 - 执行PreFilterPlugins
 - 执行FilterPlugins
 - 执行扩展 Filter
 - 若出现FitError，执行PostFilter
2. **评分**操作即prioritizeNodes函数
 	- 执行PreScorePlugins
 	- 执行ScorePlugins
 	- 执行扩展Prioritize
3. 挑选节点即select函数（符合条件节点，按照评分排序及采样选择）
4. 节点预分配即assume（只是预先分配，可收回）
5. 相关调度数据缓存即RunReservePlugins，从该节点开始，后续阶段发生错误，需要调用UnReserve，进行回滚（类似事务）
6.  执行准入操作即RunPermitPlugins

б. Стадия связывания

1. 执行WaitOnPermit，失败时调用RunReservePluginsUnreserve
2. 执行预绑定即RunPreBindPlugins，失败时调用RunReservePluginsUnreserve
3. 执行扩展bingding即extendersBinding，失败时调用RunReservePluginsUnreserve
4. 执行绑定收尾工作即RunPostBindPlugins
Введение точки расширения

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

pkg/scheduler/framework/interface.go

точка расширения Инструкции по применению
QueueSort Используется для поддержки заказа пользовательских модулей. Если указан алгоритм сортировки QueueSort, он будет отсортирован в соответствии с указанным алгоритмом сортировки в очереди планирования, и только один из них может быть включен.
Prefilter Предварительная обработка информации о подах, например, кэширование подов и т. д.
Filter В соответствии со старым стилем Predicate фильтрация узлов, не соответствующих требованиям
PostFilter POD для обработки Когда операция не удалась этап фильтра, вытеснительные действия E.G.
PreScore Для некоторого поколения информации перед оценкой вы можете создавать некоторые журналы или информацию о мониторинге здесь.
Score В соответствии со старым приоритетом оптимальный узел выбирается в соответствии со стратегией оценки, определяемой точкой расширения (оценка и нормализация).
Reserver Последний подключаемый модуль на этапе планирования для предотвращения конкуренции за ресурсы после успешного планирования и обеспечения точности информации о ресурсах кластера.
Permit Он в основном обеспечивает функцию перехвата привязки Pod и позволяет, отклонять или ждать pod’ы в зависимости от условий.
PreBind Прежде чем привязать узел, сделайте что-нибудь
Bind Pod будет обрабатываться только одним BindPlugin, создавая объект Bind.
PostBind Логика выполнена после успешного привязки
Unreserve На этапах от Permit до Bind, пока сообщается об ошибке, данные откатываются в исходное состояние, аналогично транзакции.
В-четвертых, использование сцены

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

  1. совместное планирование

    похожийkube-batch, что позволяет планировать задачи с определенным количеством подов в целом. Он может запланировать несколько воркеров задачи обучения в целом, и только когда ресурсы всех воркеров в задаче будут удовлетворены, контейнер будет запущен на узле.

  2. Динамическое связывание кластерных ресурсов

    Планирование с учетом топологии тома может быть реализовано с помощью фильтрации и предварительной привязки.

  3. Расширение расписания

    Фреймворк позволяет запускать пользовательские плагины в виде основной функции, инкапсулирующей планировщик.

Что касается части структуры, эта статья будет представлена ​​здесь, а следующая часть войдет в стадию исходного кода.Дополнительный контент связан с конфигурацией планирования и интеграцией планирования сторонних разработчиков, так что следите за обновлениями.

Для получения дополнительных материалов, пожалуйста, проверьте официальный аккаунт: DCOS

5. Ссылки
1. https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/
2. https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/
3. https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md
Категории