С момента создания фонда CNCF до бурного развития сообщества Kubernetes, после 6 лет, 17 лет внезапного появления, в соревновании mesos, swarm и других проектов вышел на первое место, а затем унифицировал оркестрацию контейнеров, Основные причины его успеха можно резюмировать следующим образом:
- Настойчивость и дальновидность руководителей проекта
- Хорошо функционирующие сообщества и культура сообщества
- Положительные отзывы от сообщества и предприятия
Несмотря на то, что было много знакомство с kubernetes, разработка облачных проектов и проектов Kubernetes вошла в глубокую область, поэтому сегодня zouyee предлагает вам «планирование kuberneter от мелкого к глубокому». Я надеюсь, что в следующих пяти статьях вы сможете иметь систематическое и глубокое понимание системы планирования kubernetes. Соответствующая версия этой серии1.20.+, сегодня представляет серию «Система планирования Kubernetes от мелкой к глубокой серии: предварительное исследование».
Введение в планирование
Прежде чем мы начнем, давайте взглянем на диаграмму архитектуры Kubernetes.Плоскость управления включает в себя следующие три компонента: kube-scheduler, kube-apiserver и kube-controller-manager. Анализ компонентов kubelet и kube-proxy будет объяснен в отдельных главах.Теперь мы можем просто разобрать сложность понимания вышеперечисленных компонентов, kube-apiserver, kubelet, kube-scheduler, kube-controller-manager, kube-proxy.
{%note danger%}
Как упоминалось выше,kube-schedulerЭто один из основных компонентов системы K8S. Он в основном отвечает за планирование подов. Он отслеживает kube-apiserver и опрашивает поды, которые не были выделены Узлы (нераспределенные, не удалось выделить и не удалось выделить после много попыток).В соответствии с настроенной политикой планирования поды планируются для оптимального рабочего узла, чтобы эффективно и разумно использовать ресурсы кластера, эта функция является одним из ключевых факторов для пользователей при выборе системы K8S, который помогает пользователям повысить эффективность и снизить потребление энергии.
{%endnote%}
kube-schedulerОтвечает за планирование подов в кластере.лучший узел(на основе наилучшего значения, рассчитанного соответствующей политикой), он слушает kube-apiserver, запросите поды, которым не были назначены узлы, а затем назначьте узлы этим подам в соответствии с политикой планирования и выполните операцию привязки узлов (обновитеnodeNameполе).
В ходе вышеуказанного процесса необходимо рассмотреть следующие вопросы:
- Как обеспечить справедливость распределения узлов
- Как обеспечить эффективность распределения ресурсов узла
- Как обеспечить справедливость при планировании подов
- Как обеспечить эффективность планирования подов
- Как расширить политику планирования подов
Чтобы решить вышеуказанную проблему,kube-schedulerСобирая информацию, такую как ресурсы узла, область узла, зеркальное отображение узлов, планирование модулей и другие комплексные решения, чтобы гарантировать, что модули распределяются между лучшими узлами, следующее:kube-schedulerОсновные цели:
- Справедливость: при планировании модулей требуются справедливые решения, каждый узел может быть назначен, и планировщик должен принимать сбалансированные решения для разных узлов.
- Эффективность ресурсов: максимально используйте все планируемые ресурсы, чтобы такие ресурсы, как ограниченный ЦП и память, могли обслуживать как можно больше модулей.
- Производительность: он может быстро завершить планирование крупномасштабных модулей и по-прежнему может обеспечивать производительность планирования в случае расширения кластера.
- Гибкость: в реальном производстве пользователи ожидают, что стратегия планирования модулей будет масштабируемой, чтобы алгоритмы планирования можно было настраивать для решения сложных практических задач. Следовательно, платформа должна позволять нескольким планировщикам работать параллельно и поддерживать пользовательские планировщики.
Во-вторых, процесс планирования
Во-первых, мы создаем интуитивно понятный опыт планирования подов с помощью следующей общей схемы взаимодействия.
Вышеприведенное использует создание Pod в качестве примера, чтобы кратко представить процесс планирования:
-
Пользователи создают поды через командную строку (выберите создание подов напрямую вместо других рабочих нагрузок, чтобы опустить kube-controller-manager)
-
kube-apiserver записывается в etcd после проверки объектов, допусков, квот и других операций доступа
-
kube-apiserver возвращает результат пользователю
-
В то же время kube-scheduler отслеживает события node, Pod и т. д. (процесс 1).
-
kube-scheduler добавляет модуль spec.nodeName в очередь планирования и выполняет цикл планирования (этот цикл является содержанием последующего введения) (процесс 2-3)
-
kube-scheduler привязывает pod к узлу с наивысшим баллом (процесс 4)
-
kube-apiserver записывает информацию о привязке в etcd
-
Кублет отслеживает назначенный ему под и вызывает интерфейс CRI для создания пода (эта часть контента будет представлена позже в этой серии).
-
После того, как kubelet создает под, он обновляет статус пода и другую информацию и сообщает об этом kube-apiserver.
-
kube-apiserver записывает данные
Период планирования
kube-schedulerЗадача пода — привязать поды к наиболее подходящим рабочим нодам по различным алгоритмам планирования, весь процесс планирования делится на два этапа: фильтрация и оценка. Схематическая диаграмма процесса показана ниже.
Примечание. Ранее называвшиеся предикатом и приоритетами, а в настоящее время вместе называемые фильтрацией и оценкой, фактический эффект тот же.
-
фильтр: входы — это все узлы, а выходы — узлы, удовлетворяющие предварительно выбранному условию.
kube-schedulerОтфильтруйте неудовлетворительные узлы в соответствии с политикой фильтрации. Например, если ресурсов узла недостаточно или не выполняются условия политики предварительного выбора, такие как «метка узла должна соответствовать селектору пода», фильтр не может быть пройден. -
**Оценка: **Входом является узел, прошедший этап фильтрации.При подсчете очков узел, прошедший фильтр, будет оцениваться в соответствии с алгоритмом подсчета очков, и будет выбран узел с наибольшим количеством очков. Например, узел с большим количеством ресурсов и меньшей нагрузкой может иметь более высокий ранг.
С точки зрения непрофессионала, процесс планирования должен ответить на два вопроса: 1. Что такое узлы-кандидаты? 2. Какой из них наиболее подходит?
Если ни один узел не удовлетворяет условиям на этапе фильтрации, Pod будет оставаться в состоянии Pending до тех пор, пока не появится удовлетворяющий узел, в течение которого планировщик продолжит повторять попытки. Если есть несколько узлов с одинаковым счетом, тоkube-schedulerВыберите любой из них.
Примечание. Pod сначала входит в очередь планирования, затем переходит в режим отсрочки после сбоя и переходит в режим отмены расписания после нескольких сбоев.Эта часть контента будет представлена позже.
Алгоритм планирования
В настоящее время существует два способа настройки алгоритмов фильтрации и подсчета очков:
1. Scheduling Policies：通过文件或者configmap配置Predicate算法(过滤)和 Priorities算法(评分)的算法
2. Scheduling Profiles：当前调度系统为插拔架构，其将调度周期分为 `QueueSort`、`PreFilter`、`Filter`、`PreScore`、`Score`、`Reserve`、`Permit`、`PreBind`、`Bind`、`PostBind`等阶段，通过定制调度周期中不同阶段的插件行为来实现自定义。
Ниже приведено краткое введение в настройку с помощью политик планирования.
pkg/scheduler/framework/plugins/legacy_registry.go
Предваряет
| Имя алгоритма | Алгоритм Значение |
|---|---|
| MatchInterPodAffinity | Проверьте, соответствует ли объект ресурса pod правилу сходства с другими объектами ресурса pod. |
| CheckVolumeBinding | Проверьте, соответствует ли узел требованиям к монтажу ПВХ объекта ресурса pod. |
| GeneralPredicates | Проверьте, подключено ли количество объектов ресурсов модуля на узле и соответствуют ли требованиям такие ресурсы, как ЦП, память, графический процессор. |
| HostName | Проверьте, соответствует ли имя узла, указанное подом, текущему узлу. |
| PodFitsHostPorts | Убедитесь, что HostPort, требуемый контейнером Pod, уже занят другими контейнерами или службами на узле. Если он занят, поду запрещается планировать этот узел. |
| MatchNodeSelector | Проверьте, соответствует ли селектор узла Pod метке узла. |
| PodFitsResources | Проверьте, достаточно ли на узле свободных ресурсов (таких как ЦП и память), чтобы удовлетворить требования пода. |
| NoDiskConflict | Проверьте, не конфликтует ли том, используемый текущим ресурсным объектом модуля, с томом, используемым другими объектами ресурсов модуля на узле. |
| PodToleratesNodeTaints | Если текущий узел помечен как испорченный, проверьте, может ли объект ресурса модуля допускать пороки узла. |
| CheckNodeUnschedulable | Проверить, является ли узел запланированным |
| CheckNodeLabelPresence | Проверить, существует ли метка узла |
| CheckServiceAffinity | Проверить принадлежность службы |
| MaxCSIVolumeCountPred | Если установлена функция featuregate (attachvolumelimit), проверьте, превышает ли том csi, смонтированный объектом ресурса pod, максимальное количество смонтированных томов на узле. |
| NoVolumeZoneConflict | Проверьте, является ли монтирование объекта ресурса pod pvc межрегиональным монтированием, поскольку ни хранилище gce pd, ни том aws ebs не поддерживают межрегиональное монтирование. |
| EvenPodsSpreadPred | Группа подов на определенном TopologyKey должна быть сбалансирована и разбросана. |
Примечание. От алгоритмов предварительного выбора поставщиков облачных услуг, таких как MaxEBSVolumeCountPred, MaxGCEPDVolumeCountPred, MaxAzureDiskVolumeCountPred и MaxCinderVolumeCountPred, отказались.
Приоритеты
| Имя алгоритма | Алгоритм Значение |
|---|---|
| EqualPriority | Веса узлов равны |
| MostRequestedPriority | Смещение узлов с наиболее запрашиваемыми ресурсами. Эта стратегия размещает запланированные модули для запуска на самых маленьких узлах, необходимых для всего набора рабочих нагрузок. |
| RequestedToCapacityRatioPriority | Создайте RequestToCapacity на основе ResourceAllocationPriority, используя функциональную модель оценки ресурсов по умолчанию. |
| SelectorSpreadPriority | Попробуйте запланировать модули, принадлежащие одной и той же службе rcs rss sts, на разных узлах. |
| ServiceSpreadingPriority | Для данной службы эта стратегия направлена на то, чтобы модули службы работали на разных узлах. Общий результат заключается в том, что Служба становится более устойчивой к сбоям отдельных узлов. |
| InterPodAffinityPriority | Рассчитать баллы на основе аффинности и анти-аффинности |
| LeastRequestdPriority | Отдавайте предпочтение узлам, которые используют меньше запрашиваемых ресурсов. Другими словами, чем больше модулей Pod размещено на узле и чем больше ресурсов они используют, тем ниже рейтинг, присвоенный этой стратегией. |
| BalancedRequestdPriority | Рассчитайте использование ЦП и памяти на узле, и узел с наиболее сбалансированным использованием является лучшим. |
| NodePreferAvoidPodsPriority | На основе оценки аннотации (аннотации), определенной на узле, если в аннотации определено значение alpha.kubernetes.io/preferAvoidPods, ReplicationController будет отключен или ресурсный объект модуля ReplicaSet будет запланирован на узле. |
| NodeAffinityPriority | Рассчитать баллы на основе сходства узлов |
| TaintTolerationPriority | Рассчитать балл на основе совпадения порчи и допусков |
| ImageLocalityPriority | Вычислить оценку на основе того, было ли изображение работающего объекта ресурса pod снято на узле. |
| EvenPodsSpreadPriority | Используется для указания требований для разделения набора подходящих модулей в определенной топологии. |
Чтобы получить больше контента, связанного с облачными технологиями, обратите внимание на общедоступную учетную запись: DCOS.