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

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

Графік завершення життєвого циклу 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.

Зміни, що порушують сумісність​

• Пострендери тепер є втулками — 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

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

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

Підсумок​

Колишній домен дзеркала APT Helm baltocdn.com було виведено з експлуатації у вересні 2025 року. Після виведення з експлуатації спроби доступу або завантаження пакунків Helm з baltocdn.com мали б завершитися невдачею через припинення роботи базової інфраструктури.

Пізніше термін реєстрації домену baltocdn.com закінчився, і домен був повторно зареєстрований третьою стороною 19 травня 2026 року. У результаті користувачі, системи або автоматизація, які досі намагаються завантажити пакунки Helm з baltocdn.com, можуть бути спрямовані на вміст, контрольований новим реєстрантом домену.

Наразі команда безпеки Helm отримала повідомлення від сторонніх організацій про те, що домен міг бути переорієнтований для розповсюдження шкідливого вмісту. Ми не підтвердили ці повідомлення самостійно. Проте оскільки домен більше не контролюється попереднім оператором репозиторію APT і більше не є кінцевою точкою розповсюдження Helm, будь-яке подальше використання baltocdn.com становить потенційну загрозу ланцюга постачання.

Користувачі, яких це стосується​

Ви можете бути під впливом, якщо будь-які системи на базі Debian або Ubuntu, репозиторії APT, завдання CI, образи контейнерів, сценарії встановлення, сценарії початкового завантаження, шаблони управління конфігурацією або внутрішня документація досі містять посилання на:

baltocdn.com

Будь-який користувач, який виконував двійкові файли, отримані з baltocdn.com, після 19 травня 2026 року, повинен вважати відповідну систему скомпрометованою та дотримуватися звичайних процедур реагування на інциденти.

Користувачі, які мають застарілі посилання на baltocdn.com, але не намагалися встановлювати або оновлювати Helm з цього домену після 19 травня 2026 року, все одно повинні негайно видалити ці посилання, дотримуючись наведених нижче кроків.

Виправлення​

Будь ласка, переконайтеся, що всі установки Helm на базі APT для Debian/Ubuntu використовують поточний репозиторій APT:

https://packages.buildkite.com/helm-linux/helm-debian

Перегляньте свої системи та репозиторії на наявність будь-яких залишкових посилань на baltocdn.com і замініть їх на поточні інструкції зі встановлення.

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

https://helm.sh/docs/intro/install/#from-apt-debianubuntu

Рекомендовані дії:

1. Видаліть будь-які записи джерел APT, які посилаються на baltocdn.com.
2. Оновіть конфігурацію встановлення Helm на базі APT для Debian/Ubuntu для використання packages.buildkite.com.
3. Перегляньте конвеєри CI/CD, Dockerfiles, сценарії початкового завантаження, управління конфігурацією та внутрішню документацію на наявність застарілих посилань.
4. Вважайте будь-яку систему, на якій було виконано двійкові файли, отримані з baltocdn.com, після 19 травня 2026 року, потенційно скомпрометованою.
5. Дотримуйтесь процесу реагування на інциденти вашої організації, якщо ви вважаєте, що система могла завантажити або виконати вміст із повторно зареєстрованого домену.
6. Заблокуйте доступ (корпоративний проксі/брандмауер тощо) до baltocdn.com. Оскільки сайт раніше було виведено з експлуатації та він більше не обслуговує вміст, пов'язаний із проектом Helm, обмеження доступу не порушить існуючих робочих процесів.

Про репозиторій APT Helm​

Репозиторій APT Helm для Debian/Ubuntu репозиторій (та його попередник baltocdn.com) підтримується спільнотою з вдячністю. Він не підтримується безпосередньо супровідниками Helm.

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

Взаємодія зі спільнотою Helm​

Проєкт Helm надає кілька способів взаємодії зі спільнотою, включаючи канали Slack та щотижневі зустрічі розробників. Члени команди безпеки Helm та супровідники присутні на цих форумах і разом із рештою спільноти можуть відповісти на запитання чи занепокоєння, пов'язані з проектом Helm.

Повідомлення про проблеми безпеки​

Для отримання додаткової інформації про повідомлення про проблеми безпеки, повʼязані з проєктом Helm, див. процес та політику безпеки Helm:

https://helm.sh/community/security/

Висновок​

baltocdn.com більше не є дзеркалом APT Helm і не повинен використовуватися для встановлення та керування Helm. Користувачі повинні перенести будь-які залишкові конфігурації встановлення Helm на базі APT для Debian/Ubuntu на packages.buildkite.com та переглянути свої середовища на наявність застарілих посилань на колишній домен, щоб зменшити потенційні загрози безпеці.

Що нового​

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

Деякі з нових функцій включають:

