# Узлы

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->

Kubernetes запускает ваши приложения, помещая контейнеры в Поды для запуска на Узлах (_Nodes_).
В зависимости от кластера, узел может быть виртуальной или физической машиной. Каждый узел
содержит сервисы, необходимые для запуска
<a class='glossary-tooltip' title='Самый маленький и простой объект в Kubernetes. Под — это набор запущенных контейнеров в кластере.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/workloads/pods/pod-overview/' target='_blank' aria-label='Подов'>Подов</a>, управляемых
<a class='glossary-tooltip' title='Уровень оркестрации контейнеров, предоставляющий API и интерфейсы для определения, развёртывания и управления жизненным циклом контейнеров.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/reference/glossary/?all=true#term-control-plane' target='_blank' aria-label='control plane (управляющим слоем)'>control plane (управляющим слоем)</a>.

Обычно у вас есть несколько узлов в кластере; однако в среде обучения или среде
с ограниченными ресурсами у вас может быть только один.

[Компоненты](/ru/docs/concepts/overview/components/##компоненты-узла) на узле включают
<a class='glossary-tooltip' title='Агент, работающий на каждом узле в кластере. Он следит за тем, чтобы контейнеры были запущены в поде.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/reference/command-line-tools-reference/kubelet' target='_blank' aria-label='kubelet'>kubelet</a>,
<a class='glossary-tooltip' title='Иcполняемая среда контейнеров — это программное обеспечение, предназначенное для запуска контейнеров.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/setup/production-environment/container-runtimes' target='_blank' aria-label='среду выполнения контейнера'>среду выполнения контейнера</a> и
<a class='glossary-tooltip' title='kube-proxy — сетевой прокси, работающий на каждом узле в кластере.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/reference/command-line-tools-reference/kube-proxy/' target='_blank' aria-label='kube-proxy'>kube-proxy</a>.

<!-- body -->

## Управление

Существует два основных способа добавления Узлов в <a class='glossary-tooltip' title='Компонент управляющего слоя, предоставляющий Kubernetes API.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/reference/generated/kube-apiserver/' target='_blank' aria-label='API сервер'>API сервер</a>:

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` Узла.
Если узел здоров (если все необходимые сервисы запущены),
он имеет право на запуск Пода. В противном случае этот узел игнорируется для любой активности кластера
до тех пор, пока он не станет здоровым.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примечание:</h4><p>Kubernetes сохраняет объект для невалидного Узла и продолжает проверять, становится ли он здоровым.</p>
<p>Вы или <a class='glossary-tooltip' title='Управляющий цикл, который отслеживает общее состояние кластера через API-сервер и вносит изменения, пытаясь привести текущее состояние к желаемому.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/architecture/controller/' target='_blank' aria-label='контроллер'>контроллер</a> должны явно удалить объект Узла, чтобы
остановить проверку доступности узла.</p>
</div>


Имя объекта Узла должно быть валидным
[именем поддомена DNS](/ru/docs/concepts/overview/working-with-objects/names#имена-поддоменов-dns).

### Саморегистрация Узлов

Когда kubelet флаг `--register-node` имеет значение _true_ (по умолчанию), то kubelet будет пытаться
зарегистрировать себя на API сервере. Это наиболее предпочтительная модель, используемая большинством дистрибутивов.

Для саморегистрации kubelet запускается со следующими опциями:

  - `--kubeconfig` - Путь к учетным данным для аутентификации на API сервере.
  - `--cloud-provider` - Как общаться с <a class='glossary-tooltip' title='Организация, которая предлагает платформу облачных вычислений.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/cluster-administration/cloud-providers' target='_blank' aria-label='облачным провайдером'>облачным провайдером</a>, чтобы прочитать метаданные о себе.
  - `--register-node` - Автоматически зарегистрироваться на API сервере.
  - `--register-with-taints` - Зарегистрировать узел с приведенным списком <a class='glossary-tooltip' title='A core object consisting of three required properties: key, value, and effect. Taints prevent the scheduling of pods on nodes or node groups.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/scheduling-eviction/taint-and-toleration/' target='_blank' aria-label='ограничений (taints)'>ограничений (taints)</a> (разделенных запятыми `<key>=<value>:<effect>`).

    Ничего не делает, если `register-node` - _false_.
  - `--node-ip` - IP-адрес узла.
  - `--node-labels` - <a class='glossary-tooltip' title='Тегирует объекты произвольными метками, которые идентифицируют их и имеют смысл для пользователей.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/overview/working-with-objects/labels' target='_blank' aria-label='Метки'>Метки</a> для добавления при регистрации узла в кластере (смотрите ограничения для меток, установленные [плагином согласования (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'ы имеют право только создавать/изменять свой собственный ресурс Узла.

### Ручное администрирование узла

Вы можете создавать и изменять объекты узла используя
<a class='glossary-tooltip' title='A command line tool for communicating with a Kubernetes cluster.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/reference/kubectl/' target='_blank' aria-label='kubectl'>kubectl</a>.

Когда вы хотите создать объекты Узла вручную, установите kubelet флаг `--register-node=false`.

Вы можете изменять объекты Узла независимо от настройки  `--register-node`.
Например, вы можете установить метки на существующем Узле или пометить его не назначаемым.

Вы можете использовать метки на Узлах в сочетании с селекторами узла на Подах для управления планированием.
Например, вы можете ограничить Под, иметь право на запуск только на группе доступных узлов.

Маркировка узла как не назначаемого предотвращает размещение планировщиком новых подов на этом Узле,
но не влияет на существующие Поды на Узле. Это полезно в качестве
подготовительного шага перед перезагрузкой узла или другим обслуживанием.

Чтобы отметить Узел не назначаемым, выполните:

```shell
kubectl cordon $NODENAME
```


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примечание:</h4>Поды, являющиеся частью <a class='glossary-tooltip' title='Гарантирует, что копия пода выполняется на множестве узлов кластера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/workloads/controllers/daemonset' target='_blank' aria-label='DaemonSet'>DaemonSet</a> допускают
запуск на не назначаемом Узле. DaemonSets обычно обеспечивает локальные сервисы узла,
которые должны запускаться на Узле, даже если узел вытесняется для запуска приложений.</div>


## Статус Узла

Статус узла содержит следующие данные:

* [Адреса (Addresses)](#адреса)
* [Условия (Conditions)](#условие)
* [Емкость и Выделяемые ресурсы (Capacity and Allocatable)](#емкость)
* [Информация (Info)](#информация)

Вы можете использовать `kubectl` для просмотра статуса Узла и других деталей:

```shell
kubectl describe node <insert-node-name-here>
```

Каждая секция из вывода команды описана ниже.

### Адреса (Addresses)

Использование этих полей варьируется в зависимости от вашего облачного провайдера или конфигурации физических серверов (_bare metal_).

* HostName: Имя хоста, сообщаемое ядром узла. Может быть переопределено через kubelet `--hostname-override` параметр.
* ExternalIP: Обычно, IP адрес узла, который является внешне маршрутизируемым (доступен за пределами кластера).
* InternalIP: Обычно, IP адрес узла, который маршрутизируется только внутри кластера.

### Условия (Conditions) {#условие}

Поле `conditions` описывает статус всех `Running` узлов. Примеры условий включают в себя:



 





<table><caption style="display: none;">Условия узла и описание того, когда применяется каждое условие.</caption>
	<thead>
			<tr>
					<th>Условие Узла</th>
					<th>Описание</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td><code>Ready</code></td>
					<td><code>True</code> если узел здоров и готов принять поды, <code>False</code> если узел нездоров и не принимает поды, и <code>Unknown</code> если контроллер узла не получал информацию от узла в течение последнего периода <code>node-monitor-grace-period</code> (по умолчанию 40 секунд)</td>
			</tr>
			<tr>
					<td><code>DiskPressure</code></td>
					<td><code>True</code> если присутствует давление на размер диска - то есть, если емкость диска мала; иначе <code>False</code></td>
			</tr>
			<tr>
					<td><code>MemoryPressure</code></td>
					<td><code>True</code> если существует давление на память узла - то есть, если памяти на узле мало; иначе <code>False</code></td>
			</tr>
			<tr>
					<td><code>PIDPressure</code></td>
					<td><code>True</code> если существует давление на процессы - то есть, если на узле слишком много процессов; иначе <code>False</code></td>
			</tr>
			<tr>
					<td><code>NetworkUnavailable</code></td>
					<td><code>True</code> если сеть для узла настроена некорректно, иначе <code>False</code></td>
			</tr>
	</tbody>
</table>



<div class="alert alert-info" role="note"><h4 class="alert-heading">Примечание:</h4>Если вы используете инструменты командной строки для вывода сведений об блокированном узле,
то Условие включает <code>SchedulingDisabled</code>. <code>SchedulingDisabled</code> не является Условием в Kubernetes API;
вместо этого блокированные узлы помечены как Не назначаемые в их спецификации.</div>


Состояние узла представлено в виде 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`(аргумент, переданный в
<a class='glossary-tooltip' title='Компонент управляющего слоя, который запускает процессы контроллера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/reference/command-line-tools-reference/kube-controller-manager/' target='_blank' aria-label='kube-controller-manager'>kube-controller-manager</a>), то все Поды
на узле планируются к удалению контроллером узла. По умолчанию таймаут выселения **пять минут**.
В некоторых случаях, когда узел недоступен, 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, память и максимальное количество подов,
которые могут быть запланированы на узле.

Поля в блоке capacity указывают общее количество ресурсов, которые есть на Узле.
Блок allocatable указывает количество ресурсов на Узле,
которые доступны для использования обычными Подами.

Вы можете прочитать больше о емкости и выделяемых ресурсах, изучая, как [зарезервировать вычислительные ресурсы](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) на Узле.

### Информация (Info)

Описывает общую информацию об узле, такую как версия ядра, версия Kubernetes (версии kubelet и kube-proxy), версия Docker (если используется) и название ОС.
Эта информация собирается Kubelet'ом на узле.

### Контроллер узла

<a class='glossary-tooltip' title='Управляющий цикл, который отслеживает общее состояние кластера через API-сервер и вносит изменения, пытаясь привести текущее состояние к желаемому.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/architecture/controller/' target='_blank' aria-label='Контроллер '>Контроллер </a> узла является компонентом
управляющего слоя Kubernetes, который управляет различными аспектами узлов.

Контроллер узла играет различные роли в жизни узла. Первая - назначение CIDR-блока узлу
при его регистрации (если включено назначение CIDR).

Вторая - поддержание в актуальном состоянии внутреннего списка узлов контроллера узла
согласно списку доступных машин облачного провайдера. При работе в облачной среде всякий раз,
когда узел неисправен, контроллер узла запрашивает облачного провайдера, доступна ли
виртуальная машина для этого узла. Если нет, то контроллер узла удаляет узел из
своего списка узлов.

Третья - это мониторинг работоспособности узлов. Контроллер узла
отвечает за обновление условия NodeReady для NodeStatus на
ConditionUnknown, когда узел становится недоступным (т.е. контроллер узла
по какой-то причине перестает получать сердцебиения (heartbeats) от узла,
например, из-за того, что узел упал), и затем позже выселяет все поды с узла
(используя мягкое (graceful) завершение) если узел продолжает быть недоступным.
(По умолчанию таймауты составляют 40 секунд, чтобы начать сообщать `ConditionUnknown`,
и 5 минут после, чтобы начать выселять поды.) 

Контроллер узла проверяет состояние каждого узла каждые  `--node-monitor-period` секунд.

#### Сердцебиения

Сердцебиения, посылаемые узлами Kubernetes, помогают определить доступность узла.

Существует две формы сердцебиений: обновление  `NodeStatus` и
[Lease объект](/docs/reference/generated/kubernetes-api/v1.36/#lease-v1-coordination-k8s-io).
Каждый узел имеет связанный с ним Lease объект в `kube-node-lease`
<a class='glossary-tooltip' title='Абстракция, которую Kubernetes использует для изоляции групп ресурсов в рамках одного кластера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/overview/working-with-objects/namespaces' target='_blank' aria-label='namespace'>namespace</a>.
Lease - это легковесный ресурс, который улучшает производительность
сердцебиений узла при масштабировании кластера.

Kubelet отвечает за создание и обновление `NodeStatus` и Lease объекта.

- Kubelet обновляет `NodeStatus` либо когда происходит изменение статуса,
  либо если в течение настроенного интервала обновления не было. По умолчанию
  интервал для обновлений `NodeStatus` составляет 5 минут (намного больше,
  чем 40-секундный стандартный таймаут для недоступных узлов).
- Kubelet создает и затем обновляет свой Lease объект каждый 10 секунд
  (интервал обновления по умолчанию). Lease обновления происходят независимо от
  `NodeStatus` обновлений. Если обновление Lease завершается неудачно,
  kubelet повторяет попытку с экспоненциальным откатом, начинающимся с 200 миллисекунд и ограниченным 7 секундами.

#### Надежность

В большинстве случаев контроллер узла ограничивает скорость выселения
до `--node-eviction-rate` (по умолчанию 0,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` ограничениями, за исключением тех подов, которые сопротивляются этим ограничениям.
Контроллер узла так же добавляет <a class='glossary-tooltip' title='A core object consisting of three required properties: key, value, and effect. Taints prevent the scheduling of pods on nodes or node groups.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/scheduling-eviction/taint-and-toleration/' target='_blank' aria-label='ограничения'>ограничения</a>
соответствующие проблемам узла, таким как узел недоступен или не готов. Это означает,
что планировщик не будет размещать поды на нездоровых узлах.

<div class="alert alert-caution" role="note"><h4 class="alert-heading">Внимание:</h4><code>kubectl cordon</code> помечает узел как 'не назначаемый', что имеет побочный эффект от контроллера сервисов,
удаляющего узел из любых списков целей LoadBalancer узла, на которые он ранее имел право,
эффективно убирая входящий трафик балансировщика нагрузки с блокированного узла(ов).</div>


### Емкость узла

Объекты узла отслеживают информацию о емкости ресурсов узла (например,
объем доступной памяти и количество CPU).
Узлы, которые [самостоятельно зарегистрировались](#саморегистрация-узлов), сообщают
о своей емкости во время регистрации. Если вы [вручную](#ручное-администрирование-узла)
добавляете узел, то вам нужно задать информацию о емкости узла при его добавлении.

<a class='glossary-tooltip' title='Компонент управляющего слоя, который отслеживает недавно созданные поды без назначенного для них узла и выбирает узел, на котором они должны работать.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/reference/generated/kube-scheduler/' target='_blank' aria-label='Планировщик'>Планировщик</a> Kubernetes гарантирует,
что для всех Подов на Узле достаточно ресурсов. Планировщик проверяет,
что сумма requests от контейнеров на узле не превышает емкость узла.
Эта сумма requests включает все контейнеры, управляемые kubelet,
но исключает любые контейнеры, запущенные непосредственно средой выполнения контейнера,
а также исключает любые процессы, запущенные вне контроля kubelet.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примечание:</h4>Если вы явно хотите зарезервировать ресурсы для процессов, не связанных с Подами, смотрите раздел
<a href="/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved">зарезервировать ресурсы для системных демонов</a>.</div>


## Топология узла








  <div class="feature-state-notice feature-alpha">
      <span class="feature-state-name">СТАТУС ФИЧИ:</span>
      <code>Kubernetes v1.16 [alpha]</code>
    </div>
  



Если вы включили `TopologyManager`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), то kubelet
может использовать подсказки топологии при принятии решений о выделении ресурсов.
Смотрите [Контроль Политик Управления Топологией на Узле](/docs/tasks/administer-cluster/topology-manager/)
для дополнительной информации.

## Что дальше

* Подробнее про[компоненты](/ru/docs/concepts/overview/components/#компоненты-узла) из которых состоит узел.
* Подробнее про [Определение API для Узла](/docs/reference/generated/kubernetes-api/v1.36/#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).