Облачная платформаAdvanced

Обзор

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Kubernetes планирует рабочие нагрузки на основе pod‑ов. После создания рабочей нагрузки планировщик автоматически назначает pod‑ы. Например, планировщик распределяет pod‑ы по узлам, которые имеют достаточные ресурсы.

Хотя поведение планировщика по умолчанию достаточно для большинства потребностей, могут возникнуть ситуации, когда требуется более точный контроль над тем, где развертываются pod‑ы. Для решения этой задачи Kubernetes позволяет настраивать политики планирования при создании рабочих нагрузок. Например, вам может потребоваться:
  • Развернуть фронтенд‑приложение и бэкенд‑приложение на одном узле. Это снижает задержку, поскольку pod‑ы обоих приложений могут использовать физические ресурсы узла.
  • Развернуть определённый тип приложений на конкретных узлах, чтобы гарантировать, что эти критические приложения всегда работают на лучшем оборудовании или конфигурации.
  • Развернуть разные приложения на отдельных узлах, чтобы изолировать их друг от друга. Это предотвращает влияние проблем одного приложения на другие.

Используйте методы, перечисленные в таблице ниже, чтобы выбрать политику планирования pod‑ов в Kubernetes.
Table 1 Workload scheduling policies

Scheduling Policy

YAML Field

Description

Reference

Node allocation

nodeSelector

Базовый режим планирования, при котором Kubernetes выбирает целевой узел в соответствии с метками узла. Это означает, что pod‑ы планируются только на узел, имеющий конкретную метку.

Настройка указанного планирования узла (nodeSelector)

Node affinity

nodeAffinity

Node affinity более выразителен, чем nodeSelector. Он позволяет использовать Label Selectors для фильтрации узлов, которым требуется аффинити на основе их меток, и выбирать между Required и Preferred для Affinity Rules.

ПРИМЕЧАНИЕ:

Если одновременно указаны nodeSelector и nodeAffinity, pod может быть запланирован на кандидатный узел только при выполнении обоих условий.

Настройка планирования Node Affinity (nodeAffinity)

Планирование аффинити или антиаффинити рабочей нагрузки

podAffinity/podAntiAffinity

Используйте Label Selectors для идентификации pod‑ов для правил аффинити или антиаффинити. Затем вы можете планировать новые pod‑ы рабочей нагрузки либо вместе с целевыми pod‑ами на том же узле (или в том же домене топологии), либо отдельно от них. Кроме того, задайте Affinity Rules как Required и Preferred.

ПРИМЕЧАНИЕ:

Аффинити и антиаффинити рабочей нагрузки требуют определённого объёма вычислительного времени, что значительно замедляет планирование в кластерах большого масштаба. Не включайте аффинити и антиаффинити рабочей нагрузки в кластере, содержащем сотни узлов.

Настройка планирования аффинити или антиаффинити рабочей нагрузки (podAffinity или podAntiAffinity)

Affinity Rules

Политики планирования, использующие node affinity или аффинити/антиаффинити рабочей нагрузки, могут включать как жёсткие, так и мягкие ограничения для удовлетворения сложных требований к планированию. Жёсткие ограничения должны быть выполнены, а мягкие — насколько это возможно.
Таблица 2 правила аффинности

Тип правила

Поле YAML

Описание

Ссылка

Требуется

requiredDuringSchedulingIgnoredDuringExecution

Жёсткое ограничение. Планировщик размещает pod только на узлах, соответствующих указанным правилам. Если совпадений нет, pod остаётся незапланированным.

Предпочтительно

preferredDuringSchedulingIgnoredDuringExecution

Мягкое ограничение. Планировщик предпочитает узлы, соответствующие указанным правилам. Если совпадений нет, pod всё равно будет размещён на любом доступном узле.

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

Поле YAML requiredDuringScheduling или preferredDuringScheduling в указанных выше правилах аффинности указывает, что правило метки должно быть принудительно выполнено или должно быть выполнено насколько возможно во время планирования. IgnoredDuringExecution указывает, что любые изменения метки узла после того, как Kubernetes планирует pod, не повлияют на работу pod и не приведут к его повторному планированию. Однако, если kubelet на узле перезапускается, kubelet повторно проверит правило аффинности узла, и pod всё равно будет размещён на другом узле.

Label Selectors

При создании scheduling policy используйте логические операторы label selector для фильтрации значений меток и определения объектов, которым требуется affinity или anti-affinity.
Таблица 3 Label selectors

Parameter

Description

Example YAML

key

Ключ метки. Объекты, соответствующие критериям фильтра, должны содержать метку с этим ключом, а значение метки должно соответствовать логической операции между списком значений метки (values field) и логическими операторами.

В приведённом ниже примере объекты, соответствующие критериям фильтра, должны иметь метку с ключом topology.kubernetes.io/zone и значением либо az1, либо az2.

matchExpressions:
  - key:  topology.kubernetes.io/zone 
    operator:  In 
    values:
    -  az1 
    -  az2

operator

Логический оператор, который можно использовать для определения правил фильтрации значений меток. Параметры:

  • In: Метка объекта affinity или anti-affinity is в списке значений метки (values field).
  • NotIn: Метка объекта affinity или anti-affinity not в списке значений метки (values field).
  • Exists: Объект affinity или anti-affinity has указанный ключ метки. Нет необходимости настраивать список значений метки (values field).
  • DoesNotExist: Объект affinity или anti-affinity not имеет указанный ключ метки. Нет необходимости настраивать список значений метки (values field).
  • Gt: (available only for node affinity) Значение метки запланированного узла больше, чем указано (строковое сравнение).
  • Lt: (available only for node affinity) Значение метки запланированного узла меньше, чем указано (строковое сравнение).

значения

Значения меток
Родительская тема: Scheduling a Workload
Предыдущая статья
Планирование нагрузки
Следующая статья
Настройка выбора узлов (nodeSelector)
Поддержка Юридические документы Политика конфиденциальности
© 2026 Cloud.ru