• Перероблена система втулків, що підтримує втулки на основі Web Assembly
• Пострендери тепер є втулками
• Тепер підтримується застосування на стороні сервера (server-side apply)
• Покращене відстеження ресурсів для підтримки очікування на основі kstatus
• Локальне кешування на основі вмісту (наприклад, для чартів)
• Логування через slog, що дозволяє інтегрувати логування SDK з сучасними логерами
• Відтворювані/ідемпотентні збірки архівів чартів
• Оновлений SDK API, включаючи підтримку кількох версій API чартів (нова експериментальна версія API чартів v3 з'явиться найближчим часом)

Детальніше про зміни можна дізнатися в Огляді Helm 4.

Підтримка Helm v3​

Коли виходить нова основна версія програмного забезпечення, потрібен час для переходу. Підтримка Helm v3 буде продовжуватися, щоб забезпечити плавний перехід. Дати продовженої підтримки такі:

• Виправлення помилок до 8 липня 2026 року.
• Виправлення безпеки до 11 листопада 2026 року.

Helm випускає оновлення по середах (зазвичай 2-а середа місяця), і ці дати відповідають датам випуску. Протягом цього часу НЕ будуть перенесені нові функції, окрім оновлень клієнтських бібліотек Kubernetes, які забезпечують підтримку нових версій Kubernetes.

Дізнатися більше​

Ви можете дізнатися про зміни в Helm у Огляді або знайти всі зміни в повному журналі змін. Документація містить набагато більше деталей, оскільки ви можете знайти всі способи, якими Helm залишався незмінним, та нові функції, якими ви можете скористатися.

Helm Booth in Project Pavilion​

Don't miss out on meeting our project maintainers at the Helm booth - we'll be hanging out the second half of each day. Drop by to ask questions, learn about what's in Helm 4, and pick up special Hazel swag celebrating Helm's 10th birthday!

• TUES Nov 11 @ 03:30 PM - 07:45 PM ET

• WED Nov 12 @ 02:00 PM - 05:00 PM ET

• THUR Nov 13 @ 12:30 PM - 02:00 PM ET

LOCATION: 8B, back side of Flux and across from Argo

Tuesday November 11, 2025​

Simplifying Advanced AI Model Serving on Kubernetes Using Helm Charts​

TIME: 12:00 PM - 12:30 PM ET

LOCATION: Building B | Level 4 | B401-402

SPEAKERS: Ajay Vohra & Caron Zhang

The AI model serving landscape on Kubernetes presents practitioners with an overwhelming array of technology choices: From inference servers like Ray Serve and Triton Inference Server, inference engines like vLLM, and orchestration platforms like Ray Cluster and KServe. While this diversity drives innovation, it also creates complexity. Teams often prematurely standardize on limited technology stacks to manage this complexity.

This talk introduces an innovative Helm-based approach that abstracts the complexity of AI model serving while preserving the flexibility to leverage the best tools for each use case. Our solution is accelerator agnostic, and provides a consistent YAML interface for deploying and experimenting with various serving technologies.

We'll demonstrate this approach through two concrete examples of multi-node, multi-accelerator model serving with auto scaling: 1/ Ray Serve + vLLM + Ray Cluster, and 2/ LeaderWorkerSet + Triton Inference Server + vLLM + Ray Cluster + HPA.

Wednesday November 12, 2025​

Maintainer Track: Introducing Helm 4​

TIME: 11:00 AM - 11:30 AM ET

LOCATION: Building C | Level 3 | Georgia Ballroom 1

SPEAKERS: Matt Farina & Robert Sirchia (Helm Maintainers)

The wait is over! After six years with Helm v3, Helm v4 is finally here. In this session you'll learn about Helm v4, why there was 6 years between major versions (from backwards compatible feature development to maintainer ups and downs), what's new in Helm v4, how long Helm v3 will still be supported, and what comes next. Could that include a Helm v5?

Contribfest: Hands-On With Helm 4: Wasm Plugins, OCI, and Resource Sequencing. Oh My!​

TIME: 02:15pm - 03:30 PM ET

LOCATION: Building B | Level 2 | B207

SPEAKERS: Andrew Block, Scott Rigby, & George Jenkins (Helm Maintainers)

Join Helm maintainers for an interactive session contributing to core Helm and building integrations with some of Helm 4's emerging features. We'll guide contributors through creating Helm 4's newest enhancements including WebAssembly plugins, enhancements to how OCI content is manged, and implementing resource sequencing for controlled deployment order. Attendees will explore how to build Download/Postrender/CLI plugins in WebAssembly, develop capabilities related to changes to Helm's management of OCI content including repository prefixes and aliases, and use approaches for sequencing chart deployments beyond Helm's traditional mechanisms.

This session is geared toward anyone interested in Helm development including leveraging and building upon some of the latest features associated with Helm 4!

Helm 4 Release Party​

TIME: 06:00 PM - 09:00 PM EST

LOCATION: Max Lager's Wood-Fired Grill & Brewery

Replicated and the CNCF are throwing a Helm 4 Release Party to celebrate the release of Helm 4! Drop by for a low country boil and hang out with the Helm project maintainers for the night! See the invitation here, and don't forget to save your spot – RSVP here.

Thursday November 13, 2025​

Mission Abort: Intercepting Dangerous Deletes Before Helm Hits Apply​

TIME: 01:45 PM - 02:15 PM ET

LOCATION: Building B | Level 5 | Thomas Murphy Ballroom 4

SPEAKERS: Payal Godhani

What if your next Helm deployment silently deletes a LoadBalancer, a Gateway, or an entire namespace? We’ve lived that nightmare—multiple times. In this talk, we’ll share how we turned painful Sev1 outages into a resilient, guardrail-first deployment strategy. By integrating Helm Diff and Argo CD Diff, we built a system that scans every deployment for destructive changes—like the removal of LoadBalancers, KGateways, Services, PVCs, or Namespaces—and blocks them unless explicitly approved. This second-layer approval acts as a safety circuit for your release pipelines. No guesswork. No blind deploys. Just real-time visibility into what’s about to break—before it actually does. Whether you’re managing a single cluster or an entire fleet, this talk will show you how to stop fearing Helm and start trusting it again. Because resilience isn’t about avoiding failure—it’s about learning, adapting, and building guardrails that protect everyone.

commit ecad6e2ef9523a0218864ec552bbfc724f0b9d3d
Author: Matt Butcher <mbutcher@engineyard.com>
Date:   Mon Oct 19 17:43:26 2015 -0600

    initial add

The first commit can be found on the helm-classic Git repository where the codebase for Helm v1 is located. This is the original Helm, before it merged with Deployment Manager and was folded into the Kubernetes project.

This commit was just the beginning. Helm would be shown off at the first KubeCon, just a few weeks later. From there Helm development would take off and a community of developers and charts would follow.

Happy 10th Birthday, Helm!

Альфа-період​

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

Якщо ви користуєтеся Helm, протягом цього періоду ви можете протестувати поточні можливості та надати відгук, якщо щось не працює як очікується. Просто памʼятайте, що це програмне забезпечення альфа-якості, і зміни все ще відбуваються.

Для користувачів Helm SDK зараз хороший час, щоб ознайомитися з API і перевірити, чи є якісь занепокоєння щодо змін у дизайні, а також чи вплинуть вони на вашу роботу.

Період Альфа триватиме протягом вересня.

Бета-період​

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

Тестувальники повинні повідомляти про помилки, коли вони стикаються з будь-якими проблемами.

Відповідно до політики випуску версій, після виходу першої бета-версії буде обрано та оголошено остаточну дату випуску версії 4.0.0.

Претенденти на випуск​

Наприкінці жовтня буде створено першого претендента на випуск. Він представляє те, що, на нашу думку, буде випущено як Helm v4. Якщо будуть виявлені якісь серйозні проблеми, їх буде виправлено і буде створено нового претендента на випуск.

🎉 Випуск 🎉​

Випуск заплановано на KubeCon + CloudNativeCon North America 2025 в середині листопада, що через 6 років після випуску Helm v3 і через 10 років після створення Helm. Більш детальну інформацію про випуск буде надано згодом.

Update your APT key and references to the repository using the new installation instructions.

Contribfest: Expanding the Helm Ecosystem With Helm 4​

DATE: Wednesday April 2

TIME: 16:15 - 17:30 BST

LOCATION: Level 3 | ICC Capital Suite 17

Are you passionate about Helm and looking for ways to contribute? Join Helm maintainers at this ContribFest session to help shape the future of the project and its ecosystem! This session focuses on three exciting initiatives:

• Exploring the Helm Ecosystem
• Building a Triage Team
• Diving into Helm 4

Don't miss this session with Scott, Robert, and Ingy for your chance at contributing to Helm 4 efforts! For more details on the Contribfest session, check the session page for the latest updates.

Helm Maintainer Track Talk: Helm 4 You​

DATE: Thursday April 3

TIME: 16:45 - 17:15 BST

LOCATION: Level 3 | ICC Capital Suite 10-12

Join Helm maintainers Matt Farina and Andrew Block as they provide an update on the next major version of Helm, the timelines, and the features being evaluated. They will also share how the community has been inspirational in helping make Helm 4 a reality. Since Helm continues to be a crucial component in the workflows of users and enterprises worldwide, a new version of Helm is only possible thanks to the continued collaboration from the Cloud Native community.

Full details on the talk can be found on the session page.

Helm Booth in Project Pavilion​

WED April 2 @ 15:30 – 19:45 BST

THUR April 3 @ 14:00 – 17:00 BST

FRI April 4 @ 12:30 – 14:00 BST

LOCATION: 2B, near the sticker wall + back side of Backstage

Our maintainers and contributors will be staffing the Helm project booth during the second half of each day. Let us know how you're using Helm, what questions you have, and learn more about what's coming in Helm 4. We'll have Helm stickers and custom Helm tea towels to help us all remember our time in the UK!

Helm Sessions from the Community​

Aside from sessions with our Helm maintainers, there are several talks from the cloud native ecosystem that touch on Helm – be sure to check these out as well ~

• Project Lightning Talk: Kubeflow Helm Chart - Krzysztof Romanowski, Maintainer // Tuesday April 1, 2025 @ 12:34 - 12:39 BST // Platinum Suite | Level 3
• Project Lightning Talk: Stir to Combine: Creating Porter Mixins - Sarah Christoff, Maintainer // Tuesday April 1, 2025 @ 16:07 - 16:12 BST // Platinum Suite | Level 3
• Poster Session: Helmless (PS 06): Fast Serverless Deployments Without the Overhead of Kubernetes and Terraform - Michael Reichenbach, 1KOMMA5° // Wednesday April 2, 2025 @ 13:30 - 14:30 BST // Level 1 | Hall Entrance N8-N9 | Poster Pavilion
• Jaeger V2: OpenTelemetry at the Core of Modern Distributed Tracing - Jonah Kowall, Paessler // Wednesday April 2, 2025 @ 17:00 - 17:30 BST // Level 3 | ICC Capital Suite 10-12
• Into the Shopfloor: Moving Manufacturing Execution Systems To Kubernetes - Manuel Peuster & Andrei Traian Cucuruzac, Bosch Connected Industry // Friday April 4, 2025 @ 11:45 - 12:15 BST // Level 1 | Hall Entrance N10 | Room E

See everyone this week!

Join maintainers and members of the Helm community at KubeCon + CloudNativeCon North America at the Demo Theater during the booth crawl on Wednesday November 13 at 7pm MST as we review the process involved to perform a release of the latest version of Helm so that it can be made available to the entire cloud native community. Along the way, you will learn about the associated activities, individuals, and processes involved with taking source code and transforming it into a consumable artifact for all across a myriad of supported runtimes and platforms.

Whether you are a Helm aficionado or just have an interest in release engineering, this is a session that you certainly want to circle on your agendas!

Not able to make it to KubeCon + CloudNativeCon North America? Don’t fret! The session will be recorded and made available at a later date.

This release session is just one of several Helm related events taking place at KubeCon + CloudNativeCon North America 2024. A full overview can be found here.

Helm буде присутній на KubeCon / CloudNativeCon North America в Солт-Лейк-Сіті. Щодня під час основної частини конференції відбуватимуться різні події, зокрема:

• Середа:
  • Присутність на стенді в павільйоні проєктів з 3:15pm до 8pm.
  • О 7pm MST ми плануємо наживо зробити реліз.
• Четвер:
  • Присутність на стенді в павільйоні проєктів з 1:45pm до 5pm.
  • Сесія: Contribfest: Helm 4: Наступне покоління менеджера пакунків для Kubernetes
  • Сесія: Шлях до Helm 4
• Пʼятниця:
  • З 12:30pm до 2:30pm у павільйоні проєктів

Якщо ви хочете поспілкуватися із супровідником, щоб дізнатися більше про Helm або залишити свої відгуки, павільйон проєктів — це ідеальне місце для цього. Якщо вас цікавить Helm v4, сесія "Шлях до Helm 4" надасть огляд. А якщо ви хочете зробити свій перший внесок у Helm, сесія Contribfest стане гарним стартом.

Якщо ви будете в Солт-Лейк-Сіті, сподіваємось побачити вас там.

One year later, Helm 2 became unsupported.

Here we are, over 3 years since Helm 2 became unsupported. It would be expected that all users should be migrated to Helm 3 by this time. Following consensus among the Helm org maintainers, we are announcing today the official end of support for the helm-2to3 tool.

In practice, this means that Helm 2to3 will receive no more updates (not even security patches).

We strongly discourage the use of the helm-2to3 tool moving forward, as it will be receiving no future security updates or patches. We hope that it has been a useful tool to aid in the migration from Helm 2 to 3.

Один із головних принципів проєкту Helm — суворо дотримуватися політики зворотної сумісності. Саме завдяки цьому підходу, що обмежує вплив змін на кінцевих користувачів, Helm став стабільним проєктом, на який може покластися спільнота. На жаль, політика зворотної сумісності обмежує типи змін і функцій, які можна запроваджувати. Важливо памʼятати, що Helm — це не лише інструмент командного рядка, а й SDK. SDK Helm підтримує цілу екосистему рішень для керування вмістом Helm. Будь-яка несумісна зміна може негативно вплинути на одну з цих інтеграцій.

Попри суворі обмеження на зміни, від випуску Helm 3 у 2019 році проєкт поступово додавав нові можливості. Першою такою функцією, що зʼявилася у Helm 3.1.0, став пострендеринг: він дає змогу користувачам змінювати згенеровані маніфести перед їхнім встановленням або оновленням за допомогою Helm. Додавання етапу пострендерингу до життєвого циклу релізу Helm стало важливою зміною і для користувачів, і для супровідників чартів. Користувачам більше не потрібно виправляти чарти, створювати їхні форки чи вручну рендерити шаблони локально, щоб внести власні зміни. Завдяки цьому супровідникам чартів більше не потрібно надмірно ускладнювати чарти, намагаючись охопити всі можливі сценарії. Відтоді мінорні версії Helm із новими функціями виходять щокварталу й надають користувачам дедалі більше можливостей.

Ще однією важливою новою функцією Helm 3 стала підтримка реєстрів OCI як способу поширення чартів. Підтримка цієї експериментальної функції зʼявилася у Helm 3.0.0, а повноцінною вона стала у версії 3.8.0. Користувачі CLI та SDK отримали змогу зберігати чарти тим самим перевіреним способом, що й образи контейнерів. Оскільки чарти в реєстрах контейнерів відповідають стандартам OCI, користувачі Helm і супровідники чартів також можуть використовувати для роботи з ними багато інструментів для образів контейнерів, які постійно вдосконалюються. Helm допоміг стандартизувати ширшу екосистему Cloud Native: це був один із перших проєктів, що використав OCI для зберігання, і він сприяв популяризації артефактів OCI в інших проєктах. Повний перелік нових функцій Helm можна знайти в примітках до випуску кожної мінорної версії в репозиторії.

Успіх Helm частково повʼязаний з архітектурними змінами, запровадженими у Helm 3. Серверний компонент Tiller, який обмежував використання Helm у багатокористувацьких середовищах і середовищах із підвищеними вимогами до безпеки, залишився в минулому. Також було внесено безліч інших удосконалень, які відрізняють Helm 3 від попередніх версій.

Маркус Лемоніс сказав: «Якщо не розвиватися — загинеш». Це особливо справедливо для технологічної галузі, де щодня зʼявляються нові інструменти, підходи й архітектури. Від випуску Helm 3 минуло пʼять років, і завдяки відгукам спільноти стало зрозуміло: проєкту потрібні суттєвіші зміни, щоб Helm і надалі залишався ефективним менеджером пакунків для Kubernetes. Тож спільнота Helm із радістю оголошує про початок роботи над шляхом до Helm 4.

ContribFest про Helm 4 на KubeCon EU 2024​

Часто запитують: «Чи популярний Helm?» Відгуки учасників таких заходів, як KubeCon, де сесії про проєкт збирають повні зали, дають однозначну відповідь: «Так!» Перші кроки до збору відгуків спільноти відкритого коду про наступну версію Helm відбулися на KubeCon EU 2024 у Парижі. Це сталося під час сесії ContribFest під назвою «Building the Helm 4 Highway». Очевидно, що спільнота зацікавлена в розвитку можливостей проєкту Helm. Сесія зібрала повний зал, а учасники запропонували чимало цікавих ідей: додати підтримку мов шаблонів, крім Go, розширити використання втулків і посилити підтримку безпечного ланцюга постачання програмного забезпечення, зокрема додати інші способи підписання чартів. Повний перелік ідей і тем сесії ContribFest доступний тут.

Як долучитися​

Якщо ви хочете взяти участь у створенні наступної версії Helm — будемо раді бачити вас! Ось кілька способів долучитися:

1. Приєднуйтеся до щотижневих зустрічей щодо плану розвитку Helm 4, які відбуваються щопʼятниці о 19:00 UTC. Учасники спільноти діляться ідеями, розробляють рішення та співпрацюють над наступною версією Helm.
   1. Зустріч у Zoom
2. Беріть участь в обговореннях у каналі #helm-dev у Kubernetes Slack. Там учасники спільноти Helm співпрацюють над розвитком Helm, зокрема над версією 4.
3. Створіть тікет у репозиторії Helm на GitHub.
4. Стежте за @HelmPack у Twitter/X, щоб дізнаватися новини про проєкт.

Helm допоміг визначити, як пакувати програмне забезпечення для Kubernetes і керувати ним. Але на цьому не зупиняймося: вдосконалюючи Helm 4 і додаючи до нього нові функції та можливості, ми й надалі створюватимемо інструмент, яким спільнота зможе впевнено користуватися для пошуку, поширення та запуску програмного забезпечення в Kubernetes.

Not A Vulnerability In Helm​

The Helm project rejects this disclosure’s assertion of a vulnerability within Helm.

The advisory listing on GitHub lists the categorization as CWE-200, which is for “Exposure of Sensitive Information to an Unauthorized Actor”. The documentation for this CWE notes that its use is discouraged due to frequent misuse. The description aligns with the implementation within Helm in this situation.

The --dry-run flag, when used with helm install and helm upgrade, is designed to send all of the generated chart manifests to standard out that would normally be sent to the Kubernetes API. This is useful for multiple use cases, such as debugging the development of a chart (i.e. package). These manifests are generated from the chart logic. Kubernetes Secrets have been designed by the Kubernetes project to be manifests, like any other resource. When generating manifests, including Secrets, there are times they need to be debugged in order to ensure the generated structure is correct.

This functionality, used in many situations including local development environments, is not an issue. The output is not exposed to an unauthorized actor. In fact, the output is needed. If this functionality is used in an environment that captures the output for unauthorized actors, such as in a CI system, then the vulnerability is in the use of a tool that outputs this information, rather than in the tool itself.

Consider a simple alternative situation. There is a Kubernetes manifest file containing both secret and non-secret information. kubectl, the Kubernetes CLI, is used in an attempt to apply the manifest to a cluster and the attempt fails. So, the cat utility is used to display the contents of the file containing the Secret. Is it the vulnerability in cat for displaying the information or in the CI setup for using cat to display secret information? The vulnerability is in the use of the tool rather than the tool itself.

Helm Changes​

To provide greater clarity, the Helm maintainers have made two changes.

1. Documentation has been updated to make the possible exposure of secret information explicit.
2. A flag has been added, which will be available in the next minor release, that will hide secret information in the dry-run output of these commands.

Why A Delay In Response​

When the CVE listing was released and the Helm maintainers became aware, the team went to work evaluating the potential impacts.

The Helm project takes security seriously. Some examples of this include:

• A documented security policy that enables someone to contact the security team with encrypted communications.
• Two 3rd party security audits (on versions of Helm that contained this functionality).
• A fuzzing audit and continuous fuzzing has been set up.
• Documented security assurance case, which is an OpenSSF best practices requirement on the way to a silver level.
• Helm releases are signed by the maintainer who produced the release.

Normally, a discussion about a security issue would stay internal to the Helm project. But, this listing was public and contentious. Helm maintainers contacted security professionals from multiple organizations and sought feedback on the situation prior to publicly commenting or performing any remediation work.

Please Responsibly Contact The Helm Security Team​

The Helm security team is responsive. In this calendar year, there have been releases to address two CVEs responsibly reported. You can learn more about reporting security issues in the documented process and participate, when necessary, to keep the Helm project and community secure.

Dry-run & Template Can Connect To Servers​

The dry-run feature on install and upgrade, and Helm template has not been able to communicate with Kubernetes servers. This is for security and because Helm template was designed for template rendering alone.

With Helm 3.13, there is now an opt-in option to communicate with Kubernetes by setting --dry-run=server. This tells Helm to communicate with the server for gathering information but not to perform updates. This flag also works on helm template. If you use --dry-run without setting a value it works as it did before.

Helm SDK users will find a new property, named DryRunOption, that allows you to tell the SDK to communicate with the server.

Values Handling Improvements​

Values handling has had a number of bugs filed about it. For example, importing values was inconsistent. Some of the handling even depended on ordering. Using null to remove properties was inconsistent, too. It worked in some cases but not others. That's fixed in Helm 3.13.

The order you can expect for a value to be used is:

1. User specified values (e.g CLI)
2. Imported values from dependencies
3. Parent chart values
4. Sub-chart values

JSON Indexes​

Helm repositories have an index in YAML containing details about the charts and versions of charts it contains. When this file grows large it can be expensive (e.g., processing time and memory) to parse. This is in part because YAML has anchors and aliases which are handy but cause more work to deal with.

Those index.yaml files can now contain JSON instead of YAML. Helm will generate them when the --json flag is set. The index.yaml file is used so the same file location can continue to be used for backwards compatibility. The structure for the data is the same. Helm going all the way back to 3.0.0 can handle parsing index.yaml files with JSON instead of YAML.

Tests were run on very large indexes to look at the perform difference. The results found that:

• Helm 3 versions before 3.13:
  • Parsed JSON in ~80% the time of parsing YAML
  • Used ~93% the memory parsing JSON compared to YAML
• Helm 3.13+, with special case handling to detect and handle JSON:
  • Parsed JSON in ~13% the time of parsing YAML
  • Used ~5% the memory parsing JSON compared to YAML

Get Metadata Command​

helm get provides the ability to get information about a release in a cluster. It has been able to get values, notes, hooks, and the generated manifests. In addition to those it can now get information about the metadata of the chart the release is based on.

To illustrate this, I installed WordPress and retrieved the metadata:

$ helm get metadata wp
NAME: wp
CHART: wordpress
VERSION: 17.1.13
APP_VERSION: 6.3.1
NAMESPACE: default
REVISION: 1
STATUS: deployed
DEPLOYED_AT: 2023-09-28T16:28:30-04:00

And More...​

These are just some of the highlights. Helm 3.13 includes even more features. You can read the details in the release notes.

OCI Artifacts​

Even though the majority of content stored within OCI registries are container images, additional content types can also be stored. The Open Container Initiative (OCI) defines these other assets as “Artifacts” and the ability to make use of OCI registries to store arbitrary content types has fundamentally changed how content is distributed. Instead of requiring a separate repository management tool for each type of asset, the very same registry that is already present to house container images can be reused without requiring additional software or infrastructure resources. This not only simplifies operational concerns from a hosting perspective, but provides a more uniform method of distributing content.

Helm has taken full advantage of the benefits of storing charts as OCI artifacts as it not only eliminates the complexity of managing a traditional chart repository, but simplifies the amount of resources that need to be maintained. When using a chart repository as a distribution and hosting solution, multiple assets need to be maintained:

• The packaged chart
• An optional provenance file
• A repository index file

Producing a Helm chart that is stored as an OCI artifact results in an asset with all of the necessary content packaged as a single atomic unit. The structure of the OCI artifact consists of the following three (3) key resources:

• An OCI Image Config containing the contents of the Chart.yaml file
• The packaged chart within an Image Layer
• The provenance file (when included) as an Image Layer

The composition of an OCI Helm Chart and the relationship of each of the aforementioned resources can be seen by inspecting the associated OCI Image Manifest. An example is displayed below:

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.cncf.helm.config.v1+json",
    "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111",
    "size": 117
  },
  "layers": [
    {
      "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip",
      "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617",
      "size": 2487
    },
    {
      "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov",
      "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a",
      "size": 643
    }
  ]
}

