Apply suggestions from code review

Co-authored-by: Dmitry Shurupov <dmitry.shurupov@palark.com>

content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -30,7 +30,7 @@ weight: 20
 Kubernetes также предоставляет стандартный набор лейблов на всех узлах кластера. Список общих для узлов лейблов приведен в разделе [Типичные лейблы, аннотации и taint'ы](/docs/reference/labels-annotations-taints/).
 
 {{<note>}}
-Значения этих лейблов зависят от облачного провайдера и не гарантируются.
+Значения этих лейблов зависят от облачного провайдера, поэтому нельзя точно на них полагаться.
 Например, в одних окружениях значение `kubernetes.io/hostname` может совпадать с именем узла, в других — отличаться.
 {{</note>}}
 
@@ -44,7 +44,6 @@ Kubernetes также предоставляет стандартный набо
 
 Чтобы использовать этот префикс для изоляции узла:
 
-
 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`.
 
@@ -55,9 +54,9 @@ Kubernetes также предоставляет стандартный набо
 
 Дополнительную информацию см. в разделе [Размещение Pod'ов на узлах](/docs/tasks/configure-pod-container/assign-pods-nodes).
 
-## Правила совместного/раздельного существования (affinity и anti-affinity)
+## Правила совместного/раздельного существования (affinity и anti-affinity) {#affinity-and-anti-affinity}
 
-`nodeSelector` — самый простой способ развернуть Pod'ы на узлах с определенными лейблами. Плавила совместного/раздельного существования расширяют типы ограничений, которые можно накладывать. Вот некоторые из их преимуществ:
+`nodeSelector` — самый простой способ развернуть Pod'ы на узлах с определенными лейблами. Правила совместного/раздельного существования расширяют типы ограничений, которые можно накладывать. Вот некоторые из их преимуществ:
 
 * Язык правил affinity/anti-affinity более выразителен. `nodeSelector` выбирает узлы только со всеми указанными лейблами. Правила affinity/anti-affinity расширяют логику выбора и делают ее более гибкой.
 * Правило может быть *мягким* (soft) или *предпочтительным* (preferred). В этом случае планировщик все равно запланирует Pod, даже если подходящего узла для него не найдется.
@@ -70,7 +69,7 @@ Kubernetes также предоставляет стандартный набо
 
 ### Правила совместного существования для узлов (node affinity)
 
-Правила совместного существования для узлов концептуально похожи на `nodeSelector`. С помощью лейблов они позволяют ограничивать список узлов, на которые может быть запланирован Существует два типа таких правил:
+Правила совместного существования для узлов концептуально похожи на `nodeSelector`. С помощью лейблов они позволяют ограничивать список узлов, на которые может быть запланирован Pod. Существует два типа таких правил:
 
   * `requiredDuringSchedulingIgnoredDuringExecution`: Планировщик не может запланировать Pod, если правило не выполнено. Работает как `nodeSelector`, но с более выразительным синтаксисом.
   * `preferredDuringSchedulingIgnoredDuringExecution`: Планировщик пытается найти узел, который соответствует правилу. Если подходящий узел не удается найти, планировщик все равно планирует Pod.
@@ -90,17 +89,17 @@ Kubernetes также предоставляет стандартный набо
   * У узла *должен* быть лейбл с ключом `topology.kubernetes.io/zone`, и значение этого лейбла *должно* быть либо `antarctica-east1`, либо `antarctica-west1`.
   * *Предпочтительно*, чтобы у узла был лейбл с ключом `another-node-label-key` и значением `another-node-label-value`.
 
-Можно использовать поле `operator` для указания логического оператора, который Kubernetes будет использовать при интерпретации правил. Доступны `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt` и `Lt`.
+Можно использовать поле `operator` для указания логического оператора, который Kubernetes будет применять при интерпретации правил. Доступны `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt` и `Lt`.
 
 `NotIn` и `DoesNotExist` позволяют задавать правила раздельного существования (anti-affinity) для узла.
 Кроме того, можно использовать [taint'ы узлов](/docs/concepts/scheduling-eviction/taint-and-toleration/), чтобы "отвадить" Pod'ы от определенных узлов.
 
 {{<note>}}
-Когда указаны и `nodeSelector`, и `nodeAffinity`,  Pod будет запланирован на узел только в том случае, если *оба* этих параметра удовлетворены.
+Когда указаны и `nodeSelector`, и `nodeAffinity`, Pod будет запланирован на узел только в том случае, если *оба* этих параметра удовлетворены.
 
 Если указать несколько условий `nodeSelectorTerms`, привязанных к типам `nodeAffinity`, то Pod может быть запланирован на узел, если удовлетворяется одно из указанных условий `nodeSelectorTerms`.
 
-Если задать несколько выражений `matchExpressions` для одного условия `nodeSelectorTerms`, Pod будет запланирован на узел только если удовлетворены все выражения `matchExpressions`. {{}}
+Если задать несколько выражений `matchExpressions` для одного условия `nodeSelectorTerms`, Pod будет запланирован на узел, только если удовлетворены все выражения `matchExpressions`. {{}}
 {{</note>}}
 
 Дополнительную информацию см. в разделе [Размещаем Pod'ы на узлы с помощью Node Affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/).
@@ -109,7 +108,7 @@ Kubernetes также предоставляет стандартный набо
 
 Для каждого правила типа `preferredDuringSchedulingIgnoredDuringExecution` можно указать вес `weight` в диапазоне от 1 до 100. Найдя несколько узлов, удовлетворяющих всем остальным требованиям для планирования Pod'а, планировщик перебирает предпочтительные правила, которым удовлетворяет узел, и прибавляет их вес для этого выражения к сумме.
 
-Итоговая сумма добавляется к оценке, полученной при анализе других параметров, влияющих на приоритета узл. Принимая решение о размещении Pod'а, планировщик отдает предпочтение узлам с наибольшей суммарной оценкой.
+Итоговая сумма добавляется к оценке, полученной при анализе других параметров, влияющих на приоритет узла. Принимая решение о размещении Pod'а, планировщик отдает предпочтение узлам с наибольшей суммарной оценкой.
 
 В качестве примера рассмотрим следующую спецификацию Pod'а:
 
@@ -147,7 +146,7 @@ profiles:
                   - foo
 ```
 
-Правило addedAffinity применяется ко всем Pod'ам с полем `.spec.schedulerName`, имеющем значение `foo-scheduler`, в дополнение к NodeAffinity, заданному в PodSpec. Таким образом, подходящие для Pod'а узлы должны удовлетворять параметрам `addedAffinity` и правилам `.spec.NodeAffinity` Pod'а.
+Правило `addedAffinity` применяется ко всем Pod'ам с полем `.spec.schedulerName`, имеющем значение `foo-scheduler`, в дополнение к NodeAffinity, заданному в PodSpec. Таким образом, подходящие для Pod'а узлы должны удовлетворять параметрам `addedAffinity` и правилам `.spec.NodeAffinity` Pod'а.
 
 Поскольку конечные пользователи не видят `addedAffinity`, результат применения этих правил может быть для них неожиданным. Используйте лейблы узлов, которые однозначно соотносятся с именем профиля планировщика.