チャートができたら、Helm での日々の作業は、ほぼすべてリリースの管理です。インストールし、チャートや values の変更に応じてアップグレードし、ときどきリリースをロールバックします。このガイドでは、そのライフサイクルを最初から最後まで説明します。

中心となるコマンド

コマンド	何をするか
helm install NAME CHART	チャートから新しいリリースを作成します。
helm upgrade NAME CHART	既存のリリースに変更を適用します。
helm upgrade --install NAME CHART	リリースがなければインストールし、あればアップグレードします。
helm list	現在の namespace のリリースを一覧表示します（すべての namespace は -A）。
helm status NAME	リリースの現在の状態を表示し、その NOTES.txt をもう一度表示します。
helm rollback NAME REVISION	リリースを以前のリビジョンに戻します。
helm uninstall NAME	リリースとそのリソースを削除します。

helm upgrade --install は、単独で取り上げる価値があります。ほとんどすべての CI/CD パイプラインが実際に使っているパターンだからです。スクリプトが、最初のデプロイなのか 100 回目なのかを知ったり確認したりする必要なく、「この設定でこのリリースが存在することを保証する」という意味になります。

すべての変更は番号付きのリビジョンになる

helm install web ./webapp
helm list

新規インストールはリビジョン 1 です。以降の upgrade ごとに次の番号が追加され、rollback も 1 つ追加します。ロールバックはタイムマシンではなく、内容がたまたま古いものと一致する新しいリビジョンだからです。

操作	結果のリビジョン
helm install	1
helm upgrade	2
helm upgrade	3
helm rollback web 1	4（内容はリビジョン 1 と一致するが、番号は増え続ける）

helm history web

は、すべてのリビジョンを、ステータス、チャートのバージョン、アプリのバージョンとともに一覧表示します。これは、rollback と下の検査コマンドが読み取る情報です。

アップグレードがうまくいかなかったときにロールバックする

helm rollback web 2
kubectl rollout status deployment/web

特定のリビジョン番号にロールバックするのが通常のケースです。番号なしの helm rollback web は、直前のものに戻します。ロールバックは新しいリビジョンを作成するため、ロールバックしてからもう一度ロールバックすると、元の場所に戻ります。ロールバック自体が取り消されるわけではありません。実際にどのリビジョンに戻そうとしているのかは、helm history で確認してください。

変更せずにリリースを調べる

helm status web
helm get values web
helm get manifest web
helm diff upgrade web ./webapp -f values-prod.yaml   # helm-diff プラグインが必要

get values は、このリリースに実際に与えられたものを表示します。実行中のリリースが、ディスク上の values ファイルが示すものと一致しないときに便利です。get manifest は、テンプレート適用後に Helm が適用した正確な Kubernetes YAML を表示します。これは、チャートのソースと実際に稼働しているものとの食い違いをデバッグするときの、確かな情報です。helm diff は組み込みではなく、広く使われているコミュニティのプラグイン（helm plugin install https://github.com/databus23/helm-diff）です。自信のないアップグレードを実行する前に入れておく価値があります。何も適用せずに、何が変更されるかを正確に表示してくれるからです。

アンインストールして、履歴を残すか破棄するか

helm uninstall web
helm uninstall web --keep-history

デフォルトでは、アンインストールはリリースのリソースと履歴の両方を削除します。--keep-history は、リソースを削除しますが、リリースの記録は残します。そのため、後から helm history web と helm rollback が引き続き機能します。復元する必要がある場合や、以前何が動いていたかの監査証跡が欲しい場合に使えます。--keep-history を付けても、アンインストールされたリリースは、-a/--all を追加しない限り helm list に表示されません。

Helm 4 で変わったこと

Helm 4 を使っている場合、動作の違いが 1 つあります。新規インストールは、Helm 3 が使っていたクライアントサイド apply ではなく、デフォルトで Kubernetes の server-side apply を使うようになりました。これはツール間のフィールドの所有権と競合を、より予測可能に処理します。Helm 3 で作成されたリリースのアップグレードとロールバックは、--server-side を明示的に渡さない限り、引き続きクライアントサイド apply を使います。そのため、バージョンが混在するワークフローで、動作が突然変わることはありません。これは上のコマンドのどれも変更せず、結果のマニフェストの適用方法だけが変わります。