Kubernetes планирует рабочие нагрузки на основе pod‑ов. После создания нагрузки планировщик автоматически назначает pod‑ы. Например, планировщик распределяет pod‑ы по узлам, у которых достаточно ресурсов.
Хотя поведение планировщика по умолчанию удовлетворяет большинству потребностей, могут возникнуть ситуации, когда требуется более точный контроль над размещением pod‑ов. Для этого Kubernetes позволяет настраивать политики планирования при создании нагрузок. Например, вам может потребоваться:
- Развернуть фронтенд‑приложение и бэкенд‑приложение на одном узле. Это уменьшает задержку, поскольку pod‑ы обоих приложений могут использовать физические ресурсы узла.
- Развернуть определённый тип приложений на конкретных узлах, чтобы гарантировать, что эти критические приложения всегда работают на лучшем оборудовании или конфигурации.
- Развернуть различные приложения на отдельных узлах для их изоляции друг от друга. Это предотвращает влияние проблем одного приложения на другие.
Используйте методы, перечисленные в следующей таблице, для выбора политики планирования pod‑ов в Kubernetes.
Политика планирования | Поле YAML | Описание | Ссылка |
|---|---|---|---|
Селектор узла | nodeSelector | Базовый режим планирования, при котором Kubernetes выбирает целевой узел согласно меткам узла. Это означает, что pod‑ы планируются только на узел, имеющий конкретную метку. | |
Аффинитет узла | nodeAffinity | Аффинитет узла более выразителен, чем nodeSelector. Он позволяет использовать Селекторы меток для фильтрации узлов, требующих аффинитета, по их меткам и выбора между Обязательный и Предпочтительный для Правила аффинитета. NOTE: Когда одновременно указаны nodeSelector и nodeAffinity, pod может быть запланирован на кандидатный узел только если выполнены оба условия. | |
Планирование аффинитета или анти-аффинитета нагрузки | podAffinity/podAntiAffinity | Вы можете использовать Селекторы меток для фильтрации pod‑ов, требующих аффинитета или анти-аффинитета, по меткам нагрузки. Затем можно определить, следует ли планировать новые pod‑ы нагрузки на тот же узел (или группу узлов), что и целевой pod, или нет. Кроме того, можно выбирать между Обязательный и Предпочтительный для Правила аффинитета. NOTE: Аффинитет и анти-аффинитет нагрузки требуют определённого объёма вычислительных ресурсов, что существенно замедляет планирование в кластерах большого масштаба. Не включайте аффинитет и анти-аффинитет нагрузки в кластере, содержащем сотни узлов. |
Правила аффинитета
Политики планирования, использующие аффинитет узла или аффинитет/анти-аффинитет нагрузки, могут включать как жёсткие, так и мягкие ограничения для удовлетворения сложных требований к планированию. Жёсткие ограничения должны быть соблюдены, а мягкие — насколько это возможно.
Тип правила | Поле 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.
|
оператор | Логический оператор, который может использоваться для определения правил фильтрации значений меток. Параметры:
| |
значения | Значения меток |
- Правила аффинности
- Селекторы меток