# Стан вузла

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

---

<!-- overview -->

Стан [вузла](/docs/concepts/architecture/nodes/) у Kubernetes є критичним аспектом управління кластером Kubernetes. У цій статті ми розглянемо основи моніторингу та підтримки стану вузлів, щоб забезпечити справний та стабільний кластер.

## Поля стану вузла {#node-status-fields}

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

* [Адреси](#addresses)
* [Стани](#condition)
* [Місткість та Доступність](#capacity)
* [Інформація](#info)
* [Оголошені Функції](#declaredfeatures)

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

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

Кожен розділ вихідних даних описано нижче.

## Адреси {#addresses}

Використання цих полів варіюється залежно від вашого постачальника хмарних послуг або конфігурації на голому залізі.

* HostName: Імʼя хосту, яке повідомляється ядром вузла. Може бути перевизначене за допомогою параметра kubelet `--hostname-override`.
* ExternalIP: Як правило, це IP-адреса вузла, яка доступна ззовні кластера.
* InternalIP: Як правило, це IP-адреса вузла, яка доступна лише всередині кластера.

## Стани {#condition}

Поле `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>, якщо вузол справний та готовий приймати Podʼи, <code>False</code>, якщо вузол не справний і не приймає Podʼи, та <code>Unknown</code>, якщо контролер вузла не отримав інформацію від вузла протягом останнього <code>node-monitor-grace-period</code> (стандартно 50 секунд)</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>Якщо ви використовуєте командний рядок для перегляду деталей вузла з вимкненим плануванням (cordoned Node), стан включає <code>SchedulingDisabled</code>. <code>SchedulingDisabled</code> не є станом в API Kubernetes; замість цього вузли з вимкненим плануванням позначені як Unschedulable в їхній специфікації.</div>


В API Kubernetes стан вузла представлений як частина `.status` ресурсу Node. Наприклад, наступна структура 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"
  }
]
```

Коли на вузлах виникають проблеми, панель управління Kubernetes автоматично створює [taints](/docs/concepts/scheduling-eviction/taint-and-toleration/), які відповідають станам, що впливають на вузол. Прикладом цього є ситуація, коли `status` стану Ready залишається `Unknown` або `False` довше, ніж налаштований інтервал NodeMonitorGracePeriod у kube-controller-manager, який стандартно становить 50 секунд. Це спричинить додавання на вузол taint `node.kubernetes.io/unreachable` для статусу `Unknown` або taint `node.kubernetes.io/not-ready` для статусу `False`.

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

Дивіться [Виселення на основі taint](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) та [Taint вузлів за станами](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition) для отримання додаткової інформації.

## Місткість та Доступність {#capacity}

Описує ресурси, доступні на вузлі: процесор, памʼять та максимальну кількість Podʼів, які можуть бути заплановані на вузлі.

Поля у блоці місткості вказують на загальну кількість ресурсів, які має вузол. Блок доступності вказує на кількість ресурсів на вузлі, які доступні для використання звичайними подами.

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

## Інформація {#info}

Описує загальну інформацію про вузол, таку як версія ядра, версія Kubernetes (kubelet і kube-proxy), деталі контейнерного середовища та яка операційна система використовується на вузлі. Kubelet збирає цю інформацію з вузла та публікує її в API Kubernetes.

## Оголошені Функції {#declaredfeatures}








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


У цьому полі перелічено конкретні функції Kubernetes, які наразі ввімкнено в kubelet вузла за допомогою [функціональних можливостей](/docs/reference/command-line-tools-reference/feature-gates/). Функції повідомляються kubelet у вигляді списку рядків у полі `.status.declaredFeatures` обʼєкта Node.

Це поле призначене для нових функцій, що знаходяться в стадії активної розробки; функції, які пройшли випробування і більше не потребують функціональної можливості, вважаються базовими і не зазначаються в цьому полі. Це стосується увімкнення функцій Kubernetes, а не можливостей операційної системи або ядра вузла.

Детальніше див. [Функції, оголошені вузлом](/docs/concepts/scheduling-eviction/node-declared-features/).

## Пульс {#heartbeats}

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

Для вузлів існує дві форми пульсу:

* оновлення `.status` вузла
* обʼєкти [Lease](/docs/concepts/architecture/leases/) у <a class='glossary-tooltip' title='Абстракція, що використовується в Kubernetes для ізоляції груп ресурсів в межах одного кластера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/namespaces' target='_blank' aria-label='просторі імен'>просторі імен</a> `kube-node-lease`. Кожен вузол має повʼязаний обʼєкт Lease.

Порівняно з оновленнями `.status` вузла, Lease є легким ресурсом. Використання Lease для пульсу знижує вплив цих оновлень на продуктивність для великих кластерів.

Kubelet відповідає за створення та оновлення `.status` вузлів, а також за оновлення їх повʼязаних Lease.

* Kubelet оновлює `.status` вузла або коли стан змінюється, або якщо не було оновлень протягом налаштованого інтервалу. Стандартний інтервал для оновлень `.status` вузлів становить 5 хвилин, що значно довше, ніж типових 40 секунд для вузлів, що стали недоступними.
* Kubelet створює та оновлює свій обʼєкт Lease кожні 10 секунд (стандартний інтервал оновлення). Оновлення Lease відбуваються незалежно від оновлень `.status` вузла. Якщо оновлення Lease не вдається, Kubelet повторює спробу, використовуючи експоненціальне збільшення інтервалу з початкового 200 мілісекунд до максимально 7 секунд.