Helm 3. Завершення життєвого циклу

Helm 3 наближається до завершення життєвого циклу. Останній обмежений функціональний реліз Helm 3 вийде 9 вересня 2026 року, а оновлення безпеки будуть надаватися до лютого 2027 року.

З успішним випуском Helm 4 у листопаді 2025 року, супровідники та спільнота тепер зосереджені на поліпшенні функціональності Helm 4. Якщо ви ще не почали тестувати Helm 4, саме зараз настав час це зробити.

Helm 4 пропонує низку покращень порівняно з Helm 3 (детально описаних нижче) і очікується, що він буде сумісний з більшістю існуючих Helm 3 chartів, релізів та робочих процесів.

Графік завершення життєвого циклу Helm 3

У оголошенні про випуск Helm 4 було викладено початковий графік підтримки Helm 3 після випуску Helm 4.0.0 у листопаді 2025 року. Однак розробники Helm вирішили випустити ще одну (обмежену) версію з новими функціями 9 вересня 2026 року та продовжити підтримку безпеки до 10 лютого 2027 року — на три місяці довше, ніж передбачалося спочатку.

Цикл розробки Helm 4 та графік підтримки Helm 3 спочатку були викладені в документі HIP-0012: Процес розробки Helm 4: Підтримка Helm 3.

Оновлений графік виглядає наступним чином:

• Виправлення помилок аж до останнього функціонального релізу, 9 вересня 2026 року.
• Останній функціональний реліз: 9 вересня 2026 року — це буде останній мінорний реліз Helm 3, обмежений оновленнями клієнтської бібліотеки Kubernetes для підтримки нових версій Kubernetes. Жодні інші нові функції не будут перенесені.
• Виправлення безпеки закінчаться 10 лютого 2027 року (розширено з листопада 2026 року).

Після лютого 2027 року Helm 3 більше не отримуватиме жодних оновлень: включаючи оновлення клієнтської бібліотеки Kubernetes та виправлення безпеки. Ми наполегливо рекомендуємо всім користувачам перейти на Helm 4 до цієї дати.

Чому Helm 4

Helm 3 добре служив спільноті Kubernetes понад шість років. За цей час проєкт накопичив технічний борг та зіткнувся з архітектурними обмеженнями, які не дозволяли впроваджувати нові функції без порушення публічних API SDK. Helm 4 вирішує цю проблему з кардинальними змінами, що дозволяє йому рухатися вперед, при цьому зберігаючи значну зворотну сумісність із більшістю наявних робочих процесів.

Для повних деталей дивіться HIP-0012: Процес розробки Helm 4.

Чарти, що розгортаються з Helm 3, мають бути придатними для розгортання з Helm 4. Так само, будь-який наявний чарт (реліз), керований Helm 3, загалом має бути оновлюваним за допомогою Helm 4.

Це означає, що ви можете оновити бінарний файл Helm без необхідності переписати свої чарти або повторно розгорнути свої релізи. Робочі процеси CLI також значною мірою зберігаються — для більшості користувачів зміни будуть мінімальними або взагалі не будуть потрібні.

Що нового в Helm 4

Ось огляд ключових змін. Для повних деталей дивіться Огляд Helm 4.

Нові функції

• Переробка системи втулків — опціональний рушій WebAssembly для втулків з підвищеною безпекою. Наявні втулки продовжують працювати. У Helm 4 поставляються три типи втулків: CLI, getter та post-renderer втулки, плюс розширювана система для нових типів втулків. Детальніше дивіться HIP-0026.
• Кращий моніторинг ресурсів — інтеграція kstatus забезпечує детальне відстеження статусу розгортання.
• Багатодокументні values — розділення values між декількома YAML файлами для конфігурацій, специфічних для середовища.
• Server-side apply — стандартно для нових релізів, з автоматичним перемиканням на client-side apply для оновлень наявних релізів Helm 3.
• Користувацькі шаблонні функції — розширення можливостей шаблонізації Helm через втулки.
• Стабільне SDK API — кардинальні зміни API завершені, що дозволяє розвиток Charts v3.

Кардальні зміни

• Post-renderers тепер є втулками — helm install --post-renderer тепер приймає назву втулка, а не шлях до виконуваного файлу. Оновіть будь-які наявні post-renderer робочі процеси.
• Логін в реєстрі обмежений доменом — helm registry login приймає лише доменні імена (не повні URL), що дозволяє майбутній per-scope логін.
• Перейменування CLI прапорців — --atomic тепер --rollback-on-failure, а --force тепер --force-replace. Старі прапорці все ще працюють, але видають попередження про застарівання.

Покращення

• Швидше визначення залежностей та кешування чартів на основі вмісту.
• Більш зрозумілі повідомлення про помилки.
• Покращена підтримка OAuth та токенів для приватних реєстрів.

Патч-реліз Helm 3 з виправленнями вразливостей

HIP-0012 спочатку передбачав виправлення вразливостей протягом одного року з моменту випуску Helm 4.0.0 — до листопада 2026 року. Розробники Helm продовжують цей термін на три місяці — до 10 лютого 2027 року, надаючи спільноті більше часу для завершення переходу на Helm 4.

Протягом цього періоду технічного обслуговування, присвяченого виключно безпеці:

• Жодних нових функцій не буде впроваджено в Helm 3, включаючи оновлення клієнтських бібліотек Kubernetes.
• Випускатимуться лише виправлення безпеки (за запитом / за необхідності).
• Виправлення помилок не застосовуватимуться.

Якщо до лютого 2027 року в Helm 3 буде виявлено вразливість безпеки, буде випущено виправлення. Після 10 лютого 2027 року жодних інших випусків Helm 3 будь-якого типу не буде.

Міграція на Helm 4

Процес оновлення розроблено таким чином, щоб він був простим. Щоб зробити процес міграції якомога простішим, можна скористатися такими кроками:

1. Перевірте свої чарти — розгорніть наявні чарти за допомогою Helm 4 у тестовому середовищі
2. Перевірте свої конвеєри CI/CD — оновіть усі скрипти, використовуючи перейменовані прапорці CLI (--atomic → --rollback-on-failure, --force → --force-replace)
3. Перевірте робочі процеси після рендерингу — перенесіть усі випадки використання --post-renderer до нової системи втулків
4. Перевірте автентифікацію в реєстрі — перевірте робочі процеси OCI за допомогою команди helm registry login, використовуючи лише доменні імена
5. Оновлення — Helm 4 може керувати наявними релізами Helm 3 без жодних кроків міграції
   • Зверніть увагу: Helm 4 зазвичай використовуватиме застосування на стороні сервера (server-side apply) під час встановлення нового релізу Chart. Під час оновлення (або відкату) Helm типово дотримуватиметься попереднього методу застосування релізу. Цю поведінку фіксації можна перевизначити, явно встановивши --server-side=false.

Для повного чек-листу оновлення дивіться розділ Оновлення до Helm 4 документації.

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

• GitHub Issues: helm/helm
• Kubernetes Slack: #helm-dev та #helm-users
• Щотижневі dev-наради: четвер о 9:30 PT на Zoom

Для деталей дивіться посібник спільноти щодо комунікації.