Helm 3のサポート終了（end of life）を解説

Helm 3のサポート終了（end of life）とは、HelmプロジェクトがHelm 3のリリースを一切出さなくなる日のことだ。セキュリティ修正も含まれる。その日は2027年2月10日だと、Helmプロジェクトのサポート終了告知は書いている。多くの解説はいまも、当初の計画にあった2026年11月を挙げている。スクリプトやパイプラインでHelm 3を使うチームには、Helm 4へ移るまで約3か月が残っている。

HelmはKubernetes向けのパッケージマネージャーだ。Kubernetesは、多数のサーバーでコンテナを動かす仕組みである。Helmチャートは、1つのアプリのテンプレートをまとめたパッケージだ。チャートをインストールするとリリースができる。アップグレードのたびに、そのリリースの履歴に番号付きのリビジョンが増える。

このガイドでは、スケジュール、Helm 4の変更点、そしてHelm 3.22.1が作ったリリースをHelm 4.3.1で操作した実地検証を扱う。

Helm 3のサポート終了の仕組み

Helm 3は2段階で終わる。George Jenkins氏が2026年6月2日にプロジェクトのために書いたサポート終了告知による。

• バグ修正は2026年9月9日に終わった。 この日のリリースが、Helm 3最後の機能リリースだった。追加されたのは更新版のKubernetesクライアントライブラリだけだ。これでHelm 3は新しいKubernetesのバージョンと通信できるようになった。
• セキュリティ修正は2027年2月10日に終わる。 それまでに欠陥が見つかれば、プロジェクトはパッチを出す。その日を過ぎると、Helm 3には「Kubernetesクライアントライブラリとセキュリティパッチを含め」更新が一切出ないと告知は書いている。

v3.22.0のリリースノートは、3.22がHelm 3最後のマイナーバージョンだと認めている。最新のパッチ3.22.1は2026年10月15日に出た。

サポート終了で何かが止まるわけではない。Private DevOpsが移行ガイドで指摘するとおり、Helm 3のバイナリは2027年2月10日以降も動く。ただし、セキュリティ修正と新しいKubernetesバージョンへの対応は届かなくなる。

何がいつ変わったか

当初のタイムラインは、Helm改善提案のHIP-0012から来ている。HIP-0012は、Helm 4.0.0の後1年間、Helm 3にセキュリティ修正を出すと約束していた。つまり2026年11月までだ。6月、メンテナーはこれを3か月延ばした。

日付	出来事
2025年11月12日	KubeConでHelm 4.0.0がリリース。6年ぶりのHelmの新しいメジャーバージョン
2026年6月2日	HelmがHelm 3のセキュリティ修正を3か月延長
2026年9月9日	Helm 3最後の機能リリース（3.22）。バグ修正が終了
2026年10月15日	Helm 3.22.1とHelm 4.3.1がリリース。11月8日時点の最新版
2027年1月13日	リリースページによると、Helm 4.4.0の予定日
2027年2月10日	Helm 3のセキュリティ修正が終了。以後Helm 3のリリースはない

告知の助言ははっきりしている。「その日より前に、すべての利用者がHelm 4へ移行することを強く勧める」。

Helm 3の利用者にとってHelm 4で変わること

Helmプロジェクトによれば、Helm 4は「既存のHelm 3のチャート、リリース、ワークフローの大半と互換性がある見込み」だ。現在のv2形式のチャートはそのまま動く。新しいv3チャート形式はまだ実験的だ。変更点のうち重要なものは、Helm 4の概要に並んでいる。

