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

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

---

<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='Вузол — це робоча машина в Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/nodes/' target='_blank' aria-label='вузлі'>вузлі</a> Kubernetes. У цьому документі описані файли, які kubelet читає та записує.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Цей документ має інформаційний характер і не описує жодної гарантованої поведінки або API. У ньому перелічено ресурси, що використовуються kubelet, що є деталлю реалізації та може бути змінено у будь-якій версії.</div>


Зазвичай, kubelet використовує <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='Середовище виконання контейнера — це програмне забезпечення, яке відповідає за запуск та виконання контейнерів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/setup/production-environment/container-runtimes' target='_blank' aria-label='середовище виконання контейнерів'>середовище виконання контейнерів</a> для отримання поточного стану контейнерів. За наявності _kubeconfig_ (конфігурації клієнта API), kubelet підключається до панелі управління; інакше вузол працює в _автономному режимі_.

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

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

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


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Ця сторінка наводить шляхи у форматі Linux, які відповідають шляхам Windows із додаванням кореневого диска <code>C:\</code> замість <code>/</code> (якщо не вказано інше). Наприклад, <code>/var/lib/kubelet/device-plugins</code> відповідає шляху <code>C:\var\lib\kubelet\device-plugins</code>.</div>


## Конфігурація {#configuration}

### Конфігураційні файли kubelet {#kubelet-configuration-files}

Шлях до конфігураційного файлу kubelet можна налаштувати за допомогою командного аргументу `--config`. Kubelet також підтримує [доповнювані конфігураційні файли](/docs/tasks/administer-cluster/kubelet-config-file/#kubelet-conf-d) для розширення налаштувань.

### Сертифікати {#certificates}

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

### Маніфести {#manifests}

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

### Налаштування юнітів systemd {#systemd-unit-settings}

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

- командні аргументи для [запуску kubelet](/docs/reference/command-line-tools-reference/kubelet/)
- змінні середовища, що використовуються kubelet або для [налаштування середовища golang](https://pkg.go.dev/runtime#hdr-Environment_Variables)

## Стан {#state}

### Файли контрольних точок для менеджерів ресурсів {#resource-managers-state}

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

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

- `memory_manager_state` для [менеджера памʼяті](/docs/tasks/administer-cluster/memory-manager/)
- `cpu_manager_state` для [менеджера процесорів](/docs/tasks/administer-cluster/cpu-management-policies/)
- `dra_manager_state` для [DRA](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)

### Файл контрольної точки для менеджера пристроїв {#device-manager-state}

Менеджер пристроїв створює контрольні точки в тій самій теці, що й сокет-файли: `/var/lib/kubelet/device-plugins/`. Цей шлях задано жорстко і він не є відносним до кореневої теки kubelet. Назва файлу контрольної точки — `kubelet_internal_checkpoint` для [менеджера пристроїв](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager).

### Контрольні точки ресурсів Pod {#pod-resource-checkpoints}








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


Якщо на вузлі увімкнено [функціональну можливість](/docs/reference/command-line-tools-reference/feature-gates/)  `InPlacePodVerticalScaling`, kubelet зберігає локальний запис про _виділені_ та _активовані_ ресурси Pod. Докладніше про використання цих записів див. у статті [Зміна розміру ресурсів CPU та памʼяті, призначених контейнерам](/docs/tasks/configure-pod-container/resize-container-resources/).

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

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

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

### Середовище виконання контейнерів {#container-runtime}

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

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

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

### Втулки пристроїв {#device-plugins}

Kubelet відкриває сокет за шляхом `/var/lib/kubelet/device-plugins/kubelet.sock` для [реєстрації різних втулків пристроїв](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-implementation).

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

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

### API ресурсів Podʼів {#pod-resources-api}

[Pod Resources API](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources) буде доступний за шляхом `pod-resources` у базовій теці kubelet (root directory). На типовому Linux-вузлі це означає `/var/lib/kubelet/pod-resources`.

### DRA, CSI та втулки пристроїв {#dra-csi-and-device-plugins}

Kubelet шукає сокет-файли, створені втулками пристроїв, керованими через [DRA](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/), менеджер пристроїв або втулки зберігання, а потім намагається приєднатись до цих сокетів. Текою, у якій kubelet шукає, є `plugins_registry` у базовій теці kubelet, тобто на типовому Linux-вузлі це — `/var/lib/kubelet/plugins_registry`.

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

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

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

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

### Належне вимкнення вузлів {#graceful-node-shutdown}








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


[Належне вимкнення вузлів](/docs/concepts/cluster-administration/node-shutdown/#graceful-node-shutdown) зберігає стан локально за адресою `/var/lib/kubelet/graceful_node_shutdown_state`.

### Записи отримання образів {#image-pull-records}








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


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

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

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

Докладні відомості наведено у розділі [Перевірка облікових даних при отриманні образів](/docs/concepts/containers/images#ensureimagepullcredentialverification).

## Профілі безпеки та конфігурація {#security-profiles-configuration}

### Seccomp {#seccomp}

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

### AppArmor {#apparmor}

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

## Блокування {#locking}








  <div class="feature-state-notice feature-alpha">
      <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span>
      <code>Kubernetes v1.2 [alpha]</code>
    </div>
  



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

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

## Що далі

- Дізнайтеся більше про [аргументи командного рядка kubelet](/docs/reference/command-line-tools-reference/kubelet/).
- Ознайомтеся з [довідником з налаштування Kubelet (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/).