Kubernetes Ceph CSI の使い分け – RBD と CephFS をどう見るか

Kubernetes で Ceph を永続ボリュームとして使う場合、Ceph CSI には大きく RBD と CephFS の 2 つの入口があります。どちらも Ceph を使いますが、Pod から見える性質は同じではありません。

この記事では、Ceph CSI RBD と Ceph CSI CephFS を、StorageClass、PVC、Pod の使い方から見比べます。具体的なクラスタ値ではなく、運用時にどちらを選ぶべきかを判断するための観点を扱います。

RBD と CephFS の違い

RBD はブロックデバイスとしてボリュームを提供します。多くのデータベースや単一 Pod が書き込む用途では扱いやすい選択です。CephFS はファイルシステムとして提供され、複数 Pod から共有して読み書きする用途に向いています。

項目	RBD	CephFS
Pod からの見え方	ブロックデバイスをファイルシステムとしてマウントする	共有ファイルシステムをマウントする
典型的な用途	DB、単一 writer、状態を持つ Pod	共有ディレクトリ、複数 reader/writer、アプリ間共有
アクセスモード	主に ReadWriteOnce	ReadWriteMany を扱いやすい
確認する設定	pool、image features、fstype	fs name、subvolume、共有範囲
注意点	複数 Pod から同時 writer にしない	共有前提の権限とディレクトリ設計が必要

この違いを曖昧にしたまま StorageClass を作ると、PVC は作成できても、アプリケーションの期待する読み書きモデルと合わないことがあります。

Ceph CSI では、StorageClass に provisioner、reclaim policy、volume binding mode、volume expansion の可否などを持たせます。RBD ではさらに image features や fstype も設計対象になります。

kubectl get storageclass
kubectl describe storageclass ceph-csi-rbd
kubectl describe storageclass ceph-csi-cephfs

reclaimPolicy は PVC 削除時に実体ボリュームをどう扱うかに関わります。検証環境では Delete が便利ですが、重要データを扱う環境では消える範囲を理解しておく必要があります。

volumeBindingMode はボリューム確保のタイミングに関わります。Ceph のような外部ストレージでは、Kubernetes ノードのローカル制約だけでなく、Ceph 側の pool、filesystem、認証情報も合わせて考えます。

RBD は、1 つの Pod が状態を持ち、再作成されても同じデータを使いたい場面で扱いやすいです。MariaDB、PostgreSQL、Redis など、基本的に単一 writer として動かす構成では RBD を選ぶ理由があります。

ただし、RBD は共有ファイルシステムではありません。複数 Pod から同時に書き込む共有ディレクトリとして使うと、アプリケーション側の想定と合わないことがあります。

CephFS は、複数 Pod から同じファイルツリーを扱いたい場合に候補になります。アップロードファイル、共有コンテンツ、複数 replica から参照する静的ファイルなど、ファイルシステムとして共有したい用途で検討します。

CephFS を使えば共有はしやすくなりますが、共有してよいデータと共有してはいけないデータの境界はアプリケーション側で決める必要があります。単に RWX が使えるからという理由だけで選ぶと、障害時の切り分けが難しくなります。

StorageClass を作っただけでは、アプリケーションが正しく永続化できているとは言えません。PVC が Bound になっていること、Pod にマウントされていること、Pod 再作成後もデータが残ることを分けて確認します。

kubectl get pvc -A
kubectl describe pvc -n default data-example
kubectl get pod -n default -o wide
kubectl describe pod -n default example-pod

PVC が Pending の場合は、StorageClass、provisioner、Ceph 側の認証情報、pool または filesystem の存在を確認します。Pod が起動しない場合は、PVC ではなくマウント権限やファイルシステムの問題で止まっていることもあります。

Ceph CSI を Helm で導入している場合でも、見るべき対象は Helm release だけではありません。release が存在すること、CSI driver の Pod が起動していること、StorageClass と Secret が期待どおり作られていることを分けて確認します。

helm list -A
kubectl get pods -A | grep ceph-csi
kubectl get csidriver
kubectl get secret -A | grep ceph-csi

Helm release が deployed でも、Ceph monitor への到達性や認証情報が誤っていれば PVC の作成で失敗します。Kubernetes 側の状態と Ceph 側の実体を分けて見ることが重要です。

Ceph CSI は、Kubernetes の中だけで完結する機能ではありません。Kubernetes、CSI driver、Ceph cluster、アプリケーションの読み書きモデルがつながって初めて安定します。

RBD と CephFS は、どちらが上位という関係ではありません。アプリケーションが必要とする読み書きモデルに合わせて使い分けるものです。

Kubernetes完全ガイド第2版

Kubernetes の永続ボリューム、StorageClass、Pod 運用を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。

このリンクは Amazon アソシエイトリンクです。

Kubernetes Ceph CSI の使い分け – RBD と CephFS をどう見るか