Helm VS Kustomize
背景
Kubernetes上でマイクロサービスアーキテクチャを実現する上で大量のmanifestの管理は避けて通れない。
この問題を解決するには、共通部分を使い回しやすくする仕組みが求められる。
Kubernetes上でmanifestを管理しやすくするツールは複数開発されており、Helmや、Kustomizeなどが有る。
冒頭で挙げた共通部分を使い回しやすくする上で、どのツールが適しているかについて簡単に検討する。
前提
いきなり、網羅的でなく恐縮ですが、HelmとKustomize以外のツールは今回の比較から除外します。
除外されたツールは主にKsoonet、Kapitan、Kubecfgを指します。
以下、理由になります。
- KapitanとKubecfgはGitOpsツールのArgo CDが対応していないため（今回はGitOpsのワークフローで使用することを前提としている）
- KsoonetはYAMLの形態からかけ離れており、マイクロサービスで複数チームが都度使うにはKubernetesの学習に加えて更に学習コストが高くなりそうに早々に思えたため。
結論
早速ですが、私の結論です。
- アプリケーション開発においてはKustomizeが適している。
- 共通部分の管理しやすさ、設定変更の容易さ、ConfigMapの作成難易度を低下、dev環境・prd環境へのデプロイの切り替えの容易さなど、開発面で重宝されるような機能が多い。
- アプリケーション配布においてはHelmが適している。
- Helmはあくまでパッケージマネージャー
- 設定の変更を限定させることができ、想定外の使われ方が起きづらい。
- Helmリポジトリから配布するといった利用者までの提供の導線が既に有る。
つまり、kubernetes上でマイクロサービスアーキテクチャで開発したいという要件であればKustomizeが適していると考えます。
最初はKustomizeのひな形を作って各チームに配布、個別要件があれば上patchで上書きする形が悪くないと思っています。
一方で、マイクロサービスアーキテクチャに必要なメッセージキューなどの共通ミドルウェアの配布にはHelmでも良いのでは無いかと考えます。（Kustomizeでも良いと思いますが。）
検討
Helmのメリット
- 利用者にパッケージ化して提供できる。（yumやaptのような感覚で）
Helmのデメリット
- Helm Chartを最初は作成する必要がある
- 後続のデメリット理由から、Chart自体のを変更する必要が有る＋学習コストから再利用性が低い。
- カスタマイズ性が低い
- 設定が穴埋め方式。
- Template内で変更したいフィールドが公開されていない場合、Helm リポジトリからフォークしてChartを書き換える（自分で穴をあけてあげる）必要が有る。
- Go Templateの学習コストが高い
Kustomizeのメリット
- 共通のnamespaceやLabelを簡単に書ける
- kustomiztion.ymalに記述するだけ
- Kustomization.yaml以外は既存のmanifestと同様なので、HelmのGo Templateに比べれば学習コストは極小
- カスタマイズ性が高い
- 設定は穴埋め方式ではなく、上書き方式
- 上書きしたい内容を既存のmanifestの形式で書いてpatchとして当てればOK
- ConfigMapのGeneratorが用意されている。
- kubectlに統合された
Kustomizeのデメリット
- Helmと比較すると第3者への配布の仕組みが弱い。
最後に
上記は私の私見を多く含みます。
結論ありきなメリデメ比較になってしまったとも思っているので、有識者からのコメントをお待ちしております。
メリデメには書きませんでしたが、Git上でのSecretの扱いも課題感として持っています。これについても良い解決策があればコメントをお待ちしております。