This cross-section illustrates not only the components of an OCI based Helm Chart, but OCI based content in general. Each resource, whether it be a layer or a Config Manifest contain the same sets of properties within the Image Manifest.

• Size – Content size
• Digest – Content addressable reference signifying the algorithm and hash used
• Media Type – Media Type of the referenced content

The Media Type property is arguably the most significant property given the purpose of this discussion. Now that we see where they are referenced within OCI Artifacts, let’s review Media Types in further detail.

Media Types and Their Significance​

Media Types, previously known as MIME (Multipurpose Internet Mail Extensions) Types have been around since the early days of the World Wide Web era as they identify file formats and content transmitted through the internet. Their structure consists of two concise sections separated by a slash (/): types and subtypes. Only a limited number of types are defined (10 in total) as they represent a broad use of the type itself. Subtypes are much more diverse and they are organized into a tree structure to enable a hierarchy of related types.

A common Media Type that anyone who has experience with RESTful based communication is familiar with is application/json as it is used to indicate that the content being transmitted is in JSON format. By indicating a Media Type whenever content is being transferred, the format and its representation is understood by both producers and consumers.

The OCI Image Specification contains several Media Types that represent the various structural elements of an image. These include:

• application/vnd.oci.image.index.v1+json - Index Image
• application/vnd.oci.image.manifest.v1+json - Image Manifest
• application/vnd.oci.image.layer.v1.tar+gzip - gzip compressed Layer

