運用環境でKubernetesを使用してクラスターデータベースを実行することをお勧めしますか？

Question

運用環境でMySQLなどのクラスタ化されたデータベースにKubernetesを使用することは妥当ですか？

mysql galera exampleのような構成例があります。ただし、ほとんどの例では、永続ボリュームを使用していません。私が理解している限り、永続ボリュームはここで定義されているような共有ファイルシステム上に存在しなければなりませんKubernetes types of persistent volumes。共有ファイルシステムは、ポッドのデータベースファイルがポッドをホストしているマシンに対してローカルになることを保証しません。それはむしろ遅いネットワークを介してアクセスされます。さらに、MySQLやNFSにも問題があります。

これは、テスト環境では問題ありません。しかし、私はプロダクション環境で何をすべきですか？データベースクラスタをKubernetes以外で実行し、Kubernetesでアプリケーションサーバだけを実行する方が良いでしょうか？

Answer 1

Kubernetesプロジェクトは、ステートフルなアプリケーションを実行するための新しいポッド管理の抽象化であるPetSetsを導入しました。 現在は（バージョン1.4以降）のアルファ機能であり、急速に動いています。ベータ版に移行する際のさまざまな問題のリストはhereです。 when to use petsetsのセクションから引用：

PetSetは、一意のIDを持つ指定された数の「ペット」が常に実行されていることを保証します。ペットの識別がで構成されています：DNSで利用できる、

• 安定したホスト名
• 序インデックス
• 貯蔵安定性：序&ホスト名に加えて

にリンククラスタ化されたステートフルアプリケーションを展開して管理するのに役立ついくつかの他の機能と組み合わせることができます。たとえば、dynamic volume provisioningと組み合わせると、ストレージを自動的にプロビジョニングするために使用できます。

MySQLでReplicaSetsとDeploymentsを使用して利用可能ないくつかのYAML設定ファイル（参照しているものなど）があります。これは実稼働環境で実行されている可能性があります。しかし、PetSetsは、アップグレード、メンテナンス、スケーリングなどをサポートしながら、これらのタイプのワークロードを実行することを非常に簡単にすることが期待されています。

petsets hereを使用して分散データベースの例を見つけることができます。

---

ネットワーク化され、非ローカル（GlusterFSなど）である永続ボリュームをプロビジョニングする利点は、大規模に実現されます。しかし、比較的小規模のクラスタでは、今後local storage persistent volumesを許可する提案があります。

---