事実上の標準ツールとなっているKubernetes向けデプロイツール「Helm」入門
近年ではKubernetesクラスタ上で動作させるアプリケーションにおいて、そのデプロイに「Helm」と呼ばれるツールを使用する例が増えている。Helmは設定ファイルを元にアプリケーションのデプロイを自動実行するツールで、Kubernetesアプリケーション向けのパッケージマネージャとも言われている。今回はこのHelmの概要、使い方、設定ファイルの書き方などを紹介する。
目次
Kubernetes上にアプリケーションをデプロイするための事実上の標準的ツールとなっている「Helm」
近年ではコンテナクラスタ技術であるKubernetesを活用したサービスの運用が増えており、Kubernetes上で動かすことを前提とするソフトウェアも登場している。一方で、Kubernetes上でのアプリケーションのデプロイについては課題も多い。
Kubernetesはサービスを複数の小規模コンポーネントに分割して実装するマイクロサービスアーキテクチャと相性が良い。そういった構成のサービスでは、それぞれのコンポーネントを個別にクラスタ上にデプロイする必要がある。また、サービスを外部に公開したり、各種設定を行ったりするためにKubernetesクラスタ上に「リソース」を作成して設定を行う必要もある。こういった作業は時に複雑になるため、Kubernetesクラスタでのデプロイを支援したり、デプロイされたコンテナを管理したりするためのさまざまなツールが登場している。
今回紹介するHelmは、そういったKubernetesクラスタへのアプリケーションのデプロイを支援するツールの1つだ(図1)。
昨今のOSやプログラミング言語の多くでは、第三者が作成したソフトウェア(パッケージ)を集積して公開するサービス(リポジトリ)が提供されており、そこで公開されているソフトウェアの検索やダウンロード、インストールなどを簡単な操作で行える「パッケージマネージャ」と呼ばれるソフトウェアが用意されている。HelmはKubernetes向けのパッケージマネージャとも呼ばれており、OSやプログラミング言語のパッケージマネージャと類似した機能を備えている。Helmによって提供される具体的な機能を簡単にまとめると、次のようになる。
- 「Chart」と呼ばれる設定ファイルに基づいた各種リソースの自動作成
- デプロイされたアプリケーションの削除・更新といった管理
- リポジトリで公開されているChartの検索やダウンロード、インストール
- Chartのパッケージ化やリポジトリへのアップロード
Kubernetesのベースとなっているコンテナ技術のDockerでは、すでにコンテナイメージを提供するリポジトリ機構が用意されている。そのため、Helmではイメージ自体は直接扱わず、「Chart」(チャート)と呼ばれる設定ファイルのみをリポジトリで管理する仕組みになっている。その点を除けば、Helmが提供する機能は一般的なパッケージマネージャが備える機能とほぼ同じで、「helm」と呼ばれるコマンドラインツールを使ってChartをダウンロードしたり、それに基づいてクラスタ内に自動的にアプリケーションをデプロイしたりできるようになっている。
また、Helmでは「stable」や「incubator」という名称の公式リポジトリが提供されているほか、サードパーティによるリポジトリも多く提供されている。これらのリポジトリで公開されているChartは、Helm Hubというサイトで横断的に検索できるようになっている(図2)。
Helmの歴史とコミュニティ
Helmは2016年2月にv1.0がリリースされ、現在までに2度のメジャーアップデートが行われている。最新版は2020年2月にリリースされたv3.1.0だ。
当初はKubernetesのサブプロジェクトとして開発が進められていたが、その後Linux Foundation傘下の非営利団体であるCloud Native Computing Foundation(CNCF)傘下となり、現在もその体制で開発が進められている。CNCFはクラウド関連技術の開発を推進する団体で、Kubernetes自体もCNCFの傘下で開発が進められている。こういった歴史的背景のため、HelmはKubernetesの(事実上の)公式パッケージマネージャとも言われている。
Helmプロジェクト自身が提供する「stable」や「incubator」などの公式リポジトリではすでにさまざまなアプリケーションのChartが公開されているほか、有志によって作成されたChartも多く公開されている。また、以前紹介したKubernetes関連ツールのIstioやJenkins Xといったソフトウェアでも、Helmが公式のインストール手段として採用されている。
なお、helmは船舶などで使われる「舵(かじ)」を意味する単語だ。また、chartは「海図」に由来している。
Helmのインストール
helmコマンドはGitHubのリリースページから入手が可能で、ここではソースコードのほかWindowsおよびLinux、macOS向けのバイナリも提供されている。配布アーカイブ内にはバイナリファイル(「helm」)がそのまま格納されているので、これを、Helmを利用したいマシン上にダウンロードし、展開後にパスの通ったディレクトリにコピーすればインストール完了だ。
また、macOSのHomebrewやWindowsのChocolateyといったパッケージマネージャ経由でもインストールできる。これらについて詳しくはドキュメントを参照して欲しい。
なお、helmコマンドはKubernetesクラスタへのアクセスにkubectlコマンドを利用するため、helmコマンドを実行するマシン上にkubectlコマンドがインストールされており、さらにkubectlコマンドでKubernetesクラスタにアクセスできるよう設定を行っておく必要がある。
サポートするKubernetesクラスタのバージョンについては明記されていないが、「Kubernetesの最新安定版」との組み合わせが推奨となっている。とはいえ、古いバージョンのKubernetesだからといって直ちに利用できなくなることはないようだ。ただし、Kubernetes 1.6以前では役割(ロール)ベースのアクセスコントロール(RBAC)関連設定で制限があるとされている。
ちなみに、Helmのv2系ではhelmコマンドに加えてKubernetes上で動作する「tiller」というアプリケーションが必要だったが、v3ではtillerは廃止され、helmコマンドのみが必要なように変更されている。
公開されているChartを使ってアプリケーションをデプロイする
前述のように、HelmではChartと呼ばれる設定ファイルに基づいてアプリケーションのデプロイを実行する。Chartはhelmコマンドを実行するローカルマシン上に用意されたものだけでなく、リポジトリで公開されているChartを直接ダウンロードして利用することも可能だ。まずはHelmによるアプリケーションのデプロイ例として、リポジトリで公開されているChartを利用する流れを紹介しよう。
前述のとおり、公開されているChartはHelm Hubというサイトで検索できる。Helm Hubでは「<リポジトリ名>/<Chart名>」という形式でChartが表示されており、そのうちリポジトリ名が「stable」や「incubator」になっているものがHelmの公式リポジトリで提供されているChartで、リポジトリ名がそれ以外のものになっているものはサードパーティが提供しているChartだ。同一の名称のChartが異なるリポジトリで公開されていることもあるが、それらは提供元が異なっているという点に注意したい。
さて、リポジトリ経由でChartをインストールする場合、まずはそのChartを提供しているリポジトリをローカルマシン上に登録する必要がある。Helmのインストール直後はいずれのリポジトリも登録されていない状態になっているはずなので、公式リポジトリで提供されているChartを利用する場合でもリポジトリの追加作業が必要となる。
リポジトリの追加は、「helm repo add <リポジトリ名> <URL>」コマンドで実行できる。たとえば公式の「stable」リポジトリを追加する場合、以下のように実行する。
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/ "stable" has been added to your repositories
ちなみにLinux環境では、使用するリポジトリの設定はホームディレクトリ以下の.config/helmディレクトリ以下に、リポジトリで公開されているChart一覧のキャッシュはホームディレクトリ以下の.cache/helm/repositoryディレクトリ内に格納される。これらの情報は「helm -h」コマンドで表示できるhelmコマンドのヘルプに記載されているので、必要に応じて確認しておこう。
$ helm -h The Kubernetes package manager : : +------------------+---------------------------+--------------------------------+-------------------------+ | Operating System | Cache Path | Configuration Path | Data Path | +------------------+---------------------------+--------------------------------+-------------------------+ | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | +------------------+---------------------------+--------------------------------+-------------------------+
リポジトリの登録後は、「helm search」コマンドでリポジトリに登録されているChartを検索できる。
helm search repo [<検索するキーワード>]
キーワードを省略した場合、登録されているリポジトリで提供されているすべてのChartが出力される。
$ helm search repo NAME CHART VERSION APP VERSION DESCRIPTION stable/acs-engine-autoscaler 2.2.2 2.1.1 DEPRECATED Scales worker nodes within agent pools stable/aerospike 0.3.2 v4.5.0.5 A Helm chart for Aerospike in Kubernetes : :
登録したリポジトリの情報はローカルにキャッシュされるため、時間が経つと古くなっている可能性がある。「helm repo update」コマンドを実行することで、リポジトリのキャッシュを最新のものに更新できる。
$ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ? Happy Helming!?
Helmでは、Chartを使ってアプリケーションをデプロイすることを「install(インストール)と呼び、インストールされたアプリケーションのインスタンスは「Release(リリース)」と呼ぶ。また、各インスタンスはそれぞれに固有の名前(Release名)を持つ。Release名が重複しない限り、同一のChartから複数のReleaseを作成することも可能だ。
さて、リポジトリで公開されているChartを使ってアプリケーションをインストール(デプロイ)するには、「helm install <Release名> <Chart名>」コマンドを実行する。
次の例は、「stable/wordpress」というChartを「wordpress」というRelease名でデプロイしたものだ。デプロイに成功すると、そのアプリケーションに関するメモなどを含む「NOTES」が表示される。
$ helm install wordpress stable/wordpress NAME: wordpress LAST DEPLOYED: Mon Feb 17 19:42:51 2020 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: 1. Get the WordPress URL: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w wordpress' export SERVICE_IP=$(kubectl get svc --namespace default wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
デプロイは現在のKubernetesのコンテキストに対して行われるため、特定のネームスペースを使用したい場合などは事前に「kubectl config」コマンドなどでコンテキストの設定を行っておこう。
なお、このstable/wordpress Chartでは永続化ストレージを利用するため、クラスタ内でデフォルトのStorage Classが設定されている必要がある。Storage Classの設定方法は使用しているKubernetesクラスタによって異なるが、独自で作成したクラスタの場合は以前の記事『Kubernetes環境に特化したCI/CDツール「Jenkins X」を試してみる』内で「インストール作業2:KubernetesのStorage Classの作成」として紹介しているので、そちらを参照してほしい。
デプロイされたReleaseの一覧は「helm list」コマンドで確認できる。
$ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION wordpress default 1 2020-02-06 20:38:52.212353733 +0900 JST deployed wordpress-8.1.2 5.3.2
ここで作成されたPodを「kubectl get po」コマンドで確認すると、次のように「wordpress-8bcc6cf8c-4nr2l」と「wordpress-mariadb-0」の2つのPodが作成されていることが分かる(環境に応じて「8bcc6cf8c-4nr2l」の部分は変わる)。
$ kubectl get po NAME READY STATUS RESTARTS AGE nfs-client-provisioner-78b7d65564-kkzw4 1/1 Running 0 15m wordpress-8bcc6cf8c-4nr2l 1/1 Running 0 5m9s wordpress-mariadb-0 1/1 Running 0 5m9s
このうち「wordpress-8bcc6cf8c-4nr2l」は「wordpress」というDeployment(deploy)によって作成されたもので、また「wordpress-mariadb-0」は「wordpress-mariadb」というStatefulsetで作成されている。
$ kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE nfs-client-provisioner 1/1 1 1 14m wordpress 1/1 1 1 4m54s $ kubectl get statefulset NAME READY AGE wordpress-mariadb 1/1 7m24s
各種設定を保存するリソースであるConfigMag(cm)についても、「wordpress-mariadb」と「wordpress-mariadb-tests」というものが作成されている。
$ kubectl get cm NAME DATA AGE wordpress-mariadb 1 12m wordpress-mariadb-tests 1 12m
デプロイされたサービスにアクセスするためのIPアドレスは、「kubectl get svc」コマンドでKubernetesのServiceリソースの情報を表示することで確認できる。
$ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 117d wordpress LoadBalancer 10.101.202.201 <pending> 80:32404/TCP,443:30919/TCP 8m23s wordpress-mariadb ClusterIP 10.102.21.63 <none> 3306/TCP 8m23s
ここで「wordpress」が今回デプロイされたWordPressに紐付けられたServiceとなる。今回使用したKubernetes環境はingressの設定を行っていないため「EXTERNAL-IP」は「<pending>」となっているが、curlコマンドなどで「CLUSTER-IP」で表示されているIPアドレス(今回の例の場合は「10.101.202.201」)にアクセスすると、WordPressのトップページを確認できるはずだ。
デプロイ時にパラメータ設定を行う
Helmではアプリケーションのデプロイ時にさまざまなパラメータを与えて設定を行う仕組みが用意されている。これらパラメータは、「helm install」コマンドの実行時に「--set <パラメータ名>=<値>」オプションで指定するか、もしくはYAML形式でファイルに記述し、「-f <YAMLファイル>」オプションでそのファイルを指定することで設定できる。また、「--set」オプションでは「--set <パラメータ名>=<値>, <パラメータ名>=<値>」のようにカンマ区切りで複数のパラメータと値を同時に指定することもできる。
使用できるパラメータはChartごとに異なるが、多くの場合アプリケーションの挙動を変更するためのパラメータや、Kubernetesクラスタへのデプロイ時の挙動を変更するためのパラメータなどが用意されている。たとえば前述の「stable/wordpress」Chartでは、「global.storageClass」では使用するKubernetesのストレージクラスを、「image.repository」ではイメージ名を指定できる。また、「wordpressEmail」ではWordPressの管理者のメールアドレスを、「mariadb.db.name」ではデプロイされるMariaDBで作成されるデータベースのデータベース名を指定できる。詳しくはドキュメントを参照して欲しい。
Releaseのアップグレードを行う
Helmでは、デプロイしたアプリケーションのアップグレードやロールバックといった機能も提供されている。これを利用して、Chartのアップデートにあわせてアプリケーションを更新したり、またデプロイ時(「helm install」コマンドの実行時)に指定したパラメータを変更する(もしくはパラメータを追加する)といったことができる。
たとえば、先に「stable/wordpress」Chartを使ってインストールしたWordPressについて、新たに「wordpressBlogName」パラメータを追加したい場合、次のように実行する。ここでは、このパラメータに対し「foobar」という値を指定している。
$ helm upgrade wordpress stable/wordpress --set wordpressBlogName=foobar
「helm upgrade」コマンドでアップグレードを行った場合、その履歴はすべて記録されるようになっており、任意のタイミングでロールバックを実行できる。この履歴は、「helm history <Release名>」コマンドで確認できる。
$ helm history wordpress REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Feb 17 19:48:14 2020 superseded wordpress-8.1.3 5.3.2 Install complete 2 Mon Feb 17 20:05:18 2020 deployed wordpress-8.1.3 5.3.2 Upgrade complete
ここでは最初に「helm install」コマンドでインストールしたReleaseがリビジョン(REVISION)1、続いて「helm upgrade」コマンドで更新を行ったReleaseがリビジョン2となっている。
Releaseのロールバックを行うには、「helm rollback <Release名> <リビジョン>」コマンドを使用する。たとえば「wordpress」というRelease名でデプロイされたアプリケーションをリビジョン1に戻すには、次のように実行する。
$ helm rollback wordpress 1 Rollback was a success! Happy Helming!
デプロイされたアプリケーションを削除するには、「helm uninstall <Release名>」コマンドを実行する。たとえば「wordpress」というRelease名でデプロイされたアプリケーションを削除するには、次のように実行する。
$ helm uninstall wordpress
このように、Helmでは単一のChartからコマンド1つでアプリケーションの動作に必要な複数のKubernetesリソースを作成したり、それらをアップグレード/ロールバック/削除したりできる点が特徴となっている。
Chartの作成と変更
Helm向けのChartはすでにさまざまなものが公開されているが、使いたいアプリケーション向けのChartがなかったり、また独自に修正・改良を加えたい、というケースも当然ながらあるだろう。そのため、続いては既存のChartを改変したり、新しいChartを作成したりするための手順を紹介していく。
なお、Chartに関する情報はドキュメントの「Charts」というページにまとめられているので、こちらもあわせて参照して欲しい。
既存のChartをダウンロードする
リポジトリで公開されている既存のChartを修正して使いたいという場合、「helm pull <Chart名>」コマンドでそのChartをローカルのマシン上にダウンロードできる。たとえば「stable/wordpress」というChartをダウンロードするには、次のようにする。
$ helm pull stable/wordpress
「helm pull」コマンドでダウンロードしたChartはtarおよびgzipで圧縮されているので、適宜展開しよう。
$ ls wordpress-8.1.2.tgz $ tar xvzf wordpress-8.1.2.tgz $ ls wordpress
なお、ローカルに保存されたChartからデプロイを行うには、次のようにそのディレクトリを指定して「helm install」コマンドを実行すれば良い。
$ helm install wordpress ./wordpress
Chartの構造
それでは、Chartの構造について見てみよう。Chartには、表1のファイルおよびディレクトリが含まれている。なお、備考が「必須」になっていないものは用意せずともかまわない。
ファイル/ディレクトリ名 | ファイルの内容 | 備考 |
---|---|---|
Chart.yaml | Chartに関する各種メタデータなどが格納されている | 必須 |
LICENSE | Chartのライセンス | |
README.md | Chartのドキュメント(いわゆるREADMEファイル) | |
values.yaml | Chartのデフォルトパラメータ | 必須 |
values.schema.json | パラメータの定義 | |
charts/ | 依存するChartを格納するディレクトリ | |
crds/ | カスタムリソース定義(Custom Resource Definitions)のためのマニフェストファイルを格納するディレクトリ | |
templates/ | Kubernetesのマニフェストファイルを生成するためのテンプレートファイルを格納するディレクトリ | 必須 |
templates/NOTES.txt | 備考(note)などを記述する。このファイルはChartのインストール時に表示される |
まずChart.yamlファイルだが、ここではChartの名前や説明、ホームページ、メンテナといった情報をYAML形式で記述する。たとえば先のstable/wordpressでは、このファイルの内容は次のようになっている。
apiVersion: v1 appVersion: 5.3.2 description: Web publishing platform for building blogs and websites. engine: gotpl home: http://www.wordpress.com/ icon: https://bitnami.com/assets/stacks/wordpress/img/wordpress-stack-220x234.png keywords: - wordpress - cms - blog - http - web - application - php maintainers: - email: containers@bitnami.com name: Bitnami name: wordpress sources: - https://github.com/bitnami/bitnami-docker-wordpress version: 8.1.2
なお、この設定ファイルのapiVersionは「v1」となっており、1つ前のバージョンのフォーマットで記述されている点に注意したい(現行のバージョンは「v2」)。apiVersionがv1のChartは現在のHelmでもサポートされているものの、v2とは若干ではあるが仕様が異なっている。v1とv2を比較した場合での大きな変更点としては、v1では「requirements.yaml」というファイルでChartの依存関係が定義されていたが、v2ではこれらがChart.yamlファイルの「dependencies」フィールドに統合されている点がある(後述)。
さて、ここで設定すべき項目は表2の通りだ。
項目名 | 説明 | 備考 |
---|---|---|
apiVersion | ChartのAPIバージョン。現行では「v2」 | 必須 |
name | Chart名 | 必須 |
version | Chartのバージョン。SemVer 2形式で指定する | 必須 |
kubeVersion | 必須とするKubernetesのバージョン | |
description | Chart内容を説明する文章 | |
type | Chartのタイプ(「application」もしくは「library」) | デフォルトは「application」 |
keywords | 検索などの際に使用されるキーワードをリスト形式で指定する | |
home | ChartのホームページなどのURL | |
sources | Chartで使用しているソースコードを公開しているURLなどをリスト形式で指定 | |
dependencies | Chartが依存するChartについての情報をリスト形式で指定 | |
maintainers | Chartのメンテナに関する情報をリスト形式で指定 | |
icon | Helm Hubなどでの表示時に使用されるアイコン画像のURLを指定(SVGもしくはPNGが使用可能) | |
appVersion | このChartで提供されるアプリケーションのバージョン | |
deprecated | Chartが廃止予定(deprecated)かどうかをbool形式(trueもしくはfalse)で指定 |
このうちdependenciesフィールドについては後述する。また、maintainersフィールドについては表3の要素をもつハッシュのリストで指定する。
パラメータ名 | 説明 | 備考 |
---|---|---|
name | メンテナ名 | 必須 |
メンテナのメールアドレス | ||
url | メンテナのURL |
Chartのパラメータ
前述のように、「helm install」コマンドの実行時には「--set」オプションもしくは「-f <YAMLファイル>」オプションでパラメータおよびその値を指定できるようになっている。そのChartでどのようなパラメータを利用できるかを指定するのが、「values.yaml」ファイルと「values.scheme.json」ファイルだ。
まず「values.yaml」ファイルは、パラメータおよびそのデフォルト値の組み合わせをYAML形式で記述したものだ。たとえばstable/wordpressの場合、次のようになっている(一部のみ抜粋)。
## Bitnami WordPress image version ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.3.2-debian-10-r0 ## Specify a imagePullPolicy ## Defaults to 'Always' if image tag is 'latest', else set to 'IfNotPresent' ## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images ## pullPolicy: IfNotPresent ## Optionally specify an array of imagePullSecrets. ## Secrets must be manually created in the namespace. ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/ ## # pullSecrets: # - myRegistryKeySecretName : :
ここでは、「image.registry」や「image.repository」、「image.tag」、「image.pullPolicy」などのパラメータと、そのデフォルト値が定義されている。
また、「values.schema.json」ファイルはvalues.yamlファイルで指定されたパラメータについて、その型や必須とするパラメータなどを指定するものだ。このファイルはJSON Schema形式で記述するようになっている。記述方法について詳しくはこのJSON Schemaのドキュメントを参照して欲しいが、たとえば次のように指定した場合、「image」というプロパティはオブジェクト形式で、文字列型の「repo」および「tag」というプロパティを持つ、といったことが定義できる。
{ "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, : :
Chartの依存関係
アプリケーションの実行時にほかのアプリケーションが必要となる場合、必要なアプリケーションをデプロイするための設定を別のChartに分離しておくことで、メンテナンス性や再利用性が向上する。このようなChartの依存関係は、Chart.yamlファイルの「dependencies」要素で指定できる。なお、Helmにおいてはこのようにあるチャートが依存するChartのことを「Subchart(サブチャート)」などと呼ぶ。
たとえば先に説明したstable/wordpress Chartでは、WordPressを利用するために必要となるMariaDBをデプロイするためのSubchartが含まれている。これによって、「helm install」コマンドでstable/wordpress Chartをデプロイすると、WordPressだけでなくデータベースのMariaDBも同時にデプロイされる仕組みになっている。
Subchartは、Chart.yaml内(apiVersionが「v1」の場合は「requirements.yaml」という別ファイル内)の「dependencies」プロパティに記述したうえで「charts」ディレクトリにそのChartを格納することで利用できるようになる。
たとえば前述のstable/wordpress Chartでは、「requirements.yaml」内に以下のように記述されている。
dependencies: - name: mariadb version: 7.x.x repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - wordpress-database
これはapiVersionがv1の場合の例だが、v2の場合でもこのrequirements.yaml内のdependencies要素がChart.yamlファイル内に移動されただけで、記述する内容は同じだ。また、stable/wordpress Chartのchartsディレクトリ内にはこれに対応する「mariadb」というChartが含まれている。
$ ls charts mariadb
ちなみに、Chart.yamlがあるディレクトリ上で「helm dependency update」コマンドを実行すると、dependenciesの情報を元に対応するChartの最新版を自動でダウンロードしてchartsディレクトリ内に格納してくれる。
$ helm dependency update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ?Happy Helming!? Saving 1 charts Downloading mariadb from repo https://kubernetes-charts.storage.googleapis.com/ Deleting outdated charts
さて、このdependencies要素では、表4の要素を持つハッシュのリストという形で依存するChartの情報を指定するようになっている。
パラメータ名 | 説明 | 備考 |
---|---|---|
name | 依存するChartの名前 | 必須 |
version | 依存するChartのバージョン | 必須 |
repository | 依存するChartのリポジトリのURL | 必須 |
condition | 依存Chartの有効/無効を切り替えるために使用する設定パラメータ名 | |
tags | 依存Chartの有効/無効を切り替えるために使用するタグ名をリスト形式で指定する | |
enabled | Chartの有効/無効をbool形式(true/false)で指定する | |
import-values | 使用するChartに渡す設定パラメータ。リスト形式で指定する | |
alias | Chartにエイリアスとして割り当てる名前をここで指定する |
たとえばstable/wordpress Chartの例では、依存するSubchartとして「https://kubernetes-charts.storage.googleapis.com/」というリポジトリで公開されている「mariadb」というChartのバージョン7.x.xが指定されており、stable/wordpress ChartをインストールするとデフォルトではこのChartも自動的にインストールされる。この際にはパラメータとして親Chart(この場合はstable/wordpress)内で設定されているパラメータおよびその値がこのChartにも渡される仕組みになっている。
「condition」要素は「helm install」コマンドの実行時にSubchartをデプロイするかどうかを判断するパラメータを指定するものだ。特に設定がされていない場合、Chartのインストール時にはSubchartも自動的にデプロイされる。stable/wordpress Chartでは「condition: mariadb.enable」と指定されているが、この場合stable/wordpress Chartのインストール時に「--set」オプションもしくは「-f <YAMLファイル>」オプションで「mariadb.enable」パラメータの値をfalseに設定すると、このSubchartはデプロイされなくなる。
「tags」要素もconditions要素に似た要素だが、設定パラメータの「tags」要素でSubchartをデプロイするかどうかを判断する点が異なる。たとえば次のように「foo」と「bar」というタグが設定されていた場合、パラメータの「tags」で「foo」もしくは「bar」に「false」が指定されるとそのSubchartはデプロイされなくなる。
tags: - foo - bar
Chartの各種設定ファイルやパラメータからKubernetesのマニフェストファイルを生成するテンプレート
Helmでは、Chartのvalues.yamlファイルで指定されたパラメータや、「helm install」コマンドの実行時に与えられたパラメータをtemplatesディレクトリ内に格納されているテンプレートに与えてKubernetesのマニフェストファイルを作成し、それを適用(apply)することで各種リソースを作成する仕組みになっている。これはGo言語のテンプレート機能(text/template)を使用して実装されており、テンプレートはこの機能でサポートされる書式に従って記述する必要がある。
Go言語のテンプレート機能については「静的サイトジェネレータ「Hugo」と技術文書公開向けテーマ「Docsy」でOSSサイトを作る」という記事内の「Go言語のテンプレート機構」節でも簡単に説明しているので今回は割愛する。詳細についてはGo言語のドキュメントも参照して欲しい。
たとえばstable/wordpress Chartでは、以下の設定ファイルが用意されている。
NOTES.txt _helpers.tpl deployment.yaml externaldb-secrets.yaml ingress.yaml pvc.yaml secrets.yaml servicemonitor.yaml svc.yaml tests/test-mariadb-connection.yaml tls-secrets.yaml
このうち、「NOTES.txt」ファイルはChartのインストール時(「helm install」コマンドの実行時)にユーザーに表示する文章を記述するテンプレートで、「_helpers.tpl」ファイルはChart内で複数回利用されるようなテンプレートや値を定義しておくヘルパーファイルだ。
さて、これらテンプレート内では、values.yamlファイルや「helm install」コマンドの実行時に指定したパラメータに対し、「.Values」というオブジェクト経由でアクセスできる。たとえば「image.registry」というパラメータに対しては「.Values.image.registry」と指定することでその値を参照できる。
また、values.yamlファイルや「helm install」コマンド実行時に指定したパラメータ以外にもいくつかの値が定義済みの値として提供される。これらもテンプレート内で利用が可能だ(表5)。これらについてもドキュメントにまとめられているので、そちらも参照して欲しい。
名前 | 説明 |
---|---|
.Release.Name | helm installコマンドの引数で指定されたリリース名 |
.Release.Namespace | デプロイ先のKubernetesのネームスペース |
.Release.IsUpgrade | リリースを管理するサービス |
.Release.IsInstall | upgradeもしくはrollback時にtrue、そうでない場合はfalse |
.Chart | Chart.yamlファイルの中身がそのまま格納されたオブジェクト |
.Files | Chart内に含まれるファイルの一覧が格納されているオブジェクト |
.Capabilities | 使用しているKubernetes環境の情報が格納されたオブジェクト |
たとえばstable/wordpressのdeployment.yamlテンプレートは次のようになっている(一部抜粋)。
apiVersion: {{ template "wordpress.deployment.apiVersion" . }} kind: Deployment metadata: name: {{ template "wordpress.fullname" . }} labels: app: "{{ template "wordpress.fullname" . }}" chart: "{{ template "wordpress.chart" . }}" release: {{ .Release.Name | quote }} heritage: {{ .Release.Service | quote }} spec: selector: matchLabels: app: "{{ template "wordpress.fullname" . }}" release: {{ .Release.Name | quote }} {{- if .Values.updateStrategy }} strategy: {{ toYaml .Values.updateStrategy | nindent 4 }} {{- end }} replicas: {{ .Values.replicaCount }} template: metadata: labels: app: "{{ template "wordpress.fullname" . }}" chart: "{{ template "wordpress.chart" . }}" release: {{ .Release.Name | quote }} : :
ちなみにstable/wordpress Chartでは、次のように_helpers.tplファイル内でパラメータを元に「wordpress.name」や「wordpress.fullname」といった変数を定義して使用するようになっている。
{{/* Expand the name of the chart. */}} {{- define "wordpress.name" -}} {{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" -}} {{- end -}} {{/* Create a default fully qualified app name. We truncate at 63 chars because some Kubernetes name fields are limited to this (by the DNS naming spec). */}} {{- define "wordpress.fullname" -}} {{- if .Values.fullnameOverride -}} {{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" -}} {{- else -}} {{- $name := default .Chart.Name .Values.nameOverride -}} {{- if contains $name .Release.Name -}} {{- .Release.Name | trunc 63 | trimSuffix "-" -}} {{- else -}} {{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" -}} {{- end -}} {{- end -}} {{- end -}} : :
anotationによるフック指定
Helmでは、テンプレートの「metadata.annotaions」プロパティで「helm.sh/hook」というプロパティを追加し、そこで実行タイミングを指定する値を指定することで、特定のタイミングで作成したいリソースを定義できるようになっている。この仕組みは「hook(フック)」と呼ばれている。
helm.sh/hookプロパティで指定できる値は表6のとおりだ。
指定する値 | 関連する処理 | 実行タイミング |
---|---|---|
pre-install | インストール | リソースの作成前 |
post-install | インストール | リソースの作成完了後 |
pre-delete | 削除 | リソースの削除前 |
post-delete | 削除 | リソースの削除完了後 |
pre-upgrade | アップグレード | リソースのアップグレード前 |
post-upgrade | アップグレード | リソースのアップグレード完了後 |
pre-rollback | ロールバック | リソースのロールバック前 |
post-rollback | ロールバック | リソースのロールバック完了後 |
test | テスト | 「helm test」コマンドの実行時 |
Kubernetesでは、常時実行されるのではなく、処理が完了したら終了するようなコンテナ(ジョブ)を管理するために「Job」というタイプのリソースが用意されており、これとHelmのhook機能を組み合わせることで、特定のタイミングで実行できるジョブを定義することができる。たとえばChartのインストール完了後に実行したいジョブなら、テンプレート内の「metadata.annotations」部分で「"helm.sh/hook": post-install」と指定すれば良い。なお、apiVersionが「v1」のChartではCRDのインストール時(「crd-install」)やテスト時(「test-failure」と「test-success」)を指定するフックが用意されていたが、これらはv2では廃止予定となっている。
hookはJob以外のリソースでも利用可能だ。たとえばstable/mysql Chartでは、templates/tests/test-mariadb-connection.yamlテンプレートでhookを使用したテスト用のPodが定義されている。
{{- if .Values.mariadb.enabled }} apiVersion: v1 kind: Pod metadata: name: "{{ .Release.Name }}-credentials-test" annotations: "helm.sh/hook": test-success spec: containers: *[:] *[:]
ここでは「metadata.annotations」プロパティで「"helm.sh/hook": test-success」と指定されているため、このPodはChartのインストール後、「helm test」コマンドの実行時に作成される。「helm test」コマンドはこのように定義されたリソースを作成してテストを実行するためのコマンドだ。
たとえば、stable/wordpress Chartを「wordpress」というRelease名でデプロイしていた場合、次のようにしてテストを実行できる。
$ helm test wordpress Pod wordpress-credentials-test pending Pod wordpress-credentials-test pending Pod wordpress-credentials-test succeeded Pod wordpress-mariadb-test-cxvx8 pending Pod wordpress-mariadb-test-cxvx8 pending Pod wordpress-mariadb-test-cxvx8 pending Pod wordpress-mariadb-test-cxvx8 pending Pod wordpress-mariadb-test-cxvx8 succeeded NAME: wordpress LAST DEPLOYED: Tue Feb 18 17:58:11 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: wordpress-credentials-test Last Started: Tue Feb 18 18:06:04 2020 Last Completed: Tue Feb 18 18:06:05 2020 Phase: Succeeded TEST SUITE: wordpress-mariadb-test-cxvx8 Last Started: Tue Feb 18 18:06:06 2020 Last Completed: Tue Feb 18 18:06:20 2020 Phase: Succeeded : :
ここでは「wordpress-credentials-test」と「wordpress-mariadb-test-cxvx8」の2つのテストが実行され、いずれも成功していることが分かる。
なお、テストについて詳しくはドキュメントを参照して欲しい。
CRDの定義
Kubernetesでは独自のリソースを定義できる「CustomResourceDefinitions」(CRD)という仕組みが用意されている。独自のCRDを定義したり、それらを使用するようなChartを作成したりする場合は、「crds」ディレクトリ内にCRDを作成するためのマニフェストファイルを格納しておく。このディレクトリ内に格納されたファイルは、templatesディレクトリ以下に配置されているマニフェストファイルが処理される前に、直接YAML形式のKubernetesマニフェストとして処理される。templatesディレクトリ以下のファイルとは異なり、テンプレートによる変数展開などは利用できない点に注意が必要だ。
さらに、HelmではCRDのインストールのみが可能で、再インストールやアップグレード、ロールバックといった処理は行えない。そのため、CRDのアップグレードや削除は手作業で実行する必要がある。
新たなChartを作成する
ここまででChartの基本的な仕様をすべて説明したので、続いては実際に独自のChartを作成してみよう。
helmコマンドでChartのひな形を作成する
helmコマンドでは、Chartを新規に作成するためのひな形を作成する「helm create <Chart名>」コマンドが用意されている。まずはこのコマンドを使ってChartに必要なファイルを生成すると良い。
次の例は、「example」というChart名を指定して「helm create」コマンドを実行したものだ。このコマンドを実行するとChart名と同一のディレクトリが作成され、そこにChartとして利用するために最低限必要なファイルが作成される。
$ helm create example Creating example $ ls -R example/ example/: Chart.yaml charts templates values.yaml example/charts: example/templates: NOTES.txt _helpers.tpl deployment.yaml ingress.yaml service.yaml serviceaccount.yaml tests example/templates/tests: test-connection.yaml
ここでは基本的な設定ファイルやテンプレートに加えて、templates/_helpers.tplといったヘルパーファイルや、テストを記述するtemplates/test/test-connection.yamlといったファイルも作成されていることが分かる。
「helm create」コマンドで作成されたChartには必要な最低限の設定がすべて記述されており、デフォルトではnginxのコンテナイメージをデプロイするよう指定されている。そのため、特に手を加えなくても次のようにインストールが可能だ。
$ helm install example ./example NAME: example LAST DEPLOYED: Fri Feb 14 17:41:59 2020 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: 1. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=example,app.kubernetes.io/instance=example" -o jsonpath="{.items[0].metadata.name}") echo "Visit http://127.0.0.1:8080 to use your application" kubectl --namespace default port-forward $POD_NAME 8080:80 $ helm uninstall example
また、templatesディレクトリ内にはDeploymentを使ってコンテナをデプロイしたり、ルーティングを行うためのServiceリソースを定義したり、外部からサービスにアクセスするためのIngressリソースを定義するための設定ファイルが一通り用意されている。これらはパラメータ設定ファイル(values.yaml)内で定義されているパラメータを参照するようになっており、シンプルなサービスであればこのvalues.yamlファイルを編集するだけで動作するChartが完成する。
これらテンプレートの詳細についてはテンプレートファイル自体やパラメータ設定ファイルのvalues.yamlを見てもらうのが確実だが、values.yamlで定義されているパラメータは次の表7のとおりだ。ただし、今後ひな形ファイルの更新等で仕様が変わる可能性がある点には注意したい。
パラメータ名 | 説明 | 対応するプロパティ |
---|---|---|
replicaCount | デプロイ時のレプリカ数 | Deploymentのspec.replicas |
image.repository | デプロイするコンテナイメージ | Deploymentのspec.template.spec.containers.image |
image.pullPolicy | デプロイ時のPull Policy | Deploymentのspec.template.spec.containers.imagePullPolicy |
imagePullSecrets | コンテナイメージをPullする際に使用するDockerレジストリのアカウント情報 | Deploymentのspec.template.spec.imagePullSecrets |
nameOverride | 作成する各種リソースの名前。ここで指定した名前の前にリリース名とハイフンを付けたものが実際の名前となる | (後述) |
fullnameOverride | 作成する各種リソースの名前。こちらを指定した場合、これがそのまま名前として使われる | (後述) |
serviceAccount.create | trueを指定した場合、ServiceAccountが作成される | |
serviceAccount.annotations | ServiceAccount作成時に指定するannotationsパラメータ | ServiceAccountのmetadata.annotations |
serviceAccount.name | 作成するServiceAccount名 | (後述) |
podSecurityContext | Deployment作成時に指定するPodのsecurityContext | Deploymentのspec.template.spec.securityContext |
securityContext | Deployment作成時に指定するコンテナのsecurityContext | Deploymentのspec.template.spec.containers.securityContext |
service.type | 作成するServiceリソースのタイプ | Serviceのspec.type |
service.port | 作成するServiceリソースに割り当てるポート番号 | Serviceのspec.ports.port |
ingress.enabled | trueを指定した場合、Ingressリソースが作成される | |
ingress.annotations | Ingress作成時に指定するannotationsパラメータ | Ingressのmetadata.annotations |
ingress.hosts | Ingress作成時に指定するホストルール | Ingressのspec.rules |
ingress.tls | Ingress作成時に指定するTLS設定ルール | Ingressのspec.tls |
resources | コンテナのリソース設定パラメータ | Deploymentのspec.template.spec.containers.resources |
nodeSelector | PodのnodeSelectorパラメータ | Deploymentのspec.template.spec.nodeSelector |
tolerations | Podのtolerationsパラメータ | Deploymentのspec.template.spec.tolerations |
affinity | Podのaffinityパラメータ | Deploymentのspec.template.spec.affinity |
ここでnameOverrideやfullnameOverrideといったパラメータは作成されるリソースの名前を指定するもので、これらパラメータを元に_helpers.tplファイル内で実際に指定する名前を組み立てるようになっている。具体的には、これらのパラメータが指定されていない場合は「<リリース名>-<Chart名>」が作成される各種リソースの名前になる。nameOverrideパラメータが指定されていた場合、nameOverrideパラメータで指定された値がChart名の代わりに使用される(「<リリース名>-<nameOverrideパラメータで指定された値>」がリソース名になる)。一方、fullnameOverrideパラメータが指定されていた場合、それがそのままリソース名として使われる。
serviceAccount.nameパラメータについては、これが指定されていない場合はほかのリソースの同じ名前が、指定されていた場合はその値が作成されるServiceAccountの名前として使われる。
また、使用するコンテナイメージはimage.repositoryパラメータで指定できるのだが、タグとしてChart.yamlで記載したappVersionの値が指定される点に注意したい(「<image.repository>:<appVersion>」というコンテナイメージが使われる)。Chart.yaml内のappVersionパラメータで忘れずに使用するタグを指定しておこう。
これらを踏まえ、実際に独自のChartを作成する際には次のような手順で設定ファイルの修正を行っていけば良い。
- Chart.yamlファイルを編集し、Chartの基本的な情報やappVersionを指定する
- values.yamlファイルを編集し、使用するコンテナイメージファイルやServiceに割り当てるポート番号、ServiceAccountおよびIngressを作成するかどうかを指定する
- templates/deployment.yamlを編集し、作成するPodのパラメータなどを変更する
- templates.service.yamlを編集し、使用するポートなどの情報を変更する
- 必要に応じてserviceaccount.yamlやingress.yamlを編集してパラメータや設定を変更する
もちろんこれ以外のリソース定義が必要な場合や、依存するChartがある場合はそれらに関しての設定変更や設定ファイル編集が必要だ。また、デフォルトのDeployment設定では、「http://<コンテナのIPアドレス>/」というURLにアクセスしてコンテナの死活監視を行う設定になっている。必要に応じてURLを変更するか、無効にしておこう。
たとえば次の例は、HTTPでのリクエストに対し指定したテキストを返すだけのテスト用コンテナイメージであるhttp-echo:0.2.3をデプロイするChartを作成するものだ。
1. Chart.yamlを編集し、descriptionなどを変更するとともに、appVersionを0.2.3に変更する
# This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application. appVersion: 0.2.3
2. values.yamlでimage.repositoryを「hashicorp/http-echo」に、service.portを「5678」に設定する。また、http-echoでは「-text」という引数でレスポンスとして送信する文字列を指定できるようになっているので、httpEcho.textというパラメータを追加し、適当なデフォルト文字列(今回は"hello")を指定する
httpEcho: text: "hello" image: repository: hashicorp/http-echo pullPolicy: IfNotPresent : : service: type: ClusterIP port: 5678
3. templates/deployment.yamlを編集し、Pod作成時の引数を指定するspec.template.spec.containers.argsの追加や使用するポートの変更、spec.template.spec.containers.livenessProbeおよびspec.template.spec.containers.readinessProbeの設定変更を行う
: : containers: - name: {{ .Chart.Name }} securityContext: {{- toYaml .Values.securityContext | nindent 12 }} image: "{{ .Values.image.repository }}:{{ .Chart.AppVersion }}" imagePullPolicy: {{ .Values.image.pullPolicy }} ports: - name: http containerPort: 5678 protocol: TCP livenessProbe: httpGet: path: / port: 5678 readinessProbe: httpGet: path: / port: 5678 resources: {{- toYaml .Values.resources | nindent 12 }} args: [ "-text=\"{{ .Values.httpEcho.text }}\"" ] {{- with .Values.nodeSelector }} : :
4. templates/service.yamlを編集し、コンテナ側のポート番号を5678に変更する
apiVersion: v1 kind: Service metadata: name: {{ include "example.fullname" . }} labels: {{- include "example.labels" . | nindent 4 }} spec: type: {{ .Values.service.type }} ports: - port: {{ .Values.service.port }} targetPort: 5678 protocol: TCP name: http selector: {{- include "example.selectorLabels" . | nindent 4 }}
以上の作業完了後、「helm install」コマンドでChartをインストールすると、アプリケーションのデプロイが行われる。
$ helm install example example NAME: example LAST DEPLOYED: Fri Feb 14 19:43:24 2020 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: 1. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=example,app.kubernetes.io/instance=example" -o jsonpath="{.items[0].metadata.name}") echo "Visit http://127.0.0.1:8080 to use your application" kubectl --namespace default port-forward $POD_NAME 8080:80
これで「example」というDeploymentやServiceが作成され、それによってPodが作成される。
$ kubectl get deploy example NAME READY UP-TO-DATE AVAILABLE AGE example 1/1 1 1 16m $ kubectl get svc example NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE example ClusterIP 10.106.8.38 <none> 5678/TCP 16m
また、ServiceのIPアドレス(この例の場合10.106.8.38)の5678番ポートにHTTPでアクセスすると、values.yamlで指定した文字列がレスポンスとして返される。
$ curl 10.106.8.38:5678 "hello"
今回作成したChartでは、「httpEcho.text」というパラメータで返される文字列を変更できるようになっている。たとえば次のようにしてパラメータを指定して「helm upgrade」コマンドを実行すると、実際に文字列が変更されることが確認できる。
$ helm upgrade example example --set httpEcho.text="foobar" $ curl 10.106.8.38:5678 "foobar"
リポジトリでChartを公開する
HelmではChartを公開するための独自リポジトリを容易に作成できるようになっており、これを利用すれば簡単に最新バージョンのChartをネットワーク経由でダウンロードしてインストールできるようになる。最後に、このリポジトリの作成方法を紹介しておこう。
Helmで使用するリポジトリ(Chartリポジトリ)では特別なソフトウェアなどは不要で、公開するChartの情報を含む「index.yaml」というインデックスファイルと、tar.gz形式で圧縮したChartをHTTP(もしくはHTTPS)で公開するだけで良い。helmコマンドにはこれらを行うためのサブコマンドも用意されている。
たとえば、先で作成した「example」Chartを公開するリポジトリを作成するには、まずこのChartのディレクトリを丸ごと含むアーカイブファイルを「helm package <ディレクトリ>」コマンドで作成する。
$ helm package example/ Successfully packaged chart and saved it to: /home/hylom/helm_test/mychart/example-0.1.0.tgz
また、index.yamlファイルは「helm repo index <ディレクトリ>」コマンドで作成できる。カレントディレクトリを対象にindex.yamlファイルを作成するには、次のように実行する。
$ helm repo index .
これで、ディレクトリ内にtar.gz形式で圧縮されたChartと、index.yamlが作成された。あとはこれらのファイルを適当なWebサーバーで公開すれば良い。
$ ls example-0.1.0.tgz index.yaml
このようにして公開されたChartを利用するには、ほかのChartレポジトリを利用する場合と同様にまず「helm repo add」コマンドでリポジトリを追加する必要がある。たとえば次の例では、「mycharts」という名前でリポジトリの登録を行っている。
$ helm repo add mycharts <リポジトリのURL>
リポジトリの登録後、「helm search repo」コマンドでリポジトリを検索すると、先ほど作成した「example」Chartが利用できるようになっていることが分かる。
$ helm search repo mycharts NAME CHART VERSION APP VERSION DESCRIPTION mycharts/example 0.1.0 0.2.3 A Helm chart for Kubernetes
また、次のように「mycharts/example」と指定して「helm install」コマンドを実行することで、このChartをインストールできる。
$ helm install example mycharts/example
なお、Chartを不特定多数に公開するようなリポジトリを作成する場合にはリポジトリをHTTPSで公開したり、作成者を保証できるようにしたりするための「provenance record」(直訳すると「起源記録」)と呼ばれる情報を記録したファイルをリポジトリ内に用意することが推奨されている。これについて詳しくはドキュメントのHelm Provenance and Integrityページを参照して欲しい。
Kubernetes上へのデプロイ管理ツールとして必要十分、ただ設定関連には慣れが必要
ここまでで解説してきたとおり、Helmの本質はパラメータとテンプレートを使ったマニフェストファイルの自動生成であり、提供している機能は非常にシンプルだ。とはいえ、Kubernetesクラスタにアプリケーションを柔軟性のある形でデプロイするという問題に対しては十分な解決手段となっている。ただ、多くのChartでは設定できるパラメータが膨大になっているという問題もある。柔軟性を確保するためには仕方がないのかもしれないが、ユーザービリティとしてはあまり好ましくない。
一方で、ひな形の自動生成機能を活用することで、シンプルなものであれば比較的容易に独自のChartを作成できる点は便利だ。また、アップグレードやロールバックの仕組みが用意されている点も有用だ。既存のChartを使わず、単に独自のアプリケーションのデプロイツールとして利用するだけでも十分に利用価値がある。すでにHelmはKubernetesの事実上標準的なデプロイ管理ツールとなっていることもあり、習得しておいて損はないだろう。