Rook/Cephのオブジェクトストレージ ~ 現在と将来

はじめに

本記事はRookと仲間たち、クラウドネイティブなストレージの Advent Calendar 2020 5日目の記事です。Rook/Cephのオブジェクトストレージのこれまでとこれから、とくにインタフェースについて述べます。まずはCephのオブジェクトストレージについて軽く触れた後に、Rookにおいてオブジェクトストレージをどのように使うのか、今後はどうなるのか、という順番で説明します。

Cephのオブジェクトストレージ

CephはRadosGW(RGW)という機能名でオブジェクトストレージをサポートしています。インタフェースはS3互換のものとSwift互換のものの二つを提供しています。Cephの中心部にはRADOSという名前の独自形式のオブジェクトストレージシステムが存在していて、この機能はそれと一般によく使われている前述のインタフェースとのゲートウェイなので"Rados" "Gateway"とう名前がついています。

現在のRookのオブジェクトストレージ

RookはRGWのうちS3互換インタフェースをサポートしています。Kubernetesはv1.20の時点でオブジェクトストレージにアクセスするためのリソースを提供していませんが、Rookは次のようなカスタムリソース(CR)を使って、直接S3 APIを叩くことなくオブジェクトストレージの作成、バケットの作成、削除などができます。

• CephObjectStore CR: ひとつのオブジェクトストレージに対応
• Objectbucket CR (以後OBと記載):ひとつのバケットに対応
• ObjectBucketClaim CR (以後OBCと記載): ユーザからのバケット使用要求。要求に基づいてOBが割り当てられる
• ObjectStoreUser CR: オブジェクトストアのユーザ

使い方を簡単に説明すると、次のようになります。

1. CephObjectStore CRを作る。これによってオブジェクトストアを作る。
2. OBCを作る。これによって自動的にバケット、およびそれに対応するOB、ユーザ、バケットにアクセスするための情報を含むConfigMapとSecretが作られる。
3. Podから上述のConfigMapとSecretをenvFromによって取り込む
4. Podから所定の環境変数を使ってオブジェクトストレージにアクセス

バケットに紐づかないユーザが欲しいときにはObjectStoreUser CRを作成するとRookがユーザを作ってくれます。ただ、その後の操作は自力でS3 APIを叩かなければいけません。

Rookにおいてオブジェクトストレージを実際に使ってみたいというかたには宇都宮さんの記事が参考になると思います。仕様は公式ドキュメントでご確認ください。

OB, OBCを提供するlib-bucket-provisioner

ここまで書いたところでKubernetesのストレージに詳しいかたは気づかれたかもしれませんが、OB,OBCの役割はPodからブロックデバイスやファイルシステムへアクセスするためのPersistentVolume(PV)、PersistentVolumeClaim(PVC)と非常によく似ています。実際OB,OBはPVやPVCのようなKubernetesらしい方法でオブジェクトストレージにアクセスしたいという思いから生まれたものです。

OB,OBCはlib-bucket-provisionerというライブラリによって提供されていて、Rookはこのライブラリを内部的に使っています。lib-bucket-provisionerがRook/Cephなどのユーザに提供しているインタフェースも、CSI^[1]と非常によく似ています。

lib-bucket-provisionerは非常に便利な反面、Kubernetes標準ではないがゆえにKubernetesのバージョンアップについていくのが大変であるなど、多くの問題を抱えていました。これらの問題はそのユーザであるRook/Cephなどにとっても悩みの種でした。具体的に何がどう辛いかについてはこの記事をご覧ください。

Kubernetesにおけるオブジェクトストレージへのアクセス方法の標準化

前述の通り、Kubernetesにはオブジェクトストレージにアクセスするための標準的な方法が存在しません。これによってユーザ、ストレージベンダなど様々な関係者が不利益を被っていたため、昨年この問題を解決するためのKEP^[2]が作られました。当初そのインタフェースはlib-bucket-provisionerをもとにしていました。

KEPができた後は、多くの技術者の間で長きにわたって激論が交わされました。どれくらい激論だったかというと、上述のPR1383はコメントが多すぎて頻繁に忌々しいユニコーンが出てくる状態になったので別途別のPRが作られたほどでした。

最終的に今年の10月にPR2100がマージされ、v1.21でαリリースを目指すこととなりました。ただしインタフェースはもとの提案とは全く異なるContainer Object Storage Interface(COSI)というものになりました。この名前からもCSIを強く意識していることがわかります^[3]。

さてCOSIが標準になるとわかった今、lib-bucket-provisionerは今後どうなるかが気になると思います。結論から言うと、このライブラリはすでにdeprecated扱いになっています。以下公式ページのREADMEからの引用です。

DEPRECATION NOTICE:
There is a Kubernetes Enhancement Proposal under review which will significantly
change this design and interfaces. This repo is not longer active and should not
be used.

今後新規にlib-bucket-provisionerは使わないほうがよいでしょう。

Rookのオブジェクトストレージの将来

内部的にlib-bucket-provisionerを使っているRookのオブジェクトストレージはどうなるでしょうか。筆者はRookユーザが慌てて今すぐ何かをしなければならないとは思っていません。これからその理由を述べたいと思います。

第一に、現状COSIにはコードが一行もないため、Rookユーザはおろか開発者も何もしようがありません。仮に期待通りv1.21でαリリースできたとしても来年の話ですし、Rook/CephのCOSIドライバを書いて安定させるにはさらに時間がかかります。もう一点、Rookは非常に古いバージョンのKubernetesもサポートしているという都合上((v1.5時点ではKubernetes v1.11以降をサポート))、早くてもv1.21以降でしか使えないCOSIドライバのみをサポートするというのは事実上不可能でしょう。

ざくっとした見積もりではRookユーザは次のような意識でいればよいのではないかと思っています。

• 1年後あたりまではKubernetesにCOSIのコードが無いので誰も何もしようがない
• 1,2年後あたりにはRookのCOSIドライバが試験的にリリースされる
• 2,3年後には移行できる人はしたほうがよい状態になる
• 5年後くらいには余程の理由がなければ移行したほうがよい状態になる

参考までに書いておくと、この見積もりはファイル/ブロックストレージにおけるCSIおよびCSIドライバの普及具合、それに伴うRookのCeph CSIドライバへの対応状況を参考にしました。

余談ですが、lib-bucket-provisionerについては現状は「使うべきではない」と書いてはいるものの、PRを受け付けている状況なので、すぐに無くなるということはないでしょう。いずれは修正を受け付けなくなり、例えばRookなどの大口ユーザがforkして丸抱えするという可能性もあるかもしれませんが、現段階ではなんともいえません。

おわりに

本記事では、筆者がRookの開発やKubernetesのストレージまわりの情報収集から得た知見をもとに、Rookのオブジェクトストレージの現状と将来について書いてみました。Kubernetesの世界は動きが速いのでここで書いた予測は完全に外れる可能性はありますが、一つの参考にしていただければ幸いです。

脚注

1. 正式名称はContainer Storage Interface。コンテナ化環境におけるブロック/ファイルストレージへのアクセスインタフェースを定めたCNCFの標標

2. 正式名称はKubernetes Enhancement Proposal。Kubernetesへの機能追加提案のこと

3. COSIはいまのところCNCFは全く関係なく、Kubernetes独自のものです。