Помимо Kube-Scheduler, нужен кластерный балансировщик K8s

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

Kubernetes (k8s)  — это распределенная система с открытым исходным кодом для автоматизированного развертывания, масштабирования развертываний в соответствии с трафиком и другими потребностями доступности бизнеса и управления контейнеризованными приложениями.

Я хочу поделиться своим первоначальным опытом работы с контейнерным приложением, проблемами, с которыми я столкнулся при управлении им, и тем, как Марафон , а затем и Кубернетес стали спасителем для меня. Однако сегодня я выбираю немного продвинутую, хотя и не сложную, тему, связанную с управлением кластерами в Kubernetes. Хорошо, давайте начнем Kube-schedulerуглубляться в структуру планирования K8, и, наконец, я представлю не очень популярный, хотя и элегантный проект для балансировки кластера Kubernetes, названныйDescheduler.

Концепции Kube-schedulerи структура планирования Kubernetes

Хорошо, мы знаем тот факт, что все распределенные системы нуждаются в процессе или программе, чтобы запланировать работу или задачу в кластере для выполнения; Точно так же Kubernetes нуждается в этом также, и как следует из названия, Kube-schedulerвыполняет ту же соответствующую роль для Kubernetes. Kube-планировщик работает как часть плоскости управления и отслеживает все вновь созданные модули , для которых не назначен ни один узел. 

Проще говоря, Kube-schedulerотвечает за обнаружение вновь созданного модуля и выбирает оптимальный узел для его запуска. В настоящее время вам, ребята, может быть интересно, как Kube-schedulerопределить лучший доступный узел, верно? Согласно официальной документации K8s, выбор узла для модуля состоит из двух этапов:

1. Фильтрация : найдите набор узлов, в которых возможно запланировать модуль. Узлы, которые соответствуют критериям планирования модуля, известны как выполнимые узлы. Если этап фильтрации приводит к пустым допустимым узлам, установите модуль как незапланированный до тех пор, пока планировщик не найдет набор допустимых узлов. Пожалуйста, следуйте документации по фильтрации для получения дополнительной информации о критериях фильтрации.
2. Оценка . На этом этапе планировщик ранжирует возможные наборы узлов, чтобы выбрать наиболее подходящий узел для размещения модуля. Планировщик следует активным правилам оценки для определения ранга узла.

После Kube-schedulerопределения наиболее подходящего узла для размещения модуля он уведомляет сервер API о решении в процессе, называемом связыванием . Согласно документации структуры планирования K8s , выбор узла и процесс привязки известны как цикл планирования и цикл привязки. Вместе цикл планирования и цикл привязки известны как scheduling context. 

Scheduling-framework — это новая подключаемая архитектура для планировщика k8s, которая упрощает настройку планировщика. Цикл планирования является последовательным; однако цикл привязки является параллельным. Следующая картинка изображает структуру планирования

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

Зачем нам нужен балансирующий кластер Kubernetes?

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

Из-за изменений в течение определенного периода кластер Kubernetes достигает несбалансированного состояния, и возникает необходимость в балансировке кластера.

Подход к решению

Балансировка кластера вручную — это утомительный процесс, потому что, во-первых, нам нужно определить неправильно расположенные блоки в соответствии с новым состоянием кластера, а затем выяснить стратегию их перемещения на оптимальном узле. Но, если мы посмотрим на вторую часть проблемы, она уже решена Kube-scheduler. Нам просто нужен процесс, который определяет неправильно размещенные модули и удаляет их. Верный? Хорошо, вот и все, наша проблема сейчас элементарна. Нам нужен основанный на правилах descheduler.

Время для решения

Итак, самое время представить благотворителя, тада, роль барабана, пожалуйста. Герой назван Descheduler. Без каких-либо задержек позвольте мне сначала представить репозиторий проекта GitHub . Как я уже сказал, Deschedulerнам может помочь требование о расписании модулей на основе правил и следующие пять настраиваемых стратегий .

1. RemoveDuplicates : он гарантирует, что на одном узле выполняется только один модуль, связанный с объектом Replica Set (RS), Replication Controller (RC), Deployment или Job.
2. LowNodeUtilization : найдите недостаточно используемые узлы и извлекают модули из других узлов, чтобы планировщик Kube разместил их на недостаточно используемых.
3. RemovePodsViolatingNodeTaints : он обеспечивает удаление модулей, нарушающих NoSchedule.
4. RemovePodsViolatingNodeAffinity : он обеспечивает удаление модулей, нарушающих анти-сродство между модулями .
5. RemovePodsViolatingInterPodAntiAffinity : он обеспечивает удаление модулей, нарушающих сходство узлов.

Следующий вопрос, это выглядит многообещающе, как я могу его использовать?

Из  README.MD самого Descheduler можно запустить как Job или CronJob внутри кластера k8s. Преимущество заключается в возможности запуска несколько раз без необходимости вмешательства пользователя. Модуль Descheduler работает как критический модуль в  Kube-system пространстве имен, чтобы избежать его выселения самим или Kubelet.

Простой объект Kubernetes для запуска Descheduler

• RBAC Object