Red HatでOpenShiftのサポートをしているid:nekopです。OpenShift 全部俺 Advent Calendar 2018 - Qiitaの6日目のエントリです。
JapanContainerDays v18.12でも何度か話題になったのですが、データベースをKubernetes上で動かすのは良くないであるとかアンチパターンである、というようなお話が何度かありました。直接聞いたわけではなく伝聞であるケースが多いので、きちんと理由まで説明されていたかどうか、というところは少し不安です。
まず、このような使い方はKubernetesの公式ドキュメントにも普通に載っています。OpenShiftのユーザの方は普通にMySQLやPostgreSQLデータベースをOpenShift上で動かしていますし、デフォルトでカタログに入っているので数クリックで利用可能です。
KubernetesでMySQLのようなデータベースを動かすには、MySQL podをデプロイしてPVにReadWriteOnceなブロックストレージをattachするだけです。ブロックストレージというのはたとえばAWSであればEBSのPVです。iSCSIやFC接続のストレージでも良いでしょう。このようなブロックボリュームをattachしたVMでMySQLを動作させるのと、ブロックボリュームをattachしたコンテナでMySQLを動作させるのと、何か異なるでしょうか。
普通に利用するだけであればコンテナでも問題ないでしょう。コンテナにすることで障害などが発生した場合は(多少時間はかかりますが)自動復旧する、という利点はデータベースのpodでも同様です。ただし当たり前ですが旧来のRDBMSは同一データを参照したまま2 podsにスケールアップしてもそのまま動作する、などということはない(データが壊れる、もしくは起動しない)ので、常に1 podで運用することになります。Rolling Updateを使った無停止アップデートなども途中で2 pods同時稼働が必要になるのでもちろんできません。
データベースのマネージドサービスを利用するほうが本番運用が簡単、という意見であれば恐らくその通りです。ただし、開発時に開発者ごとにデータベースも割り当てたい＆ローカルで完結したい、というようなマネージドサービスが不向きなユースケースもあります。他にもデータベースの前提要件やドキュメントでVMが想定されているので、コンテナだと必要な設定が適用できない、パフォーマンスを限界までチューニングできない、HA対応しているデータベースでもコンテナの制約でHA構成ができない、周辺ツールがVMじゃないと動作させることができない、といった様々なケースはあります。
データベースのHA構成はOperatorなどの管理ツールを作成すればKubernetes上に構成可能です。しかし、そこまでのコストをかけてHA構成のRDBMSをk8sに持ち込むというのはあまり良いアプローチではないでしょう。ネイティブでHAをサポートするetcdやCassandraなどのNoSQLタイプのクラウドネイティブなデータストアを利用したほうが良いと思います。いくつかのメジャーなデータストアはk8sで利用するためのOperatorが用意されています。
そのような制限を理解した上で、あまり規模の大きくない、特殊な運用も必要ない普通のデータベースをk8s上で動かすのは問題ありません。もちろん本番環境までその構成で運用できるかどうか、という話であればケースバイケースの部分が大きいので、運用時に必要になるアクションや周辺ツールの確認を行った上で決める必要があるでしょう。
