Kubernetes v1.35: Тека drop-in для конфігурації kubelet переходить до GA

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

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

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

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

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

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

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

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

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

Розглянемо кластер із декількома типами вузлів: стандартні обчислювальні вузли, вузли великої ємності (наприклад, з GPU або великим обсягом памʼяті) та 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-обчислення зазвичай мають меншу ємність)

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

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

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

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

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

Перегляд обʼєднаної конфігурації

Оскільки конфігурація тепер розподілена між декількома файлами, ви можете перевірити остаточну обʼєднану конфігурацію за допомогою точки доступу 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.

Приєднуйтесь

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

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

Змінено November 03, 2026 at 6:52 PM PST: [uk] Add blog posts ippr-goes-ga, kubelet-config-drop-in-directory-ga and ensure-secret-pulled-images (15146984ed)

Блог Kubernetes