Kubernetes планирует рабочие нагрузки на основе pod‑ов. После создания рабочей нагрузки планировщик автоматически назначает pod‑ы. Например, планировщик распределяет pod‑ы по узлам, которые имеют достаточные ресурсы.
Хотя поведение планировщика по умолчанию достаточно для большинства потребностей, могут возникнуть ситуации, когда требуется более точный контроль над тем, где развертываются pod‑ы. Для решения этой задачи Kubernetes позволяет настраивать политики планирования при создании рабочих нагрузок. Например, вам может потребоваться:
Используйте методы, перечисленные в таблице ниже, чтобы выбрать политику планирования pod в Kubernetes.
Scheduling Policy | YAML Field | Description | Reference |
|---|---|---|---|
Node selector | nodeSelector | Базовый режим планирования, при котором Kubernetes выбирает целевой узел в соответствии с метками узла. Это означает, что pod‑ы планируются только на узел, имеющий конкретную метку. | |
Node affinity | nodeAffinity | Node affinity более выразителен, чем nodeSelector. Он позволяет использовать Label Selectors для фильтрации узлов, которым требуется аффинити на основе их меток, и выбирать между Required и Preferred для Affinity Rules. ПРИМЕЧАНИЕ: Когда одновременно указаны nodeSelector и nodeAffinity, pod может быть запланирован на кандидатный узел только при выполнении обоих условий. | |
Планирование аффинити или анти‑аффинити рабочей нагрузки | podAffinity/podAntiAffinity | Вы можете использовать Label Selectors для фильтрации pod‑ов, которым требуется аффинити или анти‑аффинити на основе меток рабочей нагрузки. Затем можно определить, планировать ли новые pod‑ы рабочей нагрузки на тот же узел (или группу узлов), что и целевой pod, или нет. Кроме того, вы можете выбрать между Required и Preferred для Affinity Rules. ПРИМЕЧАНИЕ: Аффинити и анти‑аффинити рабочей нагрузки требуют определённого объёма вычислительного времени, что значительно замедляет планирование в кластерах большого масштаба. Не включайте аффинити и анти‑аффинити рабочей нагрузки в кластере, содержащем сотни узлов. | Настройка планирования аффинити или анти‑аффинити рабочей нагрузки (podAffinity or podAntiAffinity) |
Политики планирования, использующие node affinity или аффинити/анти‑аффинити рабочей нагрузки, могут включать как жёсткие, так и мягкие ограничения для удовлетворения сложных требований к планированию. Жёсткие ограничения должны быть выполнены, а мягкие — насколько это возможно.
Тип правила | Поле YAML | Описание | Пример |
|---|---|---|---|
Требуется | requiredDuringSchedulingIgnoredDuringExecution | Жесткое ограничение, которое must be met. Планировщик может выполнять планирование только когда правило выполнено. | |
Предпочтительно | preferredDuringSchedulingIgnoredDuringExecution | Мягкое ограничение. Планировщик пытается найти целевой объект, который удовлетворяет целевому правилу. Планировщик разместит pod, даже если не сможет найти соответствующий целевой объект, удовлетворяющий целевому правилу. При использовании предпочтительной affinity вы можете задать поле веса в диапазоне от 1 до 100 для каждого pod. Присвоение более высокого веса pod увеличит его приоритет в процессе планирования. |
Поле YAML requiredDuringScheduling или preferredDuringScheduling в приведённых выше правилах Affinity указывает, что правило метки должно быть принудительно выполнено или должно быть выполнено насколько это возможно во время планирования. IgnoredDuringExecution указывает, что любые изменения метки узла после того, как Kubernetes запланировал pod, не повлияют на работу pod и не приведут к его повторному планированию. Однако, если kubelet на узле перезапускается, kubelet повторно проверит правило node affinity, и pod всё равно будет запланирован на другой узел.
При создании политики планирования используйте логические операторы селектора меток для фильтрации значений меток и определения объектов, которым требуется affinity или anti‑affinity.
Параметр | Описание | Пример YAML |
|---|---|---|
key | Ключ метки. Объекты, соответствующие критериям фильтра, должны содержать метку с этим ключом, а значение метки должно соответствовать логической операции между списком значений метки (values поле) и логическими операторами. | В приведённом ниже примере объекты, соответствующие критериям фильтра, должны иметь метку с ключом topology.kubernetes.io/zone и значением либо az1, либо az2.
|
operator | Логический оператор, который можно использовать для определения правил фильтрации значений меток. Параметры:
| |
значения | Значения меток |