Блог

У меня есть кластер на EKS с включенным автоскалером кластера. Предположим, что есть 3 узла node-1, node-2, node3. На узлах может быть не более 10 модулей каждый. Теперь, когда появится 31-й модуль, центр сертификации запустит новый узел и запланирует модуль на нем. Теперь, возможно, допустим, что 4 модуля из узла 2 не требуются, и они выходят из строя. Теперь в соответствии с требованием, если запускается новый модуль, планировщик помещает новый модуль на 4-й узел (запущенный центром сертификации), а не на второй узел. Также я хочу, чтобы это продолжалось, если модули удаляются из узлов, тогда новые модули должны поступать в уже существующий узел, а не в новый узел, созданный CA. Я попытался обновить конфигурационный файл планировщика EKS по умолчанию с помощью плагина планировщика, но не смог этого сделать.

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

Это команда: «kube-scheduler —config custom.config», и это ошибка «попытка получить leader lease kube-system / kube-scheduler …»

Это мой пользовательский файл.config

 apiVersion: kubescheduler.config.k8s.io/v1beta1
clientConnection:
   kubeconfig: /etc/kubernetes/scheduler.conf
kind: KubeSchedulerConfiguration
percentageOfNodesToScore: 100
profiles:
- schedulerName: kube-scheduler-new
  plugins:
   score:
  disabled:
    - name: '*'
  enabled:
    - name: NodeResourcesMostAllocated
 

Как управлять расписанием модулей?

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

Выбор алгоритма планирования можно разбить на две части:

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

Kubernetes отлично работает, если вы позволяете планировщику решать, на какие узлы должен перейти модуль, и он поставляется с инструментами, которые будут давать подсказки планировщику:

• Для удаления некоторых модулей с узла можно использовать искажения и допуски. Это очень полезно, если вы хотите разделить свой кластер и разрешить некоторым определенным людям планировать некоторые определенные узлы. Может также использоваться, когда у вас есть несколько аппаратных узлов, и некоторые модули требуют этого (например, в вашем вопросе, где вы хотите, чтобы модуль был запланирован на узле 2). Они имеют 3 эффекта:

1. NoSchedule это означает, что планирования не будет
2. PreferNoSchedule это означает, что планировщик попытается избежать планирования
3. NoExecute также влияет на планирование и влияет на модули, уже запущенные на узле. ЕСЛИ вы добавите это заражение в узел, модули, запущенные на узле и не допускающие этого, будут удалены.

• Привязка к узлу на другой стороне может использоваться для привлечения определенных модулей к определенным узлам. Аналогично привязке к узлу tains, это дает мне несколько вариантов для точной настройки ваших настроек планирования:
  1. requiredDuringSchedulingIgnoredDuringExecution который можно использовать в качестве жесткого требования и сообщать планировщику, что для планирования pod на узле должны соблюдаться правила.
  2. preferredDuringSchedulingIgnoredDuringExecution которое можно использовать в качестве мягкого требования и указать планировщику попытаться обеспечить его соблюдение, но это не обязательно должно быть гарантировано
• PodAffinity можно использовать, если вы, например, хотите, чтобы ваши интерфейсные модули запускались на том же узле, что и ваш модуль базы данных. Это может быть аналогичным образом описано как жесткое или мягкое требование соответственно.
• podAntiAffinity можно использовать, если вы не хотите, чтобы некоторые определенные модули работали друг с другом.