Kubernetes планирует рабочие нагрузки на основе подов. После создания рабочей нагрузки планировщик автоматически назначает поды. Например, планировщик распределяет поды по узлам, у которых достаточно ресурсов.
Хотя поведение планировщика по умолчанию достаточно для большинства потребностей, могут возникнуть ситуации, когда требуется более точный контроль над тем, где размещаются поды. Для решения этой задачи Kubernetes позволяет настраивать политики планирования при создании рабочих нагрузок. Например, вам может понадобиться:
Используйте методы, перечисленные в следующей таблице, для выбора политики планирования подов в Kubernetes.
Политика планирования | Поле YAML | Описание | Ссылка |
|---|---|---|---|
Селектор узлов | nodeSelector | Базовый режим планирования, при котором Kubernetes выбирает целевой узел в соответствии с метками узла. Это означает, что pods планируются только на узел, имеющий конкретную метку. | |
Аффинитет узла | nodeAffinity | Аффинитет узла более выразителен, чем nodeSelector. Он позволяет использовать Селекторы меток для фильтрации узлов, которым требуется аффинитет на основе их меток, и выбора между Обязательный и Предпочтительный для Правила аффинитета. ПРИМЕЧАНИЕ: Когда одновременно указаны nodeSelector и nodeAffinity, pod может быть запланирован только на кандидатный узел, если выполнены оба условия. | |
Планирование affinity или anti-affinity нагрузки | podAffinity/podAntiAffinity | Вы можете использовать Селекторы меток для фильтрации pod, требующих affinity или anti-affinity на основе меток нагрузки. Затем вы можете определить, следует ли планировать новые pod нагрузки на тот же узел (или группу узлов), что и целевой pod, или нет. Кроме того, вы можете выбрать между Требуется и Предпочтительно для Правила affinity. ПРИМЕЧАНИЕ: Аффинитет и анти-аффинитет рабочей нагрузки требуют определённого количества вычислительного времени, что значительно замедляет планирование в масштабных кластерах. Не включайте аффинитет и анти-аффинитет рабочей нагрузки в кластере, содержащем сотни узлов. |
Политики планирования, использующие аффинитет узла или аффинитет/анти-аффинитет рабочей нагрузки, могут включать как жёсткие, так и мягкие ограничения для удовлетворения сложных требований планирования. Жёсткие ограничения должны быть выполнены, а мягкие ограничения следует выполнять насколько это возможно.
Тип правила | Поле YAML | Описание | Пример |
|---|---|---|---|
Обязательно | requiredDuringSchedulingIgnoredDuringExecution | Жёсткое ограничение, которое должно быть выполнено. Планировщик может выполнять планирование только когда правило выполнено. | |
Предпочтительно | preferredDuringSchedulingIgnoredDuringExecution | Мягкое ограничение. Планировщик пытается найти целевой объект, который удовлетворяет целевому правилу. Планировщик будет планировать pod, даже если не может найти соответствующий целевой объект, удовлетворяющий целевому правилу. При использовании предпочтительной привязки вы можете задать поле веса в диапазоне от 1 до 100 для каждого pod. Присвоение более высокого веса pod увеличит его приоритет в процессе планирования. |
Поле YAML requiredDuringScheduling или preferredDuringScheduling в правилах привязки выше указывает, что правило метки должно быть принудительно выполнено или должно быть выполнено настолько, насколько возможно, во время планирования. IgnoredDuringExecution указывает, что любые изменения метки узла после того, как Kubernetes планирует pod, не влияют на работу pod и не вызывают его повторного планирования. Однако, если kubelet на узле перезапускается, kubelet повторно проверит правило привязки к узлу, и pod всё ещё будет запланирован на другой узел.
При создании политики планирования используйте логические операторы селектора меток для фильтрации значений меток и определения объектов, которым необходима привязка или антипривязка.
Параметр | Описание | Пример YAML |
|---|---|---|
ключ | Ключ метки. Объекты, удовлетворяющие критериям фильтра, должны содержать метку с этим ключом, а значение метки должно соответствовать операционной связи со списком значений метки (значения поле) и логическим операторам. | В приведённом ниже примере объекты, удовлетворяющие критериям фильтра, должны иметь метку с ключом topology.kubernetes.io/zone и значение либо az1 или az2.
|
оператор | Логический оператор, который может использоваться для определения правил фильтрации значений меток. Параметры:
| |
значения | Значения метки |