Це багатосторінковий друкований вигляд цього розділу. Натисність щоб друкувати.

Повернутися до звичайного перегляду сторінки.

Довідкова інформація про вузли

1: Стандартні атрибути пристроїв для динамічного виділення ресурсів
2: Локальні файли та шляхи, які використовує Kubelet
3: Версії API Kubelet Device Manager
4: Поведінка свопу на вузлах Linux
5:

У цьому розділі містяться такі довідкові теми про вузли:

Ви також можете ознайомитись з довідкою про вузли в інших розділах документації Kubernetes, зокрема:

1 - Стандартні атрибути пристроїв для динамічного виділення ресурсів

Kubernetes визначає набір стандартних атрибутів пристроїв у домені resource.kubernetes.io для використання з динамічним виділенням ресурсів (DRA). Ці атрибути мають чітко визначену семантику, тому обмеження matchAttribute працюють для пристроїв з різних драйверів DRA без необхідності знань, специфічних для драйвера.

Драйверам DRA рекомендується публікувати ці атрибути, коли це доречно. Допоміжна бібліотека DRA Kubernetes (k8s.io/dynamic-resource-allocation/deviceattribute) надає функції, які драйвери можуть викликати для отримання правильних значень з sysfs.

Стандартні атрибути

`resource.kubernetes.io/numaNode`

Визначає топологію NUMA пристрою. Цей атрибут може бути:

Скалярним цілим числом: фізичний вузол NUMA пристрою, зчитаний із запису numa_node у sysfs ядра. Ця форма працює без жодної функціональної можливості.
Списком цілих чисел (потребує функціональної можливості DRAListTypeAttributes): фізичний вузол NUMA, за яким ідуть вузли NUMA того самого сокета на мінімальній відстані ACPI SLIT. Наприклад, у системі AMD EPYC з 4 вузлами NUMA на сокет, пристрій на вузлі NUMA 5 може публікувати [5, 4, 6, 7], щоб вказати, що вузли NUMA 4, 6 та 7 знаходяться на тому самому сокеті та рівновіддалені.

Використовуйте matchAttribute разом із цим атрибутом, щоб розмістити пристрої з різних драйверів на одному NUMA-вузлі. При використанні значень типу списку планувальник виконує операцію перетину множин: два пристрої вважаються сумісними, якщо їхні списки NUMA-вузлів мають хоча б одне спільне значення.

Пристрої без спорідненості NUMA (numa_node = -1 у sysfs) не повинні публікувати цей атрибут.

Допоміжні функції для авторів драйверів DRA:

GetNUMANodeAttributeByPCIBusID(pciBusID, attrForm): для пристроїв PCI (GPU, NIC, контролерів NVMe). Зчитує numa_node з sysfs і, коли attrForm є ListAttribute, обчислює список на основі SLIT.
GetNUMANodeAttribute(numaNode, attrForm): для пристроїв, які вже знають свій вузол NUMA (CPU, памʼять).
GetNUMANodeForCPU(cpuID): повертає вузол NUMA для ядра CPU.

`resource.kubernetes.io/pciBusID`

Адреса шини PCI пристрою PCI у розширеній нотації BDF (Domain:Bus:Device.Function). Цей атрибут однозначно ідентифікує пристрій PCI на вузлі.

`resource.kubernetes.io/pcieRoot`

PCIe Root Complex пристрою PCI у форматі pci<domain>:<bus>. Пристрої, які спільно використовують той самий PCIe Root Complex, підключені до тієї самої ієрархії комутаторів PCIe. Використовуйте matchAttribute з цим атрибутом, щоб розміщувати пристрої під тим самим коренем PCIe для звʼязку з найменшою затримкою.

2 - Локальні файли та шляхи, які використовує Kubelet

kubelet — це переважно процес без збереження стану, який працює на вузлі Kubernetes. У цьому документі описані файли, які kubelet читає та записує.

Примітка:

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

Зазвичай kubelet використовує панель управління як джерело істини про те, що повинно запускатися на вузлі, і середовище виконання контейнерів для отримання поточного стану контейнерів. Якщо ви надаєте kubelet kubeconfig (конфігурацію клієнта API), kubelet підключається до вашої панелі управління; інакше вузол працює в автономному режимі.

На Linux-вузлах kubelet також читає cgroups та різні системні файли для збору метрик.

На Windows-вузлах kubelet збирає метрики іншим механізмом, що не спирається на шляхи.