These provide a concrete example to aid in understanding the structural composition of a Media Type. Each of these fall within the application type as they are utilized by specific applications. The subtree here can be broken down into the following components:

• vnd - The vendor tree which are associated with specific products
• oci - The organization or company responsible
• image - A short name for the type
• index/manifest/layer - an optional subcomponent of the type
• v1 - enables the versioning of the schema
• json/tar+gzip - Optional format signifier

A more detailed description of the composition of a Media Type can be found here.

Helm Media Types​

The Helm community has worked with the IANA to register three new Media Types representing each of the components comprising an OCI based Helm Chart.

• application/vnd.cncf.helm.config.v1+json
• application/vnd.cncf.helm.chart.content.v1.tar+gzip
• application/vnd.cncf.helm.chart.provenance.v1.prov

Similar to the OCI Media Types shown in the prior section, the Helm Media Types are also located within the vendor tree and use the abbreviation for the Cloud Native Computing Foundation (cncf) as the responsible organization. The remainder of the Media Type subtree is fairly self explanatory as it provides additional distinction to the type of content itself and the format. Anyone inspecting a resource within an OCI registry representing a Helm chart would be able to easily identify it as a Helm chart and understand how to interact with the content.

For those interested in learning more about the Helm Media Types, including the low level technical details, can view the registration details within IANA which provides a wealth of information including the intended use and lower level data specification.

