Helm vs Kustomize vs kpt: K8s設定管理
Helmはテンプレート化されバージョン管理されたchartでKubernetesアプリをパッケージ化し、Kustomizeはoverlayでベースmanifestにパッチを当て、kptはfunctionを使ってpackageとして設定を管理します。
HelmはGoテンプレートとvaluesを使って再利用可能なchartをレンダリングおよびバージョン管理し、releaseとrollbackを備え、アプリの配布に理想的です。KustomizeはテンプレートなしのプレーンなYAMLベースに宣言的なoverlayを適用し、manifestを有効かつdiffしやすい状態に保ち、kubectlに同梱されています。kptは設定をfunctionで変換されるバージョン管理されたpackageとして扱い、GitOpsスタイルのパイプラインを重視します。これらはtemplating、overlaying、package-functionという哲学を表しています。
| Helm | Kustomize | kpt | |
|---|---|---|---|
| アプローチ | Templating + values | Overlayパッチ | Package + functions |
| Templating | Goテンプレート | なし (純粋なYAML) | Functions |
| バージョン管理 | Chart release | Git | Packageバージョン |
| kubectlに組み込み | いいえ | はい | いいえ |
| 最適な用途 | アプリ配布 | 環境overlay | GitOps設定パイプライン |
アプローチと重複
Helmはパラメータ化されたvaluesとrelease管理でアプリをパッケージ化・共有するためのデフォルトです。KustomizeはテンプレートなしでプレーンなYAMLと環境ごとのoverlayを好むチームに適しており、GitOpsと相性が良いです。kptはパイプライン内で再利用可能なfunctionによって変換されるバージョン管理された設定packageを望むチームに向いています。HelmとKustomizeはしばしば組み合わせて使われます (chartをレンダリングしてからパッチを当てる)。
CIにおいて
CIでlintとtemplate-renderを行い (helm lint/template、kustomize build)、その後manifestをクラスターAPIに対して検証しpolicyチェックを実行します。3つすべてがマネージドrunner上で動作し、より高速なrunnerがrender、validate、deployの各ステップを短縮します。
結論
パラメータ化とreleaseを伴うアプリのパッケージ化と配布: Helm。プレーンなYAMLでoverlayベースの環境ごとの設定: Kustomize。GitOpsのためのfunctionパイプラインを備えたバージョン管理された設定package: kpt。多くのチームはサードパーティのchartにHelmを、自前のoverlayにKustomizeを使い、function駆動のGitOps構成ではkptに頼ります。