Helm, легендарний менеджер пакетів для Kubernetes, офіційно представив версію 4.0. Це перший великий апгрейд за останні шість років, і він припав якраз на десяту річницю проєкту під крилом Cloud Native Computing Foundation (CNCF).
Helm 4 покликаний розв’язати кілька болючих проблем, що накопичилися, зокрема щодо масштабованості, безпеки та робочого процесу. У цьому релізі видно, що Helm поступово виходить за межі звичайного рендерингу чартів і рухається в бік повноцінного інструмента для керування розгортаннями.
Виправлення старих обмежень і нові можливості
У версії Helm 4 команда прибрала частину рішень, які накопичилися ще з часів старих апдейтів. Розробка йшла за планом і була спрямована на те, щоб узгодити роботу Helm із сучасною поведінкою Kubernetes та зробити інструмент більш готовим до подальшого розвитку.
У фокусі цього релізу чотири основні напрями: глибша інтеграція з Kubernetes, оновлена система плагінів, покращення роботи з чардами та загальна оптимізація роботи інструмента.
Що саме змінилося в Helm 4?
Одне з найважливіших оновлень. Тепер Helm може застосовувати зміни так, як це робить сучасний Kubernetes — логіка перенесена на рівень API-сервера. Це означає:
- менше конфліктів при зміні ресурсів;
- більш передбачуване поводження під час деплою;
- кращу сумісність із GitOps-підходами.
Фактично Helm нарешті працює в одному ритмі з інструментами, які керують станом кластера.
Нова система плагінів на WebAssembly
Класичні плагіни не зникли, але тепер з’явилася альтернатива — WebAssembly. Це сильно спрощує створення розширень:
- один плагін працює на будь-якій платформі;
- немає потреби збирати окремі бінарники для різних ОС і процесорів;
- плагіни працюють ізольовано та передбачувано.
Для Helm це розв’язує давню проблему кросплатформності.
Оновлення для інтеграцій
Helm 4 також отримав низку змін, які роблять його зручнішим для команд, що вбудовують інструмент у свої системи:
- нова система логування на Go, яка дозволяє працювати з різними форматами логів;
- можливість інтегрувати команди Helm прямо у свої утиліти чи сервіси;
- підтримка інструментів для більш точного визначення стану ресурсів у кластері.
Покращення безпеки та автоматизації
Ще один важливий блок змін стосується надійності чартів:
- механізм підписання чартів став надійнішим;
- з’явилися кращі можливості для автоматизації тестування;
- запроваджено принцип відтворюваних збірок, що робить пакети прогнозованішими.
Продуктивність та нове кешування
Helm 4 отримав помітні оптимізації, які впливають на загальну продуктивність:
- поліпшене кешування, яке враховує вміст чарту, а не лише метадані;
- нові механізми контролю готовності ресурсів, що зменшують ризики конфліктів під час деплою складних систем.
Такі покращення найбільше оцінять команди, які часто деплоять великі сервіси або працюють із багатьма залежностями.
Що лишилося без змін?
Питання з підтримкою Custom Resource Definitions (CRD) залишається одним із найболючіших у Helm. Попри очікування, ситуація майже не змінилася. Пропозиції щодо оновлення CRD, злиття нових версій або безпечного rollback так і не увійшли до релізу.
Усе працює так само як і раніше:
- під час першої інсталяції Helm встановлює CRD з теки crds/;
- при оновленні чарту Helm не змінює і не видаляє CRD;
- якщо ти додаєш новий YAML у crds/, Helm просто пропустить його з попередженням, але не застосує.
Саме тому спільнота відреагувала доволі різко. Для команд, які активно використовують CRD у своїх процесах, це означає одне — доводиться тримати власні обхідні рішення й тулінг, бо Helm досі не бере на себе керування життєвим циклом.
Проте, попри це, Helm 4 все ще вважається значним етапом, що покращує довгострокову життєздатність проєкту. Розробники запевнили, що функції, які не були прийняті в 4 версії, можуть бути розглянуті в наступних релізах.
Спільнота буде уважно стежити за тим, коли оновлення стануть достатньо безпечними, стабільними та задокументованими для широкого впровадження.
До головної версії 4.0
Цікаво згадати й історію Helm. Спочатку проєкт називався «Kate’s Place» — жарт на тему «K8s» із кавовою стилістикою, де пакети жартома називали шотами. Він з’явився на хакатоні у 2015 році, за який команда навіть отримала подарункову картку на 75 доларів.
Метт Бутчер, один із засновників, раніше писав, що це був правильний інструмент у потрібний час, оскільки Kubernetes тільки набирав обертів. Проєкт швидко потрапив до CNCF і став одним із перших, хто досяг статусу Graduated Project.
- Helm 1 проіснував лише кілька місяців.
- Helm 2 — близько року.
- Helm 3 — три роки.
- Helm 4 з’явився після шести років розвитку третьої версії.
З роками акцент зміщується: реальна робота — це не перевизначення того, що таке управління пакетами, а те, які функції допоможуть виконувати роботу ефективніше.
Зміни, які можуть здатися нудними, як-от покращене логування, насправді мають величезний вплив. Воно не виграє нагород за найбільш модну функцію, але, безумовно, приносить дуже реальну користь у житті користувачів Helm. Такі фічі економлять DevOps-інженерам та сисадмінам купу часу та енергії.
Висновок
Helm 4 забезпечує довгострокову життєздатність проєкту. Він робить важливий крок до повної сумісності з сучасними робочими процесами DevOps та GitOps, роблячи деплой більш безпечним, швидким та портативним.
Які твої думки щодо Helm 4? Чи встиг ти вже протестувати нову підтримку Server-Side Apply або WebAssembly-плагіни?
