Helm は、Kubernetes アプリケーションをチャートとしてパッケージ化します。テンプレート化されたマニフェストのディレクトリと、デフォルトの値のセットです。このガイドでは、すべてのチャートに共通するフォルダー構造と、Helm のあらゆる要素の土台となる 3 つの概念、チャート、values、リリースを説明します。

なぜプレーンなマニフェストだけでは足りないのか

自明でないアプリケーションが、1 つの Deployment だけであることはまれです。Deployment、Service、ConfigMap、そしておそらく Secret と Ingress があり、そして同じセットを dev、staging、本番にデプロイしたいが、環境間で異なるのは、イメージタグ、レプリカ数、namespace といったごく少数の値だけ、というのが普通です。環境ごとにマニフェストをコピー＆ペーストすると、共有されているすべてのフィールドが、同期を失う可能性があります。チャートは、マニフェストを 1 度だけテンプレートとして保持し、各インストールが独自の値を与えられるようにします。

フォルダー構造

helm create webapp

これにより、次のものが生成されます。

webapp/
├── Chart.yaml           # チャートのメタデータ：名前、バージョン、説明
├── values.yaml          # デフォルトの設定値
├── charts/              # このチャートが依存するチャート
├── .helmignore
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    ├── _helpers.tpl      # 再利用可能なテンプレートの断片
    ├── NOTES.txt         # install/upgrade の後に表示される
    └── tests/
        └── test-connection.yaml

Chart.yaml はチャート自体に関するメタデータで、主に名前、バージョン、apiVersion（Helm 3 と現在の Helm 4 では v2）です。values.yaml はデフォルトの設定を保持します。templates/ には、Helm のテンプレート構文が混在した Kubernetes マニフェストが入ります。charts/ には、このチャートが依存するチャートが入ります。これは、チャートを組み合わせ始めるときにだけ関係してきます。生成されるサンプルは、通常必要以上のものを含む動作する nginx のチャートです。ほとんどのチームは、足場を削除して 3 つか 4 つの独自のテンプレートを書くか、当てはまらないものを削ります。

values がテンプレートに流れ込む

テンプレートは、プレースホルダーのある通常のマニフェストのように見えます。

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.appName }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: {{ .Values.appName }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

# values.yaml
appName: webapp
replicaCount: 2
image:
  repository: nginx
  tag: "1.25"

.Values は values.yaml から構築され、コマンドラインで指定されたものとマージされたオブジェクトです。helm install や helm template を実行すると、templates/ 内のすべてのファイルをそのオブジェクトでレンダリングし、プレーンな Kubernetes YAML を生成します。{{ }} の構文は Go テンプレートで、Kubernetes のエコシステムの他の場所でも使われているテンプレート言語と同じなので、それ以外に独自の学ぶべきものはありません。値は 3 つの方法で上書きでき、優先度の低い順に、values.yaml のデフォルト、-f で渡す追加ファイル、コマンドラインの個別の --set key=value フラグです。

リリースはチャートの特定のデプロイである

チャートをレンダリングして結果をクラスターに適用すると、リリースが作られます。独自の履歴を持つ、名前付きで追跡されるインストールです。

helm install web-dev ./webapp
helm list

web-dev はリリース名です。同じチャートを、同じ namespace または別の namespace に、異なるリリース名で何度もインストールできます。たとえば web-dev と web-staging です。リリースに対する helm upgrade のたびに、その履歴に新しいリビジョンが追加されます。これこそが後で helm rollback を可能にするものです。Helm は単に YAML を適用しているのではなく、何がいつ適用されたかを追跡しています。このシリーズのリリース管理のガイドで、そのワークフロー全体を説明します。

NOTES.txt の用途

templates/NOTES.txt は、同じようにテンプレート化されたプレーンテキストで、Helm が install や upgrade の後に出力します。インストールした人に、次に何をすべきかを伝えるために使います。kubectl port-forward コマンド、Service に到達できる URL、最初の実行時の手順などです。クラスターには何の影響もなく、コマンドを実行する人への純粋なメッセージです。

チャートの入手先

すべてのチャートを自分で書く必要はありません。一般的なソフトウェア、データベース、モニタリングスタック、ingress コントローラーのための公開チャートは、Artifact Hub で公開されており、1 つのコマンドでインストールできます。このシリーズの残りでは、まず独自のチャートの書き方を、次に公開されているチャートの見つけ方とインストール方法を説明します。