diff --git a/content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md index ab5bd7a41f..3b46a52eb8 100644 --- a/content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -9,7 +9,7 @@ weight: 20 Можно настроить {{< glossary_tooltip text="под" term_id="pod" >}} так, чтобы тот мог запускаться _только_ на определенном(-ых) {{< glossary_tooltip text="узле(-ах)" term_id="node" >}} или _предпочитал_ определенную группу узлов. Сделать это можно несколькими способами, при этом все рекомендуемые подходы используют [селекторы лейблов](/ru/docs/concepts/overview/working-with-objects/labels/) для выбора. -Зачастую нужды в подобных ограничениях нет; {{< glossary_tooltip text="планировщик" term_id="kube-scheduler" >}} автоматически размещает поды оптимальным образом (например, распределяет их по узлам, чтобы они не оказались все на одном узле и не привели к дефициту ресурсов). +Зачастую нужды в подобных ограничениях нет; {{< glossary_tooltip text="планировщик" term_id="kube-scheduler" >}} автоматически размещает поды оптимальным образом (например, распределяет их по узлам, чтобы они не оказались все на одном узле с дефицитом ресурсов). Однако в некоторых обстоятельствах возможность контролировать, куда именно попадет под, может пригодиться. Например, она поможет запланировать под на узел с быстрым SSD-хранилищем или разместить два активно взаимодействующих друг с другом пода в одной зоне доступности. @@ -24,18 +24,18 @@ weight: 20 ## Лейблы узлов {#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 также навешивает [стандартный набор лейблов](/docs/reference/node/node-labels/) на все узлы кластера. {{}} -Значения этих лейблов зависят от облачного провайдера, поэтому нельзя точно на них полагаться. +Значения этих лейблов зависят от облачного провайдера, поэтому на них нельзя полагаться. Например, в одних окружениях значение `kubernetes.io/hostname` может совпадать с именем узла, в других — отличаться. {{}} ### Изоляция узла/ограничение его использования -Лейблы узлов позволяют планировать поды на определенные узлы или группы узлов. С их помощью можно планировать поды на узлы с определенными требованиями к изоляции, безопасности или соответствию нормативным актам. +Лейблы узлов позволяют размещать поды на определенные узлы или группы узлов. С их помощью можно планировать поды на узлы с определенными требованиями к изоляции, безопасности или соответствию нормативным положениям. -При использовании лейблов для изоляции узлов следует выбирать ключи лейблов, которые {{}} не может изменить. В этом случае взломанный узел не сможет навесить на себя эти лейблы в надежде заполучить рабочие нагрузки. +При использовании лейблов для изоляции узлов следует выбирать ключи лейблов, которые {{}} не может изменить. В этом случае взломанный узел не сможет навесить на себя эти лейблы в надежде, что планировщик разместит на него рабочие нагрузки. [Admission-плагин NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) не позволяет kubelet'у устанавливать или изменять лейблы с префиксом `node-restriction.kubernetes.io/`. @@ -47,7 +47,7 @@ Kubernetes также предоставляет [стандартный наб ## nodeSelector `nodeSelector` — простейшая рекомендуемая форма настроек выбора узлов. -Можно добавить поле `nodeSelector` в спецификацию пода и перечислить в нем [лейблы узлов](#built-in-node-labels), подходящих для развертывания пода. В этом случае Kubernetes будет размещать под только на узлах с указанными лейблами. +Можно добавить поле `nodeSelector` в спецификацию пода и перечислить в нем [лейблы узлов](#built-in-node-labels), которые подходят для развертывания пода. В этом случае Kubernetes будет планировать под только на узлы со всеми указанными лейблами. Дополнительную информацию см. в разделе [Размещение подов на узлах](/docs/tasks/configure-pod-container/assign-pods-nodes). @@ -94,18 +94,18 @@ Kubernetes также предоставляет [стандартный наб Кроме того, можно использовать [taint'ы узлов](/docs/concepts/scheduling-eviction/taint-and-toleration/), чтобы "отвадить" поды от определенных узлов. {{}} -Когда указаны и `nodeSelector`, и `nodeAffinity`, под будет запланирован на узел только в том случае, если *оба* этих параметра удовлетворены. +Когда указаны и `nodeSelector`, и `nodeAffinity`, под будет запланирован на узел только в том случае, если *оба* этих условия удовлетворены. Если указать несколько условий `nodeSelectorTerms`, привязанных к типам `nodeAffinity`, то под может быть запланирован на узел, если удовлетворяется одно из указанных условий `nodeSelectorTerms`. К условиям применяется логическое ИЛИ. -Если задать несколько выражений `matchExpressions` для одного условия `nodeSelectorTerms`, под будет запланирован на узел, только если удовлетворены все выражения `matchExpressions`. К условиям применяется логическое И. +Если задать несколько выражений в поле `matchExpressions` для одного условия `nodeSelectorTerms`, под будет запланирован на узел только если удовлетворены все выражения `matchExpressions`. К условиям применяется логическое И. {{}} -Дополнительную информацию см. в разделе [Размещаем Pod'ы на узлы с помощью Node Affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/). +Дополнительную информацию см. в разделе [Размещаем поды на узлы с помощью Node Affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/). #### Вес правил совместного существования -Для каждого правила типа `preferredDuringSchedulingIgnoredDuringExecution` можно указать вес `weight` в диапазоне от 1 до 100. Найдя несколько узлов, удовлетворяющих всем остальным требованиям для планирования пода, планировщик перебирает предпочтительные правила, которым удовлетворяет узел, и прибавляет их вес для этого выражения к сумме. +Для каждого правила типа `preferredDuringSchedulingIgnoredDuringExecution` можно указать вес `weight` в диапазоне от 1 до 100. Найдя несколько узлов, удовлетворяющих всем остальным требованиям для планирования пода, планировщик перебирает предпочтительные правила, которым удовлетворяет узел, и суммирует их веса. Итоговая сумма добавляется к оценке, полученной при анализе других параметров, влияющих на приоритет узла. Принимая решение о размещении пода, планировщик отдает предпочтение узлам с наибольшей суммарной оценкой. @@ -157,7 +157,7 @@ profiles: Правила совместного/раздельного существования подов позволяют выбирать узлы для планирования в зависимости от лейблов **подов**, которые уже на этих узлах работают (вместо лейблов самих узлов). -Алгоритм работы правил совместного/раздельного существования подов можно описать так: "данный под должен (или не должен в случае раздельного (anti-affinity) существования) размещаться на X, если на нем уже работает один или несколько подов, удовлетворяющих правилу Y", где X — топологический домен, например, узел, стойка, зона/регион облачного провайдера и т.п., а Y — правило, которое Kubernetes пытается удовлетворить. +Алгоритм работы правил совместного/раздельного существования подов можно описать так: "данный под _должен_ (или _не должен_ в случае раздельного (anti-affinity) существования) размещаться на X, если на нем уже работает один или несколько подов, удовлетворяющих правилу Y", где X — топологический домен, например, узел, стойка, зона/регион облачного провайдера и т. п., а Y — правило, которое Kubernetes пытается удовлетворить. Для задания правил Y используются [селекторы лейблов](/ru/docs/concepts/overview/working-with-objects/labels/#селекторы-меток) с необязательным связанным списком пространств имен. Для подов в Kubernetes указываются пространства имен, соответственно, их лейблы также оказываются неявно связаны с этими же пространствами имен. Любые селекторы лейблов для лейблов подов должны содержать пространства имен, в которых Kubernetes должен искать эти лейблы. @@ -178,7 +178,7 @@ profiles: * `requiredDuringSchedulingIgnoredDuringExecution` * `preferredDuringSchedulingIgnoredDuringExecution` -Например, с помощью правила совместного существования `requiredDuringSchedulingIgnoredDuringExecution` можно указать планировщику размещать поды, относящиеся к разным сервисам, в одной зоне облачного провайдера, поскольку они активно обмениваются данными друг с другом. +Например, с помощью правила совместного существования `requiredDuringSchedulingIgnoredDuringExecution` можно заставить планировщик размещать поды, относящиеся к разным сервисам, в одной зоне облачного провайдера, поскольку они активно обмениваются данными друг с другом. Аналогичным образом можно использовать правило раздельного существования `preferredDuringSchedulingIgnoredDuringExecution` для распределения подов по нескольким зонам облачного провайдера. @@ -186,6 +186,14 @@ profiles: Для задания правил раздельного существования предназначено поле `affinity.podAntiAffinity` в спецификации пода. +#### Планирование группы подов, связанных правилами совместного существования + +Если планируемый под — первый в серии подов, связанных правилами совместного существования, +он может быть запланирован, если удовлетворит всем остальным правилам совместного существования. Чтобы подтвердить, что этот под — действительно первый, +проводится проверка, которая должна показать, что пространство имен и селектор этого пода уникальны в кластере (то есть нет других таких подов). Кроме того, +под должен соответствовать своим собственным правилам, а выбранный узел — всем запрошенным топологиям. +Это предотвращает тупиковую ситуацию, когда поды не могут запланироваться из-за того, что все они связаны правилами совместного существования. + #### Пример правил совместного/раздельного существования для пода {#an-example-of-a-pod-that-uses-pod-affinity} Рассмотрим следующую спецификацию пода: @@ -194,9 +202,31 @@ profiles: В примере задается одно правило совместного существования подов, и одно — раздельного. Для совместного правила используется жесткий тип `requiredDuringSchedulingIgnoredDuringExecution`, для раздельного — мягкий `preferredDuringSchedulingIgnoredDuringExecution`. -Правило совместного существования гласит, что планировщик может разместить под на узел, только если тот находится в зоне с одним или более подами с лейблом `security=S1`. Точнее, планировщик должен разместить под на узле с лейблом `topology.kubernetes.io/zone=V`, если в этой зоне есть хотя бы один узел, на котором работают один или несколько подов с лейблом `security=S1`. +Правило совместного существования гласит, что планировщик может разместить под на узел, только если тот находится в зоне с одним или более подами с лейблом `security=S1`. +For instance, if we have a cluster with a designated zone, let's call it "Zone V," +consisting of nodes labeled with `topology.kubernetes.io/zone=V`, the scheduler can +assign the Pod to any node within Zone V, as long as there is at least one Pod within +Zone V already labeled with `security=S1`. Conversely, if there are no Pods with `security=S1` +labels in Zone V, the scheduler will not assign the example Pod to any node in that zone. + + +Точнее, планировщик должен разместить под на узле с лейблом `topology.kubernetes.io/zone=V`, если в этой зоне есть хотя бы один узел, на котором работают один или несколько подов с лейблом `security=S1`. + + + + +Правило раздельного существования гласит, что планировщик при возможности не должен размещать под на узел, если тот находится в зоне с одним или более подами с лейблом `security=S2`. +For instance, if we have a cluster with a designated zone, let's call it "Zone R," +consisting of nodes labeled with `topology.kubernetes.io/zone=R`, the scheduler should avoid +assigning the Pod to any node within Zone R, as long as there is at least one Pod within +Zone R already labeled with `security=S2`. Conversely, the anti-affinity rule does not impact +scheduling into Zone R if there are no Pods with `security=S2` labels. + + +Точнее, планировщик при возможности не должен размещать под на узлы с лейблом `topology.kubernetes.io/zone=R`, если в этой зоне есть другие узлы, на которых работают поды с лейблом `security=S2`. + + -Правило раздельного существования гласит, что планировщик при возможности не должен размещать под на узел, если тот находится в зоне с одним или более подами с лейблом `security=S2`. Точнее, планировщик при возможности не должен размещать под на узлы с лейблом `topology.kubernetes.io/zone=R`, если в этой зоне есть другие узлы, на которых работают поды с лейблом `security=S2`. Больше примеров правил совместного/раздельного существования для подов можно найти в [рабочей документации](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).