Rook

Ceph ストレージシステムを Kubernetes のカスタムリソースに変換するオペレータ。ブロック・ファイル・オブジェクトストレージを、他の Kubernetes オブジェクトと同じように宣言し reconcile する。

カテゴリ: Storage & Database
CNCF 成熟度: Graduated
言語: Go
ライセンス: Apache-2.0
リポジトリ: rook/rook
ドキュメント基準コミット: 63eed4e (2026-06-19, master)

何をするものか

Rook は Ceph を Kubernetes 上で動かすためのオペレータである。ストレージエンジンを自前で実装しているわけではない。実績のある分散ストレージシステムである Ceph をパッケージ化し、CRD (Custom Resource Definition) を通じて駆動する。管理者は望むクラスタ構成を YAML で宣言し、Rook は稼働中の Ceph デーモンをその状態へ向けて reconcile する。

プロジェクト全体は rook という単一の Go バイナリとして出荷される。その ceph operator サブコマンドがオペレータ本体を動かし、それ以外のサブコマンドは pod 内のヘルパとして機能する (cmd/rook/main.go:27)。オペレータはストレージの概念ごとに 1 つずつコントローラ (pool、filesystem、object store など) を登録し、各カスタムリソースを Ceph の monitor・manager・OSD と、実データパスを担う CSI ドライバへ翻訳する。

位置づけはクラスタのストレージ層である。アプリケーションが PersistentVolumeClaim を要求すると、Ceph CSI ドライバが Rook の構成したプールからそれを払い出し、Rook はノードやディスクの増減に合わせて下層の mon/mgr/OSD トポロジを健全に保つ。

いつ使うか

ブロック・ファイル・S3 互換オブジェクトストレージを単一システムから、すべて Kubernetes 内で払い出したいとき。
Ceph を動かしたいが、そのデーモン・keyring・アップグレードを手で管理したくないとき。
マネージドストレージが使えないオンプレや複数クラウドノードで、ステートフルなワークロードを動かすとき。
ボリューム種別が 1 つで足り、運用のシンプルさを優先したいときは避ける。Longhorn のような軽量プロジェクトの方が、Ceph の CRUSH map や placement group の学習コストよりずっと安い。
Ceph の CPU・メモリオーバーヘッドが利得を上回るような極小クラスタでは避ける。

このディープダイブの構成

歴史: Upbound での起源、CNCF への移行、Ceph への収斂。
アーキテクチャ: オペレータ、そのコントローラ群、CephCluster の reconcile。
採用事例・エコシステム: 出典のある採用企業、シグナル、代替候補。
内部実装: ソースから読んだ CephCluster の reconcile パス。
はじめに: オペレータのインストールと最初のクラスタ作成。

Rook ​

何をするものか ​

いつ使うか ​

このディープダイブの構成 ​

出典 ​

Rook

何をするものか

いつ使うか

このディープダイブの構成

出典