Є також кілька інших файлів, які використовуються kubelet, оскільки kubelet спілкується за допомогою локальних сокетів Unix-домену. Деякі з них — це сокети, на яких слухає kubelet, а інші — сокети, які kubelet виявляє та підключається до них як клієнт.

Примітка:

Ця сторінка наводить шляхи у форматі Linux, які відповідають шляхам Windows із додаванням кореневого диска C:\ замість / (якщо не вказано інше). Наприклад, /var/lib/kubelet/device-plugins відповідає шляху C:\var\lib\kubelet\device-plugins.

Конфігурація

Конфігураційні файли kubelet

Шлях до конфігураційного файлу kubelet можна налаштувати за допомогою аргументу командного рядка --config. Kubelet також підтримує доповнювані конфігураційні файли для розширення налаштувань.

Сертифікати

Сертифікати та приватні ключі зазвичай розташовані в /var/lib/kubelet/pki, але цей шлях можна налаштувати за допомогою аргументу командного рядка kubelet --cert-dir. Імена файлів сертифікатів також можна налаштувати.

Маніфести

Маніфести для статичних Podʼів зазвичай розташовані в /etc/kubernetes/manifests. Місце розташування можна налаштувати за допомогою опції конфігурації kubelet staticPodPath.

Налаштування юнітів systemd

Коли kubelet працює як юніт systemd, деякі налаштування kubelet можуть бути визначені у файлі налаштувань юніта systemd. Зазвичай це включає:

аргументи командного рядка для запуску kubelet
змінні середовища, що використовуються kubelet або для налаштування середовища виконання golang

Стан

Файли контрольних точок для менеджерів ресурсів

Усі менеджери ресурсів зберігають відповідність між Podʼами та виділеними ресурсами у файлах стану. Ці файли розташовані в базовій теці kubelet, також відомій як root directory (але це не те саме, що /, коренева тека вузла). Ви можете налаштувати базову теку для kubelet за допомогою аргументу командного рядка --root-dir.

Назви файлів:

memory_manager_state для менеджера памʼяті
cpu_manager_state для менеджера CPU
dra_manager_state для DRA

Файл контрольної точки для менеджера пристроїв

Менеджер пристроїв створює контрольні точки в тій самій теці, що й сокет-файли: /var/lib/kubelet/device-plugins/. Цей шлях задано жорстко і він не є відносним до кореневої теки kubelet. Назва файлу контрольної точки — kubelet_internal_checkpoint для менеджера пристроїв.

Контрольні точки ресурсів Podʼів

СТАН ФУНКЦІОНАЛУ: GA since Kubernetes v1.35

More information about this feature

This is a stable feature in Kubernetes, and has been since version v1.35. It was first available in the v1.27 release. You can no longer disable or opt out of this feature or behavior (it is locked); if you explicitly set a value for the associated feature gate InPlacePodVerticalScaling, Kubernetes ignores it but does not report any error.

Якщо на вузлі увімкнено функціональну можливість InPlacePodVerticalScaling, kubelet зберігає локальний запис про виділені та активовані ресурси Podʼів. Докладніше про використання цих записів див. у статті Зміна розміру ресурсів CPU та памʼяті, призначених контейнерам.

Назви файлів:

allocated_pods_state записує ресурси, виділені для кожного Podʼа, запущеного на вузлі
actuated_pods_state записує ресурси, які були прийняті середовищем виконання для кожного Podʼа, запущеного на вузлі

Файли знаходяться у базовій теці kubelet (/var/lib/kubelet типово у Linux; налаштовується за допомогою --root-dir).

Середовище виконання контейнерів

Kubelet спілкується з середовищем виконання контейнерів за допомогою сокета, налаштованого через такі параметри конфігурації:

containerRuntimeEndpoint для операцій із середовищем виконання
imageServiceEndpoint для операцій з управління образами

Фактичні значення цих точок доступу залежать від середовища виконання контейнерів, яке використовується.

Втулки пристроїв

Kubelet відкриває сокет за шляхом /var/lib/kubelet/device-plugins/kubelet.sock для реєстрації різних втулків пристроїв.

Коли втулок пристрою реєструється, він надає шлях до свого сокета, щоб kubelet міг підʼєднатися.

Сокет втулка пристрою повинен знаходитися в теці /var/lib/kubelet/device-plugins/. Цей шлях задано жорстко і він не є відносним до базової теки kubelet (root directory). На Linux цей шлях завжди /var/lib/kubelet/device-plugins.

