kubelet — це переважно процес без збереження стану, який працює на вузлі Kubernetes. У цьому документі описані файли, які kubelet читає та записує.
Зазвичай kubelet використовує панель управління як джерело істини про те, що повинно запускатися на вузлі, і середовище виконання контейнерів для отримання поточного стану контейнерів. Якщо ви надаєте kubelet kubeconfig (конфігурацію клієнта API), kubelet підключається до вашої панелі управління; інакше вузол працює в автономному режимі.
На Linux-вузлах kubelet також читає cgroups та різні системні файли для збору метрик.
На Windows-вузлах kubelet збирає метрики іншим механізмом, що не спирається на шляхи.
Є також кілька інших файлів, які використовуються kubelet, оскільки kubelet спілкується за допомогою локальних сокетів Unix-домену. Деякі з них — це сокети, на яких слухає kubelet, а інші — сокети, які kubelet виявляє та підключається до них як клієнт.
C:\ замість / (якщо не вказано інше). Наприклад, /var/lib/kubelet/device-plugins відповідає шляху C:\var\lib\kubelet\device-plugins.Шлях до конфігураційного файлу kubelet можна налаштувати за допомогою аргументу командного рядка --config. Kubelet також підтримує доповнювані конфігураційні файли для розширення налаштувань.
Сертифікати та приватні ключі зазвичай розташовані в /var/lib/kubelet/pki, але цей шлях можна налаштувати за допомогою аргументу командного рядка kubelet --cert-dir. Імена файлів сертифікатів також можна налаштувати.
Маніфести для статичних Podʼів зазвичай розташовані в /etc/kubernetes/manifests. Місце розташування можна налаштувати за допомогою опції конфігурації kubelet staticPodPath.
Коли kubelet працює як юніт systemd, деякі налаштування kubelet можуть бути визначені у файлі налаштувань юніта systemd. Зазвичай це включає:
Усі менеджери ресурсів зберігають відповідність між Podʼами та виділеними ресурсами у файлах стану. Ці файли розташовані в базовій теці kubelet, також відомій як root directory (але це не те саме, що /, коренева тека вузла). Ви можете налаштувати базову теку для kubelet за допомогою аргументу командного рядка --root-dir.
Назви файлів:
memory_manager_state для менеджера памʼятіcpu_manager_state для менеджера CPUdra_manager_state для DRAМенеджер пристроїв створює контрольні точки в тій самій теці, що й сокет-файли: /var/lib/kubelet/device-plugins/. Цей шлях задано жорстко і він не є відносним до кореневої теки kubelet. Назва файлу контрольної точки — kubelet_internal_checkpoint для менеджера пристроїв.
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ʼів буде доступний за шляхом pod-resources у базовій теці kubelet (root directory). На типовому Linux-вузлі це означає /var/lib/kubelet/pod-resources.
Kubelet шукає сокет-файли, створені втулками пристроїв, керованими через DRA, менеджер пристроїв або втулки зберігання, а потім намагається приєднатись до цих сокетів. Текою, у якій kubelet шукає, є plugins_registry у базовій теці kubelet, тобто на типовому Linux-вузлі це — /var/lib/kubelet/plugins_registry.
Зверніть увагу, що для втулків пристроїв є два альтернативні механізми реєстрації. Тільки один із них повинен використовуватися для певного втулка.
Типи втулків, які можуть розміщувати сокет-файли в цій теці:
(зазвичай /var/lib/kubelet/plugins_registry).
Коректне вимкнення вузла зберігає стан локально за адресою /var/lib/kubelet/graceful_node_shutdown_state.
Kubelet зберігає записи про спроби та успішні отримання образів і використовує їх для перевірки того, що образ вже було успішно отримано з тими самими обліковими даними.
Ці записи кешуються у вигляді файлів у теці image_registry у базовій теці kubelet. На типовому вузлі Linux це означає /var/lib/kubelet/image_manager. У image_manager є дві вкладені теки:
pulling — зберігає записи про образи, які Kubelet намагається отримати.pulled — зберігає записи про образи, які було успішно отримано Kubelet, разом з метаданими про облікові дані, які було використано для отримання.Докладні відомості наведено у розділі Перевірка облікових даних при отриманні образів.
Файли профілів seccomp, на які посилаються Podʼи, мають бути розміщені у /var/lib/kubelet/seccomp. Дивіться довідку Seccomp для деталей.
Kubelet не завантажує і не звертається до профілів AppArmor за специфічним для Kubernetes шляхом. Профілі AppArmor завантажуються через операційну систему вузла, а не посилаються за їх шляхом.
Файл блокування для kubelet зазвичай знаходиться за адресою /var/run/kubelet.lock. Kubelet використовує цей файл для того, щоб два різні екземпляри kubelet не намагалися працювати, конфліктуючи один з одним.
Ви можете налаштувати шлях до файлу блокування, використовуючи аргумент командного рядка kubelet --lock-file.
Якщо два екземпляри kubelet на одному вузлі використовують різні значення для шляху до файлу блокування, вони не зможуть виявити конфлікт, коли обидва працюють одночасно.