Helm is certainly not alone in the use of OCI artifacts as a distribution method. Other prominent technologies, including Web Assembly (WASM) and Software Bill of Materials (SBOM’s), also leverage OCI artifacts. It is safe to say that we will see the continued adoption of OCI artifacts as a method of storing content by more and more projects and technologies moving forward.

The Future for Helm’s OCI Media Types​

As anyone who has worked in software development, especially with regards to large, complex projects, can relate to the amount of time it takes for features to be implemented. Work surrounding OCI integration was originally introduced back in Helm version 3.5 and how OCI artifacts in general are stored and managed have evolved since that time. The OCI version 1.1 image specification provides not only additional structure, but guidance on how to manage OCI artifacts. As this specification is not only finalized, but adopted and implemented by registry providers, we will continue to see an increased adoption of the technology. The Helm project and community will continue to evolve with the rest of the industry so that Chart producers and consumers have not only the best experience possible, but can best leverage the available technology.

Helm is described as the Kubernetes package manager. It helps simplify finding, sharing, and using software built for Kubernetes. Helm began as what is now known as Helm Classic, a Deis project begun in 2015 and introduced at the inaugural KubeCon. In January of 2016, the project merged with a GCS tool called Kubernetes Deployment Manager, and the project was moved under Kubernetes. Helm was promoted from a Kubernetes subproject to a full-fledged CNCF project in June 2018. Helm graduated as a CNCF project in April 2020. The CNCF annual survey of 2022 found that around 90% of companies are either using or evaluating Kubernetes, and Helm’s performance and security are important, for the continued business operations of these users.

