From 976d81067cb35c22f3c8ad1a8e7d450a43311583 Mon Sep 17 00:00:00 2001 From: woblerr Date: Mon, 22 Jun 2020 11:34:11 +0300 Subject: [PATCH] translate into Russian: concepts-nodes; glossary-cloud-provider; glossary-controller --- .../ru/docs/concepts/architecture/_index.md | 5 + .../ru/docs/concepts/architecture/nodes.md | 340 ++++++++++++++++++ .../docs/reference/glossary/cloud-provider.md | 32 ++ .../ru/docs/reference/glossary/controller.md | 29 ++ 4 files changed, 406 insertions(+) create mode 100755 content/ru/docs/concepts/architecture/_index.md create mode 100644 content/ru/docs/concepts/architecture/nodes.md create mode 100755 content/ru/docs/reference/glossary/cloud-provider.md create mode 100755 content/ru/docs/reference/glossary/controller.md diff --git a/content/ru/docs/concepts/architecture/_index.md b/content/ru/docs/concepts/architecture/_index.md new file mode 100755 index 0000000000..eb68a67e53 --- /dev/null +++ b/content/ru/docs/concepts/architecture/_index.md @@ -0,0 +1,5 @@ +--- +title: "Кластерная Архитектура" +weight: 30 +--- + diff --git a/content/ru/docs/concepts/architecture/nodes.md b/content/ru/docs/concepts/architecture/nodes.md new file mode 100644 index 0000000000..1cd0a41ac2 --- /dev/null +++ b/content/ru/docs/concepts/architecture/nodes.md @@ -0,0 +1,340 @@ +--- +reviewers: +- caesarxuchao +- dchen1107 +title: Узлы +content_template: concept +weight: 10 +--- + + + +Kubernetes запускает ваши приложения, помещая контейнеры в Поды для запуска на Узлах (_Nodes_). +В зависимотри от кластера узел может быть виртуальной или физической машиной. Каждый узел +содержит сервисы, необходимые для запуска +{{< glossary_tooltip text="Подов" term_id="pod" >}}, управляемых +{{< glossary_tooltip text="плоскостью управления" term_id="control-plane" >}}. + +Обычно у вас есть несколько узлов в кластере; в среде обучения или среде +с ограниченными ресурсами у вас может быть только один. + +[Компоненты](/ru/docs/concepts/overview/components/##компоненты-узла) на узле включают +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, +{{< glossary_tooltip text="среду выполнения контейнера" term_id="container-runtime" >}} и +{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}. + + + +## Управление + +Существует два основных способа добавления Узлов в {{< glossary_tooltip text="API сервер" term_id="kube-apiserver" >}}: + +1. Kubelet на узле саморегистрируется узел в плоскости управления +2. Вы или другой пользователь вручную добавляете объект Узла + +После того как вы создадите объект Узла или kubelet на узле самозарегистируется, +плоскость управления проверяет, является ли новый объект Узла валидным (правильным). Например, если вы +попробуйте создать Узел при помощи следующего JSON манифеста: + +```json +{ + "kind": "Node", + "apiVersion": "v1", + "metadata": { + "name": "10.240.79.157", + "labels": { + "name": "my-first-k8s-node" + } + } +} +``` + +Kubernetes создает внутри себя объект Узла (представление). Kubernetes проверяет, +что kubelet зарегистрировался на API сервере, который совпадает с значением поля `metadata.name` Узла. +Если узел здоров (если все необходимые сервисы запущены), +он имеет право на запуск Пода. В противном случае, этот узел игнорируется для любой активности кластера +до тех пор, пока он не станет здоровым. + +{{< note >}} +Kubernetes сохраняет объект для невалидного Узла и продолжает проверять, становится ли он здоровым. + +Вы или {{< glossary_tooltip term_id="controller" text="контроллер">}} должны явно удалить объект Узла, чтобы +остановить проверку здоровья узла. +{{< /note >}} + +Имя объекта Узла дожно быть валидным +[именем поддомена DNS](/ru/docs/concepts/overview/working-with-objects/names#имена-поддоменов-dns). + +### Саморегистрация Узлов + +Когда kubelet флаг `--register-node` имеет значение _true_ (по умолчанию), то kubelet будет пытаться +зарегистрировать себя на API сервере. Это наиболее предпочтительная модель, используемая большиством дистрибутивов. + +Для саморегистрации kubelet запускается со следующими опциями: + + - `--kubeconfig` - Путь к учетным данным для аутентификации на API сервере. + - `--cloud-provider` - Как общаться с {{< glossary_tooltip text="облачным провайдером" term_id="cloud-provider" >}}, чтобы прочитать метаданные о себе. + - `--register-node` - Автоматически зарегистрироваться на API сервере. + - `--register-with-taints` - Зарегистрировать узел с приведенным списком {{< glossary_tooltip text="ограничений (taints)" term_id="taint" >}} (разделенных запятыми `=:`). + + Ничего не делает, если `register-node` - _false_. + - `--node-ip` - IP-адрес узла. + - `--node-labels` - {{< glossary_tooltip text="Метки" term_id="label" >}} для добавления при регистрации узла в кластере (смотрите ограничения для меток, установленные [плагином согласования (admission plugin) NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)). + - `--node-status-update-frequency` - Указывает, как часто kubelet отправляет статус узла мастеру. + +Когда [режим авторизации Узла](/docs/reference/access-authn-authz/node/) и +[плагин согласования NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) включены, +kubelet'ы имеют право только создавать/изменять свой собственный ресурс Узла. + +### Ручное администрирование узла + +Вы можете создавать и изменять объекты узла используя +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}. + +Когда вы хотите создать объекты Узла вручную, установите kubelet флаг `--register-node=false`. + +Вы можете изменять объекты Узла независимо от настройки `--register-node`. +Например, вы можете установить метки на существующем Узле или пометить его неназначаемым. + +Вы можете использовать метки на Узлах в сочетании с селекторами узла на Подах для управления планированием. +Например, вы можете ограничить Под иметь право на запуск только на группе доступных узлов. + +Маркировка узла как неназначаемого предотвращает размещение планировщиком новых подов на этом Узле, +но не влияет на существующие Поды на Узле. Это полезно в качестве +подготовительного шага перед перезагрузкой узла или другим обслуживанием. + +Чтобы отметить Узел неназначемым, выполните: + +```shell +kubectl cordon $NODENAME +``` + +{{< note >}} +Поды, являющиеся частью {{< glossary_tooltip term_id="daemonset" >}} допускают +запуск на неназначаемом Узле. DaemonSets обычно обеспечивает локальные сервисы узла, +которые должны запускаться на Узле, даже если узел вытесняется для запуска приложений. +{{< /note >}} + +## Статус Узла + +Статус узла содержит следующие данные: + +* [Адреса (Addresses)](#адреса) +* [Условия (Conditions)](#условие) +* [Емкость и Выделяемые ресурсы (Capacity and Allocatable)](#емкость) +* [Информация (Info)](#информация) + +Вы можете использовать `kubectl` для просмотра статуса Узла и других деталей: + +```shell +kubectl describe node +``` + +Каждая секция из вывода команды описана ниже. + +### Адреса (Addresses) + +Использование этих полей варьируется в зависимости от вашего облачного провайдера или конфигурации физических серверов (_bare metal_). + +* HostName: Имя хоста, сообщаемое ядром узла. Может быть переопределено через kubelet `--hostname-override` параметр. +* ExternalIP: Обычно, IP адрес узла, который является внешне маршрутизируемым (доступен за пределами кластера). +* InternalIP: Обычно, IP адрес узла, который маршрутизируется только внутри кластера. + +### Условия (Conditions) {#условие} + +Поле `conditions` описывает статус всех `Running` узлов. Примеры условий включают в себя: + +{{< table caption = "Условия узла и описание того, когда применяется каждое условие." >}} +| Условие Узла | Описание | +|----------------------|-------------| +| `Ready` | `True` если узел здоров и готов принять поды, `False` если узел нездоров и не принимает поды, и `Unknown` если контроллер узла не получал информацию от узла в течение последнего периода `node-monitor-grace-period` (по умолчанию 40 секунд) | +| `DiskPressure` | `True` если присутствует давление на размер диска - то есть, если емкость диска мала; иначе `False` | +| `MemoryPressure` | `True` если существует давление на память узла - то есть, если памяти на узле мало; иначе `False` | +| `PIDPressure` | `True` если существует давление на процессы - то есть, если на узле слишком много процессов; иначе `False` | +| `NetworkUnavailable` | `True` если сеть для узла настроена некорректно, иначе `False` | +{{< /table >}} + +{{< note >}} +Если вы используете инструменты командной строки для вывода сведений об блокированном узле, +то Условие включает `SchedulingDisabled`. `SchedulingDisabled` не является Условием в Kubernetes API; +вместо этого блокированные узлы помечены как Неназначемые в их спецификации. +{{< /note >}} + +Состояние узла представлено в виде JSON объекта. Например, следующая структура описывает здоровый узел: + +```json +"conditions": [ + { + "type": "Ready", + "status": "True", + "reason": "KubeletReady", + "message": "kubelet is posting ready status", + "lastHeartbeatTime": "2019-06-05T18:38:35Z", + "lastTransitionTime": "2019-06-05T11:41:27Z" + } +] +``` + +Если значение параметра Status для условия Ready остается `Unknown` или `False` +дольше чем период `pod-eviction-timeout`(аргумент, переданный в +{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), то все Поды +на узле планируются к удалению контроллером узла. По умолчанию таймаут выселения **пять минут**. +В некоторых случаях, когда узел недоступен, API сервер не может связаться с kubelet на узле. +Решение об удалении подов не может быть передано в kubelet до тех пор, пока связь с API сервером не будет восстановлена. +В то же время поды, которые запланированы к удалению, могут продолжать работать на отделенном узле. + +Контроллер узла не будет принудительно удалять поды до тех пор, пока не будет подтверждено, +что они перестали работать в кластере. Вы можете видеть, что поды, которые могут работать на недоступном узле, +находятся в состоянии `Terminating` или `Unknown`. В тех случаях, когда Kubernetes не может сделать вывод +из основной инфраструктуры о том, что узел окончательно покинул кластер, администратору кластера может потребоваться +удалить объект узла вручную. Удаление объекта узла из Kubernetes приводит к удалению всех объектов Подов, запущенных +на узле, с API сервера и освобождает их имена. + +Контроллер жизненного цикла узла автоматически создает +[ограничения (taints)](/docs/concepts/scheduling-eviction/taint-and-toleration/), которые представляют собой условия. +Планировщик учитывает ограничения Узла при назначении Пода на Узел. +Поды так же могут иметь допуски (tolerations), что позволяет им сопротивляться ограничениям Узла. + +Смотрите раздел [Ограничить Узлы по Условию](/docs/concepts/configuration/taint-and-toleration/#taint-nodes-by-condition) +для дополнительной информации. + +### Емкость и Выделяемые ресурсы (Capacity and Allocatable) {#емкость} + +Описывает ресурсы, доступные на узле: CPU, память и максимальное количество подов, +которые могут быть запланированы на узле. + +Поля в блоке capasity указывают общее количество ресурсов, которые есть на Узле. +Блок allocatable указывает количество ресурсовна Узле, +которые доступны для использования обычными Подами. + +Вы можете прочитать больше о емкости и выделяемых ресурсах, изучая, как [зарезервировать вычислительные ресурсы](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) на Узле. + +### Информация (Info) + +Описывает общую информацию об узле, такую как версия ядра, версия Kubernetes (версии kubelet и kube-proxy), версия Docker (если используется) и название ОС. +Эта информация соберается Kubelet'ом на узле. + +### Контроллер узла + +{{< glossary_tooltip text="Контроллер " term_id="controller" >}} узла является компонентом +плоскости управления Kubernetes, который управляет различными аспектами узлов. + +Контроллер узла играет различные роли в жизни узла. Первая - назначение CIDR-блока узлу +при его регистрации (если включено назначение CIDR). + +Вторая - поддержание в актуальном состоянии внутреннего списка узлов контроллера узла +согласно списку доступных машин облачного провайдера. При работе в облачной среде всякий раз, +когда узел неисправен, контроллер узла запрашивает облачного провайдера, доступна ли +виртуальная машина для этого узла. Если нет, то контроллер узла удаляет узел из +своего списка узлов. + +Третья - это мониторинг работоспособности узлов. Контроллер узла +отвечает за обновление условия NodeReady для NodeStatus на +ConditionUnknown, когда узел становится недоступным (т.е. контроллер узла +по какой-то причине перестает получать сердцебиения (heartbeats) от узла, +например, из-за того, что узел упал), и затем позже выселяет все поды с узла +(используя мягкое (graceful) завершение) если узел продолжает быть недоступным. +(По умолчанию таймауты составляют 40 секунд, чтобы начать сообщать `ConditionUnknown`, +и 5 минут после, чтобы начать выселять поды.) Контроллер узла проверяет состояние каждого узла +каждые `--node-monitor-period` секунд. + +#### Сердцебиения + +Сердцебиения, посылаемые узлами Kubernetes, помогают определить доступность узла. + +Существует две формы сердцебиений: обновление `NodeStatus` и +[Lease объект](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io). +Каждый узел имеет связанный с ним Lease объект в `kube-node-lease` +{{< glossary_tooltip term_id="namespace" text="namespace">}}. +Lease - это легковестный ресурс, который улучшает производительность +сердцебиений узла при масштабировании кластера. + +Kubelet отвечает за создание и обновление `NodeStatus` и Lease объекта. + +- Kubelet обновляет `NodeStatus` либо когда происходит изменение статуса, + либо если в течение настронного интервала обновления не было. По умолчанию + интервал для обновлений `NodeStatus` составляет 5 минут (намного больше, + чем 40-секундный стандартный таймаут для недоступных узлов). +- Kubelet созадет и затем обновляет свой Lease объект каждый 10 секунд + (интервал обновления по умолчанию). Lease обновления происходят независимо от + `NodeStatus` обновлений. Если обновление Lease завершается неудачно, + kubelet повторяет попытку с экспоненциальным откатом, начинающимся с 200 миллисекунд и ограниченным 7 секундами. + +#### Надежность + +В большинстве случаев контроллер узла ограничивает скорость выселения +до `--node-eviction-rate` (по умолчанию 0,1) в секунду, что означает, +что он не выселяет поды с узлов быстрее чем c 1 узела в 10 секунд. + +Поведение выселения узла изменяется, когда узел в текущей зоне доступности +становится нездоровым. Контроллер узла проверяет, какой процент узлов в зоне +нездоров (NodeReady условие в значении ConditionUnknown или ConditiononFalse) +в одно и то же время. Если доля нездоровых узлов не меньше +`--unhealthy-zone-threshold` (по умолчанию 0.55), то скорость выселения уменьшается: +если кластер небольшой (т.е. количество узлов меньше или равно +`--large-cluster-size-threshold` - по умолчанию, 50), то выселения прекращаются, +в противном случае скорость выселения снижается до +`--secondary-node-eviction-rate` (по умолчанию, 0.01) в секунду. Причина, по которой +эти политики реализуются для каждой зоны доступности, заключается в том, +что одна зона доступности может стать отделенной от мастера, в то время как другие +остаются подключенными. Если ваш кластер не охватывает несколько зон доступности +облачного провайдера, то существует только одна зона доступности (весь кластер). + +Основная причина разнесения ваших узлов по зонам доступности заключается в том, +что приложения могут быть перенесены в здоровые зоны, когда одна из зон полностью +становится недоступной. Поэтому, если все узлы в зоне нездоровы, то контроллер узла +выселяет поды с нормальной скоростью `--node-eviction-rate`. Крайний случай - когда все зоны +полностью нездоровы (т.е. в кластере нет здоровых узлов). В таком случае +контроллер узла предполагает, что существует некоторая проблема с подключением к мастеру, +и останавеливает все выселения, пока какое-нибудь подключение не будет восстановлено. + +Контроллер узла также отвечает за выселение подов, запущенных на узлах с +`NoExecute` ограничениями, за исключением тех подов, которые сопротивляются этим ограничениям. +Контроллер узла так же добавляет {{< glossary_tooltip text="ограничения" term_id="taint" >}} +соотвествующие проблемам узла, таким как узел недоступен или не готов. Это означает, +что планировщик не будет размещать поды на нездоровых узлах. + +{{< caution >}} +`kubectl cordon` помечает узел как 'неназначемый', что имеет побочный эфект от контроллера сервисов, +удаляющего узел из любых списков целей LoadBalancer узла, на которые он ранее имел право, +эффектино убирая входящий трафик балансировщика нагрузки с блокированного узла(ов). +{{< /caution >}} + +### Емкость узла + +Объекты узла отслеживают информацию о емкости ресурсов узла (например, +объем доступной памяти и количество CPU). +Узлы, которые [самостоятельно зарегистировались](#саморегистрация-узлов) сообщают +о свое емкости во время регистрации. Если вы [вручную](#ручное-администрирование-узла) +добавляете узел, то вам нужно задать информацию о емкости узла при его добавлении. + +{{< glossary_tooltip text="Планировщик" term_id="kube-scheduler" >}} Kubernetes гарантирует, +что для всех Подов на Узле достаточно ресурсов. Планировщик проверяет, +что сумма requests от контейнеров на узле не превышает емкость узла. +Эта сумма requests включает все контейнеры, управляемые kubelet, +но исключает любые контейнеры, запущенные непосредственно средой выполнения контейнера, +а также исключает любые процессы, запущенные вне контроля kubelet. + +{{< note >}} +Если вы явно хотите зарезервировать ресурсы для процессов, не связанныз с Подами, смотрите раздел +[зарезервировать ресурсы для системных демонов](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved). +{{< /note >}} + +## Топология узла + +{{< feature-state state="alpha" for_k8s_version="v1.16" >}} + +Если вы включили `TopologyManager` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), то kubelet +может использовать подсказки топологии при принятии решений о выделении ресурсов. +Смотрите [Контроль Политик Управления Топологией на Узле](/docs/tasks/administer-cluster/topology-manager/) +для дополнительной информации. + +## {{% heading "whatsnext" %}} + +* Подробнее про[компоненты](/ru/docs/concepts/overview/components/#компоненты-узла) из которых состоит узел. +* Подробнее про [Определение API для Узла](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). +* Подробнее про [Узлы](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) + of the architecture design document. +* Подробнее про [ограничения и допуски](/docs/concepts/configuration/taint-and-toleration/). +* Подробнее про [автомаштабирование кластера](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). diff --git a/content/ru/docs/reference/glossary/cloud-provider.md b/content/ru/docs/reference/glossary/cloud-provider.md new file mode 100755 index 0000000000..55414a63ee --- /dev/null +++ b/content/ru/docs/reference/glossary/cloud-provider.md @@ -0,0 +1,32 @@ +--- +title: Облачный Провайдер (Cloud Provider) +id: cloud-provider +date: 2018-04-12 +full_link: /docs/concepts/cluster-administration/cloud-providers +short_description: > + Организация, которая предлагает платформу облачных вычислений. + +aka: +- Поставщик Облачных Услуг (Cloud Service Provider) +tags: +- community +--- + Бизнес или другая организация, которая предлагает платформу облачных вычислений. + + + +Облачные Провайдеры, иногда называемые Поставщиками Облачных Услуг (Cloud Service Provider, CSPs), +предлагают облачные вычислительные платформы или услуги. + +Многие облачные провайдеры предлагают управляемую инфраструктуру (также называемую +Инфраструктура как Услуга (Infrastructure as a Service) или IaaS). +С управляемой инфраструктурой облачный провайдер отвечает за +сервера, хранилище и сеть, в то время как вы управляете слоями поверх этого, +такими как запуск Kubernetes кластера. + +Вы также можете найти Kubernetes в качестве управляемого сервиса; иногда его называют +Платформа как Услуга (Platform as a Service) или PaaS. С упарвляемым Kubernetes +ваш облачный провайдер отвечает за +{{< glossary_tooltip term_id="control-plane" text="плоскость управления" >}} Kubernetes, а также за +{{< glossary_tooltip term_id="node" text="узлы" >}} и инфраструктуру, на которую они полагаются: +сеть, хранилище и, возможно, другие элементы, такие как балансировщики нагрузки. diff --git a/content/ru/docs/reference/glossary/controller.md b/content/ru/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..c1efc41d1b --- /dev/null +++ b/content/ru/docs/reference/glossary/controller.md @@ -0,0 +1,29 @@ +--- +title: Контроллер (Controller) +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + Управляющий цикл который отслеживает общее состояние кластера через API-сервер и вносит изменения пытаясь приветси текушее состояние к желаемому состоянию. + +aka: +tags: +- architecture +- fundamental +--- +Контроллеры в Kubernetes - управляющие циклы, которые отслеживают состояние вашего +{{< glossary_tooltip term_id="cluster" text="кластера">}}, затем вносят или запрашивают +изменения там, где это необходимо. +Каждый контроллер пытается привести текущее состояние кластера ближе к желаемому состоянию. + + + +Контроллеры отсллеживают общее состояние вашего кластера через +{{< glossary_tooltip text="API-сервер" term_id="kube-apiserver" >}} (часть +{{< glossary_tooltip text="плоскости управления" term_id="control-plane" >}}). + +Некоторые контроллеры также работают внутри плоскости управления, обеспечивая +управляющие циклы, которые являются ядром для операций Kubernetes. Например: +контроллер развертывания (deployment controller), контроллер daemonset (daemonset controller), +контроллер пространства имен (namespace controller) и контроллер постоянных томов (persistent volume +controller) (и другие) работают с {{< glossary_tooltip term_id="kube-controller-manager" >}}.