ストレージオーケストレーター Rook : 第1話 Rook大地に立つ!!

f:id:ututaq:20191125022735p:plain

こんにちは、Red Hatでストレージを中心にクラウドインフラを生業にしている宇都宮です。

今回から、Kubernetes(k8s)におけるストレージという狭ーいちょびっと深ーい話を連続で紹介します。
ご存知の方も多いと思いますが、k8sにはPersistent Volume(PV)という無敵に素敵なストレージ抽象化の仕組みがあります。だからアプリケーションからボリュームを使えるようにする辺りの処理に関してはほとんど考えなくて大丈夫。
じゃあバックエンドのストレージ自身はどうあるべきか?みたいな話って、あんまりされないんじゃないかなって思ってます。それは、k8sには多くの外部ストレージに対応したvolume driverやpluginがあって、既存の外部ストレージをそのままPVとして使えるから。実際には外部ストレージによってできる事できない事は色々ありますが、「今あるストレージが使えるんなら基本それでええやん」ってなる事情が多いんじゃないかなと。

だがしかし、世の中には「バックエンドストレージもk8s上で動かそうや」というとんがった考え方もあるんです。"Cloud-Native Storage"とか"Container-Native Storage"とか呼ばれたりします。
これはk8s上でPodとしてSDSを動かすんですが、まじめにPodでSDSをデプロイしたり運用したりするのは、冗長性とかデータインテグリティとか拡張性とか、色々考えなきゃならなくて結構大変。
だから、Cloud-Native Storageの運用構築をサポートするためのツールが生み出されてるんですね。Cloud-Native Storage専用ツールですよ。狭くてステキ!とがり過ぎ!キレッキレ!

というわけで、今日も前置き長くなりましたが、k8sやOpenShiftでSDSをオーケストレートするツールを紹介します。Rookです。

f:id:ututaq:20190704043520p:plain
デカいねロゴが

Rookってなに

Rookは一言で言えば、k8s向けのストレージオーケストレーターです。Rookを使うことでk8s上にCephやEdgeFSなどのSDSを複数のPodとして起動して冗長化されたストレージ構成を作ることができます。
ここまでだと普通のインストーラーなんですが、Rookは運用まで自動化してお手伝いしてくれるんです。 これについてはまた後ほど。

ご多分に漏れず、Rookはオープンソースソフトウェアです。ポータルサイトのrook.ioから様々な情報を調べることができます。また、githubにリポジトリが公開されていて、誰でもお気軽に使えるし、開発に参加できます。

rook.io github.com

Operatorとして自律的なストレージを提供

Rookはオーケストレーターというだけあって、ありとあらゆる事に目を配って面倒みてくれます。次のような作業を自動的に行う仕組みを持っていて、self-managing, self-scaling, self-healing なストレージを実現します。

  • deployment
  • bootstrapping
  • configuration
  • provisioning
  • scaling
  • upgrading
  • migration
  • disaster recovery
  • monitoring
  • and resource management

例えば、容量足りなくなってきたからストレージ用のworker nodeを増やそうって時に、worker nodeをブスッと追加するだけで、自動的にババババっとストレージをスケールアウトして拡張してくれます。
アップグレードもkubectl apply一発で、全Podのコンテナイメージをチャチャッと順繰りにアップグレードしてくれます。

なんでこんなことができるのかと言うと、RookがOperatorとして動くからです。
まあ厳密にはRookが面倒をみられるSDSごとにOperatorがあって、それによってできることは違うんですが、いずれにせよSDSの運用のプラクティスをOperatorとして実装することで自動的な運用を実現しているのです。はい。
ちなみに、Ceph用とEdgeFS用のRook OperatorはすでにOperatorHubに登録されていまーす。

Rookが対応するSDS

Rookも人の子ですので、世の中にあまねく存在するSDSの面倒をみられるわけではありません。Rookが対応できるSDSは、今日の時点で次の6つです。

Name API Group Status
Ceph ceph.rook.io/v1 Stable
CockroachDB cockroachdb.rook.io/v1alpha1 Alpha
Cassandra cassandra.rook.io/v1alpha1 Alpha
EdgeFS edgefs.rook.io/v1beta1 Beta
Minio minio.rook.io/v1alpha1 Alpha
NFS nfs.rook.io/v1alpha1 Alpha

引用元 : https://github.com/rook/rook/blob/master/README.md

SDS以外にもDBとかNFSとかも対応するんですね。
というか注意してもらいたいのが、Statusのカラムですよ。StableなのCephだけ! だから今後ちゃんと使っていく見込みで取り組むなら断然Ceph! 迷わず行けよ、行けば分かるさ!

ていうかそもそもCloud-Nativeなストレージだと何が嬉しいの

f:id:ututaq:20190704044146p:plain
従来型のストレージとCloud-Native Storageの違い

最初に書いた通り、外部ストレージでもPVを提供できるのであえてCloud-Nativeなストレージにしなくてもいいじゃんっていう意見はあると思います。うん、過去の投資を最大限活用するのは大事だし、一理ある。
しかしCloud-Native Storageにはもちろんメリットがあって、それを認識するポイントは『ストレージをアプリにストレージサービスを提供するインフラアプリとして捉える』というとこかなと思います。 ストレージがk8sのインフラアプリになるということは、

  • k8s上のアプリケーション専用のストレージが提供できる
    • DataPathがk8s内で閉じる(プロセス間通信)のため速いレスポンスが期待できる
    • k8s外のワークロードを心配しなくてよい
  • ストレージの運用をk8sから行える
    • k8sと全く異なる体系のストレージ管理手順を覚えなくていい
    • Operatorがあれば運用自動化ができる
  • SDSのPodが落ちてもすぐ復活する
    • RobustだけでなくResilientなストレージシステム
  • k8sが稼働するプラットフォームならどこでも同じように動く
    • オンプレ / パブリッククラウド問わず、同じユーザーエクスペリエンス(使用感)を提供できる
    • SDSのコピーサービスを使うことでクラウド間のデータコピーやマイグレーションがしやすい

一般的にこんなメリットが考えられます。
まあユーザーさんごとに事情が違うから、納得してくれる人も居れば嘘くせーと思う人も居ると思います。僕だって別の立場だったら正直ちょっと胡散臭いと感じるかも。

っていうかこんな能書きだけで良さを感じてもらうのはやっぱね、なかなか難しいでしょう。ここはエンジニアブログなんだから。てめぇの力で勝ち取ってみろコノヤローってね。
というわけで次回第2話からは実際にRookを入れてみて使いながらRookのいいとこを紹介していきまーす。

今回はここまで。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。