What is fuzzing?​

Fuzzing is a technique for testing software for bugs and vulnerabilities by passing it pseudo-random data. The key idea is to write a fuzzing harness similar to a unit — or integration — test that will execute the application under test with some arbitrary input. The fuzzing engine that will run the fuzzing harness uses mutational algorithms to generate new inputs - also called "testcases" - that will cause the code under test to execute uniquely, i.e., generate inputs that trigger new code execution paths. The goal is then to observe if the code under test misbehaves in the event of any of the generated inputs. Fuzzing has been effective in uncovering reliability bugs and vulnerabilities in software for more than two decades, and open source software is increasingly adopting the technique.

Helm fuzzing overview​

In this engagement, the goal was to write a set of fuzzers that would cover a lot of the Helm codebase and integrate the setup into the open source fuzzing service OSS-Fuzz. OSS-Fuzz is a free service offered by Google for critical open source projects to run their fuzzers continuously and report any crashes. Continuous analysis is important due to fuzzing relying on genetic algorithms, which effectively means the fuzzers will improve over time, and OSS-Fuzz will run the fuzzers daily indefinitely. In addition to this, continuous analysis is crucial for capturing any regressions.

Helm is written in the Go programming language, making it safe from memory-corruptions. Fuzzing Go will find panics such as slice/index out of range, nil-pointer dereferences, invalid type assertions, timeouts, and out of memory. At the end of this engagement, nine issues were found, all but one of which were fixed. Refer to the report for a detailed breakdown of the issues.

