Partial update up to line 206 - assign-pod-node.md

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-хранилищем или разместить два активно взаимодействующих друг с другом пода в одной зоне доступности.
 
 <!-- body -->
@@ -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/) на все узлы кластера.
 
 {{<note>}}
-Значения этих лейблов зависят от облачного провайдера, поэтому нельзя точно на них полагаться.
+Значения этих лейблов зависят от облачного провайдера, поэтому на них нельзя полагаться.
 Например, в одних окружениях значение `kubernetes.io/hostname` может совпадать с именем узла, в других — отличаться.
 {{</note>}}
 
 ### Изоляция узла/ограничение его использования
 
-Лейблы узлов позволяют планировать поды на определенные узлы или группы узлов. С их помощью можно планировать поды на узлы с определенными требованиями к изоляции, безопасности или соответствию нормативным актам.
+Лейблы узлов позволяют размещать поды на определенные узлы или группы узлов. С их помощью можно планировать поды на узлы с определенными требованиями к изоляции, безопасности или соответствию нормативным положениям.
 
-При использовании лейблов для изоляции узлов следует выбирать ключи лейблов, которые {{<glossary_tooltip text="kubelet" term_id="kubelet">}} не может изменить. В этом случае взломанный узел не сможет навесить на себя эти лейблы в надежде заполучить рабочие нагрузки.
+При использовании лейблов для изоляции узлов следует выбирать ключи лейблов, которые {{<glossary_tooltip text="kubelet" term_id="kubelet">}} не может изменить. В этом случае взломанный узел не сможет навесить на себя эти лейблы в надежде, что планировщик разместит на него рабочие нагрузки.
 
 [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/), чтобы "отвадить" поды от определенных узлов.
 
 {{<note>}}
-Когда указаны и `nodeSelector`, и `nodeAffinity`, под будет запланирован на узел только в том случае, если *оба* этих параметра удовлетворены.
+Когда указаны и `nodeSelector`, и `nodeAffinity`, под будет запланирован на узел только в том случае, если *оба* этих условия удовлетворены.
   
 Если указать несколько условий `nodeSelectorTerms`, привязанных к типам `nodeAffinity`, то под может быть запланирован на узел, если удовлетворяется одно из указанных условий `nodeSelectorTerms`. К условиям применяется логическое ИЛИ.
 
-Если задать несколько выражений `matchExpressions` для одного условия `nodeSelectorTerms`, под будет запланирован на узел, только если удовлетворены все выражения `matchExpressions`. К условиям применяется логическое И.
+Если задать несколько выражений в поле `matchExpressions` для одного условия `nodeSelectorTerms`, под будет запланирован на узел только если удовлетворены все выражения `matchExpressions`. К условиям применяется логическое И.
 {{</note>}}
 
-Дополнительную информацию см. в разделе [Размещаем 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).