З останнім випуском Kubernetes v1.35 стала загальнодоступною підтримка теки для конфігураційних файлів kubelet. Нова стабільна функція спрощує управління конфігурацією kubelet у великих гетерогенних кластерах.
У версії 1.35 аргумент командного рядка kubelet --config-dir готовий до використання у промислових умовах і повністю підтримується, що дозволяє вказати теку, яка містить файли конфігурації kubelet. Усі файли в цій теці будуть автоматично обʼєднані з основною конфігурацією kubelet. Це дозволяє адміністраторам кластерів підтримувати єдину базову конфігурацію для kubelet, одночасно забезпечуючи цільові налаштування для різних груп вузлів або випадків використання, без складних інструментів або ручного управління конфігурацією.
У міру того, як кластери Kubernetes стають більшими та складнішими, вони часто включають гетерогенні пули вузлів з різними апаратними можливостями, вимогами до робочого навантаження та експлуатаційними обмеженнями. Ця різноманітність вимагає різних конфігурацій 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"
Файл: 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)Оскільки конфігурація тепер розподілена між декількома файлами, ви можете перевірити остаточну обʼєднану конфігурацію за допомогою точки доступу 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.
Детальні інструкції з налаштування, приклади конфігурації та поведінка злиття наведені в офіційній документації:
При використанні теки конфігурацій kubelet:
Тестуйте конфігурації поступово: завжди тестуйте нові конфігурації на підмножині вузлів, перш ніж розгортати їх у всьому кластері, щоб мінімізувати ризики.
Контролюйте версії своїх конфігурацій: зберігайте файли конфігурації (або джерело конфігурації, з якого вони генеруються) у системі контролю версій разом із вашою інфраструктурою як кодом, щоб відстежувати зміни та мати можливість легко повертатися до попередніх версій.
Використовуйте числові префікси для передбачуваного упорядкування: називайте файли за допомогою числових префіксів (наприклад, 00-, 50-, 90-) для явного контролю порядку злиття та забезпечення зрозумілості шарування конфігурації для інших адміністраторів
Звертайте увагу на тимчасові файли: деякі текстові редактори під час редагування автоматично створюють резервні файли (наприклад, .bak, .swp або файли з розширенням ~) у тій самій теці. Переконайтеся, що ці тимчасові або резервні файли не залишаються в теці конфігурації, оскільки вони можуть оброблятися kubelet.
Ця функція була розроблена спільними зусиллями SIG Node. Особлива подяка всім учасникам, які допомогли розробити, впровадити, протестувати та задокументувати цю функцію на всіх етапах її розвитку: від альфа-версії в v1.28, бета-версії в v1.30 до загальної доступності в v1.35.
Щоб надати відгук про цю функцію, приєднайтеся до Kubernetes Node Special Interest Group, беріть участь в обговореннях в публічному каналі Slack (#sig-node) або подайте заявку на GitHub.
Якщо у вас є відгуки чи запитання щодо управління конфігурацією kubelet або ви хочете поділитися своїм досвідом використання цієї функції, приєднуйтесь до обговорення:
SIG Node буде радий дізнатися про ваш досвід використання цієї функції у виробництві!