At the end of this engagement, the fuzzers provide significant coverage of the Helm project, including critical parts such as chart handling, release storage, and repositories. To write these fuzzers, Ada Logics used go-fuzz-headers to deterministically create pseudo-random structs from the data provided by libFuzzer.

Closing thoughts​

The Helm team is thankful to CNCF for providing the opportunity to work with Ada Logics to develop new fuzzers for Helm. The CNCF takes security seriously, and it previously funded two third-party security audits for the Helm project, source code for the Helm client along with the process Helm uses to handle security and source code for the Helm client along with a threat model for the use of Helm. We want to thank the following Helm maintainers who participated in this endeavour and provided fixes where required: Matt Butcher, Martin Hickey, Matt Farina and Scott Rigby. We would also like to mention and thank the Flux maintainers, especially Paulo Gomes for collaborating on an issue. The fuzzing findings and fixes are valuable add-ons to the previous conclusions of the security audits. The Helm project has efficient test suites, and code changes are backed by tests, but the newly developed fuzzers and findings have provided significant value to the project. During the fuzzing, only nine issues were found, which revalidated the high quality of the Helm code. The Helm team can now maintain the newly developed fuzzers and build on them to continue code quality and security.

Cheers to yxxhero!

Helm Maintainer Track Talk: Learn about Helm and Its Ecosystem​

DATE: Thursday October 27

TIME: 11:00am - 11:35am EDT

LOCATION: Room 410 A

Maintainers Matt Farina, Karena Angell, Scott Rigby, & Andrew Block will be doing a Maintainer Track talk introducing Helm itself and then doing a deep dive into the ecosystem around building packages, along with using Helm packages in clusters.

Helm Booth in Project Pavilion​

WED OCT 26: 15:30 – 20:00 ET

THUR OCT 27: 14:00 – 17:30 ET

FRI Oct 28: 13:00 – 16:00 ET

LOCATION: opposite side of the Fuzz booth, near the LitmusChaos/Flux/Cortex/Falco booths

Our maintainers will be hanging out at our Helm project booth the second half of each day. We'd love to learn from the community how Helm is being used, what pain points exists, and what users are looking for in the future. Help us help you by sharing your thoughts in our Helm User Survey, even if you're unable to drop by the booth.

Now for the fun part – the Helm booth will be giving away 3D Helm stickers, glow-in-the-dark Helm stickers, Helm bike bells, or limited edition Helm + Carhartt beanies to stay warm while in Detroit!

With that, we'll see the Helm community soon in-person!

Why Helm Doesn't Have Tools To Do This​

You might wonder, why doesn't Helm provide tools to do this out of the box?

Helm is a package manager. We often compare it to package managers for other platforms like apt, yum, zipper, homebrew, and others. All of these projects, Helm included, keep their scope within the realm of package management.

Managing how instances of packages are run in an environment is a separate concern and one people have varying ideas about. For example, some people use Ansible, others use Terraform, some use both, and some use something entirely different. Different tools can even use different methods (e.g. some are push based and others pull based). All of these are able work with the same package managers.

The Helm project strives to provide a package manager that works well with various other tools that can use a variety of different methods to manage releases.

Declarative and Imperative​

In the Kubernetes space we talk about declarative management. If you're not familiar with the concept, here is a brief explanation.

With declarative management you declare to the system what you want the end state to look like. For example, that you want X number of instances of your workload to be running. The system then works to make this a reality and usually reports status on the progress of making the declared status a reality. Over time, the way the system makes the declared state a reality can change without the need for what you declare or the status of the progress to change.

Imperative management has to do with telling the system what to do step by step. Instead of declaring what you want you tell the system each step to take to achieve the end goal.

Kubernetes provides a means to do both declarative and imperative management of resources. As the Kubernetes community tends to prefer declarative management, when possible, the rest of this post is going to focus on declarative tools you can use with Helm.

