From 6ee5e204a8c44d63abb5d58f089cf6da24dfabe5 Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Mon, 24 Apr 2023 08:10:44 +0300 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Dmitry Shurupov --- .../scheduling-eviction/assign-pod-node.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) 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 fd3b7f6d78593..cc2508e20ce8f 100644 --- a/content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -30,7 +30,7 @@ weight: 20 Kubernetes также предоставляет стандартный набор лейблов на всех узлах кластера. Список общих для узлов лейблов приведен в разделе [Типичные лейблы, аннотации и taint'ы](/docs/reference/labels-annotations-taints/). {{}} -Значения этих лейблов зависят от облачного провайдера и не гарантируются. +Значения этих лейблов зависят от облачного провайдера, поэтому нельзя точно на них полагаться. Например, в одних окружениях значение `kubernetes.io/hostname` может совпадать с именем узла, в других — отличаться. {{}} @@ -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'ы от определенных узлов. {{}} -Когда указаны и `nodeSelector`, и `nodeAffinity`, Pod будет запланирован на узел только в том случае, если *оба* этих параметра удовлетворены. +Когда указаны и `nodeSelector`, и `nodeAffinity`, Pod будет запланирован на узел только в том случае, если *оба* этих параметра удовлетворены. Если указать несколько условий `nodeSelectorTerms`, привязанных к типам `nodeAffinity`, то Pod может быть запланирован на узел, если удовлетворяется одно из указанных условий `nodeSelectorTerms`. -Если задать несколько выражений `matchExpressions` для одного условия `nodeSelectorTerms`, Pod будет запланирован на узел только если удовлетворены все выражения `matchExpressions`. {{}} +Если задать несколько выражений `matchExpressions` для одного условия `nodeSelectorTerms`, Pod будет запланирован на узел, только если удовлетворены все выражения `matchExpressions`. {{}} {{}} Дополнительную информацию см. в разделе [Размещаем 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`, результат применения этих правил может быть для них неожиданным. Используйте лейблы узлов, которые однозначно соотносятся с именем профиля планировщика.