Rook is a storage orchestrator for Kubernetes. It runs as an operator that deploys and manages a storage system inside the cluster, most notably Ceph, and exposes it through standard Kubernetes objects: a custom resource describes the storage cluster, and StorageClasses let applications claim block volumes, shared file systems and S3-compatible object buckets. It addresses the operational weight of running a distributed storage system: deployment, scaling, failure recovery and upgrades are expressed as reconciliation loops rather than runbooks, so storage follows the same declarative model as the workloads that use it. Rook was donated to the CNCF in 2018 and became an incubating project in September 2018. It graduated on October 7, 2020, as the thirteenth CNCF project and the first storage project of the block, file and object kind to do so.
CNCF daily · Sprint 1, day 4 · Cloud Native Storage
At a glance
| Category | Cloud Native Storage |
| CNCF status | Graduated. Incubating since September 2018; graduated October 7, 2020 |
| Written in | Go |
| License | Apache 2.0 |
| Storage provided | Block (RBD), shared file system (CephFS) and object storage (S3 and Swift APIs through the Ceph Object Gateway) |
| Storage backend | Ceph, which Rook deploys and operates |
| Interface | Custom resources such as CephCluster, CephBlockPool, CephFilesystem and CephObjectStore, plus CSI drivers |
| Recent release line | 1.19, released in January 2026, with regular patch releases |
Architecture
flowchart TB
APP[Application pods<br/>PVC or bucket claim] --> CSI[Ceph CSI drivers<br/>RBD and CephFS]
APP --> RGW[Object gateway<br/>S3 endpoint]
OP[Rook operator<br/>watches custom resources] -->|creates and reconciles| CL
subgraph CL[Ceph cluster on Kubernetes]
MON[Monitors<br/>3 for quorum] --- MGR[Manager<br/>dashboard and metrics]
MGR --- OSD[OSDs<br/>one per disk]
OSD --- MDS[MDS<br/>CephFS metadata]
end
CSI --> CL
RGW --> CL
OSD --> DISK[Raw devices<br/>on worker nodes]
MGR --> MON2[Prometheus and Grafana]
OP --> UP[Upgrades<br/>rolling by component]
| Component | Responsibility |
|---|---|
| Rook operator | Watches Rook custom resources and creates, scales, heals and upgrades the Ceph daemons to match them. |
| CephCluster resource | Declares the cluster: Ceph version, monitor count, which nodes and devices provide storage, networking and placement. |
| Monitors (mon) | Keep the cluster map and quorum. Three or five are typical, spread across failure domains. |
| OSDs | One daemon per storage device, storing data and replicating or erasure-coding it. |
| Manager (mgr) | Runs the dashboard, metrics endpoint and cluster orchestration modules. |
| MDS and RGW | Metadata servers for CephFS, and object gateways that serve S3-compatible APIs. |
| Ceph CSI drivers | Provision and attach block and file volumes to pods through the standard CSI interface. |
| Pool and store resources | CephBlockPool, CephFilesystem and CephObjectStore resources create the logical storage that StorageClasses point to. |
Design principle. Rook applies the operator pattern to storage: the desired state of the storage system is a Kubernetes resource, and a controller continuously makes the real cluster match it. Ceph still does the data work, with its own replication and self-healing, while Rook handles lifecycle and integration with Kubernetes, so the cluster can be created, expanded and upgraded through the same Git-driven workflow as any other platform component.
Production reference design
A common pattern on bare metal and on-premises Kubernetes, where no cloud block storage is available, and also on cloud clusters that need a shared file system or object store:
- Prepare the nodes. Use at least three worker nodes with raw, unformatted disks or partitions dedicated to Ceph, and a recent Linux kernel with the RBD module. Keep storage nodes separate from latency-sensitive application nodes where possible, and use a fast network between them.
- Install the operator with its Helm chart, selecting a current release:
helm repo add rook-release https://charts.rook.io/release helm install --create-namespace --namespace rook-ceph rook-ceph rook-release/rook-ceph - Declare the Ceph cluster. Pin a supported Ceph version from the Rook documentation and select devices explicitly rather than using every disk:
Check the API fields and Ceph image tag against the Rook release you install.apiVersion: ceph.rook.io/v1 kind: CephCluster metadata: { name: rook-ceph, namespace: rook-ceph } spec: cephVersion: { image: quay.io/ceph/ceph:v19.2.3 } dataDirHostPath: /var/lib/rook mon: { count: 3, allowMultiplePerNode: false } mgr: { count: 2 } dashboard: { enabled: true } storage: useAllNodes: true useAllDevices: false deviceFilter: "^nvme[0-9]n1$" - Create a replicated pool and a StorageClass so applications can claim block volumes:
apiVersion: ceph.rook.io/v1 kind: CephBlockPool metadata: { name: replicapool, namespace: rook-ceph } spec: failureDomain: host replicated: { size: 3 } --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: { name: rook-ceph-block } provisioner: rook-ceph.rbd.csi.ceph.com parameters: clusterID: rook-ceph pool: replicapool csi.storage.k8s.io/fstype: ext4 csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph reclaimPolicy: Delete allowVolumeExpansion: true - Add file and object storage when needed with CephFilesystem and CephObjectStore resources, and expose the object store through an ingress or Gateway.
- Monitor and protect it. Scrape the Ceph manager metrics with Prometheus, alert on health warnings, near-full OSDs and slow operations, and take volume snapshots through the CSI snapshot API, with off-cluster backups for critical data.
Typical production uses include persistent volumes for databases and stateful services on bare metal, a shared ReadWriteMany file system for applications, in-cluster S3 storage for backups and artifacts, and storage for on-premises and edge Kubernetes clusters.
Operational considerations
- Ceph expertise still matters. Rook automates operations but does not hide Ceph. Placement groups, CRUSH rules, recovery behaviour and capacity planning are still part of running the cluster.
- Size hardware deliberately. Plan for at least three failure domains, fast disks and a dedicated, low-latency network. Under-provisioned CPU, memory or network is the most common cause of slow or unstable clusters.
- Protect against data loss. Use three-way replication or erasure coding across hosts or zones, keep the cluster below its near-full thresholds, and keep backups outside the cluster, since a shared storage cluster is a shared failure domain.
- Upgrade in order. Upgrade the Rook operator first, then Ceph, following the documented sequence and checking cluster health between steps. Test upgrades outside production.
- Handle disks and deletion carefully. Rook claims raw devices, and removing a cluster does not wipe them by default. Follow the cleanup procedure before reusing disks, and set resource limits for daemons.
Adoption
- The CNCF graduation announcement named Calit2 at UC San Diego, Finleap Connect and Geodata as production users, and referred to many more in the project’s adopters file.
- The same announcement quoted Replicated, which uses Rook to manage Ceph and provide highly available block and object storage.
- The graduation announcement reported that the core repository’s contributors grew from 90 to 279 between September 2018 and October 2020, and that the maintainer team included people from Cloudical, Nexenta, Red Hat, SUSE and Upbound. The project completed a CNCF security audit in December 2019.
Alternatives
| Solution | Model | Best suited to |
|---|---|---|
| Longhorn | Distributed block storage built for Kubernetes | Simpler replicated block volumes on small and mid-sized clusters |
| OpenEBS | Container-attached storage with several engines | Local and replicated volumes with a lighter footprint |
| Portworx | Commercial software-defined storage | Enterprises that want vendor support and data services |
| Cloud block and file services (EBS, Persistent Disk, EFS, Filestore) | Managed storage through CSI drivers | Cloud clusters that do not want to run storage |
| Standalone Ceph (cephadm) | Ceph managed outside Kubernetes | Dedicated storage teams serving several clusters |
Strengths and limitations
| Strengths | Limitations |
|---|---|
| Block, file and object storage from one system | Ceph is complex, with a steep learning curve |
| Automated deployment, healing and upgrades through the operator | Needs several nodes, raw disks and a good network to perform well |
| Runs on bare metal, on-premises and cloud clusters alike | Storage and compute share failure domains unless nodes are separated |
| Mature project backed by Ceph’s self-healing data layer | Upgrades and recovery need care and Ceph knowledge |
| Standard Kubernetes interfaces: CSI, snapshots and StorageClasses | Heavier than lightweight alternatives for small clusters |
Recommendation
Adopt Rook with Ceph when you run Kubernetes on bare metal or on-premises and need block, shared file or object storage in the cluster, and when you have the hardware and the skills to operate it. For small clusters or cloud environments where managed storage exists, Assess Longhorn or the provider’s CSI drivers first, since they are simpler to run. Whichever you choose, test failure and upgrade scenarios before production and keep backups outside the storage cluster.
References: CNCF project page · CNCF: Rook graduation announcement · Rook documentation · Rook on GitHub · Ceph documentation