Tools​

The Kubernetes ecosystem has produced numerous projects of various styles to help you declaratively manage your Helm releases. To illustrate the options we will look at sister projects to Helm in the Cloud Native Computing Foundation (CNCF) and some more general open source projects. You can find more options in the CNCF Landscape.

CNCF Projects​

The scope of this section is limited to graduated and incubating CNCF projects. There are over 100 CNCF projects and many of them are sandbox projects. You can learn more about the differences between types of projects in the maturity level explanation. The following projects are worth looking at:

• Flux Helm Controller - Flux is a collection of projects that enable GitOps. One of the components provides a GitOps method to manage Helm releases. Flux natively supports Helm.
• Argo CD - The Argo project defines itself as providing "Open source tools for Kubernetes to run workflows, manage clusters, and do GitOps right." Argo CD is focused on declarative continuous delivery and has the ability to work with Helm charts.

Other Projects​

There are many projects beyond the CNCF projects you can use to help you manage your Helm releases. The following set is an example and not exhaustive.

• Helmfile - A declarative spec for deploying Helm charts.
• Captain - A Helm controller.
• Terraform Helm provider - Enables you to manage Helm charts through Terraform.
• Orkestra - Built on other tools in this list, Orkestra adds a robust dependency graph for a related group of Helm releases and their subcharts, as well as a reverse DAG for specifying dependency requirements for rollbacks.
• Fleet - A GitOps tool chain that works with Kubernetes manifests, Helm charts, and Kustomize.

High-Level Tool Comparison​

There are some differences between the tools we've looked at so far. The following table provides some insight into their differences. This is not exhaustive and you should evaluate any tools you use yourself.

Note, this comparison is from when the blog post was published. Projects change over time and the feature set may change over time. You should evaluate the projects in their current state before choosing one.

Conclusion​

If you want to use a configuration manager with your Helm and Kubernetes configuration there are many choices. While the Helm project doesn't endorse one project over another, we do suggest using a configuration manager when it's appropriate.

Over the past several years container registry developers have been working on ways to store other artifacts in container registries. To facilitate this in a cross platform manner, the Open Containers Initiative (OCI) - the organization that defines the specifications for containers - released their distribution specification which allowed other "artifacts" to be stored in registries.

Common Storage​

Since OCI artifacts now makes it possible to store more than container images, you can store charts, images, and other artifacts in a single OCI registry. Sharing a common storage standard that's not specific to Helm allows greater interoperability between tools from the wider container ecosystem for security, identity and access management, and more.

Working With Charts In Registries​

The combination of OCI artifact support in a registry and new functionality within Helm provides the capability to pull and push charts to and from a registry. You can also specify charts stored in OCI as a dependency in any Chart.yaml file. The following example illustrates logging into a registry and pushing a chart:

$ helm create demo
Creating demo

$ helm package demo
Successfully packaged chart and saved it to: /tmp/demo-0.1.0.tgz

$ echo "mypass" | helm registry login r.example.com -u myuser --password-stdin
Login Succeeded

$ helm push demo-0.1.0.tgz oci://r.example.com/myuser
Pushed: r.example.com/myuser/demo:0.1.0
Digest: sha256:7ed393daf1ffc94803c08ffcbecb798fa58e786bebffbab02da5458f68d0ecb0

More detail on working with registries can be found in the Helm documentation.

The Helm SDK​

The Helm SDK, which is useful for those building tools to integrate with Helm, also includes support to work with registries programmatically. The following example illustrates pushing a chart to a registry:

package main

import (
	"fmt"
	"io/ioutil"

	"helm.sh/helm/v3/pkg/registry"
)

func check(err error) {
	if err != nil {
		panic(err)
	}
}

func main() {
	client, err := registry.NewClient()
	check(err)

	b, err := ioutil.ReadFile("demo-0.1.0.tgz")
	check(err)

	info, err := client.Push(b, "r.example.com/myuser/demo:0.1.0")
	check(err)

	fmt.Printf("Pushed: %s\n", info.Ref)
	fmt.Printf("Digest: %s\n", info.Manifest.Digest)
}

More detail can be found in the documentation for the registry package.

Limitations​

There are some limitations when using registries to store charts compared to Helm repositories or storing container images in registries.

Helm repositores can be added and searched from the local Helm client. This is similar to how repositories work with other package managers such as zypper or apt. When working with OCI registries, this is not an option. OCI based registries don't provide standard APIs to facilitate searching.

While the OCI specification provides support for artifacts, not all registries support storing Helm charts or other artifacts that are not container images. Before choosing a registry, you should confirm whether it supports storing Helm charts.

Artifact Hub Support​

Artifact Hub, another CNCF project, provides a means to search and discover cloud native assets, including charts. Helm charts stored in OCI based registries can be listed on Artifact Hub, which already knows how to work with them. More details on working with Artifact Hub and Helm charts in container registries can be found in their documentation.

ORAS​

The OCI Registry as Storage (ORAS) project, another CNCF project, is used by Helm as the underlying library for working with registries. The ORAS project bills itself as:

Registries are evolving as generic artifact stores. To enable this goal, the ORAS project provides a way to push and pull OCI Artifacts to and from OCI Registries.

If you want to work with other artifacts in registries the ORAS project may provide some tools to help you.

Thanks and Help Us Keep Improving​

Thanks to everyone who worked on adding support for Helm charts and OCI registries, from the initial experiment to bringing this to a full feature. Thanks especially for end user testing, bug reports and feature requests, and coordination between community members and maintainers across several CNCF projects.

We hope this post helps give a good intro, and some things to consider when evaluating storing your Helm charts in OCI. See if it fits your needs, take it for a spin, and let us know what you think!