本記事はPostgreSQL on Kubernetes Advent Calendar 2018の24日目です。
25日間のアドベントカレンダーも残り2日となりました。ここからはPostgreSQL on Kubernetesの今後の進め方で必要となる要素を検討していきたいと思います。
TL;DR
- Kubernetesで検証をすすめると、大量のYAMLが出来上がる。
- Helmでテンプレート化しておくと後で役に立ちそう。
- もっと進めてOperator化も検討しよう。
PostgreSQL on Kubernetesの検証で積み上がったもの
これまでPostgreSQLインスタンスを分散ストレージであるRookやAmazon EBS上で動かす検証を続けてきました。KubernetesのワークロードとしてもStatefulSetを中心にDeploymentなども差異を検証しています。
さらにモニタリングのデファクトツールであるPrometheusやGrafana、DBやストレージを監視するexporterも導入してみました。
結果として残ったものは、大量のYAMLファイルです。
- PostgreSQLのRook/EBS対応版、StatefulSetとDeploymentで22ファイル
- Rook-Cephの構築用、6ファイル
- Prometheusのオペレータなどの構築用、6ファイル
ここまでで合計34ファイル、PostgreSQL用ファイルは特に美しい構成とは言えず、似たようなものが粗製乱造されています。
Helmの出番か？
改めていうまでもなく、HelmはKubernetesのパッケージ・マネージャーという位置づけのソフトウェアであり、Linuxにおけるaptやyumに相当するものと私は理解してきました。
しかし先日、#ochacafeというイベントで勉強させて頂いて認識を改めました。
詳しくはこちらのスライドにありますが、Helmは様々な環境別のマニフェストを生成するテンプレートエンジンと理解するのが正しいようです。
現状のpostgres-on-k8sリポジトリ
githubの現状のディレクトリを見てみると、以下のような構成になっています。
pg-ebs/ # EBSを利用したPostgreSQL StatefulSetのディレクトリ
pg-rook/ # Rook/Cephを利用したPostgreSQL StatefulSetのディレクトリ
|- ds/ # Rook/Cephを利用したPostgreSQL Deploymentのディレクトリ
pg-local-sf-pvc.yaml # Local Node Pathを利用したPVCのyaml
pg-local-sf-service.yaml # Local Node Pathを利用したServiceのyaml
pg-local-sf.yaml # Local Node Pathを利用したStatefulSetのyaml
環境差異となるのは利用するストレージ、そしてStatefulSetかDeploymentかなので、少なくとも前者はテンプレート化が可能なはずです。
Helm化するとしたら
これは実際にHelmのリポジトリを作成しようと思っていたのですが、明日までに作れそうな気がしないため、一旦想定段階での説明となります。
上で書いたストレージが異なるPostgreSQL on KubernetesをHelm化した場合、以下のようなディレクトリ構成になると思われます。
pg-k8s/
|- Chart.yaml # チャートの概要を記述したYAML
|- values.yaml # デフォルト設定値を記述したYAML
|- templates # リソースYAMLを配置
|- pg-k8s-sf.yaml # PostgreSQLのStatefulSet用YAML
|- pg-configmap.yaml # 初期DB、ユーザを設定するConfigMap用YAML
|- pg-postgres_conf.yaml # 初期DB、ユーザを設定するConfigMap用YAML
|- pg-k8s-sf-service.yaml # PostgreSQL用のサービス(Headless Service)用YAML
|- pg-rook-storageclass.yaml # Rook/CephのStorageClass用YAML
|- pg-rook-pvc.yaml # Rook/CephのPVC用YAML
|- pg-ebs-storageclass.yaml # EBSのStorageClass用YAML
|- pg-ebs-pvc.yaml # EBSのPVC用YAML
|- pg-local-pvc.yaml # ローカルパスを利用する際のPVC用YAML
今回のAdvent Calenderで上記のHelm化に取り組もうと思っていたのですが、目下の問題は**「Go言語のテンプレートエンジンとしてのHelm利用」**が私にとって簡単でない、ということです。[こちら]
(https://qiita.com/thinksphere/items/5f3e918015cf4e63a0bc#%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88dsl)のブログを参考にさせて頂いたのですが、Go言語の開発経験者ではなく一介のインフラエンジニアには指摘の通り、敷居が高いです。
学習コストを取るならOperatorか？
今回のPostgreSQL on Kubernetesのリポジトリをテンプレート・エンジンを用いて効率的に管理するという手法とは別に、ステートフルなアプリケーションであるPostgreSQLインスタンスの管理を効率化・自動化するというアプローチがあります。
それがOperator-Frameworkです。
Operatorについては、7月のJTF、そして12月のJKDでも本家のRedhatの方のセッションがあり、個人的に注目している（が、まだ触っていない）技術です。JKDの資料が非常に分かりやすかったのですが、資料が見つからなかったのでこちらのJTFの資料を紹介しておきます。
これを使ってやりたいことは以下となります。
- #7で紹介したStatefulSetでノードDOWN時にフェイルオーバしない部分のカスタマイズ
- #15で紹介したフェイルオーバー/フェイルバックといったクラスタの基本操作
- #16で紹介したバックアップ、リストアの省力化
上記のような目論見は例えば、MySQLのOperatorでは一部実現されており、PostgreSQLでも#1で紹介したStolonのような事例がいくつかあります。そして何より、今回利用しているRookやPrometheusもOperatorが用意されており、今回の検証で利用しています。
こちらも今回のアドベントカレンダーでの検証は叶いませんでしたが、PostgreSQL on Kubernetesとしては是非取り込みたいfeatureです。
卵（Operator）が先か、ニワトリ（Helm）が先か
といいつつ、実はJTFでも紹介されていたようにHelm App Operator Kitというものがあります。
※ブログでの紹介はこちら。
これはその名の通り、Helmチャートを作っておくとOperatorが作れるというSDKです。つまり、YAMLを沢山積んで満足するのではなく、ちゃんとHelm化しておくと良いことあるよ、ということですね！
まとめ
今日はこれまでの記事のまとめとして、検証で大量に作成したYAMLを今後どのようの資産としていくかについて検討してみました。残念ながら今回は検証までたどり着けませんでしたが、HelmもOperator Frameworkも是非試したいと思います。
よろしくお願いします。