Локальні файли та шляхи, які використовує Kubelet
kubelet — це переважно процес без збереження стану, який працює на вузлі Kubernetes. У цьому документі описані файли, які kubelet читає та записує.
Примітка:
Цей документ має інформаційний характер і не описує жодної гарантованої поведінки або API. У ньому перелічено ресурси, що використовуються 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 для менеджера процесорів
- dra_manager_state для DRA
Файл контрольної точки для менеджера пристроїв
Менеджер пристроїв створює контрольні точки в тій самій теці, що й сокет-файли: /var/lib/kubelet/device-plugins/
. Назва файлу контрольної точки — kubelet_internal_checkpoint
для менеджера пристроїв.
Збереження стану Podʼів
Kubernetes v1.27 [alpha]
(стандартно увімкнено: false)Якщо ваш кластер має вертикальне масштабування Podʼа на місці увімкнено (функціональна можливість з назвою InPlacePodVerticalScaling
), тоді kubelet зберігає локальний запис про виділені Podʼу ресурси.
Імʼя файлу — pod_status_manager_state
у базовій теці kubelet (/var/lib/kubelet
стандартно в Linux; налаштовується за допомогою --root-dir
).
Середовище виконання контейнерів
Kubelet спілкується з середовищем виконання контейнерів за допомогою сокета, налаштованого через такі параметри конфігурації:
- containerRuntimeEndpoint для операцій із середовищем виконання
- imageServiceEndpoint для операцій з управління образами
Фактичні значення цих точок доступу залежать від середовища виконання контейнерів, яке використовується.
Втулки пристроїв
Kubelet відкриває сокет за шляхом /var/lib/kubelet/device-plugins/kubelet.sock
для різних втулків пристроїв, які реєструються.
Коли втулок пристрою реєструється, він надає шлях до свого сокета, щоб kubelet міг підʼєднатися.
Сокет втулка пристрою повинен знаходитися в теці device-plugins
у базовій теці kubelet. На типовому Linux-вузлі це означає /var/lib/kubelet/device-plugins
.
API ресурсів Podʼів
API ресурсів Podʼів буде доступний за шляхом /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
).
Профілі безпеки та конфігурація
Seccomp
Файли профілів seccomp, на які посилаються Podʼи, мають бути розміщені стандартно у /var/lib/kubelet/seccomp
. Дивіться довідку Seccomp для деталей.
AppArmor
Kubelet не завантажує і не звертається до профілів AppArmor за специфічним для Kubernetes шляхом. Профілі AppArmor завантажуються через операційну систему вузла, а не посилаються за їх шляхом.
Блокування
Kubernetes v1.2 [alpha]
Файл блокування для kubelet зазвичай знаходиться за адресою /var/run/kubelet.lock
. Kubelet використовує цей файл для того, щоб два різні екземпляри kubelet не намагалися працювати у конфлікті одна одної.
Ви можете налаштувати шлях до файлу блокування, використовуючи аргумент командного рядка kubelet --lock-file
.
Якщо два екземпляри kubelet на одному вузлі використовують різні значення для шляху до файлу блокування, вони не зможуть виявити конфлікт, коли обидва працюють одночасно.
Що далі
- Дізнайтеся більше про аргументи командного рядка kubelet.
- Ознайомтеся з довідником з налаштування Kubelet (v1beta1).