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