Kubernetes v1.35: Конфігурація Kubelet Drop-in Directory переходить до GA

Автор Sohan Kunkerkar (Red Hat) | Перекладач(і) Андрій Головін | 22.12.2025

З останнім випуском Kubernetes v1.35 стала загальнодоступною підтримка теки для конфігураційних файлів kubelet. Нова стабільна функція спрощує управління конфігурацією kubelet у великих гетерогенних кластерах.

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

Проблема: управління конфігурацією kubelet у великому масштабі

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

Дрейф конфігурації: різні вузли можуть мати дещо різні конфігурації, що призводить до несумісної поведінки
Налаштування групи вузлів: вузли GPU, edge вузли та стандартні обчислювальні вузли часто вимагають різних налаштувань kubelet
Операційні накладні витрати: підтримка окремих, повних файлів конфігурації для кожного типу вузла є схильною до помилок і складною для аудиту
Управління змінами: впровадження змін конфігурації в гетерогенних пулах вузлів вимагає ретельної координації

До того, як ця підтримка була додана до Kubernetes, адміністратори кластерів мали вибирати між використанням єдиного монолітного файлу конфігурації для всіх вузлів, ручним веденням декількох повних файлів конфігурації або використанням окремих інструментів. Кожен підхід мав свої недоліки. Перехід до стабільної версії надає адміністраторам кластерів повну підтримку fourth way to solve that challenge.

Приклади використання

Управління гетерогенними пулами вузлів

Розглянемо кластер із декількома типами вузлів: стандартні обчислювальні вузли, вузли з високою продуктивністю (наприклад, із графічними процесорами або великим обʼємом памʼяті) та edge вузли зі спеціальними вимогами.

Базова конфігурація

Файл: 00-base.conf

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
  - "10.96.0.10"
clusterDomain: cluster.local

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

Файл: 50-high-capacity-nodes.conf

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
maxPods: 50
systemReserved:
  memory: "4Gi"
  cpu: "1000m"

Перевизначення для edge вузлів

Файл: 50-edge-nodes.conf (edge compute typically has lower capacity)

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "5%"

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

Поступове впровадження конфігурації

Під час впровадження змін у конфігурації ви можете:

Додати новий файл із високим числовим префіксом (наприклад, 99-new-feature.conf)
Протестувати зміни на підмножині вузлів
Поступово впроваджувати зміни на інших вузлах
Після стабілізації обʼєднати зміни в базову конфігурацію

Viewing the merged configuration

Оскільки конфігурація тепер розподілена між декількома файлами, ви можете перевірити остаточну обʼєднану конфігурацію за допомогою точки доступу kubelet /configz:

# Запустіть kubectl proxy
kubectl proxy

# В іншому терміналі завантажте обʼєднану конфігурацію
# Змініть замісник “<node-name>” перед запуском команди curl
curl -X GET http://127.0.0.1:8001/api/v1/nodes/<node-name>/proxy/configz | jq .

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

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

Подяки

Ця функція була розроблена спільними зусиллями SIG Node. Особлива подяка всім учасникам, які допомогли розробити, впровадити, протестувати та задокументувати цю функцію на всіх етапах її розвитку: від альфа-версії в v1.28, бета-версії в v1.30 до загальної доступності в v1.35.

Щоб надати відгук про цю функцію, приєднайтеся до Kubernetes Node Special Interest Group, беріть участь в обговореннях в публічному каналі Slack (#sig-node) або подайте заявку на GitHub.

Приєднуйтесь {#get involved}

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

SIG Node буде радий дізнатися про ваш досвід використання цієї функції у виробництві!

Блог