From a642258e250f371ff6fc3b4b95366e01b99dc91b Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Wed, 31 Jan 2024 18:57:58 +0300 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Dmitry Shurupov --- .../scheduling-eviction/assign-pod-node.md | 28 +++++++++++-------- .../docs/reference/issues-security/issues.md | 4 +-- .../issues-security/official-cve-feed.md | 2 +- .../reference/issues-security/security.md | 12 ++++---- 4 files changed, 25 insertions(+), 21 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 21c9ae8babcaf..ab5bd7a41f360 100644 --- a/content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -8,7 +8,7 @@ weight: 20 Можно настроить {{< 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/) на всех узлах кластера. {{}} Значения этих лейблов зависят от облачного провайдера, поэтому нельзя точно на них полагаться. @@ -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/), чтобы "отвадить" поды от определенных узлов. {{}} Когда указаны и `nodeSelector`, и `nodeAffinity`, под будет запланирован на узел только в том случае, если *оба* этих параметра удовлетворены. -Если указать несколько условий `nodeSelectorTerms`, привязанных к типам `nodeAffinity`, то под может быть запланирован на узел, если удовлетворяется одно из указанных условий `nodeSelectorTerms`. +Если указать несколько условий `nodeSelectorTerms`, привязанных к типам `nodeAffinity`, то под может быть запланирован на узел, если удовлетворяется одно из указанных условий `nodeSelectorTerms`. К условиям применяется логическое ИЛИ. -Если задать несколько выражений `matchExpressions` для одного условия `nodeSelectorTerms`, под будет запланирован на узел, только если удовлетворены все выражения `matchExpressions`. {{}} +Если задать несколько выражений `matchExpressions` для одного условия `nodeSelectorTerms`, под будет запланирован на узел, только если удовлетворены все выражения `matchExpressions`. К условиям применяется логическое И. {{}} Дополнительную информацию см. в разделе [Размещаем 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` каждого узла и добавляет его к другим оценкам для этого узла. Под планируется на узел с наивысшей итоговой оценкой. {{}} Чтобы 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 diff --git a/content/ru/docs/reference/issues-security/issues.md b/content/ru/docs/reference/issues-security/issues.md index 4be05eb955264..2724d349f8e8e 100644 --- a/content/ru/docs/reference/issues-security/issues.md +++ b/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) diff --git a/content/ru/docs/reference/issues-security/official-cve-feed.md b/content/ru/docs/reference/issues-security/official-cve-feed.md index 5b847372f9e3d..2c70731d76047 100644 --- a/content/ru/docs/reference/issues-security/official-cve-feed.md +++ b/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), включающий анонсированные проблемы в области безопасности. Доступ к нему можно получить, выполнив следующую команду: diff --git a/content/ru/docs/reference/issues-security/security.md b/content/ru/docs/reference/issues-security/security.md index 3e2be1237d0dd..8db0974d97014 100644 --- a/content/ru/docs/reference/issues-security/security.md +++ b/content/ru/docs/reference/issues-security/security.md @@ -23,17 +23,17 @@ weight: 20 Мы искренне признательны исследователям в области безопасности и пользователям, которые передают информацию об уязвимостях в Open Source-сообщество Kubernetes. Все отчеты тщательно изучаются группой добровольцев сообщества. -Чтобы создать отчет, отправьте свою уязвимость в [программу поиска багов Kubernetes](https://hackerone.com/kubernetes). Это позволит отследить и обработать уязвимость в стандартные сроки. +Чтобы создать отчет, отправьте свою уязвимость в [Bug Bounty-программу Kubernetes](https://hackerone.com/kubernetes). Это позволит отследить и обработать уязвимость в стандартные сроки. Также можно оправить [стандартное письмо об ошибках Kubernetes](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml) с описанием проблемы и ее подробностями в закрытый список [security@kubernetes.io](mailto:security@kubernetes.io). -Письмо можно зашифровать, используя GPG ключи [членов Комитета по безопасности](https://git.k8s.io/security/README.md#product-security-committee-psc). Шифрование с использованием GPG НЕ является обязательным. +Письмо можно зашифровать, используя GPG-ключи [членов Комитета по безопасности](https://git.k8s.io/security/README.md#product-security-committee-psc). Шифрование с использованием GPG НЕ является обязательным. ### Когда следует сообщать об уязвимости -- Обнаружена уязвимость, способная повлиять на безопасность Kubernetes. -- Вы не уверены, как именно уязвимость повлияет на Kubernetes, но у вас есть серьезные основания полагать, что она может ударить по безопасности оркестратора. -- Обнаружена уязвимость в проекте, от которого зависит работа Kubernetes. +- Вы думаете, что обнаружили уязвимость в безопасности Kubernetes. +- Вы не уверены, как именно уязвимость повлияет на Kubernetes. +- Вы думаете, что обнаружили уязвимость в другом проекте, от которого зависит работа Kubernetes. - Если у проекта имеется собственный регламент регистрации и раскрытия информации об уязвимостях, пожалуйста, следуйте ему и пишите сразу в проект. ### Когда НЕ следует сообщать об уязвимости @@ -44,7 +44,7 @@ weight: 20 ## Реагирование на уязвимости в области безопасности -Каждый отчет об уязвимости анализируется членами Комитета по реагированию на угрозы безопасности в течение 3 рабочих дней (автор получает подтверждение). После этого [запускается соответствующая процедура](https://git.k8s.io/security/security-release-process.md#disclosures). +Каждый отчет об уязвимости подтверждается и анализируется членами Комитета по реагированию на угрозы безопасности в течение 3 рабочих дней. После этого [запускается соответствующая процедура](https://git.k8s.io/security/security-release-process.md#disclosures). Любая информация об уязвимостях, переданная Комитету по реагированию на угрозы безопасности, остается внутри проекта Kubernetes и не передается в другие проекты, если только это не требуется для устранения проблемы.