# Вузли

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

---

<!-- overview -->

Kubernetes виконує ваше <a class='glossary-tooltip' title='Робоче навантаження є застосунком, який запущено в Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/' target='_blank' aria-label='навантаження'>навантаження</a> шляхом розміщення <a class='glossary-tooltip' title='Легкий та переносний виконуваний образ, який містить програмне забезпечення та всі його залежності.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/containers/' target='_blank' aria-label='контейнерів'>контейнерів</a> у Podʼах для запуску на _Вузлах_. Вузол може бути віртуальною або фізичною машиною, залежно від кластера. Кожен вузол керується <a class='glossary-tooltip' title='Шар оркестрування контейнерів, який надає API та інтерфейси для виявлення, розгортання та управління життєвим циклом контейнерів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/glossary/?all=true#term-control-plane' target='_blank' aria-label='панеллю управління'>панеллю управління</a> і містить необхідні служби для запуску <a class='glossary-tooltip' title='Pod є групою контейнерів, що запущені у вашому кластері.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/pods/' target='_blank' aria-label='Podʼів'>Podʼів</a>.

Зазвичай в кластері є кілька вузлів; в умовах навчання чи обмежених ресурсів може бути всього один вузол.

[Компоненти](/docs/concepts/architecture/#node-components) на вузлі включають <a class='glossary-tooltip' title='Агент, запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів у Podʼах.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/command-line-tools-reference/kubelet' target='_blank' aria-label='kubelet'>kubelet</a>, <a class='glossary-tooltip' title='Середовище виконання контейнера — це програмне забезпечення, яке відповідає за запуск та виконання контейнерів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/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='/uk/docs/reference/command-line-tools-reference/kube-proxy/' target='_blank' aria-label='kube-proxy'>kube-proxy</a>.

<!-- body -->

## Управління {#management}

Є два основних способи додавання Вузлів до <a class='glossary-tooltip' title='Компонент панелі управління, що обслуговує API Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/#kube-apiserver' target='_blank' aria-label='API-сервера'>API-сервера</a>:

1. kubelet на вузлі самостійно реєструється в панелі управління.
2. Ви (або інший користувач) вручну додаєте обʼєкт Node.

Після створення <a class='glossary-tooltip' title='Сутність у системі Kubernetes, що представляє частину стану вашого кластера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/#kubernetes-objects' target='_blank' aria-label='обʼєкта'>обʼєкта</a> Node, або якщо kubelet на вузлі самостійно реєструється, панель управління перевіряє, чи новий обʼєкт Node є дійсним. Наприклад, якщо ви спробуєте створити Вузол з наступним JSON-маніфестом:

```json
{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}
```

Kubernetes внутрішньо створює обʼєкт Node. Kubernetes перевіряє чи kubelet зареєструвався в API-сервері, що відповідає полю `metadata.name` Node. Якщо вузол є справним (тобто всі необхідні служби працюють), то він може запускати Podʼи. В іншому випадку цей вузол ігнорується для будь-якої діяльності кластера доки він не стане справним.


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


Назва обʼєкта Node повинна бути дійсним [імʼям DNS-піддомену](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).

### Унікальність назв Вузлів {#node-name-uniqueness}

[Назва](/docs/concepts/overview/working-with-objects/names#names) ідентифікує Node. Два Вузли не можуть мати однакову назву одночасно. Kubernetes також припускає, що ресурс з такою ж назвою — це той самий обʼєкт. У випадку Вузла припускається неявно, що екземпляр, який використовує ту ж назву, матиме той самий стан (наприклад, мережеві налаштування, вміст кореневого диска) та атрибути, такі як мітки вузла. Це може призвести до невідповідностей, якщо екземпляр був змінений без зміни його назви. Якщо Вузол потрібно замінити або значно оновити, наявний обʼєкт Node повинен бути видалений з API-сервера спочатку і знову доданий після оновлення.

### Самореєстрація Вузлів {#self-registration-of-nodes}

Коли прапорець 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='/uk/docs/reference/glossary/?all=true#term-cloud-provider' target='_blank' aria-label='хмарним постачальником'>хмарним постачальником</a> для отримання метаданих про себе.
- `--register-node` — Автоматична реєстрація в API-сервері.
- `--register-with-taints` — Реєстрація вузла з заданим списком <a class='glossary-tooltip' title='Основний обʼєкт, що складається з трьох обовʼязкових властивостей: key, value, та effect. Taints (додаткові властивості) запобігають розміщенню Podʼів на вузлах чи групах вузлів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/scheduling-eviction/taint-and-toleration/' target='_blank' aria-label='позначок'>позначок</a> (розділених комами `<ключ>=<значення>:<ефект>`).

  Нічого не відбувається, якщо `register-node` є false.
- `--node-ip` — Необовʼязковий розділений комами список IP-адрес вузла. Можна вказати лише одну адресу для кожного роду адрес. Наприклад, у кластері з одним стеком IPv4 ви встановлюєте це значення як IPv4-адресу, яку повинен використовувати kubelet для вузла. Див. [Налаштування подвійного стека IPv4/IPv6](/docs/concepts/services-networking/dual-stack/#configure-ipv4-ipv6-dual-stack) для отримання відомостей з запуску кластера з подвійним стеком.

  Якщо ви не вказали цей аргумент, kubelet використовує стандартну IPv4-адресу вузла, якщо є; якщо у вузла немає адреси IPv4, тоді kubelet використовує стандартну IPv6-адресу вузла.
- `--node-labels` - <a class='glossary-tooltip' title='Позначає обʼєкти атрибутами ідентифікації, які мають значення і є важливими для користувачів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/labels' target='_blank' aria-label='Мітки'>Мітки</a> для додавання при реєстрації вузла в кластері (див. обмеження міток, що накладаються [втулком доступу NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)).
- `--node-status-update-frequency` — Вказує, як часто kubelet публікує свій статус вузла на API-сервері.

Коли увімкнено [режим авторизації Вузла](/docs/reference/access-authn-authz/node/) та [втулок доступу NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction), kubeletʼи мають право створювати/змінювати лише свій власний ресурс Node.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4><p>Як зазначено в розділі <a href="#node-name-uniqueness">Унікальність назв Вузлів</a>, коли потрібно оновити конфігурацію Вузла, добре було б знову зареєструвати вузол в API-сервері. Наприклад, якщо kubelet перезапускається з новим набором <code>--node-labels</code>, але використовується та ж назва Node, зміна не відбудеться, оскільки мітки встановлюються при реєстрації вузла.</p>
<p>Podʼи, вже заплановані на Node, можуть погано поводитися або викликати проблеми, якщо конфігурація Node буде змінена при перезапуску kubelet. Наприклад, вже запущений Pod може бути позначений новими мітками, призначеними Node, тоді як інші Pod, які несумісні з цим Pod, будуть заплановані на основі цієї нової мітки. Перереєстрація вузла гарантує, що всі Podʼи будуть очищені та належним чином переплановані.</p>
</div>


### Ручне адміністрування Вузлів {#manual-node-administration}

Ви можете створювати та змінювати обʼєкти Node за допомогою <a class='glossary-tooltip' title='Інструмент командного рядка для взаємодії з кластерами Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/kubectl/' target='_blank' aria-label='kubectl'>kubectl</a>.

Коли ви хочете створювати обʼєкти Node вручну, встановіть прапорець kubelet `--register-node=false`.

Ви можете змінювати обʼєкти Node незалежно від налаштувань `--register-node`. Наприклад, ви можете встановлювати мітки на наявному Вузлі або позначати його як незапланований.

Ви можете встановити необовʼязкові ролі для вузлів, додавши один або більше `node-role.kubernetes.io/<role>: <role>` міток до вузла, де символи `<role>` обмежуються правилами [синтаксису](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) для міток.

Kubernetes ігнорує значення мітки для ролей вузлів; за домовленістю, ви можете задати для неї той самий рядок, який ви використовували для ролі вузла у ключі мітки.

Ви можете використовувати мітки на Вузлах разом із селекторами вузлів на Podʼах для управління плануванням. Наприклад, ви можете обмежити Pod лише можливістю запуску на
підмножині доступних вузлів.

Позначення вузла як незапланованого перешкоджає планувальнику розміщувати нові Podʼи на цьому Вузлі, але не впливає на наявні Podʼи на Вузлі. Це корисно як підготовчий крок перед перезавантаженням вузла чи іншим обслуговуванням.

Щоб позначити Вузол як незапланований, виконайте:

```shell
kubectl cordon $NODENAME
```

Див. [Безпечне очищення вузла](/docs/tasks/administer-cluster/safely-drain-node/) для деталей.


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


## Статус Вузла {#node-status}

Статус Вузла містить наступну інформацію:

- [Адреси](/docs/reference/node/node-status/#addresses)
- [Умови](/docs/reference/node/node-status/#condition)
- [Місткість та Розподіленість](/docs/reference/node/node-status/#capacity)
- [Інформація](/docs/reference/node/node-status/#info)

Ви можете використовувати `kubectl`, щоб переглядати статус Вузла та інші деталі:

```shell
kubectl describe node <вставте-назву-вузла-тут>
```

Див. [Статус Вузла](/docs/reference/node/node-status/) для отримання додаткової інформації.

## Сигнали Вузлів {#node-heartbeats}

Сигнали, надсилані вузлами Kubernetes, допомагають вашому кластеру визначати доступність кожного вузла та вживати заходів у випадку виявлення відмов.

Для вузлів існують дві форми сигналів:

- Оновлення в [`.status`](/docs/reference/node/node-status/) Вузла.
- Обʼєкти [Lease](/docs/concepts/architecture/leases/) у просторі імен `kube-node-lease`. Кожен Вузол має асоційований обʼєкт Lease.

## Контролер вузлів {#node-controller}

Контролер вузлів — це компонент панелі управління Kubernetes, який керує різними аспектами роботи вузлів.

У контролера вузла є кілька ролей у житті вузла. По-перше, він призначає блок CIDR вузлу при його реєстрації (якщо призначення CIDR увімкнено).

По-друге, він підтримує актуальність внутрішнього списку вузлів контролера зі списком доступних машин хмарного провайдера. У разі, якщо вузол несправний, контролер вузла перевіряє у хмарному провайдері, чи ще доступний віртуальний компʼютер (VM) для цього вузла. Якщо ні, контролер вузла видаляє вузол зі свого списку вузлів.

По-третє, контролер відповідає за моніторинг стану вузлів і:

- У випадку, якщо вузол стає недоступним, оновлення умови `Ready` у полі `.status` Вузла. У цьому випадку контролер вузла встановлює умову `Ready` в `Unknown`.
- Якщо вузол залишається недоступним: запускає [виселення, ініційоване API](/docs/concepts/scheduling-eviction/api-eviction/) для всіх Podʼів на недосяжному вузлі. Типово контролер вузла чекає 5 хвилин між позначенням вузла як `Unknown` та поданням першого запиту на виселення.

Стандартно контролер вузла перевіряє стан кожного вузла кожні 5 секунд. Цей період можна налаштувати за допомогою прапорця `--node-monitor-period` у компоненті `kube-controller-manager`.

### Обмеження швидкості виселення {#rate-limits-on-eviction}

У більшості випадків контролер вузла обмежує швидкість виселення на `--node-eviction-rate` (типово 0,1) в секунду, що означає, що він не буде виводити Podʼи з більше, ніж 1 вузла кожні 10 секунд.

Поведінка виселення вузла змінюється, коли вузол в певній доступності стає несправним. Контролер вузла перевіряє, яка частина вузлів в зоні є несправною (умова `Ready` — `Unknown` або `False`) у той самий час:

- Якщо частка несправних вузлів становить принаймні `--unhealthy-zone-threshold` (типово 0,55), тоді швидкість виселення зменшується.
- Якщо кластер малий (тобто має менше або дорівнює `--large-cluster-size-threshold` вузлів — типово 50), тоді виселення припиняється.
- У іншому випадку швидкість виселення зменшується до `--secondary-node-eviction-rate` (типово 0,01) в секунду.

Причина того, що ці політики реалізовані окремо для кожної зони доступності, полягає в тому, що одна зона може втратити зʼєднання з панеллю управління, тоді як інші залишаються підключеними. Якщо ваш кластер не охоплює кілька зон доступності хмарного провайдера, тоді механізм виселення не враховує доступність поміж зон.

Однією з ключових причин розподілу вузлів за зонами доступності є можливість переміщення навантаження в справні зони, коли одна ціла зона виходить з ладу. Таким чином, якщо всі вузли в зоні несправні, контролер вузла виводить навантаження зі звичайною швидкістю `--node-eviction-rate`. Крайній випадок — коли всі зони повністю несправні (жоден вузол в кластері не є справним). У такому випадку контролер вузла припускає, що існує якась проблема зі зʼєднанням між панеллю управління та вузлами, і не виконує жодних виселень. (Якщо стався збій і деякі вузли відновились, контролер вузла виводить Podʼи з решти вузлів, які є несправними або недосяжними).

Контролер вузла також відповідає за виселення Podʼів, що працюють на вузлах із позначками `NoExecute`, якщо ці Podʼи не толерують відповідні taint. Контролер вузла також додає <a class='glossary-tooltip' title='Основний обʼєкт, що складається з трьох обовʼязкових властивостей: key, value, та effect. Taints (додаткові властивості) запобігають розміщенню Podʼів на вузлах чи групах вузлів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/scheduling-eviction/taint-and-toleration/' target='_blank' aria-label='taint'>taint</a>, відповідні проблемам вузла, таким як недосяжність вузла або неготовність вузла. Це означає, що планувальник не розміщуватиме Podʼи на несправних вузлах.

## Відстеження місткості ресурсів {#node-capacity}

Обʼєкти Node відстежують інформацію про ресурсну місткість вузла: наприклад, кількість доступної памʼяті та кількість процесорів. Вузли, які [реєструються самостійно](#self-registration-of-nodes), повідомляють про свою місткість під час реєстрації. Якщо ви [додаєте вузол вручну](#manual-node-administration), то вам потрібно встановити інформацію про місткість вузла при його додаванні.

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


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


## Топологія вузла {#node-topology}








  <div class="feature-state-notice feature-stable" title="Функціональна можливість: TopologyManager">
              <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span> 
              <code>Kubernetes v1.27 [stable]</code>(стандартно увімкнено)</div>


Якщо ви увімкнули функціональну можливість[`TopologyManager`](/docs/reference/command-line-tools-reference/feature-gates/#TopologyManager), то kubelet може використовувати підказки топології при прийнятті рішень щодо призначення ресурсів. Див. [Керування політиками топології на вузлі](/docs/tasks/administer-cluster/topology-manager/) для отримання додаткової інформації.

## Що далі

Дізнайтеся більше про наступне:

- [Компоненти](/docs/concepts/architecture/#node-components), з яких складається вузол.
- [Визначення API для вузла](/docs/reference/generated/kubernetes-api/v1.36/#node-v1-core).
- [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) у документі з дизайну архітектури.
- [Відповідне/невідповідне вимкнення вузлів](/docs/concepts/cluster-administration/node-shutdown/).
- [Автомасштабування вузла](/docs/concepts/cluster-administration/node-autoscaling/) для керування кількістю та розміром вузлів у вашому кластері.
- [Заплямованість та Толерантність](/docs/concepts/scheduling-eviction/taint-and-toleration/).
- [Менеджери ресурсів вузла](/docs/concepts/policy/node-resource-managers/).
- [Управління ресурсами для вузлів з операційною системою Windows](/docs/concepts/configuration/windows-resource-management/).