Kustomizeを数週間触ってみての所感
このエントリーは、Kubernetes2 Advent Calendar 2018の11日目の記事です。
Kustomizeは、HelmやKsonnetのようなmanifestのテンプレーティングツールの1つです。 「Kustomizeとは」とか基本的な使い方の話は、@ryodocxさんのQittaの記事に非常によくまとまっていますのでそちらを参照ください。このエントリーでは、とある経緯でKustomizeを数週間ほど触ってみたので、そこで感じた諸々を書いていきたいと思います。
良かったところ
良かったところを書いていきます。
とっつきやすい
基本のmanifestを作っておいて、変更したい部分はそこだけを抜粋したmanifest(Overlay)を書いて被せるという仕組みです。
このやり方のおかげで、以下のようなメリットがあると思います。
- 仕組みが直感的に理解しやい（少なくとも自分には）
- 基本的なことをやる分にはカスタマイズのために新たな文法を覚える必要がなく、入門時の学習コストがとても低い
Tillerいらない
Kustomizeで生成したmanifestはそのままKubernetesに適用可能なものができ上がります。このため、HelmのTillerのようにクラスター側に何かを用意する必要がありません。
管理対象が少ないのは良いことです。
ConfigMap/Secret Generatorは便利
ConfigMap/Secret Generatorは、適当なランダム文字列つきのConfigMap/Secretを生成して、他のリソースからの参照も自動で書き換えてくれる機能です。
変更頻度の高い設定をConfigMap/Secretで渡すようにすると、同じ名前で設定値が違うリソースが量産されて管理が困難になります。この機能を使うことで「設定が異なる場合はリソース名を変える」というポリシーを自動で適用できることになるので、使わないよりも管理しやすくなるんじゃないでしょうか1。
うーんなところ
あまり良くないんじゃないかと思ったところを書いていきます。
Baseのリソースが消せない
上述のように直感的にmanifestのカスタマイズができる一方で、自由度があまり高くないように感じました。特に、baseのリソースをOverlayで消すということが現状ではできないようで2、自分のユースケースではこれが結構なダメージでした。
例えば、開発環境ではコンテナのMySQL、ステージング／本番ではRDSなどクラスター外のマネージドサービスを利用したいとします。 ここで、Baseだけでアプリが動くmanifestのセットとして成立させたいと思って、BaseにMySQLのコンテナのmanifestを書いてしまうと、ステージング／本番用のOverlayでこれを消すことができません。
仕方なくBaseにはDBを除いた要素だけを書き、開発環境用のOverlayでコンテナのMySQLを足すことになるわけですが、データストアのないアプリだけのmanifestがBaseに残ることになります。
Baseっていうものの位置づけとしてこれでいいのだろうか、良くない気がする。
イメージのタグを更新したいだけなんですが
GitOpsをやる場合、manifest中に書かれたコンテナイメージのタグを変更するということをよくやると思います。
Kustomizeは1)Overlayを書いて2)それを被せる、という形でコレを実現することになるため、Overlayのファイルの編集が必要になります。kustomize editコマンドやsedでこれをやるのですが、せっかくOverlayの仕組みがあるのにやはり編集が必要なの…、という残念感が否めません。
Helmだと変数なタグの文字列を埋め込むだけなので、スマートというか普通な感じで実現できます。考え方の違いといえばそれまでなのかもしれませんが…。
まだバギーですかね…？
Kustomzeを触った数週間で、2つほどバグらしき挙動に遭遇しました。片方は結構ダメージが大きくて、本番に耐えるmanifestを作るには結構な制約になってしまうものでした。
まだ治ってなかったら、年末休みの時間を使ってPR出そうと思います。
以上でございます。まだまだ発展途上のツールですので、今後に期待したいと思います！
