Helm＠マニフェスト管理¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. Helmの仕組み¶
アーキテクチャ¶
Helmは、helmクライアント、チャートレジストリ、複数のチャートリポジトリ、チャート、といったコンポーネントから構成される。
バージョン管理戦略¶
▼ バージョン管理戦略とは¶
HelmのHelmリリースでは、バージョン管理に関する戦略を採用している。
▼ 2方向の戦略的マージパッチ¶
Helmの v2では、2方向の戦略的マージパッチを採用している。
この戦略では、『前回のHelmリリースによるマニフェスト』『今回のHelmリリースによるマニフェスト』の2つを比較する。
そのため、Helm以外の方法 (例：kubectl editコマンド、kubectl applyコマンド) でマニフェストが変更されたことを検知できず、チャートの宣言通りにHelmリリースやロールバックを実施できなかった。
▼ 3方向の戦略的マージパッチ¶
Helmの v3では、3方向の戦略的マージパッチを採用している。
この戦略では、『前回のHelmリリースによるマニフェスト』『今回のHelmリリースのマニフェスト』『前回のHelmリリース後のHelm以外の方法によるマニフェスト』の3つを比較する。
そのため、Helm以外の方法 (例：kubectl editコマンド、kubectl applyコマンド) でマニフェストが変更されたことを検知でき、チャートの宣言通りにHelmリリースやロールバックを実施できる。
ただし、すでにHelm以外 (例：kubectl applyコマンド、Kustomize) で作成されているマニフェストからHelmに移行する場合、前回のHelmリリースによるマニフェスト自体が存在せず、新規のHelmリリースとなる。
そのため、チャートと現在のマニフェストと比較できない。
02. helmクライアント¶
helmクライアントとは¶
helmクライアントは、リポジトリからインストールしたチャートアーカイブ (.tgz形式ファイル) に基づいて、現在のコンテキストで指定されているClusterのkube-apiserverにリクエストを送信する。
これにより、Kubernetes上にKubernetesリソースが作成される。
バージョン¶
Helmは、バージョンごとに対応するKubernetesバージョンが異なる。
Kubernetesをアップグレードした場合に、Helmもアップグレードする必要がある。
注意点として、Helmが対応するKubernetesのバージョンに応じて、Helmテンプレートの異なるロジックに入る可能性がある。
このロジックでは、Kubernetesの新しいバージョンでコントロールプレーンコンポーネントに変更があった場合に、それに対応するような処理を実行する。
03. チャートレジストリ¶
チャートレジストリとは¶
チャートレジストリとして使用できるものの一覧を示す。
チャートレジストリ内にリポジトリを配置する。
| レジストリ | 補足 |
|---|---|
| ArtifactHub (Helm公式) | ・https://helm.sh/docs/topics/chart_repository/ |
| GitHub、GitHub Pages | ・https://zenn.dev/mikutas/articles/2ab146fa1ea35b |
| AWSリソース (ECR、S3) | |
| Google Cloudリソース |
04. チャートリポジトリ¶
チャートリポジトリとは¶
チャートをリモートに置いて、インストールできるようになる。
チャートのプッシュやプル時に、チャートレジストリ内のリポジトリを指定する場合は、HTTPSプロトコルを使用する。
リポジトリにリモートからインストールできないチャートが配置されている場合、そのリポジトリはチャートリポジトリではなく、マニフェストリポジトリである。
| URL | |
|---|---|
| 形式 | https://<チャートレジストリのドメイン名>/<チャートリポジトリ名> |
| 例 | https://example.com/foo-chart |
OCIリポジトリ¶
チャートリポジトリのように、リモートにあるチャートをインストールできるようになる。
チャートのプッシュやプル時に、OCIレジストリ内のリポジトリを指定する場合は、OCIプロトコルを使用する。
| URL | |
|---|---|
| 形式 | oci://<チャートレジストリ名>/<チャートリポジトリ名> |
| 例 | oci://foo-registry/foo-repository |
チャートリポジトリ化¶
▼ リポジトリをチャートリポジトリとして扱う場合¶
リポジトリをチャートリポジトリとして扱う場合、チャートリポジトリのルートディレクトリ配下に、index.yamlファイル、各バージョンのチャートアーカイブ (.tgz形式ファイル) 、を配置する。
これらにより、リモートからチャートリポジトリのURLを指定し、チャートをインストールできるようになる。
ArtifactHubや、GitHubリポジトリにて gh-pagesブランチ上で複数のバージョンのチャートを管理するような使い方は、このチャートリポジトリに相当する。
repository/ # チャートリポジトリ
├── index.yaml
├── foo-chart-1.0.0.tgz # fooチャートアーカイブ
├── foo-chart-2.0.0.tgz
├── bar-chart-1.0.0.tgz # barチャートアーカイブ
├── bar-chart-2.0.0.tgz
├── baz-chart-1.0.0.tgz # bazチャートアーカイブ
├── baz-chart-2.0.0.tgz
│
...
▼ リポジトリをマニフェストリポジトリとしてのまま扱う場合¶
リポジトリをチャートリポジトリとして扱わず、ローカルのチャートとして操作する場合、index.yamlファイルとチャートアーカイブ (.tgz形式ファイル) が不要になる。
リモートからは、チャートをインストールできない。
repository/ # マニフェストリポジトリ
├── foo-chart # fooチャート
├── bar-chart # barチャート
├── baz-chart # bazチャート
│
...
05. チャート¶
チャートとは¶
必要なKubernetesリソースを作成するためのマニフェストのセットをパッケージ化し、管理しやすくしたもの。
ルートディレクトリに Chart.yamlファイルと templateディレクトリを置く必要がある。
また、チャートのコントリビュート要件も参考にすること。
repository/
├── foo-chart/ # fooチャート
│ ├── charts/ # 依存対象のサブチャートを配置する。
│ ├── templates/ # ユーザー定義のチャートを配置する。ディレクトリ構造は自由である。
│ │ ├── tests/
│ │ ├── _helpers.tpl # ヘルパー関数のみを設定する。
│ │ └── template.yaml # チャートの共通ロジックを設定する。
│ │
│ ├── .helmignore # チャートアーカイブの作成時に無視するファイルを設定する。
│ ├── Chart.yaml # チャートの概要を設定する。頭文字は大文字である必要がある。
│ └── values.yaml # テンプレートの変数に出力する値を設定する。
│
├── bar-chart/ # barチャート
│
...
チャートアーカイブ¶
.tgz形式で圧縮されたチャートのパッケージ。
Helmリリース¶
実際にインストールされたチャートのインスタンスのこと。
インスタンスの実体は、Secretのデータとして管理している。
$ kubectl get secret -n foo-namespace
NAME TYPE DATA AGE
...
sh.helm.release.v1.foo-chart.v1 helm.sh/release.v1 1 122d
sh.helm.release.v1.foo-chart.v2 helm.sh/release.v1 1 122d
sh.helm.release.v1.foo-chart.v3 helm.sh/release.v1 1 122d
sh.helm.release.v1.foo-chart.v4 helm.sh/release.v1 1 122d
sh.helm.release.v1.foo-chart.v5 helm.sh/release.v1 1 119d
sh.helm.release.v1.bar-chart.v1 helm.sh/release.v1 1 97d
sh.helm.release.v1.bar-chart.v2 helm.sh/release.v1 1 84d
sh.helm.release.v1.bar-chart.v3 helm.sh/release.v1 1 74d
sh.helm.release.v1.bar-chart.v4 helm.sh/release.v1 1 60d
sh.helm.release.v1.bar-chart.v5 helm.sh/release.v1 1 49d
...