Apply suggestions from code review

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

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

@@ -8,7 +8,7 @@ weight: 20
 <!-- overview -->
 
 Можно настроить {{< glossary_tooltip text="под" term_id="pod" >}} так, чтобы тот мог запускаться _только_ на определенном(-ых) {{< glossary_tooltip text="узле(-ах)" term_id="node" >}} или _предпочитал_ определенную группу узлов.
-Сделать это можно несколькими способами, при этом все рекомендуемые подходы используют [селекторы лейблов](/docs/concepts/overview/working-with-objects/labels/) для выбора.
+Сделать это можно несколькими способами, при этом все рекомендуемые подходы используют [селекторы лейблов](/ru/docs/concepts/overview/working-with-objects/labels/) для выбора.
 Зачастую нужды в подобных ограничениях нет; {{< glossary_tooltip text="планировщик" term_id="kube-scheduler" >}} автоматически размещает поды оптимальным образом (например, распределяет их по узлам, чтобы они не оказались все на одном узле и не привели к дефициту ресурсов).
 Однако в некоторых обстоятельствах возможность контролировать, куда именно попадет под, может пригодиться. Например, она поможет запланировать под на узел с быстрым SSD-хранилищем или разместить два активно взаимодействующих друг с другом пода в одной зоне доступности.
 
@@ -23,8 +23,8 @@ weight: 20
 
 ## Лейблы узлов {#built-in-node-labels}
 
-Как и у многих других объектов Kubernetes, у узлов есть [лейблы](/docs/concepts/overview/working-with-objects/labels/). Их можно [навешивать вручную](/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node).
-Kubernetes также предоставляет стандартный набор лейблов на всех узлах кластера. Список общих для узлов лейблов приведен в разделе [Типичные лейблы, аннотации и taint'ы](/docs/reference/labels-annotations-taints/).
+Как и у многих других объектов 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/) на всех узлах кластера.
 
 {{<note>}}
 Значения этих лейблов зависят от облачного провайдера, поэтому нельзя точно на них полагаться.
@@ -62,9 +62,9 @@ Kubernetes также предоставляет стандартный набо
 Правила совместного существования (affinity) бывают двух типов:
 
 * *Правила для узлов* (node affinity) работают подобно полю `nodeSelector`, но более выразительны. Кроме того, можно задавать мягкие правила. 
-* *Правила для подов* позволяют при планировании учитывать наличие других подов (соответственно, и их лейблы) на узлах.
+* *Правила для подов* (inter-pod affinity и anti-affinity) позволяют при планировании учитывать лейблы других подов.
 
-### Правила совместного существования для узлов (node affinity)
+### Правила совместного существования для узлов (node affinity) {#node-affinity}
 
 Правила совместного существования для узлов концептуально похожи на `nodeSelector`. С помощью лейблов они позволяют ограничивать список узлов, на которые может быть запланирован под. Существует два типа таких правил:
 
@@ -88,15 +88,17 @@ Kubernetes также предоставляет стандартный набо
 
 Можно использовать поле `operator` для указания логического оператора, который Kubernetes будет применять при интерпретации правил. Доступны `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt` и `Lt`.
 
