When Rook is the right choice

Intermediate⏱ ~17 minkubectl

What you'll learn

Identify the situations favouring Rook
State the prerequisites for running it well
Recognise the situations where it is a poor fit
Plan a Rook deployment appropriately

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

Rook suits some deployments well and others badly, and the distinguishing factors are specific.

Situations favouring Rook

Situation	Why
Storage exists only to serve this Kubernetes cluster	no independent consumers
The team is Kubernetes-native	the operational model matches their skills
Everything is managed declaratively via GitOps	Ceph fits the same model
Nodes are ephemeral or cloud-managed	Rook handles daemon rescheduling
A development or test environment	fast to deploy and tear down
Edge deployments with small clusters	one system to operate

The first is the strongest: if nothing outside the Kubernetes cluster uses the storage, its availability being tied to Kubernetes costs little.

What running it well requires

A Kubernetes cluster that is itself well operated:
  reliable control plane
  understood node lifecycle
  working monitoring independent of Ceph
  a recovery path that does not require Ceph

Requirement	Why
Dedicated storage nodes or node affinity	prevents storage competing with workloads
Local persistent volumes or raw devices	OSDs need real devices
Understood pod eviction behaviour	an evicted OSD is an OSD failure
Priority classes on Ceph daemons	prevents eviction under pressure
Node labels reflecting failure domains	CRUSH depends on them
Monitoring outside the Ceph-backed storage	so a storage problem is visible

spec:
  placement:
    all:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: storage-node
                  operator: In
                  values: ["true"]

Situations where it is a poor fit

Situation	Why
Storage serves several independent consumers	Kubernetes becomes a dependency for all of them
Kubernetes is itself new to the team	two systems to learn simultaneously
Strict storage availability requirements	the dependency adds a failure mode
Very large clusters	operational complexity compounds
Regulatory separation between storage and compute	the model conflicts

Planning a deployment

1. Dedicate nodes for storage, or accept the contention
2. Ensure the devices are raw and available
3. Label nodes to reflect the physical failure domains
4. Set priority classes on all Ceph daemons
5. Configure the CephCluster CR with explicit placement
6. Verify monitoring does not depend on the storage being managed
7. Test the recovery path with the storage unavailable

# Substitute your own value before running:
NODE=k8s-worker-03

kubectl label node "$NODE" storage-node=true
kubectl label node "$NODE" topology.kubernetes.io/zone=zone-a

Quiz

Knowledge check · 4 questions

Q1. Why is pod eviction a significant concern in a Rook deployment?

An OSD is a pod, so node pressure eviction, preemption, and drains each produce an OSD going down and trigger Ceph failure handling Evicted pods lose their data, because an OSD's BlueStore device is a container filesystem discarded on eviction Rook cannot restart an evicted OSD, since its device stays claimed by the node it was evicted from Eviction corrupts the OSD store, because the pod receives SIGKILL before BlueStore has a chance to flush its deferred writes to the device
Q2. Placing the monitoring stack on Rook-provided storage is acceptable since Ceph is highly available.

True False
Q3. Plan a Rook deployment.

A team will deploy Rook to provide storage for their Kubernetes cluster. The nodes also run application workloads and no priority classes are configured.
Q4. What is the strongest situation favouring Rook?

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

Production discipline

Place the monitoring stack on storage independent of Rook — a Ceph problem otherwise takes down the tools needed to diagnose it. Set priority classes on every Ceph daemon; without them an OSD is evictable under exactly the pressure that also moves workloads.

Cross-course references

Kubernetes: self-hosted storage requires priority classes and dedicated nodes to be stable
Linux: diagnostic tooling must not depend on the subsystem it diagnoses