This article is based on a summary originally published on computerweekly.com. Technical details reflect the state of the Rook project as described in the original source, circa early 2020.
What Is Rook?
Rook (think chess piece, not bird) is an open-source, cloud-native storage orchestrator that runs inside a Kubernetes cluster. Its core proposition is simple but powerful: take the same principles of containerisation and declarative orchestration that Kubernetes applies to compute workloads, and apply them to storage.
Rather than treating storage as an external dependency bolted onto a cluster, Rook provisions, manages, and heals storage resources from within the cluster itself. The result is software-defined, containerised storage that is portable, programmable, and tightly integrated with Kubernetes primitives such as PersistentVolumeClaims (PVCs) and StorageClasses.
At the time the original source was written, Rook had reached version 1.2 and had graduated to incubating-project status within the Cloud Native Computing Foundation (CNCF).
Why Containerise Storage?
The defining benefit of containerisation is abstraction: decoupling an application from the specific hardware it runs on. Kubernetes extends this by letting teams deploy, scale, and manage workloads dynamically across on-premises infrastructure and cloud environments.
Storage has historically lagged behind this model. Compute could be ephemeral and portable; storage remained tied to specific hardware, arrays, or cloud-provider APIs. Rook closes that gap by treating storage backends as Kubernetes-native resources, managed through the same declarative YAML manifests, operators, and automation pipelines already familiar to platform teams.
Supported Storage Backends
Rook acts as an orchestration layer over multiple storage providers. Its primary and most mature integration is with Ceph, the open-source software-defined storage project (maintained by Red Hat, which was acquired by IBM in 2019). Ceph supports block, file, and object storage, making it a versatile backend for a wide range of workloads.
Beyond Ceph, Rook (at the time of original publication) also supported or was developing support for:
- EdgeFS – A globally distributed file system built on object storage, with file, block, and S3-compatible access methods.
- NFS – Network File System server access for traditional file-sharing use cases.
- MinIO – An S3-compatible, high-performance object storage server.
- Apache Cassandra – NoSQL database managed as a data service.
- CockroachDB – Distributed, cloud-native SQL database.
- YugabyteDB – Distributed SQL database designed for cloud-native environments.
It is worth noting that Rook is not designed to front commercial storage arrays or cloud-provider storage services. Its value lies in the orchestration intelligence it provides — replacing the role of a proprietary storage controller with open-source, Kubernetes-native management.
How Rook Works Inside Kubernetes
Rook’s architecture centres on a Kubernetes Operator. The operator continuously monitors the state of storage resources within the cluster and reconciles actual state with the desired state declared by the administrator. Key automated tasks include:
- Scheduling and deployment of storage pods across cluster nodes.
- Bootstrapping and configuration of storage clusters (for example, a Ceph cluster).
- Scaling storage capacity as demand grows.
- Load balancing across storage nodes.
- Disaster recovery and healing — detecting and replacing failed or corrupted disks automatically.
- Lifecycle management — cloning, maintenance, and decommissioning of storage resources.
From a developer and platform-engineer perspective, Rook integrates with standard Kubernetes storage constructs. Storage is exposed via StorageClasses, and applications consume it through PersistentVolumeClaims — the same workflow used with any Kubernetes storage provider. Bootstrapping a Rook-managed Ceph cluster can begin with a small number of kubectl apply commands, after which the operator takes over ongoing management.
Deployment Models: Hyper-Converged and Hyper-Scale
Rook supports two primary architectural models:
- Hyper-converged – Storage and compute run on the same cluster nodes. This suits environments where you want to minimise infrastructure footprint and manage everything through a single Kubernetes cluster.
- Hyper-scale – Storage scales independently across many nodes, appropriate for large-scale workloads with significant or unpredictable storage demand.
Benefits of Using Rook
For teams already committed to containerisation and Kubernetes, Rook offers several concrete operational advantages:
- Programmable storage – Developers and platform engineers define storage requirements in code, enabling storage-as-code workflows.
- Horizontal and vertical scaling – Add capacity by adding nodes or disks; the operator handles redistribution.
- Automated volume provisioning – Pods receive persistent volumes quickly and automatically without manual storage administrator intervention.
- Self-healing – Failed disks are detected and replaced automatically, reducing operational toil.
- Portability – In principle, workloads and their storage can be moved between on-premises clusters and cloud environments, though storage-backend compatibility remains a practical constraint.
- Unified operational model – Teams use the same Kubernetes tooling (kubectl, Helm, GitOps pipelines) to manage both compute and storage.
Limitations and Considerations
Rook is a compelling approach, but there are genuine limitations to weigh before adopting it:
- Maturity and production readiness – At the time the original source was written, Rook had production users but remained in early stages. Some storage backends were more mature than others. Always check the current CNCF project status and backend-specific stability before deploying to production.
- Incomplete storage-type support – Not all storage backends were fully supported, and coverage of commercial arrays and cloud-provider storage was not a project goal.
- Operational complexity – Rook simplifies day-2 operations significantly, but initial setup — particularly for Ceph clusters — has a non-trivial learning curve. Teams unfamiliar with distributed storage systems should invest in training.
- Not a replacement for all storage use cases – Workloads requiring very high I/O performance, specific compliance guarantees, or deep integration with vendor hardware may still be better served by dedicated storage solutions.
Rook’s Position in the Cloud-Native Ecosystem
Rook’s inclusion as a CNCF incubating project reflects a broader industry recognition that storage must become a first-class citizen in cloud-native architectures, not an afterthought. Its operator model aligns closely with Kubernetes patterns that the industry has standardised on, making it easier to extend and maintain over time.
For organisations investing heavily in Kubernetes — whether on-premises, in the cloud, or in hybrid configurations — Rook represents a logical next step: completing the containerisation story by bringing storage under the same declarative, automated, and programmable management model applied to everything else in the stack.
Getting Started
The official Rook documentation at rook.io is the authoritative source for current installation instructions, supported backends, and version-specific guidance. The quickstart guides for Ceph are a practical starting point for most teams. As with any infrastructure component, test thoroughly in a non-production environment before rolling out to production workloads.
Original source summary: Computer Weekly. Published on bestdevops.com, March 2020.