こんばんは、ACS 事業部の埜下です。
KubeCon + CloudNativeCon Europe 2023 の 2 日目、Kubernetes のデータベースオペレータの課題と解決策、そして今後どうなっていくか、のセッション内容をお伝えします。
課題
2022 年時点で、多くの人（組織）は少なくとも 20 個のオペレータを使用している、というレポートがあります。 特に、ステートフルワークロードとしてのデータベースを管理するオペレータが多いです。
オペレータによる自動化で、データベースのバキューム処理や再起動、再圧縮などの従来のデータベースメンテナンスは実行されていますが、課題もあります。
一つは安定性です。
データベース管理者は、データベースのスケーリングを伴うアップグレードなどに非常に注意を払っていおり、安定性を望んでいます。 オペレータフレームワークには自動化範囲によってレベル 1～5 でオペレータを評価しますが、品質の基準がありません。
もう一つはセキュリティです。
現在のフレームワークがセキュリティ面で評価する方法を備えておらず、大きな懸念事項でもあります。 また、オペレータに最小限の特権を与えるのが非常に難しい場合があり、オペレータが PVC も作るといったことは避けられないようなこともあります。
そのため、CNCF のプロジェクトが Graduated になるために厳しいセキュリティ監査がおこなわれるように、オペレータも監査が必要と考えられています。
セキュリティの観点ではもう一つ、データベースとしてのセキュリティも考慮が必要です。 データが安全であることを確認できるように、また、ランサムウェア対策でデータベースをバックアップする際に 1 つはコピーを作るなど、オペレータは既存のセキュリティツールなどと統合する必要があります。
解決策
これらの解決策として、Data on Kubernetes Community の Operator SIG と Kubernetes SIG Storage、SIG Security、および業界が協力してソリューションを考案していきます。 そのためのホワイトペーパーを作成しました。
また、オペレータがどのような機能を持つかユーザが理解することが難しい、という課題に対しては、オペレータ毎の機能を比較した「機能マトリクス」を作成することを目的としたプロジェクトが開始しています。
すでに PostgreSQL 用オペレータの機能マトリクスは作られており、他のデータベースやテクノロジに拡張できます。
今後
1 年後にオペレータはどうなるか、という質問に対して各パネラーがコメントしていました。
オペレータで使われる CRD (Custom Resource Definition) は業界関係者の間で共通の仕様のようなものになる可能性がある。 たとえばオブジェクトストレージを表す CRD はほぼ全員同じで、オペレータ独自に CRD を再発明するのではなく、コラボレーションを増やし、コントローラから CRD を切り離したい。
また、CSI のようにオペレータ向けのプラグインフレームワークが作成されるかもしれない。
おわりに
オペレータ、特にデータベース向けのオペレータは多く使われているものの、課題もあるようです。
PostgreSQL に対応しているものだけでも複数のオペレータが公開されているため、機能マトリクスによってオペレータの選定が楽になるかもしれませんね。