API ресурсів Podʼів

API ресурсів Podʼів буде доступний за шляхом pod-resources у базовій теці kubelet (root directory). На типовому Linux-вузлі це означає /var/lib/kubelet/pod-resources.

DRA, CSI та втулки пристроїв

Kubelet шукає сокет-файли, створені втулками пристроїв, керованими через DRA, менеджер пристроїв або втулки зберігання, а потім намагається приєднатись до цих сокетів. Текою, у якій kubelet шукає, є plugins_registry у базовій теці kubelet, тобто на типовому Linux-вузлі це — /var/lib/kubelet/plugins_registry.

Зверніть увагу, що для втулків пристроїв є два альтернативні механізми реєстрації. Тільки один із них повинен використовуватися для певного втулка.

Типи втулків, які можуть розміщувати сокет-файли в цій теці:

втулки CSI
втулки DRA
втулки менеджера пристроїв

(зазвичай /var/lib/kubelet/plugins_registry).

Коректне вимкнення вузла

СТАН ФУНКЦІОНАЛУ: Beta since Kubernetes v1.21; (стандартно увімкнено)

Коректне вимкнення вузла зберігає стан локально за адресою /var/lib/kubelet/graceful_node_shutdown_state.

Записи отримання образів

СТАН ФУНКЦІОНАЛУ: Beta since Kubernetes v1.35; (стандартно увімкнено)

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

Ці записи кешуються у вигляді файлів у теці image_registry у базовій теці kubelet. На типовому вузлі Linux це означає /var/lib/kubelet/image_manager. У image_manager є дві вкладені теки:

pulling — зберігає записи про образи, які Kubelet намагається отримати.
pulled — зберігає записи про образи, які було успішно отримано Kubelet, разом з метаданими про облікові дані, які було використано для отримання.

Докладні відомості наведено у розділі Перевірка облікових даних при отриманні образів.

Профілі безпеки та конфігурація

Seccomp

Файли профілів seccomp, на які посилаються Podʼи, мають бути розміщені у /var/lib/kubelet/seccomp. Дивіться довідку Seccomp для деталей.

AppArmor

Kubelet не завантажує і не звертається до профілів AppArmor за специфічним для Kubernetes шляхом. Профілі AppArmor завантажуються через операційну систему вузла, а не посилаються за їх шляхом.

Блокування

СТАН ФУНКЦІОНАЛУ: Alpha since Kubernetes v1.2

Файл блокування для kubelet зазвичай знаходиться за адресою /var/run/kubelet.lock. Kubelet використовує цей файл для того, щоб два різні екземпляри kubelet не намагалися працювати, конфліктуючи один з одним. Ви можете налаштувати шлях до файлу блокування, використовуючи аргумент командного рядка kubelet --lock-file.

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

Що далі

Дізнайтеся більше про аргументи командного рядка kubelet.
Ознайомтеся з довідником з налаштування Kubelet (v1beta1).

3 - Версії API Kubelet Device Manager

Ця сторінка надає інформацію про сумісність між API втулків пристроїв Kubernetes та різними версіями самого Kubernetes.

Матриця сумісності

	`v1alpha1`	`v1beta1`
Kubernetes 1.21	-	✓
Kubernetes 1.22	-	✓
Kubernetes 1.23	-	✓
Kubernetes 1.24	-	✓
Kubernetes 1.25	-	✓
Kubernetes 1.26	-	✓

Позначення:

✓ Точно ті самі можливості / обʼєкти API і в API втулків пристроїв, і у версії Kubernetes.
+ API втулків пристроїв має можливості або обʼєкти API, яких може не бути в кластері Kubernetes, або через те, що до API втулків пристроїв додано нові виклики API, або через те, що сервер видалив старий виклик API. Однак, все, що у них є спільного (більшість інших API), працюватиме. Зверніть увагу, що альфа-версії API можуть зникнути або значно змінитися між одним мінорним випуском і наступним.
- Кластер Kubernetes має можливості, які не може використовувати API втулків пристроїв, або через те, що сервер додав додаткові виклики API, або через те, що з API втулків пристроїв видалено старий виклик API. Однак, все, що у них є спільного (більшість API), працюватиме.

4 - Поведінка свопу на вузлах Linux

Щоб дозволити робочим навантаженням Kubernetes використовувати своп, на вузлі Linux необхідно вимкнути типову поведінку kubelet, за якої він завершується з помилкою, якщо виявлено своп, та вказати поведінку memory-swap як LimitedSwap:

