Rookは、分散ストレージのCephをKubernetesの上で組み立て、動かし続けるためのオペレータです。CephクラスタをYAMLのカスタムリソースとして宣言すると、モニタやOSDといったデーモン群がPodとして立ち上がり、Podから使えるブロック・ファイル・オブジェクトのストレージが払い出されます。この記事では2026年9月時点のv1.20系を前提に、オペレータの責務範囲、導入前に確認すべきディスク条件、3種類の払い出し方、そしてLonghornやクラウドのマネージドストレージとの選び分けを実装者の目線で整理しました。PVやPVCという枠組み自体の設計はKubernetes永続化ストレージの基本設計で補完してください。
まとめ：RookはCephの運用手順をKubernetesのCRDに翻訳する層
Rookの正体を一言で表すと、Cephの構築手順と運用手順をKubernetesのカスタムリソースへ置き換える翻訳層です。データを保持し、複製し、復旧させる仕事そのものはCephの担当です。Rookはその周りで、デーモンの配置、設定ファイルの生成、CSIドライバの登録、障害時の起動し直しを引き受けます。CNCFでは2018年9月25日にIncubating、2020年10月7日にGraduatedへ移り、2026年9月時点でもGraduatedの位置にあります。
採用の分かれ目は、ブロックだけで足りるのか、オブジェクトとファイル共有まで1つの基盤で賄いたいのかという要件の広さにあります。Podに永続ボリュームを配れれば十分なら、より軽い選択肢のほうが運用の担当範囲は小さく収まるでしょう。S3互換のエンドポイントを自前で建て、複数Podから同時に書ける共有ファイルシステムも同じ基盤から出したい、という要求が並んだときにRook Cephの守備範囲が効いてきます。
導入でつまずく箇所はほぼ決まっていて、OSDに割り当てるディスクの条件です。ファイルシステムが載っているデバイスはOSDになれません。ノードを用意する段階で未フォーマットの領域を確保しておかないと、クラスタ作成のマニフェストを当てた瞬間にOSDが1つも立たず、原因の切り分けに半日を溶かします。ここは設計の最初に潰しておいてください。
Rook Cephの定義と、オペレータがCephクラスタを組み立てる仕組み
まず、この基盤がクラスタのどこに座り、何を何に変換しているのかを押さえます。
RookはCephを操作しストレージの実体とデータはCephが保持する
RookとCephは別々のプロジェクトです。Cephは10年以上の歴史を持つ分散ストレージで、RADOSと呼ばれるオブジェクト基盤の上に、ブロック（RBD）・ファイル（CephFS）・S3互換オブジェクト（RGW）の3つの顔を載せた構造をしています。この仕組みは物理サーバの上でも成立し、Kubernetesとは本来無関係に動きます。
ではRookは何をしているのか。従来なら手作業やAnsibleで行っていた「モニタを3台立てる」「ディスクをOSDとして初期化する」「プールを作る」「クライアントの鍵を配る」といった一連の手順を、Kubernetesのコントローラとして実行します。人が書くのはCephClusterというカスタムリソース1枚で、そこに何台のモニタを置き、どのノードのどのデバイスをOSDに回すかを宣言する形です。コンテナオーケストレーションの宣言的な運用作法を、そのままストレージ基盤の構築に持ち込んだ設計だと捉えると理解しやすいでしょう。
この責務分担は、障害調査のときに効いてきます。Podが起動しない、CSIのマウントが失敗するといった症状はRook側の領域ですが、書き込みが遅い、リバランスが終わらない、PGがdegradedのまま止まるといった症状はCeph側の領域です。切り分けの起点を間違えるとログを読む場所を誤ります。
mon・mgr・OSD・MDS・RGWをオペレータが起動し監視する
オペレータが面倒を見るCephのデーモンは、役割ごとに分かれています。公式ドキュメントに沿って整理すると次のようになります。
| デーモン | 役割 | 配置の目安 |
|---|---|---|
| mon（モニタ） | クラスタ構成と状態を保持し、多数決で一貫性を保つ | 3台または5台の奇数 |
| mgr（マネージャ） | メトリクス収集、画面表示と各種モジュールの実行 | 2台（現用と待機） |
| OSD | ディスクごとにプロセスが動き、データ本体を保持する | デバイス数に比例 |
| MDS | CephFSのメタデータ処理。ファイル共有時のみ | 現用と待機の2台以上 |
| RGW | S3・Swift互換のオブジェクトゲートウェイ | 負荷に応じて複数 |
オペレータはこれらを起動するだけでなく、監視して必要があればフェイルオーバーさせます。モニタのPodが消えれば別ノードで立て直し、定足数を保つ動きです。ここが手組みのCephとの一番の差で、デーモンの生死管理をKubernetesのスケジューラに預けられる点が導入の動機になります。
一方で、オペレータが判断してくれない領域も残ります。プールのレプリカ数を落として容量を稼ぐべきか、OSDを追加してリバランスを走らせる時間帯をいつにするか、といった運用上の意思決定は人の側の仕事です。「入れれば勝手に回る」という期待で導入すると、この差分が運用負荷として跳ね返ってきます。
Ceph-CSIが自動構成されPodからボリュームを要求できる
Podがストレージを掴むまでの経路は、Kubernetesの標準的な仕組みに沿っています。オペレータがCeph-CSIドライバを自動構成し、そのドライバを指すStorageClassを通じてPVCが動的にプロビジョニングされる流れです。アプリケーション側から見えるのは普通のPVCなので、ストレージ基盤を差し替えてもマニフェストの書き換えは最小で済みます。
CSIドライバはRBD用とCephFS用が別々に登録され、StorageClassのパラメータでどのプール、どのファイルシステムを使うかを指定する構成です。つまり「どのStorageClassを選ぶか」が、そのまま「ブロックかファイルか」の選択になります。既定のStorageClassを何にしておくかは、後から変えると既存PVCとの整合で悩むため、初期構築時に決め切っておくのが安全です。
Rook Ceph導入前に確認する前提条件とノード構成の設計基準
ここを飛ばすと構築の初日が丸ごと消えます。マニフェストを当てる前に必ず確認してください。
対応するKubernetesのバージョン範囲と仮想マシンでの検証条件
2026年9月時点の公式ドキュメントでは、対応するKubernetesはv1.31からv1.36までと示されています。CPUアーキテクチャはamd64（x86_64）とarm64の両方が対象です。クラスタ側のバージョンが範囲の下限を下回っている場合、先にKubernetes本体の更新計画を立てる必要があります。
もう1点、公式ドキュメントは検証を物理ホストではなく仮想マシンで行うよう明記しています。Rookはノードのブロックデバイスを直接掴んで初期化するため、手元の常用マシンで試すとホスト側のディスクを巻き込む恐れがあるという理由です。試用のつもりで本番機や開発機に当てるのは避けてください。
OSDに使える未フォーマットデバイスの条件とノード台数の設計
Rook Cephの導入で最も多い詰まり方が、OSDが1つも作られないという症状です。原因はほぼディスクの状態で、公式が受け付ける形は以下に限られます。
- パーティションもファイルシステムも無いRawデバイス
- ファイルシステムが載っていないRawパーティション
- LVMの論理ボリューム
- 暗号化デバイス
- マルチパスデバイス
- ブロックモードで払い出されたPersistentVolume
クラウドのインスタンスを立てて追加ディスクをアタッチしただけなら条件を満たしますが、OSインストーラが自動でパーティションを切ったマシンや、一度検証で使ってCephのシグネチャが残ったディスクは弾かれます。再利用するなら事前にワイプが要ります。ノード調達の要件定義に「OSD用に未フォーマットのデバイスを1ノードあたりN本」と書き込んでおくのが確実です。
台数設計も同じタイミングで固めます。既定の障害ドメインはホスト単位なので、3レプリカのプールを作るならOSDを載せたノードが最低3台要ります。モニタの定足数も3台が基本形です。2ノード構成で始めて後から足せばよい、という進め方はプールの作成段階で行き詰まるため、最初から3台以上を前提に見積もってください。
ブロック・ファイル・オブジェクトを払い出す3種類のCRDと選択基準
CephClusterでクラスタが立ったら、次は用途ごとのカスタムリソースで払い出し口を作ります。ここでの選択が、後々のアプリケーション設計を縛ります。
RBDはRWOのブロックでステートフルな処理の既定選択になる
CephBlockPoolを作ると、RBDのプールとそれを指すStorageClassが用意されます。払い出されるボリュームのアクセスモードはReadWriteOnceで、1つのPodが排他的に掴む形です。データベースやメッセージキューのように、ブロックデバイスを直接扱う処理はこちらに載せます。
プールにはレプリカ数を指定します。3を指定すれば実容量は3倍消費され、1TiBのデータを預けるには3TiBのOSD容量が要ります。容量効率を上げるイレージャーコーディングも選べますが、書き込みのレイテンシと復旧時のCPU負荷が上がるため、レイテンシに敏感な処理では素直にレプリケーションを選ぶ判断が無難でしょう。
CephFSとRGWを追加する要件と選択時に確認する構成条件
CephFilesystemを作るとMDSが立ち上がり、ReadWriteManyのボリュームが払い出せます。複数のPodから同じディレクトリへ同時に書きたいという明確な要件があるときだけ足してください。MDSはメタデータ処理を一手に引き受けるため、小さなファイルを大量に扱うと、ここが先に飽和します。
CephObjectStoreを作るとRGWが立ち、S3互換のエンドポイントがクラスタ内に生まれます。オブジェクトストレージをオンプレミス側に持ちたい場合の選択肢で、バケットの払い出しはObjectBucketClaimという専用のリソース経由になります。アプリケーションから見ればS3のAPIなので、Amazon S3向けに書いたコードのエンドポイントを差し替えるだけで動く場面が多いはずです。
ただし、S3互換のエンドポイントが欲しいだけなら、Cephクラスタを丸ごと建てるのは重い選択です。オブジェクト用途に絞るならMinIOのようなS3互換ストレージを単体で建てるほうが構成要素は少なく済みます。RGWを選ぶ理由は「ブロックやファイルと同じ基盤・同じディスクプールで賄いたい」という統合の要求にあり、オブジェクト単体の性能や手軽さで選ぶものではありません。
Rook Ceph運用で必要なアップグレードと監視の実践手順
構築より運用のほうが長く続きます。導入判断の段階で、ここまで見ておく必要があります。
RookとCephのバージョンを別々に上げる二段階の更新手順
見落とされがちな性質として、オペレータのバージョンとCephのバージョンは独立しています。Rook v1.20系はCeph v20.2.4を、v1.19系はCeph v19.2.6を推奨する、といった形で対応関係が示され、更新も別々の操作です。オペレータを上げてからCephのイメージタグを上げる、という順序で二段階に進めます。
この二段構えはセキュリティ対応で現実的な意味を持ちます。実際にv1.20.6とv1.19.10のリリースノートでは、Cephの脆弱性CVE-2025-30156に触れ、Rook側とCeph側の両方を上げるよう案内されています。オペレータだけ上げてCephを据え置くと、修正が入っていない状態が残る点に注意してください。
Ceph本体の保守期限も追う対象です。2026年9月時点でActiveなのはTentacle（20.x系・2027年6月1日まで）とSquid（19.x系・2026年10月31日まで）で、Squidは1か月あまりで期限を迎えます。Reef以前はすでにArchivedです。オンプレミスのストレージ基盤は一度組むと数年動かす前提になりがちですが、この基盤は年次でメジャー系列を追う運用計画とセットで持つ必要があります。2026年9月に新規で建てるならTentacle系から始めるのが素直な判断でしょう。
Cephのhealth statusをクラスタ監視に合流させる
監視の起点はCephが自ら出す健全性ステータスです。HEALTH_OK・HEALTH_WARN・HEALTH_ERRの3段階で、mgrがPrometheus形式のメトリクスも出します。Kubernetes側のPod監視だけを見ていると、Podは全て動いているのにPGがdegradedのまま復旧していない、という状態を見逃します。
実務で拾いたい指標を挙げると、健全性ステータス、OSDの起動数と総数の差、プールごとの使用率、そしてリバランスの進捗です。使用率は特に効いてきて、OSDが満杯に近づくとCephは書き込みを止めます。空き容量の警告はディスク増設のリードタイムを織り込んだ閾値で鳴らしてください。既存のKubernetes監視の仕組みがあるなら、mgrのメトリクスをそこへ合流させるのが遠回りのない構成です。
Longhornやクラウドのマネージドストレージと選び分ける判断基準
ここが採否の分かれ目です。機能の多さで比べると判断を誤るため、要件の広さと運用体制の2軸で切り分けます。
Rook Cephを採用できる3条件と運用体制に関する判断基準
Rook Cephを選んでよい条件は、以下の3つが同時に成り立つときです。1つでも欠けるなら別の手を検討してください。
1つめは、ブロックだけでなくファイル共有かオブジェクトのいずれかが要件に入っていること。RWOのボリュームだけで足りるなら、この基盤の守備範囲は過剰です。2つめは、OSD用の未フォーマットデバイスを持つノードを3台以上、継続的に確保できること。台数は容量の伸びに合わせて足していく前提になります。3つめは、Cephの用語と挙動を追える担当者を運用体制に置けること。PG、CRUSHマップ、リバランスといった概念を誰も読めない体制で本番データを預けるのは危険です。
オンプレミスやベアメタルでこの3条件を満たす基盤を建てる場合、設計段階でノード構成とディスク本数を詰め切れるかどうかが後の安定性を決めます。クラウド側との併用も含めた構成の相談はインフラ構築の支援から受け付けています。
Rook Cephを見送る主な条件と要件別に選択できる代替手段
逆に、次のような場面では見送る判断を推奨します。判断の材料として代替も並べます。
| 場面 | 判断 | 代替 |
|---|---|---|
| 要件がRWOのブロックだけ | 見送り | LonghornかクラウドのブロックCSI |
| ノード3台未満か未フォーマットデバイスを確保不能 | 見送り | クラウドのマネージドストレージ |
| マネージドK8sでクラウドCSIを使える | 見送り | クラウド側のCSIドライバ |
| S3互換のエンドポイントだけが欲しい | 見送り | MinIOなどオブジェクト専用の実装 |
| すでに外部にCephクラスタがある | 部分採用 | 外部クラスタ接続モードでCSIだけを使う |
ブロックだけで足りるケースでの比較先がLonghornです。導入が半日で終わり、UIで状態を追え、障害時の挙動が読みやすい。守備範囲を絞ったぶんの扱いやすさが資産になります。Rook Cephはオブジェクトやファイル共有まで1つの基盤で賄え、数十ノード規模でも伸びますが、そのぶん専任の知識を前提とします。要件が広いか狭いかで素直に分かれる関係です。
マネージドKubernetesを使っているなら、そもそも自前の分散ストレージを持たない選択が有力です。Amazon EKSのような環境ではクラウド側のブロックストレージやファイルサービスのCSIドライバがそろっており、ディスク障害の対応もクラウド事業者の側に寄せられます。Rook Cephの出番は、その逃げ道が無い環境か、複数クラスタで同じストレージ基盤を共有したい要求があるときだと考えてください。
最後の行にある外部クラスタ接続は覚えておくと便利な形です。すでに物理サーバ上でCephを運用しているなら、Kubernetes側にはCSIドライバとその設定だけを置き、データの実体は既存クラスタに預けられます。Cephの運用体制を二重に持たずに済むぶん、移行の第一歩として現実的でしょう。
よくある質問
Rookとcephadmはどちらを選ぶべきですか？
Kubernetesクラスタの内側にストレージを同居させたいならRook、ストレージを独立したサーバ群として運用したいならcephadmが噛み合います。ワークロードとストレージが同じノードを取り合う構成を避けたい場合は、後者を選んで外部クラスタとして接続する形も取れます。
ノード3台の小規模クラスタでも動きますか？
動きます。3レプリカのプールとモニタ3台という基本形はノード3台で成立する構成です。ただし1台停止すると冗長が失われた状態になり、その間にもう1台落ちるとデータが読めなくなります。停止許容とメンテナンスの計画を立てにくいため、余裕を持たせるなら4台以上を推奨します。
OSDが作られないときは何を見ればよいですか？
まずOSD準備用のジョブのログを確認してください。多くはデバイスにパーティションやファイルシステムが残っていることが原因です。ノードにログインしてデバイスの状態を確認し、再利用するディスクなら既存のシグネチャを消してから、オペレータのPodを起動し直します。
Cephのバージョンは自分で選べますか？
選べます。CephClusterのイメージ指定で系列を決める形です。ただしRookのバージョンごとに推奨されるCephのバージョンが示されているため、その組み合わせから外れる指定は避けてください。保守期限が近い系列を選ぶと、短期間で更新作業が発生します。
本番データを預ける前に何を試すべきですか？
ノードを1台落とす試験と、OSDを1本抜く試験の2つは必ず通してください。復旧にかかる時間と、その間の性能低下の度合いを実測しておくと、レプリカ数や台数の設計を見直す材料になります。仮想マシンで組んだ検証環境で構いません。
関連記事
- Longhornとは？Kubernetes分散ブロックストレージの仕組み：ブロックだけで足りる場合の比較先。
- Kubernetes永続化ストレージ入門｜PV・PVC・StorageClass：Rookが差し込まれる枠組み。
- オブジェクトストレージとは？ブロックとの違い：RGWで払い出す形式の土台。
- MinIOとは？S3互換オブジェクトストレージの仕組み：オブジェクト単体で建てる場合の候補。
- Amazon S3とは？仕組みとストレージクラス：S3 APIの基準となる実装。
- Kubernetes監視・モニタリングの設計：health statusを合流させる先。
- Amazon EKSとは？ノード提供形態と料金モデル：マネージドk8sを選ぶ場合の比較先。
- コンテナオーケストレーションとは？Kubernetesの役割：前提となる基盤の考え方。
