From 354d577a0adbdd3b79cbddd499092d0acf559721 Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Sun, 29 Jan 2023 23:31:43 +0300 Subject: [PATCH] Create assign-pod-node.md Apply suggestions from code review Co-authored-by: Dmitry Shurupov Update assign-pod-node.md Copy /docs/reference/issues-security/* from EN Update content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md Add examples/pods/*.yaml files Translate _index.md Translate issues.md Update issues.md Translate official-cve-feed.md Translate official-cve-feed.md Translate security.md Update _index.md Update issues.md Apply suggestions from code review Co-authored-by: Dmitry Shurupov --- .../scheduling-eviction/assign-pod-node.md | 349 ++++++++++++++++++ .../docs/reference/issues-security/_index.md | 4 + .../docs/reference/issues-security/issues.md | 15 + .../issues-security/official-cve-feed.md | 39 ++ .../reference/issues-security/security.md | 55 +++ content/ru/examples/pods/commands.yaml | 13 + content/ru/examples/pods/init-containers.yaml | 30 ++ .../ru/examples/pods/lifecycle-events.yaml | 16 + .../pods/pod-configmap-env-var-valueFrom.yaml | 21 ++ .../examples/pods/pod-configmap-envFrom.yaml | 13 + .../pod-configmap-volume-specific-key.yaml | 20 + .../examples/pods/pod-configmap-volume.yaml | 19 + .../pod-multiple-configmap-env-variable.yaml | 21 ++ .../pods/pod-nginx-preferred-affinity.yaml | 19 + .../pods/pod-nginx-required-affinity.yaml | 18 + .../pods/pod-nginx-specific-node.yaml | 10 + content/ru/examples/pods/pod-nginx.yaml | 13 + .../pods/pod-projected-svc-token.yaml | 20 + content/ru/examples/pods/pod-rs.yaml | 23 ++ .../pod-single-configmap-env-variable.yaml | 19 + .../pods/pod-with-affinity-anti-affinity.yaml | 32 ++ .../examples/pods/pod-with-node-affinity.yaml | 26 ++ .../examples/pods/pod-with-pod-affinity.yaml | 29 ++ .../pods/pod-with-scheduling-gates.yaml | 11 + .../ru/examples/pods/pod-with-toleration.yaml | 15 + .../pods/pod-without-scheduling-gates.yaml | 8 + content/ru/examples/pods/private-reg-pod.yaml | 11 + .../pods/share-process-namespace.yaml | 17 + content/ru/examples/pods/simple-pod.yaml | 10 + .../ru/examples/pods/two-container-pod.yaml | 27 ++ .../pods/user-namespaces-stateless.yaml | 10 + 31 files changed, 933 insertions(+) create mode 100644 content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md create mode 100644 content/ru/docs/reference/issues-security/_index.md create mode 100644 content/ru/docs/reference/issues-security/issues.md create mode 100644 content/ru/docs/reference/issues-security/official-cve-feed.md create mode 100644 content/ru/docs/reference/issues-security/security.md create mode 100644 content/ru/examples/pods/commands.yaml create mode 100644 content/ru/examples/pods/init-containers.yaml create mode 100644 content/ru/examples/pods/lifecycle-events.yaml create mode 100644 content/ru/examples/pods/pod-configmap-env-var-valueFrom.yaml create mode 100644 content/ru/examples/pods/pod-configmap-envFrom.yaml create mode 100644 content/ru/examples/pods/pod-configmap-volume-specific-key.yaml create mode 100644 content/ru/examples/pods/pod-configmap-volume.yaml create mode 100644 content/ru/examples/pods/pod-multiple-configmap-env-variable.yaml create mode 100644 content/ru/examples/pods/pod-nginx-preferred-affinity.yaml create mode 100644 content/ru/examples/pods/pod-nginx-required-affinity.yaml create mode 100644 content/ru/examples/pods/pod-nginx-specific-node.yaml create mode 100644 content/ru/examples/pods/pod-nginx.yaml create mode 100644 content/ru/examples/pods/pod-projected-svc-token.yaml create mode 100644 content/ru/examples/pods/pod-rs.yaml create mode 100644 content/ru/examples/pods/pod-single-configmap-env-variable.yaml create mode 100644 content/ru/examples/pods/pod-with-affinity-anti-affinity.yaml create mode 100644 content/ru/examples/pods/pod-with-node-affinity.yaml create mode 100644 content/ru/examples/pods/pod-with-pod-affinity.yaml create mode 100644 content/ru/examples/pods/pod-with-scheduling-gates.yaml create mode 100644 content/ru/examples/pods/pod-with-toleration.yaml create mode 100644 content/ru/examples/pods/pod-without-scheduling-gates.yaml create mode 100644 content/ru/examples/pods/private-reg-pod.yaml create mode 100644 content/ru/examples/pods/share-process-namespace.yaml create mode 100644 content/ru/examples/pods/simple-pod.yaml create mode 100644 content/ru/examples/pods/two-container-pod.yaml create mode 100644 content/ru/examples/pods/user-namespaces-stateless.yaml diff --git a/content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md new file mode 100644 index 0000000000000..21c9ae8babcaf --- /dev/null +++ b/content/ru/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -0,0 +1,349 @@ +--- +title: Распределение подов по узлам +content_type: concept +weight: 20 +--- + + + + +Можно настроить {{< glossary_tooltip text="под" term_id="pod" >}} так, чтобы тот мог запускаться _только_ на определенном(-ых) {{< glossary_tooltip text="узле(-ах)" term_id="node" >}} или _предпочитал_ определенную группу узлов. +Сделать это можно несколькими способами, при этом все рекомендуемые подходы используют [селекторы лейблов](/docs/concepts/overview/working-with-objects/labels/) для выбора. +Зачастую нужды в подобных ограничениях нет; {{< glossary_tooltip text="планировщик" term_id="kube-scheduler" >}} автоматически размещает поды оптимальным образом (например, распределяет их по узлам, чтобы они не оказались все на одном узле и не привели к дефициту ресурсов). +Однако в некоторых обстоятельствах возможность контролировать, куда именно попадет под, может пригодиться. Например, она поможет запланировать под на узел с быстрым SSD-хранилищем или разместить два активно взаимодействующих друг с другом пода в одной зоне доступности. + + + +Для планирования подов на определенные узлы можно использовать любой из методов: + + * Поле [nodeSelector](#nodeselector) и [лейблы узлов](#built-in-node-labels); + * Правила [совместного/раздельного существования (affinity и anti-affinity)](#affinity-and-anti-affinity); + * Поле [nodeName](#nodename); + * [Ограничения на топологию распределения подов](#pod-topology-spread-constraints). + +## Лейблы узлов {#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.io/hostname` может совпадать с именем узла, в других — отличаться. +{{}} + +### Изоляция узла/ограничение его использования + +Лейблы узлов позволяют планировать поды на определенные узлы или группы узлов. С их помощью можно планировать поды на узлы с определенными требованиями к изоляции, безопасности или соответствию нормативным актам. + +При использовании лейблов для изоляции узлов следует выбирать ключи лейблов, которые {{}} не может изменить. В этом случае взломанный узел не сможет навесить на себя эти лейблы в надежде заполучить рабочие нагрузки. + +[Admission-плагин NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) не позволяет kubelet'у устанавливать или изменять лейблы с префиксом `node-restriction.kubernetes.io/`. + +Чтобы использовать этот префикс для изоляции узла: + +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`. + +## nodeSelector + +`nodeSelector` — простейшая рекомендуемая форма настроек выбора узлов. +Можно добавить поле `nodeSelector` в спецификацию пода и перечислить в нем [лейблы узлов](#built-in-node-labels), подходящих для развертывания пода. В этом случае Kubernetes будет размещать под только на узлах с указанными лейблами. + +Дополнительную информацию см. в разделе [Размещение подов на узлах](/docs/tasks/configure-pod-container/assign-pods-nodes). + +## Правила совместного/раздельного существования (affinity и anti-affinity) {#affinity-and-anti-affinity} + +`nodeSelector` — самый простой способ развернуть поды на узлах с определенными лейблами. Правила совместного/раздельного существования расширяют типы ограничений, которые можно накладывать. Вот некоторые из их преимуществ: + +* Язык правил affinity/anti-affinity более выразителен. `nodeSelector` выбирает узлы только со всеми указанными лейблами. Правила affinity/anti-affinity расширяют логику выбора и делают ее более гибкой. +* Правило может быть *мягким* (soft) или *предпочтительным* (preferred). В этом случае планировщик все равно запланирует под, даже если подходящего узла для него не найдется. +* При планировании пода планировщик может учитывать лейблы других подов, запущенных на узле (или в иной топологической области), а не только лейблы самого узла. Это позволяет формулировать правила, определяющие сосуществование подов на узле. + +Правила совместного существования (affinity) бывают двух типов: + +* *Правила для узлов* (node affinity) работают подобно полю `nodeSelector`, но более выразительны. Кроме того, можно задавать мягкие правила. +* *Правила для подов* позволяют при планировании учитывать наличие других подов (соответственно, и их лейблы) на узлах. + +### Правила совместного существования для узлов (node affinity) + +Правила совместного существования для узлов концептуально похожи на `nodeSelector`. С помощью лейблов они позволяют ограничивать список узлов, на которые может быть запланирован под. Существует два типа таких правил: + + * `requiredDuringSchedulingIgnoredDuringExecution`: Планировщик не может запланировать под, если правило не выполнено. Работает как `nodeSelector`, но с более выразительным синтаксисом. + * `preferredDuringSchedulingIgnoredDuringExecution`: Планировщик пытается найти узел, который соответствует правилу. Если подходящий узел не удается найти, планировщик все равно планирует под. + +{{}} +В типах выше `IgnoredDuringExecution` означает, что под продолжит свою работу, если лейблы узлов изменятся после того, как Kubernetes запланировал его. +{{}} + +Задавать правила совместного существования для узлов можно с помощью поля `.spec.affinity.nodeAffinity` в спецификации пода. + +В качестве примера рассмотрим следующую спецификацию пода: + +{{< codenew file="pods/pod-with-node-affinity.yaml" >}} + +В этом примере применяются следующие правила: + + * У узла *должен* быть лейбл с ключом `topology.kubernetes.io/zone`, и значение этого лейбла *должно* быть либо `antarctica-east1`, либо `antarctica-west1`. + * *Предпочтительно*, чтобы у узла был лейбл с ключом `another-node-label-key` и значением `another-node-label-value`. + +Можно использовать поле `operator` для указания логического оператора, который Kubernetes будет применять при интерпретации правил. Доступны `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt` и `Lt`. + +`NotIn` и `DoesNotExist` позволяют задавать правила раздельного существования (anti-affinity) для узла. +Кроме того, можно использовать [taint'ы узлов](/docs/concepts/scheduling-eviction/taint-and-toleration/), чтобы "отвадить" поды от определенных узлов. + +{{}} +Когда указаны и `nodeSelector`, и `nodeAffinity`, под будет запланирован на узел только в том случае, если *оба* этих параметра удовлетворены. + +Если указать несколько условий `nodeSelectorTerms`, привязанных к типам `nodeAffinity`, то под может быть запланирован на узел, если удовлетворяется одно из указанных условий `nodeSelectorTerms`. + +Если задать несколько выражений `matchExpressions` для одного условия `nodeSelectorTerms`, под будет запланирован на узел, только если удовлетворены все выражения `matchExpressions`. {{}} +{{}} + +Дополнительную информацию см. в разделе [Размещаем Pod'ы на узлы с помощью Node Affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/). + +#### Вес правил совместного существования + +Для каждого правила типа `preferredDuringSchedulingIgnoredDuringExecution` можно указать вес `weight` в диапазоне от 1 до 100. Найдя несколько узлов, удовлетворяющих всем остальным требованиям для планирования пода, планировщик перебирает предпочтительные правила, которым удовлетворяет узел, и прибавляет их вес для этого выражения к сумме. + +Итоговая сумма добавляется к оценке, полученной при анализе других параметров, влияющих на приоритет узла. Принимая решение о размещении пода, планировщик отдает предпочтение узлам с наибольшей суммарной оценкой. + +В качестве примера рассмотрим следующую спецификацию пода: + +{{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}} + +Если правилу `preferredDuringSchedulingIgnoredDuringExecution` соответствуют два узла (один — с лейблом `label-1:key-1`, другой — с `label-2:key-2`), планировщик считает вес `weight` каждого узла и добавляет его к другим оценкам для этого узла. под планируется на узел с наивысшей итоговой оценкой. + +{{}} +Чтобы Kubernetes смог запланировать поды в этом примере, необходимо, чтобы существовали узлы с лейблом `kubernetes.io/os=linux`. +{{}} + +#### Правила совместного существования и профили планирования + +{{< feature-state for_k8s_version="v1.20" state="beta" >}} + +При настройке нескольких [профилей планирования](/docs/reference/scheduling/config/#multiple-profiles) можно связать профиль с правилами совместного существования для узлов (это удобно, когда профиль применяется к определенному набору узлов). Для этого необходимо добавить `addedAffinity` в поле `args` [плагина `NodeAffinity`](/docs/reference/scheduling/config/#scheduling-plugins) в [конфигурации планировщика](/docs/reference/scheduling/config/). Например: + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration + +profiles: + - schedulerName: default-scheduler + - schedulerName: foo-scheduler + pluginConfig: + - name: NodeAffinity + args: + addedAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: scheduler-profile + operator: In + values: + - foo +``` + +Правило `addedAffinity` применяется ко всем подам с полем `.spec.schedulerName`, имеющем значение `foo-scheduler`, в дополнение к NodeAffinity, заданному в PodSpec. Таким образом, подходящие для пода узлы должны удовлетворять параметрам `addedAffinity` и правилам `.spec.NodeAffinity` пода. + +Поскольку конечные пользователи не видят `addedAffinity`, результат применения этих правил может быть для них неожиданным. Используйте лейблы узлов, которые однозначно соотносятся с именем профиля планировщика. + +{{< note >}} +Контроллер DaemonSet, [создающий поды для DaemonSet'ов](/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler), не поддерживает профили планирования. Контроллер DaemonSet создает поды, а штатный планировщик Kubernetes, размещая их, следит за соблюдением правил `nodeAffinity`. +{{< /note >}} + +### Правила совместного/раздельного существования подов + +Правила совместного/раздельного существования подов позволяют выбирать узлы для планирования в зависимости от лейблов **подов**, которые уже на этих узлах работают (вместо лейблов самих узлов). + +Алгоритм работы правил совместного/раздельного существования подов можно описать так: "данный под должен (или не должен в случае раздельного (anti-affinity) существования) размещаться на X, если на нем уже работает один или несколько подов, удовлетворяющих правилу Y", где X — топологический домен, например, узел, стойка, зона/регион облачного провайдера и т.п., а Y — правило, которое Kubernetes пытается удовлетворить. + +Для задания правил Y используются [селекторы лейблов](/docs/concepts/overview/working-with-objects/labels/#label-selectors) с необязательным связанным списком пространств имен. Для подов в Kubernetes указываются пространства имен, соответственно, их лейблы также оказываются неявно связаны с этими же пространствами имен. Любые селекторы лейблов для лейблов подов должны содержать пространства имен, в которых Kubernetes должен искать эти лейблы. + +Топологический домен X задается с помощью `topologyKey` — ключа для лейбла узла, который система использует для обозначения домена. Примеры см. в разделе [Типичные лейблы, аннотации и taint'ы](/docs/reference/labels-annotations-taints/). + +{{< note >}} +Обработка правил совместного/раздельного существования подов требует значительных ресурсов и может значительно замедлить планирование в больших кластерах. Их не рекомендуется использовать в кластерах, число узлов в которых превышает несколько сотен. +{{< /note >}} + +{{< note >}} +Правила раздельного существования для подов требуют согласованности лейблов узлов. Другими словами, у каждого узла в кластере должен быть лейбл, относящий его к определенному ключу `topologyKey`. Отсутствие лейблов `topologyKey` у некоторых или всех узлов в кластере может привести к непредсказуемому поведению. +{{< /note >}} + +#### Типы правил совместного/раздельного существования подов + +По аналогии [c правилами для узлов](#node-affinity) существует два типа правил для подов: + + * `requiredDuringSchedulingIgnoredDuringExecution` + * `preferredDuringSchedulingIgnoredDuringExecution` + +Например, с помощью правила совместного существования `requiredDuringSchedulingIgnoredDuringExecution` можно указать планировщику размещать поды, относящиеся к разным сервисам, в одной зоне облачного провайдера, поскольку они активно обмениваются данными друг с другом. + +Аналогичным образом можно использовать правило раздельного существования `preferredDuringSchedulingIgnoredDuringExecution` для распределения подов по нескольким зонам облачного провайдера. + +Для задания правил совместного существования предназначено поле `affinity.podAffinity` в спецификации пода. + +Для задания правил раздельного существования предназначено поле `affinity.podAntiAffinity` в спецификации пода. + +#### Пример правил совместного/раздельного существования для пода {#an-example-of-a-pod-that-uses-pod-affinity} + +Рассмотрим следующую спецификацию пода: + +{{< codenew file="pods/pod-with-pod-affinity.yaml" >}} + +В примере задается одно правило совместного существования подов, и одно — раздельного. Для совместного правила используется жесткий тип `requiredDuringSchedulingIgnoredDuringExecution`, для раздельного — мягкий `preferredDuringSchedulingIgnoredDuringExecution`. + +Правило совместного существования гласит, что планировщик может разместить под на узел, только если тот находится в зоне с одним или более подами с лейблом `security=S1`. Точнее, планировщик должен разместить под на узле с лейблом `topology.kubernetes.io/zone=V`, если в этой зоне есть хотя бы один узел, на котором работают один или несколько подов с лейблом `security=S1`. + +Правило раздельного существования гласит, что планировщик при возможности не должен размещать под на узел, если тот находится в зоне с одним или более подами с лейблом `security=S2`. Точнее, планировщик при возможности не должен размещать под на узлы с лейблом `topology.kubernetes.io/zone=R`, если в этой зоне есть другие узлы, на которых работают поды с лейблом `security=S2`. + +Больше примеров правил совместного/раздельного существования для подов можно найти в [рабочей документации](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md). + +Поле `operator` пода поддерживает значения `In`, `NotIn`, `Exists` и `DoesNotExist` при задании правил совместного/раздельного существования. + +В принципе, `topologyKey` может быть любым разрешенным лейблом-ключом со следующими исключениями по соображениям производительности и безопасности: + +* При задании правил совместного/раздельного существования для подов пустое поле `topologyKey` не допускается как для `requiredDuringSchedulingIgnoredDuringExecution`, так и для `preferredDuringSchedulingIgnoredDuringExecution`. +* Для правил раздельного существования типа `requiredDuringSchedulingIgnoredDuringExecution` admission-контроллер разрешает использовать только `kubernetes.io/hostname` в качестве `topologyKey`. Для работы с кастомными топологиями admission-контроллер можно дополнить или совсем отключить его. + +В дополнение к `labelSelector` и `topologyKey` можно опционально указать список пространств имен, которые должен выбирать `labelSelector`, с помощью поля `namespaces` на том же уровне, что `labelSelector` и `topologyKey`. Если поле `namespaces` опущено или пусто, по умолчанию выбирается пространство имен пода, в котором задаются правила совместного/раздельного существования. + +#### Селектор пространств имен +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Подходящие пространства имен также можно выбрать с помощью `namespaceSelector`, который попытается найти лейбл в наборе пространств имен. +Условия совместного существования применяются к пространствам имен, выбранным как селектором `namespaceSelector`, так и полем `namespaces`. +Обратите внимание, что пустой селектор `namespaceSelector` ({}) выбирает все пространства имен, в то время как пустой или null-список `namespaces` и null-селектор `namespaceSelector` выбирает пространство имен пода, в котором правило задано. + +#### Другие примеры использования + +Правила совместного/раздельного существования для подов особенно удобны, когда используются совместно с абстракциями более высокого уровня, такими как ReplicaSet, StatefulSet, Deployment и т.д. Эти правила позволяют настроить размещение рабочих нагрузок с учетом имеющейся топологии; например, пара связанных подов будет размещена на одном узле. + +Представьте кластер, состоящий из трех узлов. Он используется для запуска веб-приложения и как in-memory-кэш (например, Redis). Предположим, что задержка между веб-приложением и кэшем должна быть минимальной. Правила совместного/раздельного существования для подов позволяют настроить планировщик так, чтобы тот размещал веб-серверы как можно ближе к кэшу. + +В приведенном ниже примере конфигурации Deployment'а Redis'а реплики получают лейбл `app=store`. Правило `podAntiAffinity` запрещает планировщику планировать несколько реплик с лейблом `app=store` на один узел. Таким образом, каждая кэш-реплика работает на отдельном узле. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: redis-cache +spec: + selector: + matchLabels: + app: store + replicas: 3 + template: + metadata: + labels: + app: store + spec: + affinity: + podAntiAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: app + operator: In + values: + - store + topologyKey: "kubernetes.io/hostname" + containers: + - name: redis-server + image: redis:3.2-alpine +``` + +Конфигурация Deployment'а, приведенная ниже, создает три реплики веб-сервера с лейблом `app=web-store`. +Правило совместного существования предписывает планировщику размещать каждую реплику на узле, на котором уже имеется под с лейблом `app=store`. В то же время правило раздельного существования запрещает планировщику размещать несколько серверов с лейблом `app=web-store` на одном узле. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: web-server +spec: + selector: + matchLabels: + app: web-store + replicas: 3 + template: + metadata: + labels: + app: web-store + spec: + affinity: + podAntiAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: app + operator: In + values: + - web-store + topologyKey: "kubernetes.io/hostname" + podAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: app + operator: In + values: + - store + topologyKey: "kubernetes.io/hostname" + containers: + - name: web-app + image: nginx:1.16-alpine +``` + +Развертывание ресурсов в соответствии с приведенными выше конфигурациями приведет к созданию кластера, в котором на каждом узле будет по одному веб-серверу и одной реплике Redis (всего три отдельных узла): + +| узел 1 | узел 2 | узел 3 | +|:--------------------:|:-------------------:|:------------------:| +| *webserver-1* | *webserver-2* | *webserver-3* | +| *cache-1* | *cache-2* | *cache-3* | + +В итоге к каждому инстансу Redis'а, скорее всего, будет обращаться клиент, который работает с ним на том же узле. Подобный подход позволит минимизировать как перекос (дисбаланса нагрузки), так и задержки. + +Правила совместного/раздельного существования для подов можно использовать и в других случаях. + +См., например, [руководство по ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure). В нем с помощью правил раздельного существования StatefulSet настраивается так, чтобы обеспечить высокую доступность (используется подход, аналогичный тому, что применен выше). + +## nodeName + +Поле `nodeName` в спецификации пода — более непосредственный способ выбора узлов по сравнению с правилами совместного существования или селектором `nodeSelector`. Если поле `nodeName` не пустое, планировщик игнорирует под, а kubelet на узле с соответствующим именем пытается разместить под на этом узле. Приоритет поля `nodeName` выше, чем селектора `nodeSelector` или правил совместного/раздельного существования. + +Однако у `nodeName` имеются и некоторые недостатки: + +- Если узел с заданным именем не существует, под не будет запущен. Кроме того, в некоторых случаях он может быть автоматически удален. +- Если на узле с заданным именем недостаточно ресурсов для работы пода, последний будет остановлен; соответствующая причина (например, OutOfmemory или OutOfcpu) будет указана. +- В облачных окружениях имена узлов не всегда предсказуемы или стабильны. + +Ниже приведен пример спецификации пода с полем `nodeName`: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - name: nginx + image: nginx + nodeName: kube-01 +``` + +Такой под будет работать только на узле с именем `kube-01`. + +## Ограничения на топологию распределения подов + +С помощью _ограничений на топологию распределения_ (_topology spread constraints_) можно настроить размещение {{< glossary_tooltip text="подов" term_id="Pod" >}} в кластере по failure-доменам, таким как регионы, зоны, узлы, или любым другим заданным топологическим конфигурациям. Это позволяет повысить производительность, ожидаемую доступность или эффективность использования ресурсов. + +Дополнительные сведения о принципах их работы читайте в разделе [Ограничения на топологию распределения подов](/docs/concepts/scheduling-eviction/topology-spread-constraints/). + +## {{% heading "whatsnext" %}} + +* Дополнительная информация о [taint'ах и toleration'ах](/docs/concepts/scheduling-eviction/taint-and-toleration/). +* Рабочая документация по правилам [совместного существования для узлов](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md) и по правилам [совместного/раздельного существования для подов](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md). +* [Информация о том](/docs/tasks/administer-cluster/topology-manager/), как менеджер топологии участвует в принятии решений о распределении ресурсов на уровне узлов. +* Подробнее об использовании [селектора nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/). +* Подробнее об использовании правил [совместного/раздельного существования](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/). + diff --git a/content/ru/docs/reference/issues-security/_index.md b/content/ru/docs/reference/issues-security/_index.md new file mode 100644 index 0000000000000..669b610f969a9 --- /dev/null +++ b/content/ru/docs/reference/issues-security/_index.md @@ -0,0 +1,4 @@ +--- +title: Проблемы и безопасность Kubernetes +weight: 70 +--- diff --git a/content/ru/docs/reference/issues-security/issues.md b/content/ru/docs/reference/issues-security/issues.md new file mode 100644 index 0000000000000..4be05eb955264 --- /dev/null +++ b/content/ru/docs/reference/issues-security/issues.md @@ -0,0 +1,15 @@ +--- +title: Трекер задач (Issues) Kubernetes +weight: 10 +aliases: [/cve/,/cves/] +--- + +Чтобы сообщить о проблеме в области безопасности, воспользуйтесь процедурой [раскрытия информации о безопасности Kubernetes](/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/) +(уязвимостей в области безопасности), которые были обнародованы [Комитетом по реагированию на угрозы в области безопасности 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) + +Связанные с безопасностью анонсы публикуются в рассылке [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce). diff --git a/content/ru/docs/reference/issues-security/official-cve-feed.md b/content/ru/docs/reference/issues-security/official-cve-feed.md new file mode 100644 index 0000000000000..5b847372f9e3d --- /dev/null +++ b/content/ru/docs/reference/issues-security/official-cve-feed.md @@ -0,0 +1,39 @@ +--- +title: Официальный CVE-фид +weight: 25 +outputs: + - json + - html +layout: cve-feed +--- + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +Поддерживаемый сообществом список официальных CVE, анонсированных +Комитетом по реагированию на проблемы безопасности Kubernetes. Подробности см. на странице +[Общие сведения о безопасности Kubernetes и раскрытии информации](/docs/reference/issues-security/security/). + +Проект Kubernetes публикует доступный для автоматического считывания [JSON-фид](/docs/reference/issues-security/official-cve-feed/index.json), включающий анонсированные проблемы в области безопасности. Доступ к нему можно получить, выполнив следующую команду: + +{{< comment >}} +`replace` используется для обхода известной проблемы с рендерингом ">" +: https://github.com/gohugoio/hugo/issues/7229 в шаблоне макетов JSON +`layouts/_default/cve-feed.json` +{{< /comment >}} + +```shell +curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json +``` + +{{< cve-feed >}} + + + +Список автоматически обновляется с заметной, но небольшой задержкой (от нескольких минут до нескольких часов) +с момента анонса CVE до момента его появления в этом фиде. +В качестве источника используется набор GitHub Issues, отфильтрованный по контролируемому и +ограниченному лейблу `official-cve-feed`. Исходные данные хранятся в бакете Google Cloud, +право на запись в который есть только у небольшого числа доверенных представителей сообщества. diff --git a/content/ru/docs/reference/issues-security/security.md b/content/ru/docs/reference/issues-security/security.md new file mode 100644 index 0000000000000..3e2be1237d0dd --- /dev/null +++ b/content/ru/docs/reference/issues-security/security.md @@ -0,0 +1,55 @@ +--- +title: Общие сведения о безопасности Kubernetes и раскрытии информации +aliases: [/security/] +reviewers: +- eparis +- erictune +- philips +- jessfraz +content_type: concept +weight: 20 +--- + + +На этой странице приводятся общие сведения о безопасности Kubernetes и раскрытии информации, имеющей к ней отношение. + + + +## Анонсы в области безопасности + +Информация о проблемах в области безопасности и ключевых изменениях API доступна в рассылке [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce). + +## Сообщить об уязвимости + +Мы искренне признательны исследователям в области безопасности и пользователям, которые передают информацию об уязвимостях в Open Source-сообщество Kubernetes. Все отчеты тщательно изучаются группой добровольцев сообщества. + +Чтобы создать отчет, отправьте свою уязвимость в [программу поиска багов 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 НЕ является обязательным. + +### Когда следует сообщать об уязвимости + +- Обнаружена уязвимость, способная повлиять на безопасность Kubernetes. +- Вы не уверены, как именно уязвимость повлияет на Kubernetes, но у вас есть серьезные основания полагать, что она может ударить по безопасности оркестратора. +- Обнаружена уязвимость в проекте, от которого зависит работа Kubernetes. + - Если у проекта имеется собственный регламент регистрации и раскрытия информации об уязвимостях, пожалуйста, следуйте ему и пишите сразу в проект. + +### Когда НЕ следует сообщать об уязвимости + +- Вам нужна помощь в настройке компонентов Kubernetes для обеспечения безопасности. +- Вам нужна помощь в применении обновлений, связанных с безопасностью. +- Проблема не связана с безопасностью. + +## Реагирование на уязвимости в области безопасности + +Каждый отчет об уязвимости анализируется членами Комитета по реагированию на угрозы безопасности в течение 3 рабочих дней (автор получает подтверждение). После этого [запускается соответствующая процедура](https://git.k8s.io/security/security-release-process.md#disclosures). + +Любая информация об уязвимостях, переданная Комитету по реагированию на угрозы безопасности, остается внутри проекта Kubernetes и не передается в другие проекты, если только это не требуется для устранения проблемы. + +Автору отчета будет сообщено о результатах триажа и дальнейших шагах по подготовке исправления и планированию релиза. + +## Сроки раскрытия информации + +Дата публичного раскрытия согласовывается Комитетом по реагированию на угрозы безопасности Kubernetes и автором отчета об уязвимости. Мы предпочитаем полностью раскрывать информацию об обнаруженной проблеме сразу после того, как станет понятно, какие шаги необходимо предпринять для устранения ее последствий. Разумно отложить раскрытие информации, если проблема или порядок дальнейших шагов не до конца понятны, решение плохо протестировано или необходима координация действий вендоров. Срок раскрытия информации варьируется от незамедлительного (особенно если она уже широко известна) до нескольких недель. Для "простых" уязвимостей с момента подачи отчета до даты раскрытия обычно проходит около 7 дней. Комитет по реагированию на угрозы безопасности сохраняет последнее слово при определении даты раскрытия информации. diff --git a/content/ru/examples/pods/commands.yaml b/content/ru/examples/pods/commands.yaml new file mode 100644 index 0000000000000..2327d2582745f --- /dev/null +++ b/content/ru/examples/pods/commands.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: command-demo + labels: + purpose: demonstrate-command +spec: + containers: + - name: command-demo-container + image: debian + command: ["printenv"] + args: ["HOSTNAME", "KUBERNETES_PORT"] + restartPolicy: OnFailure diff --git a/content/ru/examples/pods/init-containers.yaml b/content/ru/examples/pods/init-containers.yaml new file mode 100644 index 0000000000000..e55895d673f38 --- /dev/null +++ b/content/ru/examples/pods/init-containers.yaml @@ -0,0 +1,30 @@ +apiVersion: v1 +kind: Pod +metadata: + name: init-demo +spec: + containers: + - name: nginx + image: nginx + ports: + - containerPort: 80 + volumeMounts: + - name: workdir + mountPath: /usr/share/nginx/html + # These containers are run during pod initialization + initContainers: + - name: install + image: busybox:1.28 + command: + - wget + - "-O" + - "/work-dir/index.html" + - http://info.cern.ch + volumeMounts: + - name: workdir + mountPath: "/work-dir" + dnsPolicy: Default + volumes: + - name: workdir + emptyDir: {} + diff --git a/content/ru/examples/pods/lifecycle-events.yaml b/content/ru/examples/pods/lifecycle-events.yaml new file mode 100644 index 0000000000000..4b79d7289c568 --- /dev/null +++ b/content/ru/examples/pods/lifecycle-events.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Pod +metadata: + name: lifecycle-demo +spec: + containers: + - name: lifecycle-demo-container + image: nginx + lifecycle: + postStart: + exec: + command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"] + preStop: + exec: + command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"] + diff --git a/content/ru/examples/pods/pod-configmap-env-var-valueFrom.yaml b/content/ru/examples/pods/pod-configmap-env-var-valueFrom.yaml new file mode 100644 index 0000000000000..fa172abd37135 --- /dev/null +++ b/content/ru/examples/pods/pod-configmap-env-var-valueFrom.yaml @@ -0,0 +1,21 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: registry.k8s.io/busybox + command: [ "/bin/echo", "$(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] + env: + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + name: special-config + key: SPECIAL_LEVEL + - name: SPECIAL_TYPE_KEY + valueFrom: + configMapKeyRef: + name: special-config + key: SPECIAL_TYPE + restartPolicy: Never diff --git a/content/ru/examples/pods/pod-configmap-envFrom.yaml b/content/ru/examples/pods/pod-configmap-envFrom.yaml new file mode 100644 index 0000000000000..e7b5b60841edc --- /dev/null +++ b/content/ru/examples/pods/pod-configmap-envFrom.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: registry.k8s.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - configMapRef: + name: special-config + restartPolicy: Never diff --git a/content/ru/examples/pods/pod-configmap-volume-specific-key.yaml b/content/ru/examples/pods/pod-configmap-volume-specific-key.yaml new file mode 100644 index 0000000000000..ec7a8fb541cf0 --- /dev/null +++ b/content/ru/examples/pods/pod-configmap-volume-specific-key.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: registry.k8s.io/busybox + command: [ "/bin/sh","-c","cat /etc/config/keys" ] + volumeMounts: + - name: config-volume + mountPath: /etc/config + volumes: + - name: config-volume + configMap: + name: special-config + items: + - key: SPECIAL_LEVEL + path: keys + restartPolicy: Never diff --git a/content/ru/examples/pods/pod-configmap-volume.yaml b/content/ru/examples/pods/pod-configmap-volume.yaml new file mode 100644 index 0000000000000..4926a7e6ccd88 --- /dev/null +++ b/content/ru/examples/pods/pod-configmap-volume.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: registry.k8s.io/busybox + command: [ "/bin/sh", "-c", "ls /etc/config/" ] + volumeMounts: + - name: config-volume + mountPath: /etc/config + volumes: + - name: config-volume + configMap: + # Provide the name of the ConfigMap containing the files you want + # to add to the container + name: special-config + restartPolicy: Never diff --git a/content/ru/examples/pods/pod-multiple-configmap-env-variable.yaml b/content/ru/examples/pods/pod-multiple-configmap-env-variable.yaml new file mode 100644 index 0000000000000..c7b2b7abb8217 --- /dev/null +++ b/content/ru/examples/pods/pod-multiple-configmap-env-variable.yaml @@ -0,0 +1,21 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: registry.k8s.io/busybox + command: [ "/bin/sh", "-c", "env" ] + env: + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + name: special-config + key: special.how + - name: LOG_LEVEL + valueFrom: + configMapKeyRef: + name: env-config + key: log_level + restartPolicy: Never diff --git a/content/ru/examples/pods/pod-nginx-preferred-affinity.yaml b/content/ru/examples/pods/pod-nginx-preferred-affinity.yaml new file mode 100644 index 0000000000000..183ba9f014225 --- /dev/null +++ b/content/ru/examples/pods/pod-nginx-preferred-affinity.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + affinity: + nodeAffinity: + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 + preference: + matchExpressions: + - key: disktype + operator: In + values: + - ssd + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent diff --git a/content/ru/examples/pods/pod-nginx-required-affinity.yaml b/content/ru/examples/pods/pod-nginx-required-affinity.yaml new file mode 100644 index 0000000000000..a3805eaa8d9c9 --- /dev/null +++ b/content/ru/examples/pods/pod-nginx-required-affinity.yaml @@ -0,0 +1,18 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: disktype + operator: In + values: + - ssd + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent diff --git a/content/ru/examples/pods/pod-nginx-specific-node.yaml b/content/ru/examples/pods/pod-nginx-specific-node.yaml new file mode 100644 index 0000000000000..5923400d64534 --- /dev/null +++ b/content/ru/examples/pods/pod-nginx-specific-node.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + nodeName: foo-node # schedule pod to specific node + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent diff --git a/content/ru/examples/pods/pod-nginx.yaml b/content/ru/examples/pods/pod-nginx.yaml new file mode 100644 index 0000000000000..134ddae2aa1c8 --- /dev/null +++ b/content/ru/examples/pods/pod-nginx.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + nodeSelector: + disktype: ssd diff --git a/content/ru/examples/pods/pod-projected-svc-token.yaml b/content/ru/examples/pods/pod-projected-svc-token.yaml new file mode 100644 index 0000000000000..985073c8d39dc --- /dev/null +++ b/content/ru/examples/pods/pod-projected-svc-token.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: vault-token + serviceAccountName: build-robot + volumes: + - name: vault-token + projected: + sources: + - serviceAccountToken: + path: vault-token + expirationSeconds: 7200 + audience: vault diff --git a/content/ru/examples/pods/pod-rs.yaml b/content/ru/examples/pods/pod-rs.yaml new file mode 100644 index 0000000000000..df7b390597c49 --- /dev/null +++ b/content/ru/examples/pods/pod-rs.yaml @@ -0,0 +1,23 @@ +apiVersion: v1 +kind: Pod +metadata: + name: pod1 + labels: + tier: frontend +spec: + containers: + - name: hello1 + image: gcr.io/google-samples/hello-app:2.0 + +--- + +apiVersion: v1 +kind: Pod +metadata: + name: pod2 + labels: + tier: frontend +spec: + containers: + - name: hello2 + image: gcr.io/google-samples/hello-app:1.0 diff --git a/content/ru/examples/pods/pod-single-configmap-env-variable.yaml b/content/ru/examples/pods/pod-single-configmap-env-variable.yaml new file mode 100644 index 0000000000000..f543a0d8b4c64 --- /dev/null +++ b/content/ru/examples/pods/pod-single-configmap-env-variable.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: registry.k8s.io/busybox + command: [ "/bin/sh", "-c", "env" ] + env: + # Define the environment variable + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + # The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY + name: special-config + # Specify the key associated with the value + key: special.how + restartPolicy: Never diff --git a/content/ru/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/ru/examples/pods/pod-with-affinity-anti-affinity.yaml new file mode 100644 index 0000000000000..cb8c5650b0841 --- /dev/null +++ b/content/ru/examples/pods/pod-with-affinity-anti-affinity.yaml @@ -0,0 +1,32 @@ +apiVersion: v1 +kind: Pod +metadata: + name: with-affinity-anti-affinity +spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/os + operator: In + values: + - linux + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 + preference: + matchExpressions: + - key: label-1 + operator: In + values: + - key-1 + - weight: 50 + preference: + matchExpressions: + - key: label-2 + operator: In + values: + - key-2 + containers: + - name: with-node-affinity + image: registry.k8s.io/pause:2.0 diff --git a/content/ru/examples/pods/pod-with-node-affinity.yaml b/content/ru/examples/pods/pod-with-node-affinity.yaml new file mode 100644 index 0000000000000..5fedc554bfdd4 --- /dev/null +++ b/content/ru/examples/pods/pod-with-node-affinity.yaml @@ -0,0 +1,26 @@ +apiVersion: v1 +kind: Pod +metadata: + name: with-node-affinity +spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: topology.kubernetes.io/zone + operator: In + values: + - antarctica-east1 + - antarctica-west1 + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 + preference: + matchExpressions: + - key: another-node-label-key + operator: In + values: + - another-node-label-value + containers: + - name: with-node-affinity + image: registry.k8s.io/pause:2.0 \ No newline at end of file diff --git a/content/ru/examples/pods/pod-with-pod-affinity.yaml b/content/ru/examples/pods/pod-with-pod-affinity.yaml new file mode 100644 index 0000000000000..1a4fd74fd7aa9 --- /dev/null +++ b/content/ru/examples/pods/pod-with-pod-affinity.yaml @@ -0,0 +1,29 @@ +apiVersion: v1 +kind: Pod +metadata: + name: with-pod-affinity +spec: + affinity: + podAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: security + operator: In + values: + - S1 + topologyKey: topology.kubernetes.io/zone + podAntiAffinity: + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 100 + podAffinityTerm: + labelSelector: + matchExpressions: + - key: security + operator: In + values: + - S2 + topologyKey: topology.kubernetes.io/zone + containers: + - name: with-pod-affinity + image: registry.k8s.io/pause:2.0 diff --git a/content/ru/examples/pods/pod-with-scheduling-gates.yaml b/content/ru/examples/pods/pod-with-scheduling-gates.yaml new file mode 100644 index 0000000000000..de761d969460d --- /dev/null +++ b/content/ru/examples/pods/pod-with-scheduling-gates.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: test-pod +spec: + schedulingGates: + - name: example.com/foo + - name: example.com/bar + containers: + - name: pause + image: registry.k8s.io/pause:3.6 diff --git a/content/ru/examples/pods/pod-with-toleration.yaml b/content/ru/examples/pods/pod-with-toleration.yaml new file mode 100644 index 0000000000000..79f2756a8ce5f --- /dev/null +++ b/content/ru/examples/pods/pod-with-toleration.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + tolerations: + - key: "example-key" + operator: "Exists" + effect: "NoSchedule" diff --git a/content/ru/examples/pods/pod-without-scheduling-gates.yaml b/content/ru/examples/pods/pod-without-scheduling-gates.yaml new file mode 100644 index 0000000000000..5638b6e97af5f --- /dev/null +++ b/content/ru/examples/pods/pod-without-scheduling-gates.yaml @@ -0,0 +1,8 @@ +apiVersion: v1 +kind: Pod +metadata: + name: test-pod +spec: + containers: + - name: pause + image: registry.k8s.io/pause:3.6 diff --git a/content/ru/examples/pods/private-reg-pod.yaml b/content/ru/examples/pods/private-reg-pod.yaml new file mode 100644 index 0000000000000..4029588dd0758 --- /dev/null +++ b/content/ru/examples/pods/private-reg-pod.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: private-reg +spec: + containers: + - name: private-reg-container + image: + imagePullSecrets: + - name: regcred + diff --git a/content/ru/examples/pods/share-process-namespace.yaml b/content/ru/examples/pods/share-process-namespace.yaml new file mode 100644 index 0000000000000..bd48bf0ff6e18 --- /dev/null +++ b/content/ru/examples/pods/share-process-namespace.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + shareProcessNamespace: true + containers: + - name: nginx + image: nginx + - name: shell + image: busybox:1.28 + securityContext: + capabilities: + add: + - SYS_PTRACE + stdin: true + tty: true diff --git a/content/ru/examples/pods/simple-pod.yaml b/content/ru/examples/pods/simple-pod.yaml new file mode 100644 index 0000000000000..0e79d8a3c6128 --- /dev/null +++ b/content/ru/examples/pods/simple-pod.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 diff --git a/content/ru/examples/pods/two-container-pod.yaml b/content/ru/examples/pods/two-container-pod.yaml new file mode 100644 index 0000000000000..031ada7112b4c --- /dev/null +++ b/content/ru/examples/pods/two-container-pod.yaml @@ -0,0 +1,27 @@ +apiVersion: v1 +kind: Pod +metadata: + name: two-containers +spec: + + restartPolicy: Never + + volumes: + - name: shared-data + emptyDir: {} + + containers: + + - name: nginx-container + image: nginx + volumeMounts: + - name: shared-data + mountPath: /usr/share/nginx/html + + - name: debian-container + image: debian + volumeMounts: + - name: shared-data + mountPath: /pod-data + command: ["/bin/sh"] + args: ["-c", "echo Hello from the debian container > /pod-data/index.html"] diff --git a/content/ru/examples/pods/user-namespaces-stateless.yaml b/content/ru/examples/pods/user-namespaces-stateless.yaml new file mode 100644 index 0000000000000..d254259f66cb9 --- /dev/null +++ b/content/ru/examples/pods/user-namespaces-stateless.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: userns +spec: + hostUsers: false + containers: + - name: shell + command: ["sleep", "infinity"] + image: debian