• フラグの名前変更。 --atomicは--rollback-on-failureに、--forceは--force-replaceになった。古い名前もまだ動くが、警告が出る。
• ポストレンダラーはプラグインになった。 ポストレンダラーは、Helmの出力がクラスターに届く前に書き換える。--post-rendererは今後、スクリプトのパスではなく、インストール済みプラグインの名前を受け取る。
• レジストリへのログインはホスト名で。 helm registry loginはドメインだけを受け付け、URLは受け付けない。
• 新規インストールはサーバーサイド適用。 サーバーサイド適用では、Kubernetes自身が各変更をマージし、どのツールがどのフィールドを持つかを記録する。アップグレードとロールバックは、リリースがすでに使っている方式を引き継ぐ。そのため、Helm 3が作ったリリースは古いクライアントサイド方式のままだ。--server-sideフラグでこれを上書きできる。
• 新しいプラグインシステム。 既存のプラグインは動き続ける。プラグインは任意のWebAssemblyランタイムでも動かせる。プロジェクトはセキュリティのためにこれを勧めている。

検証：Helm 3が作ったリリースでHelm 4.3.1を動かす

Tech AI Wireは2026年11月8日に検証した。macOS 26.6.2上のDocker 28.4.0で、Kubernetes 1.36.6を動かすk3sクラスターを使った。どちらのHelmバイナリもget.helm.shから入手し、SHA-256チェックサムは一致した。Helm 3.22.1が、helm createの書くサンプルチャートをインストールした。続いてHelm 4.3.1が同じリリースを操作した。以下では2つのバイナリをhelm3とhelm4と呼ぶ。

helm3 install web ./demo --wait
helm4 upgrade web ./demo --atomic --set replicaCount=2
helm4 registry login https://ghcr.io -u test -p test
helm4 template web ./demo --post-renderer ./pr.sh
helm4 get metadata web

検証	結果
Helm 4はHelm 3のリリースを読めるか	読めた。helm listとhelm historyに表示された
upgrade --atomic	動いた。「Flag --atomic has been deprecated, use --rollback-on-failure instead」と表示
upgrade --force	動いた。「Flag --force has been deprecated, use --force-replace instead」と表示
registry login https://ghcr.io	失敗：invalid reference: invalid registry "https://ghcr.io"
--post-renderer ./pr.sh（シェルスクリプト）	失敗：プラグインが見つからない。Helm 3.22.1では同じスクリプトが動いた
Helm 4でアップグレードした後の、Helm 3のリリースの適用方式	「client-side apply (defaulted)」
Helm 4で新規インストールしたリリースの適用方式	「server-side apply」
Helm 4のアップグレード後にHelm 3を使う	4つのリビジョンをすべて読み、リビジョン1へロールバックできた

Kubernetes自身の記録も一致した。Helm 3のリリースのDeploymentは「Update」操作で書かれていた。新しいHelm 4のリリースは「Apply」だった。

ドキュメントにない結果が1つある。--server-side=trueで、Helm 3のリリースはサーバーサイド適用に移った。ところがその後Helm 3.22.1でアップグレードすると、Helm 4はそれを再びクライアントサイド適用と報告し、「(defaulted)」と付けた。新旧のバイナリが1つのリリースを交互に扱うと、移行が知らないうちに元に戻ることがある。

開発者にとっての意味

• まず2つの完全な失敗を直す。 CIスクリプトで、https://付きのhelm registry loginと、スクリプトを指す--post-rendererを探す。どちらもHelm 4のパイプラインを止める。名前が変わったフラグは警告を出すだけだ。
• --atomicと--forceは今すぐ改名する。 まだ動くが、Helm 4は非推奨とし、実行のたびに警告を出す。
• リリースごとにバイナリを1つに決める。 移行中、Helm 4が一度触ったリリースはHelm 4だけでアップグレードする。そうしないと適用方式が戻ることがある。
• サーバーサイド適用は意図して選ぶ。 Helm 3が作ったリリースは、誰かが--server-sideを渡すまでクライアントサイドのままだ。本番の前にステージングのクラスターで切り替えを試す。
• CIでHelmのバージョンを固定し、ロールバックを試す。 Private DevOpsは、Helmの呼び出しをすべて洗い出し、本番以外でHelm 4を先に試すよう勧めている。
• 2月10日を待たない。 その日以降、Helm 3のセキュリティ上の欠陥は修正されない。新しいKubernetesバージョンへのHelm 3クライアントの対応もない。