The post has been translated automatically. Original language: Russian
The Helm team has released two versions in a row: On September 9, 2026, Helm 4.3.0 was released, followed by Helm 3.22.0 on September 10. These are functional releases, and the distribution of content between them is significant: almost all noticeable changes went to the fourth branch, whereas 3.22.0 consists mainly of dependency updates, including upgrading the k8s—io package group to version 0.37.0 and closing vulnerabilities in Go libraries. There is unexpectedly a lot of useful information in the new release for those who are rolling applications in Kubernetes charts.
Deleting a release began to verify the ownership of resources
The main change from the point of view of operation: before deleting resources, when removing a release, Helm now checks that the resource really belongs to this release. Previously, a scenario with an intersection of names — when an object in a cluster matched the name and type described in the chart, but was created manually or by another release — could result in the deletion of someone else's object. Now such a check is performed explicitly.
There are several more changes in release management nearby. The rollback command received a flag to indicate the reason: the description is saved in the release history, and then you can see why the version was rolled back. The template engine learned how to write to the debug log when the resource search function in the cluster returned an empty result, a typical case when the template is silently deployed with empty values and it is not noticeable in any way. The templates now have functions for working with durations. The regression was adjusted separately: the registry messages in the template rendering and chart display commands go back to the error stream instead of the standard output.
Waiting time and cluster status management
Two edits hit the command execution time directly. Resource status calculations are now running in parallel. In the release notes, this is described as eliminating delays measured in minutes. Plus, the re-synchronization period of the informer has been reduced from one hour to three minutes. On large releases with dozens of objects, the wait for readiness ceases to be unpredictably long.
Reproducibility of chart builds and minor but evil bugs
Support for an environment variable setting a fixed build date has been added to the chart packaging, and timestamps in the archive are normalized to UTC with truncation; at the same time, a test for reproducibility of the dependency lock file has been added. The result is that the same input gives a byte—by-byte identical archive, which is important for verifying signatures and caching in delivery pipelines.
Of the spot fixes, two stand out. The loader stopped losing files of values whose length falls exactly on the 4096 byte boundary, a rare but completely unnoticeable defect in the diagnosis. And the chart provenance verification mechanism has learned how to work with modern GnuPG keyboxes in the keybox format, not just with old ring files.
What does this mean in practice?
Checking ownership during deletion is the edit for which it is worth planning an update, especially if objects that were not created through Helm live in the cluster. But it's worth checking it at the stand in advance: if you have historically had resources "adopted" by a release without the correct labels and annotations of the owner, removing the release may now leave them in the cluster instead of deleting them. This is not a breakdown, but a change in behavior, and the garbage after removal will have to be cleaned by hand.
The second point is that reducing the refresh period to three minutes means more frequent access to the API server. On large installations with a large number of simultaneous operations, it is worth looking at the load of the API server after the update.
And about planning: the next patches, 4.3.1 and 3.22.1, are scheduled for October 14, 2026, minor version 4.4.0 for January 13, 2027. At the same time, there will be no more new minor releases of the third branch, it only receives patches. If migration to the fourth branch is not yet in the plans, it's time to put it there: all the new functionality is now available only there.
The draft text was prepared with the participation of AI, the facts were checked against the original source — the official notes for the release of Helm 4.3.0 on GitHub.
Команда Helm выпустила две версии подряд: 9 сентября 2026 года вышел Helm 4.3.0, а следом, 10 сентября, — Helm 3.22.0. Это функциональные релизы, и распределение содержимого между ними показательно: почти все заметные изменения ушли в четвёртую ветку, тогда как 3.22.0 состоит в основном из обновлений зависимостей, включая подъём группы пакетов k8s-io до версии 0.37.0 и закрытие уязвимостей в библиотеках Go. Полезного для тех, кто катит приложения в Kubernetes чартами, в новом выпуске неожиданно много.
Удаление релиза стало проверять принадлежность ресурсов
Главное изменение с точки зрения эксплуатации: перед удалением ресурсов при снятии релиза Helm теперь проверяет, что ресурс действительно принадлежит этому релизу. Раньше сценарий с пересечением имён — когда объект в кластере совпал по имени и типу с тем, что описан в чарте, но создан вручную или другим релизом — мог закончиться удалением чужого объекта. Теперь такая проверка выполняется явно.
Рядом легло ещё несколько изменений в управлении релизами. Команда отката получила флаг для указания причины: описание сохраняется в истории релиза, и по ней потом видно, почему версию откатили. Шаблонизатор научился писать в отладочный журнал, когда функция поиска ресурсов в кластере вернула пустой результат, — типовой случай, когда шаблон молча разворачивается с пустыми значениями и это никак не заметно. В шаблонах появились функции для работы с длительностями. Отдельно поправили регрессию: сообщения реестра в командах рендеринга шаблона и показа чарта снова уходят в поток ошибок, а не в стандартный вывод.
Скорость ожидания и работа с состоянием кластера
Две правки бьют прямо по времени выполнения команд. Вычисление статуса ресурсов теперь идёт параллельно — в заметках к выпуску это описано как устранение задержек, измерявшихся минутами. Плюс период повторной синхронизации информера снижен с одного часа до трёх минут. На больших релизах с десятками объектов ожидание готовности перестаёт быть непредсказуемо долгим.
Воспроизводимость сборки чартов и мелкие, но злые баги
В упаковку чартов добавили поддержку переменной окружения, задающей фиксированную дату сборки, а временные метки в архиве нормализуются к UTC с усечением; заодно появился тест на воспроизводимость файла блокировки зависимостей. Итог — одинаковый вход даёт побайтово одинаковый архив, что важно для проверки подписей и кеширования в конвейерах доставки.
Из точечных исправлений выделяются два. Загрузчик перестал терять файлы значений, длина которых попадает ровно на границу в 4096 байт, — редкий, но абсолютно незаметный при диагностике дефект. И механизм проверки происхождения чартов научился работать с современными связками ключей GnuPG в формате keybox, а не только со старыми файлами колец.
Что это значит на практике
Проверка принадлежности при удалении — та правка, ради которой стоит запланировать обновление, особенно если в кластере живут объекты, созданные не через Helm. Но её же стоит заранее проверить на стенде: если у вас исторически были ресурсы, «усыновлённые» релизом без корректных меток и аннотаций владельца, снятие релиза теперь может оставить их в кластере вместо удаления. Это не поломка, а изменение поведения, и мусор после удаления придётся подчищать руками.
Второй момент — сокращение периода ресинка до трёх минут означает более частые обращения к API-серверу. На крупных инсталляциях с большим числом одновременных операций стоит посмотреть на нагрузку API-сервера после обновления.
И про планирование: следующие патчи, 4.3.1 и 3.22.1, намечены на 14 октября 2026 года, минорная версия 4.4.0 — на 13 января 2027 года. При этом новых минорных выпусков третьей ветки больше не будет, она получает только патчи. Если миграция на четвёртую ветку ещё не в планах, её пора туда поставить: весь свежий функционал теперь выходит только там.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальные заметки к выпуску Helm 4.3.0 на GitHub.
Share