Доступні варіанти поведінки свопу:

NoSwap: (типово) Робочі навантаження, що виконуються як Podʼи на цьому вузлі, не використовують і не можуть використовувати своп. Однак процеси поза межами Kubernetes, такі як системні демони (включаючи сам kubelet!), можуть використовувати своп. Така поведінка є корисною для захисту вузла від стрибків памʼяті на системному рівні, але вона не захищає самі робочі навантаження від таких стрибків.
LimitedSwap: Робочі навантаження Kubernetes можуть використовувати своп-памʼять. Обсяг свопу, доступний для Podʼа, визначається автоматично.

Щоб дізнатися більше, прочитайте керування своп-памʼяттю.

5 -

Стани життєвого циклу вузла

СТАН ФУНКЦІОНАЛУ: Alpha since Kubernetes v1.37; (стандартно вимкнено)

More information about this feature

To use this feature, you (or a cluster administrator) will need to enable the NodeLifecycleConditions feature gate for all relevant components in your cluster.

See Enable Or Disable Feature Gates for more information.

Стани життєвого циклу вузла повідомляють, чи проходить вузол через подію життєвого циклу, як-от drain, обслуговування або коректне вимкнення вузла (Graceful Node Shutdown). Вони дають спільний сигнал, який адміністратори кластера, контролери та сторонні інструменти можуть використовувати для керування життєвим циклом.

Доступні такі загальновідомі стани життєвого циклу:

Стани життєвого циклу вузла та їх значення.
Стан	Опис
`DrainInProgress`	Для вузла зараз виконується drain відповідно до обраних адміністратором критеріїв drain.
`Drained`	Вузол досяг обраних адміністратором критеріїв drain.
`MaintenancePlanned`	Очікується, що вузол зазнає змін у майбутньому. Якщо зміни впливають на робочі навантаження, виконайте drain вузла перед початком обслуговування.
`MaintenanceInProgress`	Вузол зараз проходить обслуговування. Обслуговування може включати розгортання апаратного або програмного забезпечення, усунення проблем, виведення з експлуатації або налагодження.
`GracefulNodeShutdownInProgress`	Визначено, що на вузлі триває коректне вимкнення вузла.

Поле status кожного стану життєвого циклу має таке значення:

True: стан життєвого циклу, про який повідомляє цей стан, зараз спостерігається.
False: стан життєвого циклу, про який повідомляє цей стан, зараз не спостерігається.
Unknown: той, хто записує стан, не може визначити, чи активний стан життєвого циклу.

Стани життєвого циклу — це спостереження, які дають корисний контекст щодо стану життєвого циклу вузла. Наприклад, використовуйте MaintenancePlanned, щоб повідомити, що вузол може перейти в обслуговування в майбутньому, або Drained, щоб повідомити, що обраних адміністратором критеріїв drain досягнуто.

Поле reason вказує, чому стан має свій поточний статус. Ті, хто записує стани, мають використовувати для reason стабільні значення у стилі CamelCase. Поле message може містити додаткові подробиці, зрозумілі людині.

Цей приклад повідомляє, що для вузла заплановано обслуговування:

status:
  conditions:
  - type: MaintenancePlanned
    status: "True"
    reason: MaintenanceWindow
    message: "Hardware maintenance is scheduled for this Node"
    lastTransitionTime: "2026-07-20T14:00:00Z"

Запис станів життєвого циклу

Адміністратор або контролер, уповноважений адміністратором, відповідає за встановлення та очищення станів життєвого циклу на вузлі.

Той, хто записує стан, визначає, коли стан життєвого циклу активний. Коли стан більше не активний, він встановлює для стану значення False або видаляє його.

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

Примітка:

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

Наявні механізми керування життєвим циклом і далі слід використовувати:

Використовуйте kubectl cordon або встановіть .spec.unschedulable, щоб запобігти звичайному плануванню на вузол.
Використовуйте kubectl drain, щоб безпечно виселити Podʼи перед виведенням вузла з експлуатації.
Використовуйте taints і tolerations, щоб керувати плануванням Podʼів і політикою виселення.

Перегляд станів життєвого циклу

Використовуйте kubectl describe node, щоб переглянути всі стани вузла:

kubectl describe node <node-name>

Щоб вивести тип і статус кожного стану, використовуйте:

kubectl get node <node-name> \
  -o jsonpath='{range .status.conditions[*]}{.type}={.status}{"\n"}{end}'