「Helm」とは――Kubernetesのマニフェスト／デプロイ管理Hellを無にするパッケージマネジャーの基本的な使い方：Cloud Nativeチートシート（3）

Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、Helmの概要とHelmチャートの使い方、Helmリリースのライフサイクルを解説します。

[堀内保大, 岡本隆史，株式会社NTTデータ]

　Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。Kubernetesのマニフェスト管理が複雑化する課題への対応として、前回は「Kustomize」を紹介しました。

　今回から、もう一つのマニフェスト管理ツール「Helm」を2回に分けて取り上げます。今回はHelmの概要とHelmチャートの使い方、Helmリリースのライフサイクルを中心に説明して、次回はHelmチャートの作成方法とリポジトリ公開方法などを説明します。

目次

• Helmとは
• Helmの使い方の概要
• Helm自体のインストール
• チャートの検索
• Helmのライフサイクル
  • インストール：helm install
  • リリースの確認：helm list
  • パラメーターの指定方法
  • リリースの更新：helm upgrade
  • リリースのロールバック：helm rollback
  • リリースのアンインストール：helm uninstall
• 現場で役立つ3つのポイント
• まとめ
• 補足：チャートの構成

Helmとは

　Helmは、リポジトリからのインストールや、Helmによってデプロイされたアプリケーションの管理をコマンドラインツールで簡易化するオープンソースソフトウェア（OSS）です。「舵輪（だりん）」「操舵（そうだ）」「支配（権）」といった意味があり、Kubernetes向けのパッケージマネジャーとして広く使われています。LinuxにおけるyumやRPM、macOSにおけるHomebrewなどと同類のツールと考えると理解しやすいでしょう。

　2015年にDeis（現在はMicrosoftが買収）が開発を開始し、現在はCNCF（Cloud Native Computing Foundation）でホストしています。2020年4月にCNCFはHelmの「Graduation」を発表しました。

• CNCF Helm Project Journey Report

　2020年11月13日にはv2のサポートが正式に終了しており、v3の使用が強く推奨されています。本記事でもv3を前提に記載しています。

　なお前回、下記の表のようにHelmとKustomizeのメリットとデメリットを比較しました。

	メリット	デメリット
Kustomize	・学習コストが低い ・Kubernetes標準のコマンドラインツールに統合されている ・カスタマイズしやすい（Kustomizeというだけある……）	・さまざまな設定が想定されるようなアプリケーションでは、利用者側のカスタマイズが多くなり利便性が下がる
Helm	・配布の仕組みが整っている ・条件分岐などが記述できるので、さまざまな設定が想定されるアプリケーションの管理に向いている	・Helmの記述方法を学習するコストが高い ・「どこまで共通的に利用できるテンプレートにすべきか」の設計が難しい ・テンプレートに書いてある以上のことができないので、カスタマイズ性が低い ・設定値がどのように反映されるのか把握しにくい

　この表で分かる通り、Helmは配布の仕組みが整っているので、公開されているアプリケーションをKubernetes上にデプロイ（インストール）する、もしくは自分のアプリケーションを公開するツールとして利用することに適しているといえます。

　KustomizeはKubernetesのYAMLとほぼ同じ構造で記述できるので学習コストが低くカスタマイズ性も高く非常に便利ですが、「リポジトリ」というコンセプトがある点、ライフサイクルとしてデプロイを管理できる点ではHelmに分があります。

Helmの使い方の概要

　Helmでは「チャート」という設定ファイル群でKubernetesの全てのマニフェストを管理します。

　一般に公開されているチャートを利用する際は、公開されているHelmリポジトリからチャートを取得して、適宜、変数化されているパラメーターのみを書き換えた（自身のクラスタに応じてレプリカ数を変更させるなど）後、自身のKubernetesクラスタにデプロイします。これら一連の流れを「helm install」コマンドで実行できます。

　なおリポジトリは、自作することもできます（作成方法については次回記事で紹介します）。

　図1は、リポジトリから「helm install」でKubernetesクラスタにデプロイする際のイメージです。

図1　チャートのデプロイイメージ

　パラメーター設定値を書いたYAMLを指定して「helm install」を作業端末で実行すると、指定値で定義されたKubernetesマニフェストを基にクラスタにデプロイするところまでワンストップで実行されます。

　Helmによって1回でもクラスタにデプロイされたリソース群は、デプロイごとにグルーピングされて「リリース」（以下、Helmリリース）という単位で管理されます。

　yumなどでは、1つのパッケージに対し1回しかインストールできませんが、Helmでは、インストールをリリースとして管理することで、1つのチャートから用途ごとに異なるリリースを混在させ、異なるバージョンのチャートを同居させることができます。

Helmリリース

　図2はHelmリリースのライフサイクルです。

図2　リリースのライフサイクル

　「helm list」コマンドでステータスを確認して「helm upgrade」「helm rollback」「helm uninstall」コマンドでパラメーターなどを変更できます。上記コマンドで変更した際にリリースのリビジョンがインクリメントされ、クラスタへのデプロイリソースは間接的に更新されます。

　以下、各コマンドによって起こるイベントを簡単に説明します。

• helm install：チャートをリソースとしてKubernetesにデプロイする。デプロイされたリソースは、リリースという概念でデプロイごとに一括管理される
• helm list：Kubernetesクラスタにデプロイされているリリースを確認できる
• helm upgrade：デプロイ済みのリリースのValuesファイルを変更したり、「--set」オプションでパラメーターを変更して再デプロイしたりすることができる。更新されたリリースには、リビジョンが記録されており、「helm list」で確認できる
• helm rollback：以前デプロイした特定のリビジョンにロールバックできる。ロールバックしても、ロールバック対象のリビジョンが新しいリビジョンとしてデプロイされる（最新のリビジョン番号にインクリメントしたリビジョンがデプロイされる）ので、注意が必要だ
• helm uninstall：リリースで管理される全てのKubernetesリソースを一括で削除する。削除されたリリースは、「helm list」で管理できなくなるが、「--keep-history」オプションを追加しておくと「helm list --uninstalled」でアンインストールされたリリースを確認できる

図3　リリースへの変更例

リポジトリ

　Helmの特徴の一つとして、幅広いツールのチャートがHelmリポジトリに多く公開されていることがあります。公式が公開するチャートを活用することで容易かつ迅速に必要なリソーススタックをデプロイできす。

　リポジトリは世の中に数多く存在しており、「helm repo add」コマンドで追加可能です。公式の「Helm Stableリポジトリ」のURLは「https://charts.helm.sh/stable」です。

　公式のStableリポジトリから検索してチャートを使えます。コミュニティーが公開している個々のリポジトリを追加して、そのリポジトリのチャートを使うこともできます。

　リポジトリの探し方には、コミュニティー（Prometheusなど）のGitHubページを参照したり、後述する「ArtifactHUB」で検索したりといった方法があります。

　例えばPrometheusコミュニティーのHelmチャートのページは図4にあるURLでHelmリポジトリを公開しており、本リポジトリからPrometheus関連のチャートを取得できます。

図4　PrometheusコミュニティーのHelmチャートページの「Usage」

Helm自体のインストール

　ここからは、Helmを使う実例を紹介します。まずはHelmを自身の端末にインストールします。