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

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

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

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

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

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

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

Конфігураційні файли 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ʼів

Якщо ваш кластер має вертикальне масштабування 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 завантажуються через операційну систему вузла, а не посилаються за їх шляхом.

Блокування

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

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

Що далі

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