Kubernetesマニフェストのテンプレートエンジンは必要だ、と気づいてしまったので、マニフェストを生成できるツールを探していました。そこで、Kustomizeを試しみたのでアウトプットとして残しておきます。使ってみた上でハマったポイントや注意すべき点なども含めて書きたいと思います。xxxxですぐにデプロイできるし、最高だなって思ってました。いざ、開発環境と本番環境の2つのNamespaceで利用したくなったり、運用のことを考えるといろいろと不都合が発生してきました。開発環境と本番環境でパラメータが変えたいことがある本番環境だけ入れたいリソースがある(例えばLoadBalancerは本番だけほしいなど)イメージをLatestで使いたくない。タグ指定したいが、都度手動で変更したくないconfigMapやsecretの変更したときのアプリ側の再起動どうしよう、などこうなってきたときに、「あっ。マニフェストのテンプレートエンジンが必要だ。v1.14からkubectlに統合されたKustomizeが便利そうだったので、そちらでまずは使い勝手を試してみようと思い立ったわけです。managementのツールです。files)になります。kustomization.ymlにはどのマニフェストファイルを対象にするか、そしてそれらに対してどのような変更や修正、変数を割り当てるかを記述するかたちです。最終的なアウトプットとしては、変更・修正が施されたマニフェストファイルの中身がアウトプットされます。公式ドキュメントにも書いてありますがマニフェストに対するsedみたいな一面があります。ドキュメントKustomizeを実際に触っていく上でハマったポイントもあったのでご紹介します。v1.14からkubectlに組み込まれることになりました。-hでヘルプを見てみてもわかります。url.kubectlに統合されているのはバージョンが最新のものではありません。Kustomizeも進化が早いので機能差分がでてくることもめずらくありません。自分も使っていく中で何度か下記のようなエラーメッセージに出くわしました。下記の例だと、envsというフィールドがありませんというエラーです。公式ドキュメントを見て記述していたのですが、kubectlに見込まれているバージョンではそのフィールドがなかったということです。"envs"そのため、ドキュメントをみる場合は使っている方法に合わせて使い分けるといいです。WorldKustomizeはサンプルもいくつか用意してくれているので始めるのは簡単です。World的にはこちらが良いと思います。kustomization.ymlが下記の通り書いてありますが、resourcesに記載の3ファイルを対象に共通のlabelを付与するという意味になります。Worldの例ではマニフェストにconfigMap.yamlが含まれていましたが、configMapを生成するには、もうひとつconfigMapGeneratorという機能を使うこともできます。(公式ドキュメント)こちらの機能を使うと、configMapを作成時に名前にハッシュ値が付きます。configMapに変更があった場合に、そのハッシュ値も変更され別のconfigMapとして保存されます。そのconfigMapを参照しているDeploymentなどのconfigMapの名前も変更してくれます。それによって、configMapを変更時にアプリ側のPodsの再作成もされます。運用面を考えると非常に便利な機能です。以下に自分のいいたいことが全て書かれていたので、詳細についてはこちら参照してみてください。kustomizeでconfigMapを取り扱うときの注意overlay自分がKustomizeを触ろうとした主なモチベーションの部分である、環境ごとにパラメータを変えたい、一部のリソースを変えたいというニーズにはoverlayという機能で対応することができます。overlayは名前の通り「覆う」的な意味なので、Baseのマニュフェストを用意して、環境ごとにパッチ当てするマニフェストを用意する、という形になります。今回こんなサンプルを作りました。(コードはこちら)Nginxをデプロイする開発環境用はnamespaceをdevelopmentに、本番環境用はnamespaceをproductionにする本番環境用のNginxのServiceはType=LoadBalancerにするファイル構造はこのような形です。kustomization.ymlbaseには共通のマニフェストです。出力すると下記のとおりです。見ておいてほしいのはnginx-servceのTypeです。baseマニフェストではClusterIPを指定しています。80しかし、本番環境ではNamespaceを指定して、TypeをLoadBalancerで公開したかったとします。以下は本番環境用にパッチ当てするためのkustomization.ymlなのですが、baseのマニフェストを指定し、namespaceとパッチを当てるマニフェストを指定しました。80このようにして、本番環境用のパッチを当てて出力すると、typeがLoadBalancerに変わっていることがわかります。これで、1つのマニフェストを使って環境ごとにパラメータや一部のリソースを変更してデプロイできそうです。80まとめKubernetesの初歩の勉強をしているうちはあまり必要性を感じないのですが、それなりに「運用」をみすえると、マニフェストを自動で生成する必要性がでてきます。その1つの方法としてKustomizeというツールを触りました。kubectlにも統合されているので比較的簡単にはじめることができますし、自分がやりたいと思っていたことは問題なく実現できることがわかりました。今後使っていくなかで、また知見がたまればおしらせします。Shopを使ったマイクロサービス体験のハンズオン「捉」2019年振り返り「LeanとDevOpsの科学」を読んで。