+Узнать больше о том, как они работают, можно в подразделе [Операторы](/#operators).
+
 `NotIn` и `DoesNotExist` позволяют задавать правила раздельного существования (anti-affinity) для узла.
 Кроме того, можно использовать [taint'ы узлов](/docs/concepts/scheduling-eviction/taint-and-toleration/), чтобы "отвадить" поды от определенных узлов.
 
 {{<note>}}
 Когда указаны и `nodeSelector`, и `nodeAffinity`, под будет запланирован на узел только в том случае, если *оба* этих параметра удовлетворены.
 
-Если указать несколько условий `nodeSelectorTerms`, привязанных к типам `nodeAffinity`, то под может быть запланирован на узел, если удовлетворяется одно из указанных условий `nodeSelectorTerms`.
+Если указать несколько условий `nodeSelectorTerms`, привязанных к типам `nodeAffinity`, то под может быть запланирован на узел, если удовлетворяется одно из указанных условий `nodeSelectorTerms`. К условиям применяется логическое ИЛИ.
 
-Если задать несколько выражений `matchExpressions` для одного условия `nodeSelectorTerms`, под будет запланирован на узел, только если удовлетворены все выражения `matchExpressions`. {{}}
+Если задать несколько выражений `matchExpressions` для одного условия `nodeSelectorTerms`, под будет запланирован на узел, только если удовлетворены все выражения `matchExpressions`. К условиям применяется логическое И.
 {{</note>}}
 
 Дополнительную информацию см. в разделе [Размещаем Pod'ы на узлы с помощью Node Affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/).
@@ -111,7 +113,7 @@ Kubernetes также предоставляет стандартный набо
 
 {{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}}
 
-Если правилу `preferredDuringSchedulingIgnoredDuringExecution` соответствуют два узла (один — с лейблом `label-1:key-1`, другой — с `label-2:key-2`), планировщик считает вес `weight` каждого узла и добавляет его к другим оценкам для этого узла. под планируется на узел с наивысшей итоговой оценкой.
+Если правилу `preferredDuringSchedulingIgnoredDuringExecution` соответствуют два узла (один — с лейблом `label-1:key-1`, другой — с `label-2:key-2`), планировщик считает вес `weight` каждого узла и добавляет его к другим оценкам для этого узла. Под планируется на узел с наивысшей итоговой оценкой.
 
 {{<note>}}
 Чтобы Kubernetes смог запланировать поды в этом примере, необходимо, чтобы существовали узлы с лейблом `kubernetes.io/os=linux`.
@@ -143,7 +145,7 @@ profiles:
                   - foo
 ```
 
-Правило `addedAffinity` применяется ко всем подам с полем `.spec.schedulerName`, имеющем значение `foo-scheduler`, в дополнение к NodeAffinity, заданному в PodSpec. Таким образом, подходящие для пода узлы должны удовлетворять параметрам `addedAffinity` и правилам `.spec.NodeAffinity` пода.
+Правило `addedAffinity` применяется ко всем подам с полем `.spec.schedulerName`, имеющим значение `foo-scheduler`, в дополнение к NodeAffinity, заданному в PodSpec. Таким образом, подходящие для пода узлы должны удовлетворять параметрам `addedAffinity` и правилам `.spec.NodeAffinity` пода.
 
 Поскольку конечные пользователи не видят `addedAffinity`, результат применения этих правил может быть для них неожиданным. Используйте лейблы узлов, которые однозначно соотносятся с именем профиля планировщика.
 
@@ -157,7 +159,7 @@ profiles:
 
 Алгоритм работы правил совместного/раздельного существования подов можно описать так: "данный под должен (или не должен в случае раздельного (anti-affinity) существования) размещаться на X, если на нем уже работает один или несколько подов, удовлетворяющих правилу Y", где X — топологический домен, например, узел, стойка, зона/регион облачного провайдера и т.п., а Y — правило, которое Kubernetes пытается удовлетворить.
 
-Для задания правил Y используются [селекторы лейблов](/docs/concepts/overview/working-with-objects/labels/#label-selectors) с необязательным связанным списком пространств имен. Для подов в Kubernetes указываются пространства имен, соответственно, их лейблы также оказываются неявно связаны с этими же пространствами имен. Любые селекторы лейблов для лейблов подов должны содержать пространства имен, в которых Kubernetes должен искать эти лейблы.
+Для задания правил Y используются [селекторы лейблов](/ru/docs/concepts/overview/working-with-objects/labels/#селекторы-меток) с необязательным связанным списком пространств имен. Для подов в Kubernetes указываются пространства имен, соответственно, их лейблы также оказываются неявно связаны с этими же пространствами имен. Любые селекторы лейблов для лейблов подов должны содержать пространства имен, в которых Kubernetes должен искать эти лейблы.
 
 Топологический домен X задается с помощью `topologyKey` — ключа для лейбла узла, который система использует для обозначения домена. Примеры см. в разделе [Типичные лейблы, аннотации и taint'ы](/docs/reference/labels-annotations-taints/).
 
@@ -200,6 +202,8 @@ profiles:
 
 Поле `operator` пода поддерживает значения `In`, `NotIn`, `Exists` и `DoesNotExist` при задании правил совместного/раздельного существования.
 
+Узнать больше о том, как они работают, можно в подразделе [Операторы](/#operators).
+
 В принципе, `topologyKey` может быть любым разрешенным лейблом-ключом со следующими исключениями по соображениям производительности и безопасности:
 
 * При задании правил совместного/раздельного существования для подов пустое поле `topologyKey` не допускается как для `requiredDuringSchedulingIgnoredDuringExecution`, так и для `preferredDuringSchedulingIgnoredDuringExecution`.
@@ -220,7 +224,7 @@ profiles:
 
 Представьте кластер, состоящий из трех узлов. Он используется для запуска веб-приложения и как in-memory-кэш (например, Redis). Предположим, что задержка между веб-приложением и кэшем должна быть минимальной. Правила совместного/раздельного существования для подов позволяют настроить планировщик так, чтобы тот размещал веб-серверы как можно ближе к кэшу.
 
-В приведенном ниже примере конфигурации Deployment'а Redis'а реплики получают лейбл `app=store`. Правило `podAntiAffinity` запрещает планировщику планировать несколько реплик с лейблом `app=store` на один узел. Таким образом, каждая кэш-реплика работает на отдельном узле.
+В приведенном ниже примере конфигурации деплоймента с Redis его реплики получают лейбл `app=store`. Правило `podAntiAffinity` запрещает планировщику размещать несколько реплик с лейблом `app=store` на одном узле. Таким образом, каждая кэш-реплика работает на отдельном узле.
 
 ```yaml
 apiVersion: apps/v1
@@ -252,7 +256,7 @@ spec:
         image: redis:3.2-alpine
 ```
 
-Конфигурация Deployment'а, приведенная ниже, создает три реплики веб-сервера с лейблом `app=web-store`.
+Конфигурация деплоймента, приведенная ниже, создает три реплики веб-сервера с лейблом `app=web-store`.
 Правило совместного существования предписывает планировщику размещать каждую реплику на узле, на котором уже имеется под с лейблом `app=store`. В то же время правило раздельного существования запрещает планировщику размещать несколько серверов с лейблом `app=web-store` на одном узле.
 
 ```yaml

content/ru/docs/reference/issues-security/issues.md

@@ -4,11 +4,11 @@ weight: 10
 aliases: [/cve/,/cves/]
 ---
 
-Чтобы сообщить о проблеме в области безопасности, воспользуйтесь процедурой [раскрытия информации о безопасности Kubernetes](/docs/reference/issues-security/security/#report-a-vulnerability).
+Чтобы сообщить о проблеме в области безопасности, воспользуйтесь процедурой [раскрытия информации о безопасности Kubernetes](/ru/docs/reference/issues-security/security/#report-a-vulnerability).
 
 Механизм [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/) позволяет работать с кодом Kubernetes и отслеживать активные задачи.
 
-* Официальный [список известных CVE](/docs/reference/issues-security/official-cve-feed/) 
+* Официальный [список известных CVE](/ru/docs/reference/issues-security/official-cve-feed/) 
 (уязвимостей в области безопасности), которые были обнародованы [Комитетом по реагированию на угрозы в области безопасности Kubernetes](https://github.com/kubernetes/committee-security-response).
 * [Issues на GitHub, связанные с CVE](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE)
 

content/ru/docs/reference/issues-security/official-cve-feed.md

@@ -11,7 +11,7 @@ layout: cve-feed
 
 Поддерживаемый сообществом список официальных CVE, анонсированных
 Комитетом по реагированию на проблемы безопасности Kubernetes. Подробности см. на странице
-[Общие сведения о безопасности Kubernetes и раскрытии информации](/docs/reference/issues-security/security/).
+[Общие сведения о безопасности Kubernetes и раскрытии информации](/ru/docs/reference/issues-security/security/).
 
 Проект Kubernetes публикует доступный для автоматического считывания [JSON-фид](/docs/reference/issues-security/official-cve-feed/index.json), включающий анонсированные проблемы в области безопасности. Доступ к нему можно получить, выполнив следующую команду: