DB Operatorは、 Kloeckner-i社が開発した、Google Cloud SQL (GCSQL)を中心としたクラウドデータベースの管理を目的とした Kubernetes Operatorです。DB Operatorでは、Kubernetes Custom Resources (CR)を利用してGCSQLデータベースを作成することができます。データベースをKubernetesリソースとしてデプロイすることが可能になり、Kubernetes上で独自のステートフルデータベースを稼働させるという大変な作業をしなくてすむようになります。 Background Kloeckner-iでは、各機能ブランチのオンデマンド環境を作成するなどの高度なCI/CD戦略を利用しています。これらの環境のためのKubernetesリソースマニフェストは、アプリケーションのソースリポジトリに格納されています。 しかし、データベースをポッドとして実行することは、以下の点で上手く機能していないため、利用可能性が高いとは言えないし、本番に備えているとも言えません。 • Kubernetes の永続ボリュームは簡単にサイズ変更できない。 ・ポッドを別のノードに再スケジューリングした場合、永続的なストレージを切り離して再接続しなければならず、これには時間がかかることがある。 ・永続ボリュームを別のノードにデタッチして再アタッチするには、ポッドを完全に終了させる必要がある。そうしないと、データベースボリュームがReadWriteOnceであるため、ポッドの作成はマルチアタッチエラーで失敗します。 ・特定のゾーンでディスクが利用できないために、ポッドが保留モードになってしまうことがある。 これらの失敗を踏まえて、私たちは次のような疑問を投げかけました。 「クラウド管理されたデータベースインスタンスを使えばいいだけで、オンデマンド環境のライフサイクルで機能するようにはならないのだろうか？」 その疑問から、Kloeckner-iのDB Operatorが誕生しました。 How it works DBオペレーターは、 helmを介してインストールできます。 これにより、DB オペレータと以下のカスタム リソース定義(CRD)がデプロイされます。 ・DbInstance: オペレータがデータベースを作成するターゲットデータベースサーバーを定義します。KubernetesのDbInstanceリソースは、実際のデータベースサーバーを表します。 ・Database: DbInstanceに存在しなければならないデータベースを定義します。DbInstanceにデータベースを作成するには、まずDbInstanceのステータスがtrueである必要があり、Databaseリソースのspec.instanceでは、先に作成したDbInstanceの名前が参照されます。 一旦デプロイされると、DBオペレータはDatabaseとDbInstanceカスタムリソースを監視します。 DbInstance 新しいDbInstance CRが作成され、それがGCSQLを使用するように設定されている場合、DBオペレータはGoogle Cloud Platform (GCP) APIを介して新しいGCSQLインスタンスを作成します。 ここでは、GCSQLでバックアップされたDbInstanceの例を示します。 提供された例DbInstanceを使用すると、GCPでdboperator-exampleという名前の新しいGCSQLインスタンスが作成されます。 Database データベースCRが作成されると、オペレータはインスタンス内に実際のデータベースを作成します。 以下にデータベースの例を示します。 サンプル・データベースでは、dboperator-exampleデータベース・インスタンスに[namespace]-example-dbという名前のデータベースを作成する必要があります。データベースがデフォルトの名前空間で作成された場合は次のようになります。 Connecting to the Database データベースの作成に成功すると、オペレータはデータベースにアクセスするためのホスト、ユーザー、パスワードなどの接続情報を含むConfigMapとSecretを作成します。Application Podは、envFromまたはvolumeMountsを介してConfigMapとSecretを使用してデータベースに接続できます。 次のデプロイメントは、アプリケーション ポッドがデータベースに接続する方法の例です。 DB オペレータの動作やカスタム リソースの使い方については、Github プロジェクトを参照してください。 Writing Kubernetes…