# Распределение подов по узлам
LLMS index: [llms.txt](/llms.txt)
---
Можно настроить под так, чтобы тот мог запускаться _только_ на определенном(-ых) узле(-ах) или _предпочитал_ определенную группу узлов.
Сделать это можно несколькими способами, при этом все рекомендуемые подходы используют [селекторы лейблов](/ru/docs/concepts/overview/working-with-objects/labels/) для выбора.
Зачастую нужды в подобных ограничениях нет; планировщик автоматически размещает поды оптимальным образом (например, распределяет их по узлам, чтобы они не оказались все на одном узле с дефицитом ресурсов).
Однако в некоторых обстоятельствах возможность контролировать, куда именно попадет под, может пригодиться. Например, она поможет запланировать под на узел с быстрым SSD-хранилищем или разместить два активно взаимодействующих друг с другом пода в одной зоне доступности.
Для планирования подов на определенные узлы можно использовать любой из методов:
* Поле [nodeSelector](#nodeselector) и [лейблы узлов](#built-in-node-labels);
* Правила [совместного/раздельного существования (affinity и anti-affinity)](#affinity-and-anti-affinity);
* Поле [nodeName](#nodename);
* [Ограничения на топологию распределения подов](#pod-topology-spread-constraints).
## Лейблы узлов {#built-in-node-labels}
Как и у многих других объектов Kubernetes, у узлов есть [лейблы](/ru/docs/concepts/overview/working-with-objects/labels/). Их можно [навешивать вручную](/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node).
Kubernetes также навешивает [стандартный набор лейблов](/docs/reference/node/node-labels/) на все узлы кластера.
Примечание:
Значения этих лейблов зависят от облачного провайдера, поэтому на них нельзя полагаться.
Например, в одних окружениях значение kubernetes.io/hostname может совпадать с именем узла, в других — отличаться.
### Изоляция узла/ограничение его использования
Лейблы узлов позволяют размещать поды на определенные узлы или группы узлов. С их помощью можно планировать поды на узлы с определенными требованиями к изоляции, безопасности или соответствию нормативным положениям.
При использовании лейблов для изоляции узлов следует выбирать ключи лейблов, которые kubelet не может изменить. В этом случае взломанный узел не сможет навесить на себя эти лейблы в надежде, что планировщик разместит на него рабочие нагрузки.
[Admission-плагин NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) не позволяет kubelet'у устанавливать или изменять лейблы с префиксом `node-restriction.kubernetes.io/`.
Чтобы использовать этот префикс для изоляции узла:
1. Убедитесь, что используется [авторизатор узлов](/docs/reference/access-authn-authz/node/) и _включен_ admission-плагин `NodeRestriction`.
2. Добавьте лейблы с префиксом `node-restriction.kubernetes.io/` к узлам и используйте их в [селекторах узлов](#nodeselector). Например, `example.com.node-restriction.kubernetes.io/fips=true` или `example.com.node-restriction.kubernetes.io/pci-dss=true`.
## nodeSelector
`nodeSelector` — простейшая рекомендуемая форма настроек выбора узлов.
Можно добавить поле `nodeSelector` в спецификацию пода и перечислить в нем [лейблы узлов](#built-in-node-labels), которые подходят для развертывания пода. В этом случае Kubernetes будет планировать под только на узлы со всеми указанными лейблами.
Дополнительную информацию см. в разделе [Размещение подов на узлах](/docs/tasks/configure-pod-container/assign-pods-nodes).
## Правила совместного/раздельного существования (affinity и anti-affinity) {#affinity-and-anti-affinity}
`nodeSelector` — самый простой способ развернуть поды на узлах с определенными лейблами. Правила совместного/раздельного существования расширяют типы ограничений, которые можно накладывать. Вот некоторые из их преимуществ:
* Язык правил affinity/anti-affinity более выразителен. `nodeSelector` выбирает узлы только со всеми указанными лейблами. Правила affinity/anti-affinity расширяют логику выбора и делают ее более гибкой.
* Правило может быть *мягким* (soft) или *предпочтительным* (preferred). В этом случае планировщик все равно запланирует под, даже если подходящего узла для него не найдется.
* При планировании пода планировщик может учитывать лейблы других подов, запущенных на узле (или в иной топологической области), а не только лейблы самого узла. Это позволяет формулировать правила, определяющие сосуществование подов на узле.
Правила совместного существования (affinity) бывают двух типов:
* *Правила для узлов* (node affinity) работают подобно полю `nodeSelector`, но более выразительны. Кроме того, можно задавать мягкие правила.
* *Правила для подов* (inter-pod affinity и anti-affinity) позволяют при планировании учитывать лейблы других подов.
### Правила совместного существования для узлов (node affinity) {#node-affinity}
Правила совместного существования для узлов концептуально похожи на `nodeSelector`. С помощью лейблов они позволяют ограничивать список узлов, на которые может быть запланирован под. Существует два типа таких правил:
* `requiredDuringSchedulingIgnoredDuringExecution`: Планировщик не может запланировать под, если правило не выполнено. Работает как `nodeSelector`, но с более выразительным синтаксисом.
* `preferredDuringSchedulingIgnoredDuringExecution`: Планировщик пытается найти узел, который соответствует правилу. Если подходящий узел не удается найти, планировщик все равно планирует под.
Примечание:
В типах выше IgnoredDuringExecution означает, что под продолжит свою работу, если лейблы узлов изменятся после того, как Kubernetes запланировал его.
Задавать правила совместного существования для узлов можно с помощью поля `.spec.affinity.nodeAffinity` в спецификации пода.
В качестве примера рассмотрим следующую спецификацию пода:
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: topology.kubernetes.io/zone
operator: In
values:
- antarctica-east1
- antarctica-west1
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: another-node-label-key
operator: In
values:
- another-node-label-value
containers:
- name: with-node-affinity
image: registry.k8s.io/pause:2.0
В этом примере применяются следующие правила:
* У узла *должен* быть лейбл с ключом `topology.kubernetes.io/zone`, и значение этого лейбла *должно* быть либо `antarctica-east1`, либо `antarctica-west1`.
* *Предпочтительно*, чтобы у узла был лейбл с ключом `another-node-label-key` и значением `another-node-label-value`.
Можно использовать поле `operator` для указания логического оператора, который Kubernetes будет применять при интерпретации правил. Доступны `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt` и `Lt`.
Узнать больше о том, как они работают, можно в подразделе [Операторы](/#operators).
`NotIn` и `DoesNotExist` позволяют задавать правила раздельного существования (anti-affinity) для узла.
Кроме того, можно использовать [taint'ы узлов](/docs/concepts/scheduling-eviction/taint-and-toleration/), чтобы "отвадить" поды от определенных узлов.
Примечание:
Когда указаны и nodeSelector, и nodeAffinity, под будет запланирован на узел только в том случае, если оба этих условия удовлетворены.
Если указать несколько условий nodeSelectorTerms, привязанных к типам nodeAffinity, то под может быть запланирован на узел, если удовлетворяется одно из указанных условий nodeSelectorTerms. К условиям применяется логическое ИЛИ.
Если задать несколько выражений в поле matchExpressions для одного условия nodeSelectorTerms, под будет запланирован на узел только если удовлетворены все выражения matchExpressions. К условиям применяется логическое И.
apiVersion: v1
kind: Pod
metadata:
name: with-affinity-anti-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/os
operator: In
values:
- linux
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: label-1
operator: In
values:
- key-1
- weight: 50
preference:
matchExpressions:
- key: label-2
operator: In
values:
- key-2
containers:
- name: with-node-affinity
image: registry.k8s.io/pause:2.0
Если правилу `preferredDuringSchedulingIgnoredDuringExecution` соответствуют два узла (один — с лейблом `label-1:key-1`, другой — с `label-2:key-2`), планировщик считает вес `weight` каждого узла и добавляет его к другим оценкам для этого узла. Под планируется на узел с наивысшей итоговой оценкой.
Примечание:
Чтобы Kubernetes смог запланировать поды в этом примере, необходимо, чтобы существовали узлы с лейблом kubernetes.io/os=linux.
#### Правила совместного существования и профили планирования
СТАТУС ФИЧИ:
Kubernetes v1.20 [beta]
При настройке нескольких [профилей планирования](/docs/reference/scheduling/config/#multiple-profiles) можно связать профиль с правилами совместного существования для узлов (это удобно, когда профиль применяется к определенному набору узлов). Для этого необходимо добавить `addedAffinity` в поле `args` [плагина `NodeAffinity`](/docs/reference/scheduling/config/#scheduling-plugins) в [конфигурации планировщика](/docs/reference/scheduling/config/). Например:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
- schedulerName: foo-scheduler
pluginConfig:
- name: NodeAffinity
args:
addedAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: scheduler-profile
operator: In
values:
- foo
```
Правило `addedAffinity` применяется ко всем подам с полем `.spec.schedulerName`, имеющим значение `foo-scheduler`, в дополнение к NodeAffinity, заданному в PodSpec. Таким образом, подходящие для пода узлы должны удовлетворять параметрам `addedAffinity` и правилам `.spec.NodeAffinity` пода.
Поскольку конечные пользователи не видят `addedAffinity`, результат применения этих правил может быть для них неожиданным. Используйте лейблы узлов, которые однозначно соотносятся с именем профиля планировщика.
Примечание:
Контроллер DaemonSet,
создающий поды для DaemonSet'ов, не поддерживает профили планирования. Контроллер DaemonSet создает поды, а штатный планировщик Kubernetes, размещая их, следит за соблюдением правил
nodeAffinity.
Примечание:
Обработка правил совместного/раздельного существования подов требует значительных ресурсов и может значительно замедлить планирование в больших кластерах. Их не рекомендуется использовать в кластерах, число узлов в которых превышает несколько сотен.
Примечание:
Правила раздельного существования для подов требуют согласованности лейблов узлов. Другими словами, у каждого узла в кластере должен быть лейбл, относящий его к определенному ключу topologyKey. Отсутствие лейблов topologyKey у некоторых или всех узлов в кластере может привести к непредсказуемому поведению.
#### Типы правил совместного/раздельного существования подов
По аналогии [c правилами для узлов](#node-affinity) существует два типа правил для подов:
* `requiredDuringSchedulingIgnoredDuringExecution`
* `preferredDuringSchedulingIgnoredDuringExecution`
Например, с помощью правила совместного существования `requiredDuringSchedulingIgnoredDuringExecution` можно заставить планировщик размещать поды, относящиеся к разным сервисам, в одной зоне облачного провайдера, поскольку они активно обмениваются данными друг с другом.
Аналогичным образом можно использовать правило раздельного существования `preferredDuringSchedulingIgnoredDuringExecution` для распределения подов по нескольким зонам облачного провайдера.
Для задания правил совместного существования предназначено поле `affinity.podAffinity` в спецификации пода.
Для задания правил раздельного существования предназначено поле `affinity.podAntiAffinity` в спецификации пода.
#### Планирование группы подов, связанных правилами совместного существования
Если планируемый под — первый в серии подов, связанных правилами совместного существования,
он может быть запланирован, если удовлетворит всем остальным правилам совместного существования. Чтобы подтвердить, что этот под — действительно первый,
проводится проверка, которая должна показать, что пространство имен и селектор этого пода уникальны в кластере (то есть нет других таких подов). Кроме того,
под должен соответствовать своим собственным правилам, а выбранный узел — всем запрошенным топологиям.
Это предотвращает тупиковую ситуацию, когда поды не могут запланироваться из-за того, что все они связаны правилами совместного существования.
#### Пример правил совместного/раздельного существования для пода {#an-example-of-a-pod-that-uses-pod-affinity}
Рассмотрим следующую спецификацию пода:
apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: topology.kubernetes.io/zone
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: topology.kubernetes.io/zone
containers:
- name: with-pod-affinity
image: registry.k8s.io/pause:2.0
В примере задается одно правило совместного существования подов, и одно — раздельного. Для совместного правила используется жесткий тип `requiredDuringSchedulingIgnoredDuringExecution`, для раздельного — мягкий `preferredDuringSchedulingIgnoredDuringExecution`.
Правило совместного существования гласит, что планировщик может разместить под на узел, только если тот находится в зоне с одним или более подами с лейблом `security=S1`.
Например, если есть кластер с выделенной зоной, назовем ее "V",
состоящей из узлов с лейблом `topology.kubernetes.io/zone=V`, планировщик может
назначить под на любой узел зоны V только если в этой зоне уже есть хотя бы один под
с лейблом `security=S1`. И наоборот, если в зоне V нет подов с лейблом `security=S1`,
планировщик не сможет назначить под на какой-либо из узлов в этой зоне.
Правило раздельного существования гласит, что планировщик при возможности не должен размещать под на узел, если тот находится в зоне с одним или более подами с лейблом `security=S2`.
Например, если есть кластер с выделенной зоной, назовем ее "R",
состоящей из узлов с лейблами `topology.kubernetes.io/zone=R`. Планировщик должен избегать
назначать поды на узлы из зоны R, если в ней уже есть по крайней мере один под
с лейблом `security=S2`. Соответственно, если в зоне R нет подов с лейблами `security=S2`,
правило раздельного существования не будет влиять на планирование подов в эту зону.
Больше примеров правил совместного/раздельного существования для подов можно найти в [рабочей документации](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
Поле `operator` пода поддерживает значения `In`, `NotIn`, `Exists` и `DoesNotExist` при задании правил совместного/раздельного существования.
Узнать больше о том, как они работают, можно в подразделе [Операторы](/#operators).
В принципе, `topologyKey` может быть любым разрешенным лейблом-ключом со следующими исключениями по соображениям производительности и безопасности:
* При задании правил совместного/раздельного существования для подов пустое поле `topologyKey` не допускается как для `requiredDuringSchedulingIgnoredDuringExecution`, так и для `preferredDuringSchedulingIgnoredDuringExecution`.
* Для правил раздельного существования типа `requiredDuringSchedulingIgnoredDuringExecution` admission-контроллер разрешает использовать только `kubernetes.io/hostname` в качестве `topologyKey`. Для работы с кастомными топологиями admission-контроллер можно дополнить или совсем отключить его.
В дополнение к `labelSelector` и `topologyKey` можно опционально указать список пространств имен, которые должен выбирать `labelSelector`, с помощью поля `namespaces` на том же уровне, что `labelSelector` и `topologyKey`. Если поле `namespaces` опущено или пусто, по умолчанию выбирается пространство имен пода, в котором задаются правила совместного/раздельного существования.
#### Селектор пространств имен
СТАТУС ФИЧИ:
Kubernetes v1.24 [stable]
Подходящие пространства имен также можно выбрать с помощью `namespaceSelector`, который попытается найти лейбл в наборе пространств имен.
Условия совместного существования применяются к пространствам имен, выбранным как селектором `namespaceSelector`, так и полем `namespaces`.
Обратите внимание, что пустой селектор `namespaceSelector` ({}) выбирает все пространства имен, в то время как пустой или null-список `namespaces` и null-селектор `namespaceSelector` выбирает пространство имен пода, в котором правило задано.
#### matchLabelKeys
СТАТУС ФИЧИ:
Kubernetes v1.33 [stable](enabled by default)
Примечание:
Поле matchLabelKeys является полем альфа-уровня и по умолчанию отключено в
Kubernetes 1.36.
Включить его можно с помощью переключателя функциональности
(feature gate) MatchLabelKeysInPodAffinity.
СТАТУС ФИЧИ:
Kubernetes v1.33 [stable](enabled by default)
Примечание:
Поле mismatchLabelKeys является полем альфа-уровня и по умолчанию отключено в
Kubernetes 1.36.
Включить его можно с помощью переключателя функциональности
(feature gate) MatchLabelKeysInPodAffinity.
Примечание:
Поле
nodeName предназначено для использования в кастомных планировщиках или в продвинутых случаях,
когда необходимо обойти настроенные планировщики. Обход планировщиков может привести к тому, что поды не будут запущены,
если целевые узлы окажутся перегруженными. С помощью правила
совместного существования (affinity) узла или поля
nodeselector под можно назначить на определенный узел, не обходя планировщики с помощью
nodeName.
Примечание:
Операторы Gt и Lt не работают с нецелыми значениями. Если заданное значение
не является целым числом, под не будет запланирован. Кроме того, Gt и Lt
недоступны для podAffinity.
## Что дальше
* Дополнительная информация о [taint'ах и toleration'ах](/docs/concepts/scheduling-eviction/taint-and-toleration/).
* Рабочая документация по правилам [совместного существования для узлов](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md) и по правилам [совместного/раздельного существования для подов](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
* [Информация о том](/docs/tasks/administer-cluster/topology-manager/), как менеджер топологии участвует в принятии решений о распределении ресурсов на уровне узлов.
* Подробнее об использовании [селектора nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/).
* Подробнее об использовании правил [совместного/раздельного существования](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/).
