Rook and cephadm compared

Intermediate⏱ ~17 mincephkubectl

What you'll learn

Compare the two orchestration approaches
Identify what each assumes
Recognise where the operational models differ
Understand that the Ceph is the same

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

Both deploy and manage Ceph. Choosing between them is a decision about the operating environment rather than about Ceph.

The comparison

Aspect	cephadm	Rook
Runs on	any hosts with a container runtime	Kubernetes
Interface	`ceph orch` commands	Kubernetes custom resources
Model	imperative with a declarative service spec	fully declarative
Daemon placement	placement specifications and labels	operator scheduling
Upgrades	`ceph orch upgrade`	change the image in the CR
Prerequisites	SSH access, a container runtime	a working Kubernetes cluster
Failure domain awareness	manual CRUSH configuration	manual CRUSH configuration
Storage for the cluster itself	host directories	host paths or PVCs
Monitoring	deployed by cephadm	deployed alongside

What each assumes

cephadm assumes:
  hosts you control, with SSH and a container runtime
  Ceph is a first-class system on those hosts
  the operator understands Ceph directly

Rook assumes:
  a Kubernetes cluster that is already operated well
  Ceph is a workload within it
  the operator understands Kubernetes

The second assumption in each list is the substantive one: Rook makes Ceph’s availability depend on Kubernetes’ availability.

Where the operational models differ

Task	cephadm	Rook
Add a host	`ceph orch host add`	label a Kubernetes node
Add OSDs	`ceph orch daemon add osd`	edit the CephCluster storage spec
Create a pool	`ceph osd pool create`	create a CephBlockPool CR
Upgrade	`ceph orch upgrade start`	change the image tag
Scale monitors	`ceph orch apply mon --placement`	change `mon.count`
Remove a host	`ceph orch host rm`	remove the node or its label

# cephadm
ceph orch ls
ceph orch ps

# Rook
kubectl -n rook-ceph get cephcluster
kubectl -n rook-ceph get pods

The Ceph is the same

# in both cases
ceph -s
ceph osd tree
ceph df
ceph pg dump

Every diagnostic command, every configuration setting not owned by the orchestrator, every failure mode, and every recovery procedure is identical. The orchestrator determines how daemons are placed and upgraded, not how Ceph works.

Quiz

Knowledge check · 4 questions

Q1. What is the substantive difference in what Rook and cephadm assume?

Rook requires substantially more hardware, since each daemon runs in its own pod with its own resource requests, limits, and reservations cephadm requires bare metal hosts, because its daemons cannot run inside an existing container orchestration layer Rook supports fewer Ceph features, since only the parts expressed by its custom resources can be configured at all Rook makes Ceph a Kubernetes workload, so its availability depends on Kubernetes; cephadm makes Ceph a first-class system on hosts
Q2. Ceph diagnostic commands and failure modes differ between Rook and cephadm deployments.

True False
Q3. Choose an orchestrator for a new deployment.

A team runs a mature Kubernetes platform and needs Ceph storage for it. They are choosing between Rook inside the cluster and a cephadm cluster alongside it.
Q4. What determines whether the Rook-Kubernetes circular dependency is benign?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Map which Kubernetes components would depend on Ceph-backed storage before choosing Rook — the circular dependency is manageable when deliberate and severe when discovered during a recovery. Remember the Ceph is identical either way; the choice is about the operating environment.

Cross-course references

Kubernetes: self-hosted infrastructure components always create dependency loops worth mapping
Linux: a filesystem holding the tools needed to repair it is the same pattern